Linux Foundation (LF) の支援を受けることの是非について、FOSS コミュニティで意見が分かれているそうだ (The Register の記事)。

LF の Open Source Security Foundation (OpenSSF) では、20 年以上にわたって重要な FOSS 開発者ツールをサポートしてきた Sourceware に支援を申し出ているという。OpenSSF の目的はモダンな IT インフラを Sourceware プロジェクトに提供することでオープンソースソフトウェアのセキュリティを改善することだ。

Red Hat が提供する Sourceware のインフラを利用してきた GNU Toolchain Infrastructure (GTI) は 9 月、LF の提供するインフラに移行する計画を示している。しかし、Sourceware コミュニティのメンバーの中には OpenSSF の支援を受けることで企業からの影響が強まることを懸念する人もいるようだ。そのため、よりソフトウェアの自由に一致するとの考えで、Software Freedom Conservancy (SFC) の支援を受けることも提案されている。

LF は非営利組織だが、Microsoft や Oracle などがプラチナメンバーに名を連ねる。そのため、非営利組織の中でも営利企業の共通の利益を追求する業界団体のようなものだと SFC の Bradley M. Kuhn 氏は指摘する。また、オープンソースの定義を書いた Bruce Perens 氏は 2017 年、LF の状況を「樹木の代弁者だと主張する木こりのようだ」と評している。

一方、SFC は Google や Mozilla などがスポンサーに名を連ねているが、組織としては慈善団体だ。Kuhn 氏はソフトウェアの自由が保てるかどうかについて、非営利組織とのガバナンスの違いが重要だと述べている。なお、Red Hat は LF のプラチナメンバーであり、SFC のスポンサーでもある。

headless 曰く、

Microsoft Store 版の Windows Subsystem for Linux (WSL) がバージョン 1.0.0 に到達した (リリースノート、 BetaNews の記事)。

前のバージョン 0.70.8 がリリースされたのは 11 月 5 日だが、それから 10 日ほどで一気にバージョン 1.0.0 まで進んだ。「Preview」のラベルも外れ、非 Insider 環境の Windows 10 / 11 (ビルド 19041 以降) での利用も可能になっている。

多数の修正点や改善点が列挙されていたバージョン 0.70.8 のリリースノートとは異なり、バージョン 1.0.0 の変更内容は「Preview」ラベルが外れたことのほか、以下の 2 点のみ。

• ブート中に /tmp/.X11-unix ソケットが削除されないよう generator.early のオーバーライドを使用
• ブート中に systemd がタイムアウトする問題を修正するため、systemd 用の pty を作成しない

ハワイのジェミニ天文台が、地球に最も近いブラックホールを発見したそうだ。今回発見されたブラックホールは「ガイアBH1」と呼ばれ、地球から見て黄道上のへびつかい座の方向に位置する。質量は太陽の10倍ほどだという。距離にすると1600光年離れており、これは天文学的スケールからすると非常に近い距離であるとされる。これまでに発見されていたブラックホールで最も近いとされていた「一角獣座X-1」と比べると、新たに発見されたガイアBH1は地球との距離は3分の1ほどという近距離。ジェミニ天文台を運用している米NSF国立光赤外線天文学研究所は「私たちの宇宙のすぐ裏庭」ほどの距離だと説明している（Oxford Academic、GIGAZINE、ニューズウィーク日本版）。

Linux Lite は 10 月 31 日、最新版となる Linux Lite 6.2 Final をリリースした (アナウンス、 The Register の記事、 BetaNews の記事)。

メインラインのLinux カーネルはバージョン 6.1-rc3 が最新版なので紛らわしいが、Linux Lite 6.2 は Ubuntu 22.04.1 ベースであり、Linux カーネルはバージョン 5.15.0-52 となっている。また、Lite の名に反して軽量ディストロではなく、Windows ライクなデスクトップで初めて使う Linux をうたいながら UI に混乱を招くような部分があることを The Register は指摘している。

