今残ってるのはUTF-16と非'\n'の改行タイプだけだね。

ネットワークプロトコルでは永遠に付き合っていかなきゃならないよね。幸い、ほとんどのソフトウェアからは隔離されてるけど。

いい指摘だね。エンジンからエンディアンに関する#ifdefをいくつか削除したところだよ。

ビッグエンディアンがほぼ死にかけてるのはすごいね。LTRスクリプトの書き数字にも同じことが当てはまればいいのに。そうすれば、紙の上でも頭の中でも計算がもっと楽になると思う。あと、世界がISO 8601やRFC 3339みたいなまともな日付・時刻フォーマットに落ち着いてくれたらいいな（どっちも、最初の願いが叶ったら逆になるけど）。 それは、非8ビットバイトやEBCDICと一緒にコンピュータのゴミ箱に捨てられる運命だね。非8ビットバイト、特に7ビットバイトのことは全然理解できなかった。CPUやFPGA、カスタムデジタル回路でよく使われるマルチプレクサやデマルチプレクサ/デコーダ回路を考えると、実際に意味がある数字は8だけだよ。3ビットのセレクタコードに対して得られるのがそれだからね。近くの値は4と16だけど、なんで7ビットにしたんだろう？生まれるずっと前に決められたデザインの選択だと思うけど、理由を知ってる人いる？

ビッグエンディアンは、IBMがs390xで一流のLinuxサポートを提供するためにリソースを投入し続ける限り残るだろうね。もちろん、ソフトウェアがs390xで動くことを期待しないなら、リトルエンディアンを前提にしてもいいけど、AppleがPowerPCのサポートをやめて以来、ほとんどのソフトウェア開発者はそうしてるし。

アクセス可能なオープンハードウェアが必要だよね。実際には従わない一般的な基準に合わせて、プロプライエタリなハードウェアを無理やり使うのはダメだ。オープンソースは一つのことだけど、オープンハードウェアが本当に必要なんだ。フレームワークのラップトップやSystem76のマシンだけじゃなくて、バイナリブロブでロックされてない標準の64ビットオープンソースマザーボードや周辺機器が必要だよ。

そのOSはもう存在してるよ。NetBSDはほぼ何にでも動かせるし（例えば、Motorola 68k CPUを搭載したマシンもサポートしてる）。確かに、そういうマシンの多くはMMUを持ってるけど、システムプログラミングに少し知識がある人なら、まだまだ理解できる範囲だと思うよ。

POSIX OSが欲しいなら、nommu Linuxはもうそれじゃないよ。fork()がないからね。

nommuは面白いコンセプトだけど、実際にはほとんど誰も使ってないし、これから変わるとも思えない。生産環境で使う実際のユースケースがないんだよね。RTOSの方がnommuハードウェアにはずっと適してるし、「本物」のLinuxが動くパーツはどんどん安くなってる。簡単に理解できるハードウェアアーキテクチャが欲しいなら、自分で実装もできるRISC-Vの方が、nommuやそれ以外のARMよりもずっと良く扱えるよ。

ZephyrやNuttX、Contikiみたいな他のオープンOSもあるから、Linuxよりもnommuケースにはそっちの方が合ってるかもね？

これは私にとって予見できる大惨事だね。来年引退するし、私たちのキューイングシステムのコアは64ビット対応（k&r）で、Alphaでコンパイルされてるけど、クライアントソフトウェアは全然そうじゃない。これは若い人向けのゲームで、私は全然若くないからね。

それにフル機能のLinuxが必要なの？ 提供されている機能の多くは、そんな組み込みシステムにはオーバースペックだと思う。NuttXとZephyrはPOSIX風のAPIを提供してるし、NuttXはLinuxカーネルにかなり似たAPIを持ってるから、足りない部分をポートするのは多少簡単だと思うよ（実際にはやったことないけど、僕が関わってたプロジェクトはキャンセルになっちゃった）。

