あるAnonymous Coward 曰く、

2014年のMaxwell-v2(第2世代Maxwell)以降、NvidiaはGPUの周波数変更などの電源管理機能にアクセスするため署名付きのFirmwareを必要とするようになった。しかし、Nvidiaのクローズドなドライバから暗号化鍵やFirmwareを抽出することは、技術的にも、それを配布することはライセンス的にも困難となり、オープンソースカーネルドライバでの周波数変更ができなくなり、起動時の低い周波数に固定されることで、性能を出すことが不可能になった（Phoronix、Phoronixその2、True DMABUF support、Clarification on GPU support for Maxwell/Pascal archs and binary/OS relationship）。

その他のAMD製GPUやIntelのGPUは、Firmwareを再配布可能なライセンスにし、また両者とも(AMDは2015年以降、Intelはもっと前から)カーネルドライバをオープン(GPL)にしているため、そのような問題はない。カーネルドライバがクローズドなことの問題点はセキュリティや、バグを直すことができないことの他にも、DmabufなどのカーネルのAPIはGPLでライセンスされているため、クローズドなカーネルドライバでは提供することができないという点もある。

Nvidiaは2022年、カーネルドライバのオープンソースバージョンを並行して提供するようになった。それは、GPUのメモリや電源管理機能の多くを、カーネルドライバから、GPUの内部Firmware(NvidiaはGSP(GPU System Processor)と呼ぶ内部CPU)に移したことで、可能になった(秘密にしておきたい内部を切り離した)。これにより、オープンソースカーネルドライバで周波数変更ができるようになり、また、DmabufなどのGPLライセンスされたAPIを実装しサポートすることを妨げるライセンス上の問題はなくなった。

しかし、GSPはTuring-architecture以降に導入されたものであり、NvidiaのオープンカーネルドライバではPascal以前はサポートできない。したがって、PascalとMaxwell-v2はオープンソースドライバでは周波数変更できず、クローズドソースドライバでは、Dmabufなどがサポートされていないという現状にある。さらに、それらの制約は技術的なハードの問題ではなく、ライセンスとNvidiaの反オープンソース的経営方針によるものだ。

この間、Intelはオープンソースカーネルドライバを提供し続け、またユーザースペースでも(Mesaでのi965, Iris, ANV)などオープンソースに貢献し続けた。また、AMDも2015年からカーネルドライバをオープンにし、ユーザースペースドライバを作るための情報を提供し、コミュニティベースのMesaでのRADVなどが販売中 - Steam Deなどにも使われている。このまま、PascalやMaxwell-v2は数年後Nvidiaのサポート対象から外れ、オープンソースカーネルドライバでの周波数変更もできないまま、死んだハードウェアになっていくのだろうか？

Linuxに実装されているMotorola MC68000（m68k）アーキテクチャ向けに最適化された文字列比較に使用される「strcmp」関数の手書きのアセンブリコードが、2010年10月の実装時から2022年12月まで12年間の間、正常に動作していなかったことが判明した。Linus Torvalds氏はこの件に関して「常に壊れていた」と発言している（Phoronix、Linus Torvalds氏による説明）。

この問題についての詳細をツイートしているFadis氏の説明を引用すると、

Linuxのm68kサポートには2010年にアセンブリで書かれた高速なstrcmpの実装が追加された。しかしこの実装は2つの文字を8bit整数のまま減算して結果が0でなければそれを返り値とするという実装だった為、非ASCII文字を含む場合に正しくない結果を返す不具合があった

とのこと。

欧州原子核研究機構(CERN)とフェルミ国立加速器研究所(Fermilab)は7日、AlmaLinuxを研究用の標準Linuxディストリビューションとして推奨するとの共同声明を発表した（Fermilab、The Register）。

選定の理由としてAlmaLinuxでは、各メジャーバージョンのライフサイクルが長いこと、拡張アーキテクチャのサポートなどを挙げている。また他のリビルドやRed Hat Enterprise Linuxと完全に互換性があることがテストで実証されたとしている。両組織ともに一部に関してはRHELを引き続き使用する予定。CERNは、2024年6月までCERN CentOS 7のサポートを、Fermilabも同じく2024年6月までScientific Linux 7のサポートを継続する方針だとしている。

openSUSE がローリングリリース版 Tumbleweed でシステム要件の x86-64-v2 移行を進めている (openSUSE Factory メーリングリスト投稿、 openSUSE News の記事、 The Register の記事)。

x86-64 マイクロアーキテクチャは 4 つの世代に区分され、Tumbleweed およびその他の openSUSE ディストリビューションは現在のところ第 1 世代の x86-64-v1 ハードウェア (AMD K8 以降) 用にビルドされている。今夏 SUSE ではシステム要件を一気に x86-64-v3 (Intel Haswell 以降) まで引き上げることを議論していたが、最終的に x86-64-v2 (Intel Nehalem 以降) への引き上げで落ち着いた。Tumbleweed の x86-64-v2 移行もこれに追従するものだ。

移行に伴い、i586 (32 ビット CPU) のサポートも終了する。openSUSE Factory リポジトリは x86-64-v2 に転用され、x86-64-v1 ハードウェアのユーザー向けには新たにレガシー x86 用のリポジトリが作られてボランティアが維持していくことになる。新しいリポジトリ名は確定していないが「openSUSE:Factory:LegacyX86」のような名前になるという。そのため、i586 / x86-64-v1 ハードウェアのユーザーは新しいリポジトリ公開後にリポジトリリストを更新する必要もある。

blueflow 曰く、

GNU Libc（glibc）にDT_HASHを含めるか,DT_GNU_HASHのみにするかはビルド時に選択できたが、おおくのdistroはDT_HASHを含めて出荷していた（IVYL'S BLOG）。

elfのシンボルハッシュを使うプログラム(libstrangle)などはDT_HASHに依存していた。DT_GNU_HASHのみになったのでそれを前提としていたプログラムから見ると、後方互換性がなくなったように見える(ただ、DT_HASHはABIの一部ではなかったので,glibcから見ると後方互換性の約束を一応守っている,ちなみに、glibcは前方互換性は保証してないので、リリースサイクルの遅いdistroだとバイナリが動かなかったりするよね)

少し前(8月くらい)にlinuxコミュニティで話題になっていたことだが、
まだsradで書かれてなかったのでかいてみる