Project “Myna”: Speech To Text for Ubuntu、Ubuntu 26.10（Stonking）の開発; dbus-brokerへのマイグレーション

Project “Myna”: Speech To Text for Ubuntu

Stonking以降のUbuntuで提供される、Speech To Text（音声入力）プロジェクトが開始されました。

「人間のしゃべったことを忠実に繰り返す」九官鳥にちなんで、「Project Myna」と名付けられています。現時点では実装は公開されておらず、あくまで設計部分についての意見を募集中というフェーズです。また、26.10のスコープとして、「⁠デスクトップにおける音声ベースのテキスト入力」に専念することが宣言されています。将来的な拡張として音声アシスタント、音声コマンド、デスクトップ制御、翻訳、自動言語検出といったことも想定されているようですが、これらは26.10には含まれません。

実装としてはオフラインでも動作し、Canonical Inference Snapを介したローカル推論を使用すること、初期実装ではIBusに依存すること（将来的にWaylandネイティブの入力パスへ移行する予定）が明示されています。また、将来の予定として「GPU、NPUの利用」という記載が含まれていることから、おそらく最初はCPUベースの実装になるように読み取れます。Inference Snapが対応するどのモデルを利用するのか（あるいは必要に応じて変更できるのか）は現状では明示されていません。

Stonking（Ubuntu 26.10）の開発; dbus-brokerへのマイグレーション、エージェントとの協働

stonkingで予定されていたdbus-brokerへの移行のテストが呼びかけられています。対象はstonkingだけでなくresolute（26.04）も含まれ、「⁠sudo apt install dbus-broker」でインストールできる状態になっています（あくまでテスト段階であることに注意してください。また、dbus-daemonに戻すためにはdiscourse上にある手順が必要です⁠）⁠。

新しいdbus-brokerはこれまでのdbus-daemonと完全互換することが期待されるソフトウェアなので「何も起きないし、何も準備しなくて良い」タイプの更新になるはず、という性質のものではあるのですが、テスト後にデフォルト環境の移行が行われる予定です。

また、Ubuntuでの移行に時間がかかった理由として、「⁠mainに同一の機能を持つソフトウェアが存在できないこと（そして、dbus-daemonへ直接的に依存してしまっているパッケージを更新する必要があったこと⁠）⁠」⁠、「⁠dbus経由での特権アクセスについてAppArmorを用いて制御していたので、dbus-brokerもサポートする形に更新する必要があること」が挙げられています。

テストの動きの横では、作成が失敗していたamd64版ISOイメージが復帰し、利用可能な状態になっていたり、あるいはUbuntu Release UpgraderのバグトリアージのためのAIエージェントのプロトタイピングが行われていたり、rustc-1.94が投入されたり、.NET 11 Preview 5のテストが行われたり、OpenSSL 4のための修正がキューされたりと、さまざまな作業が進んでいます。

その他のニュース

Ubuntu Forumの過去のアーカイブがマークダウン形式で入手できるようになりました。
Ubuntu Core 26を用いて仮想マシンベースのローカルLLM環境を構築する方法。「⁠multipass launch core26 -n aibox --cpus 4 --memory 10GB --disk 16GB」「⁠multipass shell aibox」「⁠sudo snap install gemma4」「⁠sudo gemma4 set http.host=0.0.0.0 webui.http.host=0.0.0.0 --assume-yes」の4コマンドの実行で推論エンドポイントを構築できます[1]。
「Mythos以降」のセキュリティについてのUbuntu的な対応の整理。「⁠AppArmorとネイティブコンテナ分離（LXD）による厳格なカーネルレベルの境界を強制しています。この安全設計の基盤の上に、Rustのようなメモリ安全な言語を推進」しているということと、「⁠最も重要なセキュリティアップデートについては、平均24時間以内に準備、テスト、リリースすることを目指している」「⁠Ubuntuに影響を与えるすべての脆弱性に関する情報は、業界標準の機械可読データフィードであるOSV、VEX、およびOVALを通じて配信される」といった点がポイントです。
Ubuntu的なパッケージとしてのNVIDIA製グラフィックドライバーのうち、470系のサポート終了に伴う混乱。後継となる530系は古いGPU（たとえばGTX 7xxシリーズ）には対応しないため、「⁠NVIDIAから配布される470系」に切り替えるか、あるいはnouveauに置き換える必要があります。
Ubuntuのs390xサポート（IBM Z/IBM LinuxONE対応）10周年を記念したまとめ。
CanonicalのDesign Teamがまとめた「オープンソースプロジェクトにおけるデザインでの貢献」を成立させるためのテンプレート。

