Ubuntu 24.04.5のリリース
Ubuntu 24.04 LTSの5番目のポイントリリース、24.04.5と、デスクトップ版にのみ「24.04.5.1」がリリースされました。
24.04.5（と24.04.5.1）は、26.04 LTSのカーネルや各種ハードウェアスタックをバックポートした「26.04 LTSと同等のハードウェア対応」能力を持つリリースでもあります。24.04 LTSを利用する用途が残っている場合[1]、このバージョンを手元に残しておく価値があるでしょう。24.04 LTSを利用し、HWEカーネルを利用している場合は、最新バージョンにアップデートすることで同等の構成になります。Ubuntuにおけるポイントリリースは「インストール後の手間を省くため」と「新しいハードウェアに対応できるようにするため」のもので、中身は最新状態と同等です。
末尾「.1」という謎のバージョンが生まれた経緯は次の通りです。
まず、9月10日（現地時間）に24.04.5がリリースされました。……されましたが、AMD64のデスクトップ版にExtendedインストールを選択した場合に発生する問題が発見され、ISOイメージが取り下げられました（症状：インストールに失敗する）。
問題のバグの修正は翌日には完了し、AMD64のデスクトップ版にのみ、「24.04.5.1」というこの問題の修正版が誕生したという経緯で「ポイントリリースにさらに追加バージョン識別子がついた」というレアなバージョンが生まれることになりました。
また、22.04 LTSを利用している場合は、通常のサポート期間はあと半年、Ubuntu Proを利用しない場合は本格的に24.04へのアップグレードを検討するべき時期です。
[1] 26.04 LTSでRust版coreutils導入が行われている都合から、「大量のシェルスクリプトで支えられている」ようなシステムの場合、このパターンに該当する可能性があるかもしれません。AIエージェントなどの支援（もしくは気合い）を入れて移行の準備を並行で進める前提で、「まだ残っているワークロード」がある場合は準備を整える価値があるかもしれません。
stonking（Ubuntu 26.10）の開発; Rust版coreutilsのcp、mv、rmへの移行
stonkingのRust版coreutilsのうち、保留になっていたcp、mv、rmの移行が行われる見込みであることをPhoronixやOMG Ubuntuが報じています。
これは「TOCTOUバグが残っているのでさすがに移行できない」という判断によるもので[2]、Rust版を指定していてもこれらの実装はGNU版のものが使われるという形になっていたものです。
リリースノートが先行してアップデートされているということで、『Our plan is to address the remaining issues as soon as possible and target Ubuntu 26.10 with 100% rust-coreutils.』（プランとしては残された問題をできるだけ速やかに解決したいと思います。Ubuntu 26.10では100% rust-coreutilsにすることが目標です）という宣言が達成されることになりそうです。
[2] ちなみにこれは古典的なTOCTOU脆弱性だけでなく、古典的な動作に依存したシェルスクリプトにレースコンディションバグを引き起こす可能性もゼロではありません（ゼロではないだけで、現実的な頻度で遭遇できるのかは微妙なところですし、「そういうコードを書く時はそもそもmkdirとrmdirを使いましょう」という別の問題もあります）。
CIX P1の正式サポート
『Concept』扱いで開発されていたCIX TechnologyのP1について、CanonicalとCIXの提携を含む公式なサポートが宣言されました。
CIX P1は「Windowsが動く」ハイエンドなARMチップで、Minisforum MS-R1やFramework Laptop 13のような、「一般的なデスクトップやノートPCと遜色ない」デバイスに使われることが想定されています。
Ubuntuにおける『Concept』はコミュニティベースで開発される「テスト版」的な位置付けのリリースで、ARM版ノートなどのような「これまでにない」タイプの挑戦に付けられることが多いカテゴリーです。これにより、「Ubuntuがもしかしたら動くかもしれない」（もしくは「今は動いているが、そのうち動かなくなるかもしれない」）という状態から、継続的にサポートされるようになります。
なおCIX P1はACPIベースの素直なハードウェアであり[3]、これが無事に動く状態になったということは、「ACPIに適切に情報が格納されている」ARM64ハードウェアであれば（そしてLinuxカーネルにドライバーが含まれるようなら）Ubuntuが無事に動くようになったはず[4]、ということも言えます。
[3] 「Snapdragon搭載ノートとは違って」（Unlike Snapdragon laptops）などという記載があり、いろいろと厄介なSnapdragonベースの実装とは違う、という点が大きなポイントと言えるでしょう。
[4] 問題は、「ACPIに適切に情報が格納されている」と「Linuxカーネルにドライバーが含まれる」という2つの条件を満たす「ARM搭載ハードウェア」というものは、ノートもデスクトップもきわめて少数派ということです……。
注目すべきセキュリティー的な視点：『不要になった』コードの削除
近年のLinuxカーネルの開発では、「あまりにも古くなった（地球上に利用者がおそらくいないであろう）デバイスのドライバーを削除する」という対応が行われています。これは、「各種ドライバーはカーネル特権で動作するため、脆弱性があると特権奪取につながる」「たとえデバイスが搭載されていない環境であっても、ドライバーをロードするだけでも攻撃を成立させられる場合がある」「近年はAIにより、メモリ破壊系や特権管理の失敗など、任意のコードの実行につながる問題が容易に発見される」というような事情があります。
そして、脆弱性がAIによって発見されるだけではなく、「発見されすぎてメンテナンスコストが爆増している」というさらに別の問題が生まれ、この結果として「利用者がいないはずのコードを保持するよりは、いっそ消してしまう」という方向で対処が行われています。
これはソースコードがオープンであり、さらに多くの注目があるLinuxカーネルに特有の話……に見えますが、実際には今後、あらゆるソフトウェアに発生するであろう問題です。
まず、「ソースコードが読める」ことの意味が、AI以前とは大きく異なっています。AIによるリバースエンジニアリング能力はきわめて高く、バイナリ状態の実行ファイルから脆弱性を見つけることも難しくありません。言い換えれば、暗号化されていないバイナリがユーザーの手に渡るあらゆるソフトウェアにおいて、「AIが脆弱性を発見する」可能性は無視できません。人力では「時間がかかる上に、希少な技術力の無駄遣い」でしかないものであっても、AIに任せる限りはエンジニアリング的な希少性は制約になりません。
そして「多くの注目がある」ことも、条件としては比較的「どうでもいい」と言えるでしょう。注目がある——利用者が多い、ということは名誉を含むなんらかのリターンが期待されるものですが、そこに経済的なリターンがあれば、AIトークンコスト（あるいはローカルLLMの運用コスト）に見合うようであれば、攻撃者はそこにチャレンジしてくる必然性があります。
古典的なソフトウェアエンジニアリングの格言として、「コードがなければバグもない」、つまり「そもそも無意味な機能を実装してはならない」という考え方があります。現代ではこれがさらに時系列を飛び越えるようになってきており、「無意味になった機能は削除しなければならない」という方向に機能するようになりました。このように考えると、「ソフトウェアとしてリターンの少ない」「アタックサーフェースを構成してしまう要素」を削る、という行動がどれぐらいの効率で実現できるかが組織に求められることになります。
特に企業システムの類においては、「不要になった」コードを適切に削除できるような開発プロセスに移行できることが、今後のセキュリティ強度を支配することになるかもしれません。