一方、Firefox を Google Chrome が置き換えている点はより一般向けであり、プリインストールソフトウェアやカスタマイズしやすさなど好ましい点も多いという。そのため、冒頭に挙げたわかりやすさを除けば、初めての Linux として妥当な仕上がりになっているとのことだ。

サイバートラストは1日、CentOSの後継として利用できるRed Hat Enterprise Linux（RHEL）9 互換の国産Linux OS「MIRACLE LINUX 9」を提供開始した。（サイバートラストリリース、PC Watch）。

2021年末で開発終了したRHELクローンのCentOSの後継として利用できる。RHEL 9と同様にLinux カーネル 5.14を採用し、OpenSSLなどの主要なパッケージのバーションアップのほか、SELinuxの性能改善、セキュアブート対応など、セキュリティ関連の機能が強化されているしている。これと合わせて「MIRACLE LINUX 8」のマイナーアップデートとなる「MIRACLE LINUX 8.6」の提供もおこなっている。サポート期間は、MIRACLE LINUX 9系が2032年11月まで、8系に関しては2030年5月までとなっている。

あるAnonymous Coward 曰く、

RHEL 9互換 10年の長期サポート

headless 曰く、

Linux では i386 のサポートを 2012 年に終了しているが、2022 年は i486 のサポートを終了する時ではないかと Linus Torvalds 氏が提案している (Torvalds 氏のメーリングリスト投稿 [1]、 [2]、 Phoronix の記事、 Neowin の記事)。

提案は現在ほとんど使われていない古い CPU をサポートするため cmpxchg の処理が複雑になっていることへの対策であり、x86-32 では「cmpxchg8b」インストラクションをサポートする CPU (Pentium以降) のみをサポートすることにしてはどうか、というものだ。これにより、CONFIG_MATH_EMULATION もついに消すことが可能になるとのこと。

Torvalds 氏はほとんど (全部？) のディストロが既に (X86_CMPXCHG64 を基本要件に含む) X86_PAE を有効化していると考えており、ほとんどのディストロが 32 ビットの開発をしていないと確信しているという。また、486 関連の開発をしている人がいないわけではないことを認識しつつ、新規出荷されている 486 クラスのハードウェアがほぼないことを指摘。カーネル開発の観点で i486 サポートの重要性はないとのこと。

i486 ハードウェアはそのうち博物館の収蔵品となり、博物館のカーネルで動作することになるとし、要件を cmpxchg8b に引き上げることが不合理だとは思えないという。Torvalds 氏は i486 をサポートするカーネルが必要なら LTS を使えばいいとも述べている。Phoronix では Linux 6.1 が今年の LTS カーネルになると予想しており、Linux 6.2 で i486 サポートが削除されることを期待している。

Ubuntu で「sudo apt upgrade」を実行すると Ubuntu Pro の宣伝が表示されるとして、ユーザーから不満の声が出ている (The Register の記事、 Reddit 投稿、 Mastodon 投稿、 Ask Ubuntu 投稿)。

Canonical が先日発表した Ubuntu Pro は 10 年間のサービスが提供され、個人では最大 5 台まで無料で利用できる。sudo apt upgrade で表示される宣伝は「最大 5 台の個人向け無料サブスクリプションで Ubuntu Pro ベータ版を試してみよう。 / 詳しくは https://ubuntu.com/pro で」といった趣旨のものだ。

投稿者はこのような宣伝が表示されることが許せないようだが、Canonical ではニュース要素だと The Register に説明したという。スラドの皆さんのご意見はいかがだろう。

ITmediaの記事によると、Canonicalは、新サービス「Ubuntu Pro」を発表した。現在はベータ版として提供されている。このUbuntu Proは、Ubuntuと主要なアプリケーションに対して、10年間のセキュリティパッチなどによるメンテナンスを提供を約束するというもの（ITmedia）。

サーバ向けとデスクトップ向けを含むすべてのUbuntuのディストリビューションに対応、「Apache Tomcat」「Apache Zookeeper」「Docker」「Drupal」「Nagios」「Node.js」「phpMyAdmin」「Puppet」「WordPress」などの主要なLinuxアプリケーションもメンテナンスの対象になる。また個人に対しては最大で5台のマシンまでUbuntu Proが無料で提供されるとのこと。