ソフトウェアエミュレーションはあんまり重要じゃないと思う。話に出てる一番低いエンドのチップを見てみよう。ほぼ確実にSAM9x60だね。これ、5ドルのARMv5 MMUチップで、DDR2/LPDDR/DDR3/LPDDR3/PSRAM、いろんな組み込みRAMや「古いデスクトップRAM」、モバイルRAMをサポートしてる。確かに32ビットだけど、600MHzでGB単位のRAMサポートがある。これを使えば、10ドル以下でコンピュータを大量生産できるよ（0.75mmピッチのBGAをブレイクアウトできる4層PCBをサポートすればね）。DDR2 RAMを使ったリファレンスデザインは4層設計だし。大きめのTQFPのRockchipとかもあって、そっちの方が扱いやすいかもしれないけど、DDR RAMはBGAだから、BGAレベルのPCBレイアウトが簡単だと思う。--------- この32ビット/ARMv5チップのカテゴリより小さいもの（Microchip SAM9x60や競合のRockchip、AllWinnerなど）は、Linuxを動かすには全く不適切なマイコンなんだ。64MBのRAMに達しないなら、Linuxは単純に使えない。組み込み用途でもね。その時点でFreeRTOSとか他のものを使うべきだよ。--------- Linuxが過去20年以内に作られた64MBのハードウェアで線を引くのは…妥当かな？ちょっと妥当すぎるかも。SAM9x60が現代の新しい設計でも使えるのは嬉しいけど、どこかで線を引かないといけないよね。ARMv5はNode.jsすらコンパイルできないくらい古いから。これが古いって言ってるのは本気だよ。これは典型的なLinuxユーザーにはすでに異質な環境なんだ。

あなたは一人じゃないよ、僕も同じ気持ちだ。Linuxが本当にnommuを削除する未来があるとしたら、それはフォークになると思う。でも、そのためのコミュニティがあるかはわからないな。

そんなシステム向けのFOSS POSIXライクなものはたくさんあるよ。多分、そういうのが形になる頃には僕はこの領域にはいないと思うけど、GNU/Linuxの爆発がUNIXを置き換えたのは、コンピュータの歴史の中での一時的なフェーズに過ぎないと思う。結局、その成功に関わった人たちがいなくなったら、他の agendas が台頭するだろうね。僕が言及した代替案がすべてコピーレフトライセンスに基づいているのは偶然じゃないよ。

一番小さい実装を除けば、32ビットと64ビットのALUのコスト差は、コアのパフォーマンスを上げるために行われている他のことに比べるとかなり小さいよ。それに、コアが32ビットの演算をサポートしてないと仮定して、ALUの残りがアイドル状態になるか、ダブルポンピングみたいなことをする場合もあるしね。実際、ALUの幅は内部の実装の詳細や最適化で、完成するのにもっとサイクルがかかるけど、必要なサイズに調整できるよ。

なんで32ビットシステムが32個のトランジスタを持ってると思うの？例えば、ペンティアムプロは86ビットのアドレスバスと64ビットのデータバスを持ってたよ。

ただ電力効率が良いだけじゃなくて、ポインタが半分の大きさだから、キャッシュに占めるスペースも少なくて済むから、メモリ効率も少し良いよ。低ビットのチップはサイズも小さいし（それが、スーパースカラコアあたりのクロックを速くしたり、機能ユニットを増やしたり、ダイあたりのコアを増やしたりすることにつながるかもしれない）。この議論の問題の一部は、「64ビット」と「32ビット」を比較する時に、新しい命令セット世代に追加された便利な命令も考慮していることが多いことだね。でも、真の「同じ条件での」比較は、データパスとポインタサイズだけが違う、ほぼ同じものを使うべきだと思う。自分が使ってるプログラムやゲームは、実際には4GB以上のメモリを必要としないと思うし、64ビットの数学の精度が必要な場面は、コンパイラが32ビットの命令をいくつか追加して64ビットの数学をエミュレートすることで対処できると思う。

8ビットシステムの話を聞くまで待ってて。

時には、すごく早く動いてすぐに寝ることで電力を節約しなきゃね。

メモリバスは、他のすべてのことに比べれば微々たるものだよ。特にCPUだけじゃなくて、20個の他のデバイスもあるSoCではね。

64ビットと比べて？ そうかもね。ARMベースのシステムと比べて？ いや、全然。

Androidはすでにメインラインに完全には従っていない状態だね。最新のLTSに従っているけど、これは合理的だと思う。特に電話ベンダーがデバイスのサポートを数年間持ちたいと思っているからね。

技術にはライフサイクルがあるんだよ。11時に放送されるよ。

いつでもNetBSDがあるよ。80486までさかのぼってx86をサポートしてるはずだし、32ビットSPARCも…考えたくないような昔からサポートしてると思う。

現行バージョンや新バージョンからサポートが外れたからって、古いコードやtarballが消えるわけじゃないよ。古い32ビットカーネルをいつでも引っ張り出せるし。

フォークする選択肢もあるしね。Linuxレガシー？Linux 32？Linuxグレイビアード！

オープンソースは市場価格やベンダーにとっての便利さじゃなくて、ユーザーが何を動かす価値があるかを決める自由を与えることなんだ。ええと、ユーザーが好きなものを動かす能力があるってことだよね。実際そうなってるし。もし32ビットハードウェアのユーザーグループが最新のカーネル機能をサポートするためにボランティアを募るなら、問題ないよね。誰もやらないなら、ボランティアがそれをやるために気を使う理由は何なの？古いカーネルバージョンが動かなくなるわけじゃないし。やりたくないことをボランティアに強いるのは、ボランティアの管理としては良くない方法だよ。

