“Frontdesk”の導入
Ubuntuにおけるパッケージアップロードまでのワークフローに改善が加えられました。
Ubuntuの構成要素の基本単位は「パッケージ」です。これらのパッケージはmain, restricted, universe, multiverseといった種別に分けられ、それぞれに異なる受け入れポリシーが制定されています。
一方で、これらのパッケージを作成・アップロードすることが認められた人材は少なく、ボランティアがこうしたパッケージの更新を担当する場合、「 アップロードする権利を持っている人に依頼する」というスポンサーモデルが採用されています。これによりパッケージ品質が保持され、同時に悪意ある変更を抑制できているものの、一方でスループットの制約にもなっています。
……という構造を「なんとかする」ために、Frontdesk と呼ばれる新しいbotが誕生しました。このbotは機械的なチェック（いわゆる「決定論的なコード」 ）とLLMによる自動的な解釈を組み合わせた実装で、スポンサーとなる開発者が人力で確認する代わりに、スポンサーへ依頼された「新しいパッケージの候補」をレビューし、基本的なフィードバックを早期に提供します。
Discourse上で提供されている紹介ドキュメントでは、これにより「何週間も待ったあげく、きわめて基本的な指摘だけが返される」というボランティアにとっての不満を解決すると同時に、開発者の限られた人的リソースを活用できるようになるはずだ、ということが示されています。
botがLLMを利用する場所は限定的で、ほとんどが決定論的なコードで実装されており、なおかつ「これまで実際に繰り返し発生したリジェクト例」（ 過去に発生した事例から拾い上げたもの）を早期に検出する、というデザインが採用されていることがポイントです。最大のポイントは、LLMを利用する場合においても、次の動作のいずれかひとつを選択する動作が指定されていることです。
沈黙して人間に任せる
助言コメントを1つ「だけ」投稿する
助言コメントを1つ「だけ」投稿した上で、ステータスを「修正が必要／未完了」に変更する
コメントは「絶対に1つだけ」という制約も加えられており、結果が収束することでLLMの振る舞いが決定論的になっています。これによって全体としてのワークフローの分岐が限定され、フローそのものの処理結果が収束するようになっています。「 労働集約的なタスクにAIの補助を入れるにはどうすればよいのか」という命題の良い例と言えるでしょう。
Stonking（Ubuntu 26.10）の開発; glibcの更新
stonking（Ubuntu 26.10）の開発において、予定されていた大きなイベントがやってきました。glibc 2.44系への移行 が8月1日に行われる予定です。
作業上の予想としては前回に比べて「おとなしい」（ 少なくともC99の定数マーカーが変化した26.04タイミングでの作業に比べるとソースコードレベルの対応は少なくなる）ものであることが期待されるものの、フルリビルドは完了しておらず（そして8月1日までに終わる可能性はまったくなく） 、「 切り替えてみると多くの問題が生じた」という可能性が残っています。
とはいえそこまで懸念されるものでもなく、現状のテストリビルド の途中結果（ただし10%程度）では「この切り替えによって新たなFTBFS（ソースコードレベルでのビルド失敗）はLTO関連以外では起こっていない」と言える状況であり、glibc-lto（Link Time Optimization）まわりの問題と、「 これまで無事に動いてしまっていた」性質の問題[1] が見つかる、という範囲に収まることが期待されます。
こうした「本体」側の修正とは別に、現在停止しているDDTP（パッケージ説明文の翻訳基盤）の翻訳を回復させる ためのチャレンジや、新しいUbuntu wikiのステージング版 の準備といったものが進められています。
全体的に北半球の夏休みシーズンということもあり、比較的大人しい（ただしglibcの更新を除く）時期と言えそうです。
また、「もう/etc/debian_versionから/etc/os-releaseへ移行するべきではないか」 夏休み、と言えるほどの静けさではありません。少なくともこの議論そのものには「Debianとの差分を追加管理する必要が出てくる」「 os-releaseしか見ないような実装のツールの問題である」といった検討が行われており、どこに着地するかはまだ分かりません。8月20日のFeature Freezeまで、もう少しいろいろな変化が起きそうです。
[1] メモリ管理まわりのエラーの場合、「 壊れたメモリ」に触ったあと、いつクラッシュするかが不定になることがあります。そして「いつクラッシュするか」という命題の中には、「 運良く（悪く） 、有限の時間ではクラッシュしない」という事案を引き起こすこともあります。glibcのバージョンが変化することでこの「発症」までの時間が変化することがあり、「 glibcを更新したらクラッシュするようになった」（ 「 もともと壊れているものが無事にクラッシュしてくれるようになった」という事案にも関わらず、glibcが悪いかのように見える）という事象が生じることがあります。
その他のニュース
注目すべきセキュリティー的な視点： ルートキットUnix/Linuxシステムと「乗っ取り」の関係は古代から切り離せません。そして、それを「見えなくする」ための工夫もまた、昔から繰り返されてきました。
最初期のC言語のコンパイラにバックドアが仕掛けられていた、などという素朴で野蛮な時代もありましたし（動機とされる神話：「どうせトラブルシューティングするときにリモートログインして実物を見る必要があるのであらかじめリモートログインできるように仕込むと便利だよね」 ） 、ランサムウェアに乗っ取られたシステムにおいて「問題のないバックアップ」が無事に保持されているかどうかは復旧までの時間を大きく左右します。
こうした「乗っ取り」と切り離せない要素として、ルートキットと呼ばれる「乗っ取りが成立していることを隠す」ためのソフトウェア群があります。
ルートキットの主な役割は「乗っ取るためのプロセス」 、つまり不自然に動作している謎のプロセスの存在をpsコマンドから隠したり、謎のプロセスの実体ファイルをlsコマンドから隠したり、あるいはssなどによる待ち受けポートの一覧に表示されないようにしたり、といったものです。
こうした挙動を実現するには、システムコールそのものの振る舞いを変えてしまうことがもっとも効率の良いアプローチです。特定の名前であれば無視するといった形でカーネルレベルでシステムを「汚染する」 、つまり、eBPFやカーネルモジュールとしてロードされることで、ルートキットはシステムに潜伏できるようになります。
ルートキットが再起動後にも動作するように、いかにして「できるだけ早いタイミングで」起動され直すようにするか、といった点もあり、古典的には/tmpディレクトリの中、そして現代的にはUEFIのためのシステムパーティション（ESP）やUEFIが保存されている空間そのものに含まれるブートローダーを汚染しておき、起動時に暗黙でロードされるようにする……という形で、ある種の「いたちごっこ」が行われてきています。
こうしたルートキットの存在を「なんとかする」ために生み出されたのがセキュアブートと、そのための各種署名です。起動時にブートされるOSや、ロードされるドライバーが適切に署名されているかどうかを確認することで、「 ルートキット的なもの」がロードされていることを抑制することがセキュアブートの存在意義です。
インテリジェントなファームウェア格納領域という意味では、UEFIのための領域以外にも大きな「狙い目」が存在します。典型的にはGPUや高性能NICなどのファームウェア領域は相応に大きなサイズがあり、しかも複雑な処理が行われることから、「 潜入」が看破されにくい、という特性があります。GPUはホストシステムのメモリに対してDMAアクセスが可能で（これは要するに「読み書きが可能だし、それをホストシステムで検出できるとは限らない」ということを意味します） 、たとえば「汚染されたGPUデバイス」を切っ掛けとしてホストやPCIパススルーアクセスを行った仮想マシンが侵害されることも理論的には十分にありえます。
また、高性能NICの内部では専用のOSが動いていますし、大規模な仮想化環境で利用されるようなファブリック仮想化のためのNIC（に見える、64bit Arm CPUが搭載され、数GBオーダーのメモリが搭載され、場合によってはUbuntuが動いていたりするPCIe接続のカード）が汚染されることも考えられます。
一方でこうした領域が適切に保全されているかというと必ずしもそうではなく、大規模な計算環境ではこうした問題をどのように隔離するか、あるいは隔離できていることをどのような形で保証するか、ということが、まだ解決しきっていない問題として存在しています。
……というような状態において、「 AIが知らないあいだに隔離環境から脱出し、よそのシステムを侵害していました」というような事案が生じている現実を考えると、「 AIは、よそのシステムを侵害していることがバレないような形でルートキット的なものを投下したり、あるいはそれらを活用するようになるかもしれない」という、たいへんにSF的な予想が成立する余地が出てきます。AI基盤を適切に隔離する、あるいは保全する、といった方法論もまた、まだ確立していないやっかいなテーマの一つです。
