stonking（Ubuntu 26.10）の開発; Auto-MIRとOpenSSL4投入

Ubuntuの開発において、LLMによる省力化が行われる場所が少しずつ増えています。今回はMIRのための作業を支援するツールとして、Auto-MIRというソフトウェアが開発されていることが表明されています。

Ubuntuの開発においては、Debianベースの各種パッケージが利用されます。これらのパッケージはmain/universe/multiverse/restrictedといったコンポーネントに分類されており、特に「main」に属するものは、Ubuntuの「ベース」となるパッケージ群として、Canonicalによる全面的なサポートが得られる（これは「セキュリティアップデートやバグフィックスをCanonicalが実施する」という意味です）という特徴があります[1]。

Ubuntuをデフォルト設定でインストールした場合、すべてのパッケージはmain（とrestricted）由来のものに限定され、これによって「Ubuntuとしての基本機能」を安定して提供できるように設計されています。

これを実現するために、「⁠main」には厳選された（そしてメンテナンスが現実的である）ソフトウェアだけが収容され、「⁠同じ機能を提供するパッケージは原則としてひとつだけ」「⁠mainに属するパッケージは、main内で依存関係を解決しなくてはならない」といった基本原則と、この原則を保全するための開発とレビューのプロセスが規定されています。これをMIR（Main inclusion Review）[2]と呼びます。

MIRはテンプレートが用意されており、universeからmainへパッケージを移行する場合にはこのテンプレートを埋め、そして必要な作業を行う、というモデルとなっています。

しかし、このプロセスは非常に手間がかかるので（実際のテンプレートのように、きわめて大量の「TODO」を一つ一つ作業していく必要があります⁠）⁠、これをLLMを用いて効率化するための試みとして登場したのがAuto-MIRです。

Auto-MIRには動作モードとして「モデルアシストあり」「⁠決定論的レビューのみ」の2つを持ち（隠れた3つ目の選択肢として「そもそもAuto-MIRを使わない⁠」⁠）⁠、あくまでテンプレートの支援に使われるという構造になっています。

特徴としては次のようなもので、「⁠LLMですべてをラクにする」方向ではなく、「⁠地味だが責任のあるエンジニアリング」の積み重ねとしてデザインされていることが強調されています。

• 「事実」としては、決定論的レビューによって出力されるものが重視される。
• AIによる出力は「中程度」の信頼度に制限される。また、真に「解釈」が必要で、強い確信が得られるシナリオにのみ適用される。
• API認証情報は外に出ないし、「⁠使い捨て」環境に残ったりもしない。
• OpenRouterとOpenAI API互換環境に対応しており、ローカルLLMの利用も可能。

なお笑い話としては、実際に利用してみたところ、「⁠prompt-toolkitの類似パッケージとしてはcurl、openssl、network-managerがあります」という完全に意味不明な出力が得られていた（敗因：いずれのパッケージにも「コマンドライン」という文字列が含まれていたので、LLMがこれらを共通点として認識した）といったことが語られており、『⁠現実での試験は重要である』という結論が導かれています。

Ubuntuの開発においても、徐々に「LLMを用いた効率化」（⁠ただしAI Slop的なものからは距離を置く）が進展していこうとしていると言えそうです。

こうした動きの横では、Feature Freezeの前に、OpenSSL 4がstonkingのリリースポケットに投入されようとしています。現状ではまだすべてのビルド失敗（FTBFS）が修正されているわけでもないのですが（完全な識別にはフルリビルドをあらためて行う必要があります⁠）⁠、「⁠直しながらリリース可能な状態にする」という方向で作業が進むことになるでしょう。

Advantech AOM-2721のUbuntu Certified

Advantech AOM-2721がUbuntu Certifiedになったということがアナウンスされています。対象はUbuntu 24.04 LTSで、Ubuntu Pro for Devicesも利用可能、フリート単位での管理も可能ということが謳われています。

AOM-2721は「産業用の」組み込み向けボードで、Size-L OSMスタイルの小型のボードにQualcomm “⁠Dragonwing⁠”⁠ QCS6490を搭載し、12TOPSのAI性能と通信系I/Oを備えた「AIoT」向け製品です。キオスク端末や工場、あるいは場合によってはキャリアボードなどの中でUbuntuが動く、という方向で使われることになるでしょう。

『Ubuntu on Windows（WSL）の増加ペース』騒動

「WSL上のUbuntuのインストール数は、もうじきUbuntuを直接使うインストール数を上回るだろう」という見込みがあった、というCanonicalのVPへのインタビューを中心にした4月の記事が部分的に取り上げられ、さらに内容がキャッチーだったので各種SNSで話題になる、という光景が展開されていました。

いわく、「⁠この1年間、WSLのユーザー数はデスクトップ版の利用ユーザー数よりも大きく伸びている⁠」⁠。

これは伝言ゲーム的にいくつかの不幸な誤解が紛れ込んだ結果で、ZDNetがこれらの答え合わせをしています。

まずこの発言は部分的には事実で、「⁠Ubuntu on Windows、つまりWSL上のUbuntuのインストール数が伸びている」ということは正しいと言えそうです。

ただし、「⁠ネイティブのUbuntuをWSL上でのインストール数が上回りそうだ」という部分はあまり正しくなく、「⁠増えた数」ではなく「増え方」が多い、つまり絶対数ではなく「増加の割合」について述べたものであった、というのが実情で、「⁠インストール数」の増加ではなく「インストール数の増加率」が良く伸びているという話でした。さらにこの「多い」は、デスクトップ環境に限定された話で、Ubuntu全体（つまりサーバーやクラウド上のインスタンス）の話とも異なる性質のものです。

とはいえ、「⁠WSL上のUbuntuの伸び方はすごい」というのは事実らしく、おそらく「Windowsが入ったPCが支給されている」企業ユーザーが、AIや機械学習系のタスクが発生したタイミングでWSLを使っている、あるいは「Linuxベースの開発環境」を手軽に手に入れる方法論としてWSLが使われている、といったことの複合によってこの現象が成立しているということは予想でき、「⁠Ubuntuがいろいろな場面で利用される」ということは事実と言えそうです。

その他のニュース

• 英ブリストル大学と共同で、Canonicalが「CからRustへの自動翻訳を行う3年間のPhD研究プロジェクト」に投資するという発表。メモリセーフを目的としてC言語で書かれたプログラムをRustに変換する場合、unsafeなコードや「C言語の流儀が踏襲されたなにか」が生み出されてしまう、という課題に対して、単に書き換えるのではなく、プログラムを解析した上で形式手法とテストを組みあわせつつ根本的に書き直す、というアプローチを実現することを目指すとされています。対象となるソフトウェアはAppArmorとsnap-confineで、「⁠すべてが理想的に上手く行った場合」はこれらのRust版が登場するかもしれません（本文では「研究手法の妥当性を試すためのケーススタディだ」と明示されており、この展開になるとは限りません⁠）⁠。

• Workshop 0.9.5がリリースされ、WSL環境での動作バグの修正・高速化・個別のSSH設定の実現といった修正が加えられています。