Linuxの生みの親であるLinus Torvalds氏はメーリングリストで、Linuxカーネルのバージョン6.1のコードのマージが遅れていると告知した。「新しいECCメモリDIMMが届く」のを待っているためだという。同氏によればここ2、3日ほどメインのデスクトップPCが不安定となっており、allmodconfigのビルドがコンパイラの内部エラーで失敗する事例が多発していたらしい（Linus Torvalds氏のメール、The Register）。

こうした場合は、たいていは新しいカーネルのバグだとして原因を探していたがものの、バグではなく原因はPC側の不調だったそうだ。Memtest86+を回して確認したところ、メモリエラーが起きていたことが判明したとしている。仕方ないのでメモリが届くまでラップトップを使って、ゆっくりとカーネルのマージをおこなっていたとのこと。

4 日にリリースされた Linux カーネル 5.19.13 では、Intel グラフィックスのノート PC で内蔵ディスプレイパネルを破損する可能性のある問題が修正されている (Phoronix の記事、 アナウンス)。

この問題は Linux 5.19.12 で報告されていたもので、画面が連続フラッシュのように白く点滅するという。5.19.11では発生しないためFramework Laptopのフォーラムでは5.19.12にアップグレードしないよう呼びかけられていた。調査の結果、内蔵ディスプレイパネルの省電力関連に関連した問題により内蔵ディスプレイを破損する可能性が判明し、5.19.13で修正された。なお、5.19.13 の変更点はこの修正のみであることから、5.19.12 で問題が発生していない場合はアップグレード不要とのことだ。

Debian プロジェクトが採決を行い、公式イメージのインストーラーで非自由な (プロプライエタリの) ファームウェアを同梱可能にした (決議案、 採決結果、 The Register の記事)。

Debian では長らく非自由ファームウェアのサポートを避けてきたが、このようなファームウェアバイナリなしではモダンなコンピューターが完全に動作しなくなってきているというのが提案理由だ。

選択肢は大きく 3 つに分けられる。

1. 非自由ファームウェアを含む唯一のインストーラー
2. 非自由ファームウェアを含むインストーラーと含まないインストーラーの両方
3. 非自由ファームウェアを含むインストーラーを認めない

実際のオプションは以下のような 7 つとなる。

1. 唯一のインストーラー
2. 両方のインストーラーで非自由ファームウェアを含む方を推奨
3. 両方のインストーラーを提示可能にする
4. 非自由ソフトウェアを含むインストーラーを Debian の一部と認めない
5. 非自由ファームウェアを含められるよう Debian 社会契約を変更、唯一のインストーラー
6. 非自由ファームウェアを含められるよう Debian 社会契約を変更、両方のインストーラー
7. どれも該当しない

採決を勝ち抜いたのはオプション 5。Debian 社会契約の 5 番に「非自由ファームウェアを必要とするハードウェアを Debian で使用可能にするため、Debian の公式メディアには Debian の一部ではないファームウェアが同梱される可能性がある」といった趣旨の文言を追加し、同梱されるファームウェアバイナリはシステムの判断によりデフォルトで有効化されるといった声明を出すことになっている。

これにより、次期 Debian 12 (コードネーム: Bookworm) では、公式メディアに非自由ファームウェアが同梱可能となる。

スマートフォン向けゲーム「バンドリ! ガールズバンドパーティ!」向けの楽曲である「スカイクラッドの観測者」で、Linuxカーネルのコードが使われているとして話題となっている。Hiraku Toyookaさんが発見した。同氏のこのツイートに対し「めっちゃ見慣れた感じのシンボル名だらけでしたわー!」「カーネルのコードある程度読んだことある人ならわりとすぐ気付きそう」などのコメントがついている（Hiraku Toyookaさんのツイート、スカイクラッドの観測者の動画、激ロック ニュース）。

また「Linuxカーネルのコードが使われていることから楽曲もGPLになるのでしょうか」といった疑問も提示されている。Hiraku Toyooka氏は、動画をGPLで頒布している訳では無いので、動画や動画内で使われている楽曲のライセンスをGPLとして扱うことはできないんじゃないかと解釈するコメントをしている。