注目すべきセキュリティー的な視点：冗長構成のコスト

ハイアベイラビリティを実現するためのコストは、いろいろな形で、そして目に見えない形で要求されます。まず単純な話からいきましょう。

単純な構成を想定する場合、冗長性のためには、リソースを2倍用意する必要があります。これはミラー構成の場合で、たとえば「6台で構成したエッジノードのうち2台が故障しても問題が起きない」という構成を取るのであれば、1.5倍の投資で済むことになります。「⁠許容できる故障台数分のリソースを余計に用意する」という支払いが発生します。

また「必要になったとき」に動的にリソースを伸長して割り当てる（オートスケーリングを実装しておく）という手もありますが、動的なリソース割り当てには時間がかかり、また、非機能要件によってはこの時間が許容できない可能性もあります。そして安易に設計されたシステムは動的なリソース割り当てに対応できません。オートスケーリング的な動作を実現するには、事前に設計にコストを割いておく必要があります。つまり、この面でも「追加のコスト」を支払うことになります。

「冗長構成にすること」で発生する支払いには、他の形もあります。

まずひとつは管理コストを増大させることです。こうした「故障に備える」タイプの実装に使われる代表例である（Ubuntuのリリースノートに毎回顔を出すことでお馴染みの）HAProxyを例に考えてみましょう。すべてのソフトウェアにはバグがあります。そしてHAProxyもソフトウェアで、https://www.haproxy.org/bugs/index.html にknown bugリストがあります。つまり、「⁠冗長性を提供するためのソフトウェア」を追加で利用することは、「⁠そのソフトウェアパッケージを適切にアップデートする」だけでなく、「⁠バグが生まれる要素が増えることを受け入れる」というコストを支払う必要が生まれます。

そして、冗長構成にすることで発生する別の問題もあります。多くのソフトウェアは複雑になればなるほど、より厄介なバグを生み出す傾向があります。冗長構成にするためのソフトウェアもこの例外ではありませんし、さらには「故障」も一通りではありません。

「故障」が単純に動作しなくなるタイプの故障であれば良いのですが、現実的には「動作しているが応答を返すのに時間がかかる」「⁠エラーがランダムに返る」「⁠見た目動いているが、内部のカウンターが機能していない」といった、厄介な振る舞いに至ることがあります。さらにはインターネットの複雑性の中では、TCPによる通信もそれだけでは信用できません。「⁠クライアント側は正しくリクエストを送っているつもりだが、サーバーには届かない」といった振る舞いもありえます。

こうした問題に対して、冗長性を提供しようとする場合、「⁠うまく動いていない」ことを判断してサーバーノードを意図的に停止するといった実装が必要になります。また冗長化の実現方法によっては、「⁠稼働系と待機系に分けておき、稼働系が停止したら待機系が動き出す」といった方法が必要になることもあります（たとえば同時にライト可能な状態を作れないデータベースのようなシステム⁠）⁠。

「切り替え」を伴うシステムにはやはりバグが紛れ込む可能性があり、STONITHのような「誤って動作する冗長性」を強制的に停止する仕組みが必要になります。そして「強制的に停止する仕組み」にもやはりバグが紛れ込む可能性があり……と、無限に問題が発散することもしばしば生じます。

さらに「安全な」システムのためには、「⁠実際に稼働している場所」の冗長性、つまり地理的な分散が必要になることもあります。日本国内で稼働するサービスであれば、関東と関西に分離する、といった設計が一般的です。

しかし、地理的に分散すると今度は「どのようにデータを同期するか」「⁠そもそもデータが同期されていなくても正常動作させるにはどうするか」という命題を解く必要が出てきます。

……といったような形で冗長構成、あるいは非機能要件はきわめて厄介な特性を持ちます。こうした問題は「そのシステムにどのような機能が求められるのか」を整理することでしか解決できません。また、頻繁なセキュリティアップデートに対応するためにも、「⁠必要な可用性」がどのレベルなのかを考える必要もあります。管理しているシステムについてこれらが未整理な場合は、すぐに着手したほうが良いでしょう。