32ビットハードウェアに縛られてる人と、新しいカーネルの機能が必要な人のベン図ってどんな感じ？既存のカーネルは動き続けるだろうし、新しいデバイスはその古いハードウェアをサポートしないだろうね。最近新しいAGPグラフィックカード見た？2004年のコンピュータで最新のカーネルを動かす理由はあまりないし、カーネル開発者にその環境をサポートさせる理由も全然ないよ。

でも、コードがすでに存在していて動いてるなら、壊さないようにするのはそんなにコストがかかるのかな？機能によるけど、多くの場合、答えは実際に「はい」なんだ。数十年も前に廃止されたAlphaサポートが続いている理由があるけど、数年前に廃止されたItaniumサポートは完全にシステムから取り除かれてるからね。

彼らはハードウェアを陳腐化させることについて話しているけど、それは根本的に壊れているからじゃなくて、単にロードマップにうまく収まらなくなったからなんだ。実際はそうじゃないよ。議論はコストや利益、利用可能なリソースについてのものだ。オープンソースやフリーソフトウェアだからって、プロジェクトが免疫を持っているわけじゃない。実際に作業をする人が必要なんだ。 > オープンソースは、ハードウェアが商業的な関心を超えて生き続けることを目指していて、ハードウェアベンダーが見捨てた後も動き続けることを可能にしてきた。これもまた、実際にはそうじゃない。オープンソースは常にソフトウェアを自由に修正・配布することに関するものだ。これにより、誰でも自分の好きなハードウェアをサポートし続ける自由が残るけど、それは結果に過ぎない。この場合、もし誰かが古いハードウェアをサポートし続けるために必要なリソースを提供するなら、実際には問題にならないと思う。この自由は、プロジェクトの開発者が何かをもう時間をかける価値がないと判断したから奪われたわけじゃないんだ。

10年から15年前のデスクトップやノートパソコンは、基本的に全部64ビットだよ。この削除が起こる頃には、ほとんどのハードウェアが64ビットになってから20年経ってる。ハードウェアが「レトロ」になる頃には、最新のカーネルバージョンは必要ないし。多くのディストロはすでに32ビットカーネルのサポートをやめてるけど、大した騒ぎにはなってないし。

古いカーネルもまだ使えるよ。「スーパーロングタームサポート」リリースがあって、10年以上のサポートがあるんだ。一部のディストロはもっと長いかも。もし今日6.12をインストールしたら（例えばDebian 13経由で）、2035年までは大丈夫だよ。だから今削除するってことは、実質的に10年以上後に削除されるってことだね。記事にも書いてあるけど、これは主にかなり古いシステムに関すること。そんなシステムで最新のカーネルを使ってる人っているのかな？たぶんほとんどいないと思う。これは「最新の光るものを追いかける」ってわけじゃないよ。そんなのは意味不明な極端な考え方だね。

10年から15年前の古いデスクトップやノートパソコンが、まだLinuxディストリビューションで使えるっていうのは、すごく多いと思うけど、それがもう通用しなくなるんだ。メインストリームのノートパソコンやデスクトップでは、32ビット時代は2006年頃に終わった（賢い人は2003年にAthlon 64を使ってたけどね）。ネットブックや本当に弱いデバイスはもう少し長持ちしたけど、2010年には市場に出ているほとんどの新しいもの、そしてかなりの量の中古市場もすでに64ビットだった。

こういう特別なユースケースをサポートすることは、意外と価値のある練習になることがあるよ。プロジェクト内で自分が気づかずに前提を作っていた場所を見せてくれるからね。ニッチなユーザーをサポートすることで、プロジェクト全体の質が向上する可能性があると思う。

一般的に言うと、特定のハードウェアのサポートを削除することの限界利益は、ほとんどの場合、そんなに大きくないと思う。カーネルの大部分はかなり広い範囲で一般的だから、その一部を削除しても全体の幅にはあまり影響しないんじゃないかな。例えば、古いx86 CPUのためのエラッタのワークアラウンドみたいなものは削除できたらいいけど、それはx86の多様性を扱う大きなフレームワークの一部なんだよね。個々のワークアラウンドを削除しても、そのフレームワークを削除することにはならない。例外としては、サポートを削除することで最低限の共通部分から何か重要なものが失われる場合がある。ワードサイズやメモリの順序（Alphaを削除するのはかなり便利だと思う）、仮想アドレス空間の制限みたいな大きな問題がね。