ラジャ・コドゥリ（Raja Koduri）氏がツイートで、リーナス・トーバルズ氏とIntelのグラフィックスドライバチームが一緒に過ごしたというツイートをしている。リーナス氏からはカーネルドライバの更新について厳しい突っ込みが入ったとコメントしている（Raja Koduri氏のツイート）。

あるAnonymous Coward 曰く、

Intelはオープンソースグラフィックスドライバのスタックに長年貢献している。最近はbinaryblobなファームウェアを巡ってカーネルとの互換性を壊す変更や (すでに修正済) 、これまで必須でなかったGuC, HuCnなどのblobを強制する動きがあるが、GPUのオープンソースサポートの面では、ユーザースペースのドライバではAMDのRADV (MESAのAMD製GPU用Vulkanドライバ) などはANV (IntelのVulkanドライバ) を参考に作られたなど周辺環境の整備、オープンな規格の策定などこれまで多大な貢献をしてくれている。これからも、クローズドな方向に向かわないよう願うばかりだ。

AMDも2014年くらいからカーネル、ユーザースペースともオープンソースドライバを用意し、またCommunityが開発できるようにしてくれている。実際MASAはAMDが用意しているオープンソースドライバではなく、Communityベースのドライバだ (ValveもSteam Deckで使用) 。

Nvidiaは最近カーネル側のドライバを一部公開したが、GSPが乗っている世代以降でしか使えず (turing以降) 、オープンソースドライバのnouveauもあるがnvidiaの署名付きfirmwareがいるため周波数の変更ができず (起動時の一番低い周波数に限定される) 。

GPUを買うときはIntelかAMDのものにしよう

headless 曰く、

Linux カーネルが 2002 年に ACPI サポートを導入した際、一部のチップセットで発生する問題を回避するために含められた対策がモダンな AMD システムのパフォーマンスに影響することが判明し、パッチが Linux 6.0 にマージされたそうだ (Phoronix の記事 [1]、 [2]、 Ars Technica の記事、 The Register の記事)。

この問題は古いチップセットの一部で CPU クロックを停止する STPCLK# が適時にアサートされないというもので、対策として CPU が完全に停止するまでダミーの待機処理が入れられる。しかし、この処理が Zen3 システムのパフォーマンスに顕著な影響を与えることに AMD の K Prateek Nayak 氏が気付き、Zen マイクロアーキテクチャーの CPU に適用しないパッチを作成する。

一方、Intel システムでは Nehalem 以降の CPU でこのコードを使用しないのだが、実際にこの対策が必要なのは古い Intel の CPU のみだという。そのため、Intel の Dave Hansen 氏が Intel 以外のシステムに適用しないようパッチをシンプル化。このパッチが Linus Torvalds 氏に取り上げられ、Linux 6.0 にマージされることとなった。

Linux の NTFS3 ドライバーで大文字と小文字を区別しないマウントオプション「nocase」追加が提案され、Phoronix のフォーラムでは大文字と小文字を区別するファイルシステムの是非について議論が盛り上がっている (Phoronix の記事)。

Windows も「まともな」OS のように大文字小文字を区別すべきだといった意見や、大文字と小文字を区別しないファイルシステム上のファイルを Linux のツールで操作したらどうなるのか心配する意見も見られるが、Linux のネイティブファイルシステムでも ext4 や f2fs が大文字小文字を区別しない機能をサポートしている。逆に Windows 10 バージョン 1803 以降では NTFS にディレクトリ単位でファイル名の大文字と小文字を区別するフラグが追加されており、fsutil コマンドを使用して有効化が可能だ。

人間は大文字と小文字の違いだけであれば同じ名前だと認識するため、平均的なユーザーには大文字と小文字を区別するファイルシステムを理解しにくい、実用的に大文字と小文字の組み合わせのみが異なる同名のファイルを同じフォルダーに格納できることが役に立つ場面は少ない、といった意見も見られる。スラドの皆さんはどう思われるだろうか。