  |
はてなキーワード: ソースコードとは
女とコンパイラは意外と似ているのではないだろうか
おめー、セミコロンが文末にないやろ、とか言いがかりをつけられても、
文法はどこも間違っていなくて、
よくわからんが、MSのコンパイラはUTF-8のソースコードも勝手にShift-JISに解釈するらしくて、
Visual Studioは「ビジュアル」なはずなのに、
わざわざプロパティーダイアログ開いて、コマンドラインに書くオプションをそのまま書かされて、
なんか不満をもらしたり、言いがかりをつけてきても、
女も客とか上司とかも、本音の部分はどこか別のところにあって、
わざと本音を隠してるのなら人として？まだ分かるのだけど、
意外と多いのは、本人自身も不満の原因の場所をちゃんと理解しておらず、
頓珍漢な場所について文句をたれるので、そういう人はほんとに困る
でも、意外と多い
わざとはぐらかすにしろ、自分で自分自身を理解できてないにしろ、
まあ、わざとだろうが不愉快だが、わざとの方はまだ頭がいい
せめて「ユーザー目線でどうなるのが正しいか」くらいはドキュメントを残してくれ。
どうなって欲しいのかが分からんから、どう修正するべきかも分からん。
ご指摘ありがとう。ごめん「GPUに直接」って書き方が悪かった。だったらディスプレイ出力すらできないよねって話になるよね。DirectXの説明しても99.999%の人にはなんのこっちゃだろうから「直接」って表現をしたまでよ。言いたかったのはProtonの発表が2018年で、ごく最近のことだっていうこと。「これは恥ずかしい」っていうタグでわざわざ畳みかけるように指摘されてるのは、それを専門にしている開発者の矜持なんでしょうな。いい仕事してそう。
ValveがWindowsゲームをLinuxで動かす互換レイヤー「Proton」を発表
2018.08.23
PCゲームプラットフォーム「Steam」でおなじみのValve社が8月21日、Codeweavers社と共同開発したWindows専用ゲームを動かせる互換レイヤーを発表した。この互換レイヤー 「Proton （プロトン）」はLinuxユーザなら誰もが知っているWineを改造したもののようだ。
Protonはかなりの改造を施されており、いろんなところからかき集めたプログラムや技術が詰め込まれている。
ProtonにはDirectX APIコールをリアルタイムでVulkanのそれに変換するレイヤー（DXVK）が組み込まれているため、DirectX APIで作られたゲームでも割と軽快に動作する。
もともとVulkanとDirectXには機能的にそこまで大きな違いがないためだろう。相互に移植するのも難しくはないと言われている。
またOpenVRへの対応や ゲームのフルスクリーンモードの取り回しを改善、Steam対応のコントローラのサポートも改善している。
ProtonはオープンソースとしてGitHubに公開されているので誰でも中身を見ることが出来る。ベータの段階でこんなにいろんなプログラムをSteamに統合できたことに驚いたが、2年の開発期間を要したそうだ。
https://slacknotebook.com/valve-releases-compatibility-layer-for-linux-proton/
SteamユーザーがLinuxに切り替えても不自由なくゲームを楽しめるよう開発された「Proton」でプレイできるタイトル数が1万2000本を突破
PCゲームの販売プラットフォームとして絶大な人気を誇るSteamを開発するValveは、Windowsユーザー以外にも幅広くPCゲームを遊んでもらうために、Windows向けのゲームをLinux上でもプレイできるようにするためのオープンソースソフトウェア「Proton」を開発しています。
ProtonDB | Gaming reports for Linux using Proton and Steam Play
2018年8月にリリースされたProtonは、Steamの開発元であるValveとソフトウェア開発企業のCodeWeaversが共同開発しているソフトウェア。ProtonのベースとなっているのはUNIX系OSでWindows向けのソフトウェアをネイティブ動作させるために作成されたWineであるため、ProtonはWineのフォークとも言えます。なお、Protonはオープンソースのソフトウェアであるため、ソースコードはGitHub上で公開されています。
そんなProtonに関するデータをまとめたデータベースがProtonDBで、同サイトでは「Protonでのゲームプレイに関するレポートの総数」「レポートが提出されたタイトル数」「Protonを用いることで何かしらの修正なしにLinux上ですぐにプレイが可能になるゲーム(プラチナゲーム)数」がまとめられています。
2020年4月時点ではProtonで問題なくプレイ可能なプラチナゲームの数は6502本で、Steam上でリリースされているゲームの約50％がプラチナゲームとしてLinuxでプレイ可能でした。
SteamのゲームをLinuxでもプレイ可能にする互換レイヤー「Proton」のこれまでの功績とは？ - GIGAZINE
2020年12月8日時点でのプラチナゲームの数はさらに増えており、その数は何と1万2753本にまで増加しています。なお、「Protonでのゲームプレイに関するレポートの総数」は10万4508件、「レポートが提出されたタイトル数」は1万6232本です。
なお、Protonはバージョン5.13が2020年11月にリリースされたばかり。アップグレードのリリース時には、CodeWeaversのJames Ramey社長がProtonプロジェクトや会社の現状について語っています。
Podcast With James Ramey - Full Transcript - Boiling Steam
https://boilingsteam.com/podcast-with-james-ramey-full-transcript/
Protonのバージョン5.13では、ゲームの互換性に関する問題で大きなネックとなってくるアンチチートソフトウェアを回避するプロセスについて前進を見せているとのこと。ただし、ゲームが搭載するアンチチートソフトウェアとProtonの戦いは、Protonのリリース当初から続いている問題であるため、バージョン5.13で完全決着を見せるというものではなく、今後も戦いが続いていくこととなる模様。なお、次の次のアップグレードもしくはさらに次のアップグレードあたりで「NTDLLによりブロックされているゲームがプレイできるようになる」とRamey社長は言及しているため、Protonでプレイできるタイトルの数がより増えることなりそうです。
また、2020年に猛威を振るった新型コロナウイルスのパンデミックについて、Ramey社長は「幸い我が社はかなり分散した企業です。我々の開発チームの多くは西ヨーロッパ、東ヨーロッパ、アジアに拠点を置いているため、すでに在宅勤務を行っています。ミネアポリスにあるオフィスでは25人の従業員が働いていましたが、これも在宅勤務へと移行しています。通常時、我々は定期的にオフィスへ通っていましたが、2020年3月の第2週以降は1度オフィスに行ったきりです。元々リモートで仕事がこなせるように会社を設立したため、生産性の観点でいえば、新型コロナウイルスによる影響は皆無です。また、新型コロナウイルスの検査で陽性反応が出た従業員が何人かいたので、その従業員たちは必要に応じて休暇を与えました」と語りました。
さらに、Protonの登場によりLinuxをネイティブでサポートするゲームタイトルがSteam上から減少しているという指摘もあります。以下はSteam上で配信されているゲームタイトルのうち、ネイティブでLinuxに対応しているタイトルの数を示したグラフ。Protonがリリースされた2018年8月以降、明らかにLinuxをネイティブでサポートするタイトルの数が減っています。
これについてRamey社長は「Protonが提供するのは『Linuxでのゲームプレイ』という体験だけでなく、ゲーム開発者がLinux市場に簡単にアクセスできるようになるという機会でもあります。すでにリリースされているWindows版のゲームが、Protonを使用することで再開発なしで第二の市場に投入することが可能になるのですから」と語り、Protonの登場によりゲーム開発者がより手軽にLinuxユーザー向けにゲームを提供できるようになった点が関係ないとは言い切れないと主張。
特にゲームエンジンにUnreal Engineを使用していない開発者は、再コンパイルや変更なしで簡単にゲームをWindows市場だけでなくLinux市場にも投入できることをRamey社長は強調しています。また、Linuxにはさまざまなディストリビューションが存在するため、Linux市場で幅広いユーザーを狙ってゲームを販売することは非常に困難であるとRamey社長。その一方で、Protonを使用すればWindows向けにゲームを開発している開発者が、手軽かつ多くのユーザー向けにLinuxで動作するゲームを提供できるとしています。
また、ますます多くのゲーム開発者がProtonに気づき始めているそうで、Ramey社長は「まだ大騒ぎという段階にはありませんが、多くのインディー開発者がProtonに注目し始めているというだけでなく、大規模なゲーム開発者の多くもProtonに興味を示しています。その大きな理由は非常に低コストで別の市場にアクセスできるという点です。そのため、今後より多くのゲームがProtonで不自由なくプレイできるようになると思います。また、開発者が開発プロセスの段階でProton上でテストを行えるようになる可能性もあるでしょう。そのため、どこかのタイミング(転換点)で『ゲームが機能するかについてProtonの開発元であるCodeWeaversに問い合わせる必要性』が大幅に減少することを期待しています。我々が行っている多くの事柄は、そのための基盤を構築することです」と語りました。なお、Ramey社長は転換点が「今後12カ月以内にやってくる」とも主張しています。
「Githubは、めっちゃ怖い」と、言うと「また情報漏洩か」と思われそうなんだけど。
実は、以前、FPSゲームの公式公開されているステータスに関する便利ツールのソースコードが落ちてないか、Githubで「ゲーム名」を検索したことがあるだ…。
そこで、知ってしまっただが…これ闇ですね。
これの件について、英語圏の連中以外知っている奴いるのか？と思って、ググったら、5chの某スレ連中が、ボロボロやべぇこと書いてて、この世の闇を垣間見てしまった気がする…。
ちょっとググってて分かったけど、マルウェアのソースコードが載っていることもあるという記事を見つけて、ひょぇとなったし。
マジ、Github、怖いところだ。
しかし本論文は言語学だけではなく、分子生物学と考古学の視点からも考察を行っており、特に分子生物学の成果が大きい。
2010年代以降の考古遺伝学の発達はまさに革命といってもよい。2010年代以降と以前では別物と言っても過言ではない。（この発展については「交雑する人類」を読むと良い）
解析方法の発展と古代人骨の収集によるデータの発展が両輪となって、現代の考古遺伝学はほぼ数理科学となっておりこの論文でもデータセットとソースコードが公開されている。
そこには特に異論はないというか、専門外すぎて口出しできない（『交雑する人類』、日本語版が出た直後に読んだけど面白いよね）。「少なくとも言語学の側面からは」と書いたことからわかってもらえてると思うけど、分子生物学とかそのへんの研究成果について否定するつもりは毛頭ないのよ。
ただ、言語学の見地からは証拠が弱いけど、分子生物学とかで補強しまーす！ って言われると、いやいやまずは言語学の見地で証明するのが先やろが、って話になっちゃう。ロベーツさんが自分の「トランスユーラシア大語族」仮説の脆弱さを分子生物学とかの虎の威を借りて誤魔化してるようにしか見えんのよ。
それは「日本人」の原郷であって「日本語」の原郷ではないやんけ。
遺伝的系統と言語的系統はまったく別よ。極端な例だけど、スウェーデンの白人とフィンランドの白人は遺伝的にアメリカの黒人より全然近いけど、言語的にはスウェーデンの白人（印欧語族ゲルマン語派スウェーデン語）とアメリカの黒人（印欧語族ゲルマン語派英語）の方が近くてスウェーデンの白人とフィンランドの白人（ウラル語族フィンランド語）はめちゃめちゃ遠いじゃん（スウェーデン語系フィンランド人とかオーランド諸島とかそういうのはひとまず忘れといてねｗ）。
もちろん古代の話だから、ヒトという乗り物に乗って言語も一緒にやってきた、と仮定するのが無理のない話だろうし、言語学的に想定された原郷と古人類学の観点から突き止められた原郷が一致するなら「なるほど原日本人＝原日本語話者の原郷はここなんだな」という結論になるだろうけど、言語学的に穴だらけの仮説を補強するのに古人類学の成果を持ってくるのは話の順番が違うっしょ。
ちなみに言語学的な原郷が遼河流域という説自体は、個人的にはそれなりに「ありそう」だなと思ってる。大陸倭語の存在もあるから古代の朝鮮半島に日琉語が分布してたのは事実っぽいし、さらに、五十嵐（2021）は関東から東北にかけてを覆う「拡大東日本語派」と九州から沖縄まで連なる「南日本語派」がマトリョーシカ分布を示すことを指摘して、本州西部から四国あたりの地域に日本語の原郷を求めてるけど、仮に日本語の祖先が朝鮮半島から入ってきたとすると「なるほどそこから列島に入ってきたんだな」という感じで辻褄が合うんだよね。ただこれはなんの証明もできない妄想であって、もっとちゃんとした言語学的な証拠が必要だけど。
https://anond.hatelabo.jp/20211029215655
Android初期の失敗はここに十分詳しく書かれているので、余計なおまけとしてAndroidとiPhone対立煽りで会話が噛み合わない原因について書く。
AndroidはAndroid Open Source Project、略してAOSPと呼ばれる枠組みで開発されていて、誰でもソースコードをDLして改造することができるようになっている。
メーカによって改造されたAndroidがカーナビやTVやその他のデバイスに搭載されていることは、一般の人でもなんとなく知っていると思う。
ホーム画面には謎のキャラが我が物顔で走り回ることでユーザのタップを阻害し、d〇●・d●○という専門家にしか見分けがつかないアプリがプリプリプリプリ垂れ流されている。
頻繁に鳴る通知は使いもしないアンインストールもできないプリインアプリからのもので、肝心の自分が使っているアプリからの通知はそれに押し流される。
目的も定かではないOSへの改造によってデバイスのリソースは使い切られ、ユーザが使えるのはそのおこぼれでしかない。
そんなザマだからキャリアのAndroidの操作感は悪い。日本人がAndroidを投げ捨ててiPhoneに走るのも当然である。
なぜかといえば、iPhoneという競争相手がいる中で、Androidで金を稼いで飯を食う人たちによって日夜開発されているからである。
当然ながら出来が悪ければ稼ぎは少ない。実際に金を払って使用するエンドユーザではなくどこか壁に貼られたポスターとかを見ているキャリアと違って、彼らはユーザの反応をフィードバックして改善しているのである。使う人のことを考えた使いやすいものを作っているのである。
が繰り返される原因はここにある。
品質が一定水準を超えればあとは好みの問題なのだが、Android絶対否定派は魔改造されたキャリアのAndroidしか知らず、本来のAndroidを知らないのである。
「（キャリアの）Androidはダメ、iPhoneしか選択肢はない」
というのが正しい。
元記事のキャリアをやり玉に挙げたが、3大キャリアはどれもAndroidを「キャリアのAndroid」にしている。
生活費の内訳に通信費が必ず計上されるようになったこの時代において、金を払っているユーザに独自の改造を押し付けることで、日本人をどれだけ消耗させてきたことか。
というか普通に自分で触ればわかるだろ！！？！？！使いづらいんだよ！！！！！！！素のAndroid触ってごめんなさいしろ！！！！！！！！！！！！！！！
Youtubeやアマプラのために6万以上するデバイス買うやつ頭おかしい。Fireでいいやろ。
かく言う自分もipadminiは新しいのを買ったが、目的は以下の通り。
こういうスマホでは代替しにくい用途がメインで、さらにKindleや安いAndroidでは処理が追いつかない用途で使ってて今のところ、満足してる。
アマプラやYouTube見るためなら完全にオーバースペック。
これはiPhone13でも同じ。動画や望遠レンズ活用、暗所撮影をやらないのに、pro買うやつ、養分すぎる。
え？ゲームに使う？
え？バッテリー持ちが？
今日も使われてないソースコードの文脈を読み取りながら、サーバーのバージョンアップで変更される仕様に合わせて動くように書き直す仕事をする
10年以上前に誰かはわからない人よって作られた、既に使われていない処理
これっていつまで保守し続けるんだろう
使わなくなったらさっさとコード削除して欲しいんだけど、なんで削除しないんだろう
削除しないので無駄な作業が発生してるんだけど、会社的には無駄とは思っていないのだろうか
ブルシットジョブだよなぁ
よく考えたら負債を返済すらしてないな、負債が膨らみ続けてついには、利子の返済だけで一杯一杯になってるのが現状である
密結合とか疎結合とか、基本のきだと思ってたけど、何が何に影響を与えてるのかわからないコードの編み目はさながら身体の隅々を侵し尽くすガンといった様相で、それを直すでもなく、場当たり的対処に止まる私もまた、この会社のガンなのかもしれない
悪の帝国 Oracle が Java を有償化し重税を課そうとしたその時、正義の勇者 Amazon が立ち上がり新しい Java 実装 Corretto を無償で広めて救ったのだ！
……という情弱が好きそうなデマがあるんだが、こんな陳腐なシナリオに喜んでいるようではインチキなテック系 YouTuber に食い物にされてしまうぞ☆
Oracle レジスタンスはいた。彼らは Oracle の中に潜んでいたんだ。
時は2005年に遡る。
Java を開発した 米 Sun Microsystems は赤字にあえいでいた。
2004年に Java 5 (目玉機能はジェネリクス) がリリースされてしばらくの頃だ。
この頃、ひとつのオープンソースプロジェクトが立ち上がる。名を Apache Harmony という。
開発は2005年5月に開始され、2006年10月には Apache 財団のトップレベルプロジェクトとなった。
Sun は多数の企業をまきこみ、いろんな企業に Java™ をライセンスしていた。
Java の実装は Sun が持っていたが、各社が独自に実装したり、Sun と契約してコード提供を受けたりしていた。
Java™ を名乗るためには Technology Compatibility Kit (TCK) という互換チェックをパスしなければならない。
初期の Java はオープンソースではなかった。誰もが自由にコードを参照し用いることができるものではなかったんだ。
これをオープンソース化しようという野心で始まったのが Apache Harmony プロジェクトだ。
Java の実装をいちから書き起こしオープンソースの代表的な Apache License Version 2 ライセンスで提供したのだ。
しかし、Sun は Apache2 ライセンスを良しとせず、Harmony に Technology Compatibility Kit (TCK) を受けさせなかった。
なるほど。彼らが Java をオープンソース化したレジスタンスだったわけか？
違う。話はそんなにシンプルではない。
2006年 Sun は Java をオープンソースにする意志があると発表した。
Sun は Java を リンク例外付きの GNU General Public License でオープンソース化することにした。
Harmony のライセンスは自由な改変を認めるものだった。
OpenJDK のライセンスは派生物を作ったなら、そのソースコードの公開義務がある、という点が大きな違いだった。
OpenJDK は出た当初はまだ Sun の JDK との非互換が多かった。しかしこれが現代まで続く OpenJDK の始まりだったのである。
2007年11月 GoogleがAndroidを発表した。 Android は Java 言語で開発することができる。
そのベースとなったのは Sun との火種くすぶる Apache Harmony だった。よりにもよって！
(後にGoogleが負けて賠償し、現在のAndroid は OpenJDK ベース)
その渦中、赤字に喘いでいた Sun はついに身売りを決断する。2009年のことである。
当初 IBM との交渉が報じられていたが金額で折り合わなかったようだ。
そこに颯爽とあらわれたのが Oracle である。 Oracle が Sun Microsystems を買収することになった。
しかし Oracle にはよくない噂がある。敵対買収してプロダクトを潰してしまうという黒い噂だ。
Sun の Java も Oracle に食い物にされてしまうんじゃないか、いわゆる 「悪のOracle」 のイメージはこの頃からのものだ。
しかし、 Sun はすでに Java をオープンソース化していた。 派生物もオープンソースにしなくてはならない OpenJDK で！
Oracle は Java を Sun 社ごと買ったが、 Java はすでに独り占めできるようなものではなかった。
Sun 本家の JDK を引き継いだ Oracle JDK と、OpenJDKがついに統合される。
Oracle がソースコードを OpenJDK に寄贈し、 Oracle JDK も OpenJDK ベースとなった。
ここに OpenJDK への移管は完全となり、Javaのオープン化は成就した。
それまでの OpenJDK は Oracle JDK との非互換が不安視されていたわけだが、Java11 からはその不安もなくなった。
こうして完全にオープン化された Java は、各サードパーティーからディストリビューションが出るようになった。
Java11 での Java のオープン化を経て、Javaはディストリビューション乱立時代へと突入する。
Amazon Corretto もそうした OpenJDK の派生ディストリビューションのひとつである。
OpenJDK の開発は今なお Oracle が主力となって牽引している。
Java を解放しようとしたレジスタンスは、赤字に喘いでいたSunの中にいた。
たとえ Sun が身売りをすることになろうとも、Java を邪悪な独裁者の手に渡さないように。
Sun が倒れてしまう前に Java はオープン化された。Javaの仕様策定は Java Community Process (JCP) にて行われる。
Javaの仕様策定は Oracle の独断で進めることはできない。 OpenJDK の開発も Oracle の独断ですることができない。
GNU General Public License でオープンソース化された Java は、派生物のライセンスもGPLが強制されソースコードを公開しなければならない。
そんな OpenJDK をリリースした、当時の Sun の中の人達こそがレジスタンスだったんだ。
Oracle はそんな Java を、そういう存在だと分かって Sun ごと買った。
Kinzaのパッチが当たった正式版が公開されたので、引き続きこき下ろす。
この間 https://anond.hatelabo.jp/20210828113740 を書いたが、DuckDuckGo経由で無事作者に見つかってしまったらしく、ここで指摘を入れた誤字、インストール場所、公開ソースコードのREADMEが全てではないが直ってた。ここ以外にもアンチがそれなりにいるみたいで、作者のTwitterを見る限りメンタルが削られていたようだ。(あれだけTwitterでアンチコメントがあったのを知ってたのに、中途半端な覚悟でエゴサしたからじゃないの？と言いたいが)
アンチがあんなにいるのは人気がある証拠ではないか。もっといろんな人に知ってもらうまたとないチャンスだ。
誤解しないでほしいのは、こき下ろしているのは学生の合間に作った革新的で軽量なブラウザーが自称ではなく価値あるブラウザになることも期待しているからである。ブラウザ作る奴なんてほとんどいないから。
以前利用規約での遊びがひどすぎてふざけてんのかと書いたせいかは知らないが、アップグレードはちゃんとアップロードになっている、個人の感想がなくなっているなど、おふざけはなくなった。しかし、利用規約が以前と比べて長すぎる文章になってしまっている。しかも利用規約に書くべきではない内容はそのままどころか増えているし、もう少し整理できたのでは？
以前、「Ablazeの利用規約に沿って」という文に対してAblazeの利用規約をここに載せろと言ったが、掲載されたのはその利用規約ではなくプライバシーポリシーだった。「Ablazeの利用規約」は「Albazeのプライバシーポリシー」のことなのか？「Ablazeの利用規約」はホームページにも掲載されていないので、結局の所それに何が書かれているのかわからない。何が書かれているかわからない「Ablazeの利用規約」に同意しようがないので、この利用規約に真面目に従えばAblazeの関係者と同団体に盲信する人を除いてFloorpブラウザは規約上誰も使えない代物である。どうせ誰も見ないでスルーして使っているだろうが、きっちり書くべきところがきっちりできていないのは問題である。
所々「書いとけばいいんでしょ」感が出てしまっていて、ただでさえ読まれない利用規約をさらに読む気のしないものになっている。ここまで長くなったのなら、規約本文の見直しをした上でその中にあるプライバシーポリシーを分けた方が良くないか？工夫・配慮が足りない。リリース予定日に追われて、利用規約に割く時間がなかったのだろう。
それにしても、あれだけ長くなってもChromiumのライセンス情報が未だに書かれていないのはどういうことだろうか。著作権表示と許諾表示をドキュメントに書くことが条件になっているので、「BSDライセンスに従って」という書き方ではダメ。その表記で済ませるなら、ドキュメントファイルとかURLとかを明記しないと。Kinzaのパッチのことよりも憂慮するべきことではないのか(これも結構長いのでChromiumと同じようにすればよいのでは？)。
Kinzaのパッチをそのまま当てられるようにしたことで、バージョンがDevチャネル相当の95から89に大幅ダウン。Kinzaのパッチが公開されてからわずか2週間でリリースできたのはこれが理由だろう。Kinzaの言ってるとおり古いバージョンのままでは危険で、常用は避けるべきである。
ちなみに、https://developers-jp.googleblog.com/2021/04/chrome.htmlの通り、Chrome94からメジャーバージョンアップの頻度が6週間から4週間になるらしいが、メジャーバージョンアップについて来られるのかが疑問である。メジャーバージョンアップした正式版に期待が寄せられると思ったが・・・(次節に続く)
というツイートが。あれ？このブラウザって「Kinza派生系ブラウザ」だよね？たった1年ちょっとで終わりなの？
Chromiumのメジャーバージョンアップにかかる手間のことを全く考えていなかったようだ。Kinzaが終了した理由に開発継続に対するコストの問題があるって書いてあったのに。その意味が理解できていなかったのか。2022年まではやると言っているようだが、パッチ適用時のエラー量が多すぎて挫折しているのではないか？本業が学生なんだし、本業を優先するゆえにKinzaの後釜になれないのも仕方のないことだろう。というより、ブラウザ開発は本業と両立できるほど甘くないのでは？
2022年までの理由は、受験を控えているかららしい。受験は作者の人生を左右する大事なことなのでしょうがない面もあるが、Ablazeという非営利団体(?)にはそれをカバーする人が今はいないということも言える。要するに、2022年を過ぎるとメンテナンスする人が誰もいないことになる。早くもFloorpの将来性が危うい。
Fireminによる見せかけのメモリ使用量しか見ていないのは相変わらずのようで、大変残念。あれだけこき下ろしたのに懲りないね。
以前
なんて書いたら某動画で「変なこと言ってる」と言われたが、その動画でもやっぱりWindowsタスクマネージャーの一部分しか見てなくてお前もかよ。恥ずかしい人は作者だけじゃなかったわけだ。まあ仕方ないよ。Floorp軽い！って先に体感してしまってろくに検証せずそれで終わりにしたんだから。
たしかにメモリ圧縮の効果はあるからメモリ不足気味な低スペックPCなら有効かもしれない。けどな、Fireminを他のブラウザでも有効にしたら同じ効果が得られるぞ。ChromeなんかもWindowsタスクマネージャーのメモリの所を見たら数MBになるから。実際そこまで減らないけどな。
某落書きに書いてある
は全くその通り。そう思い込む奴が出てきた一因はこの間裁判に負けたギガなんとかが記事を書いたせい。あと前に言い忘れたけど、ページアウトするってことは、ページファイルへの書き込み頻度が上がってディスクの寿命を縮めるからメモリに余裕がある人はFireminは止めとけとだけ言っておく。
FloorpにはFFmpegのH.264とAACのデコーダが入っているが、それらは特許技術で保護されている。特許の入ったコードをバイナリで配布することに関して、FFmpegは特許侵害の責任は一切持たない方針をとっているので、一部の例外を除いて特許のライセンスを管理しているMPEG LAやVia Licensingとライセンス契約を結ばなければ特許侵害になる。
非商用ならライセンス料がかからないが、個人もしくは非営利団体だからライセンス料がかからないとは限らない。広告収入を得ている場合は非商用と見なされない可能性がある。将来ライセンス管理会社からライセンス料を請求される、最悪の場合特許侵害で裁判沙汰になるので覚悟しよう。ちなみにこれがKinzaが当初はH.264とAAC(と当時はまだ特許が有効だったMP3)の再生ができなかった理由であり、独自実装となった理由である。
以前言ったことが直ったものもあるが直ってないのもいくつかあって、特にhttps://github.com/Ablaze-MIRAI/Floorp-Browserの一文
が象徴的。「大部分の」は直ったが、どうやら「一番軽量」は直す気がないらしい。その誇大広告を直す気が無いのなら、なぜ一番軽量と言い切れるのか証拠を出しましょう。まさかあのメモリカスタマイザーが同梱してるからどの派生ブラウザよりも軽いんだよ、とか言い放つ気ではないだろうな？他のブラウザにFireminを入れてもなお軽いことを示してみてね。頑張って♪
Chromium派生ブラウザを初めてインストールした時に軽いとかほざく奴がいるけど、あれ何も入ってないまっさらな状態のせいだからな。履歴とかクッキーとかキャッシュとかがたまりにたまったブラウザと比べるから軽いって錯覚するだけで、地道なChromiumのコード改造とかしない限りメモリの使い方もパフォーマンスもほとんど同じ。改造以外に差があるとしたらビルドの仕方ぐらい。比べるのはプロファイルを全部コピーして同じにしてからだ。
Floorpは他のブラウザに拡張機能をインストールする！！危険！！！
って意見を持つ必要はありません。FloorpはChromeウェブストアの審査を通過した場合のみ、その機能を採用します。Googleの厳しい審査を受けている為、安全です
というTwitterの発言。大事なことを忘れている。Chromeウェブストア経由でインストールするのはGoogleの審査があるという意味では安全だが、ストア外からのインストールが安全とは言ってない。審査の通ったファイルが変化なくFloorpに入っている保証ができるのか？Floorpを信用するならインストールすればいいと思う。ソフトウェアに署名がないから改ざんされてないかが検証できないけどな。サーバーが乗っ取られて偽ファイルをダウンロードされるような事態を想定できている？何のためにストア外の拡張機能のインストールに管理者権限が必要になったか理由わかってる？
まあ学生が作ったブラウザを信頼するかしないかの問題だな。どうなっても誰も責任は取ってくれない。
今の段階だと、Chromiumのバージョンが古くてセキュリティが怪しいFloorpをわざわざ入れるまでもないんじゃないのか？FloorpSyncというxBrowserSyncベースのブラウザ同期の機能はxBrowserSync拡張機能さえ入れればどのブラウザでも使えるし、そんなに(見せかけの)メモリ使用量削減効果を見たいならFireminを入れればよいわけだし。
FloorpSyncはxBrowserSyncから名前変えただけじゃないの？まあ日本語対応はブラウザの作者がやったらしくそのことは評価できるが、Floorp自体はまだこれといった特徴がない。特徴がないのは開発が始まったばかりで仕方のないことだが、Kinzaのパッチを適用した後どうするかが特になく、将来どうしたいのかがよくわからない。挙げ句の果てにKinza派生系は2022年までという期限が付いてるし。
まあめんどくさがりにはいいんじゃない？同期やらメモリ節約やらを勝手に入れてくれるんだから。
何で批判多いのか自覚がないのは痛い。そういう厚かましさと根拠のない自信がアンチを生んでるんじゃないのか。もうエゴサしてないらしいからこれを見ることはもうないだろうがな。これを書いた屑なアンチを乗り越えてこそ本物だから。メンタル崩壊してる暇はない。しっかりしろ。
オープンソースソフトウェアの名前を変えて、それらを寄せ集めただけのブラウザで終わるのか、このブラウザならではの特徴を持ったブラウザに成長するかは作者次第。今のところは前者で開発終了になるのが目に見えている。いろいろな人から期待されている割には軽い気持ちで作っているように見受けられ、ブラウザ開発の覚悟が足りていない。
