Ubuntu 26.10（Stonking）の開発; ロードマップと音声入力

Stonking（Ubuntu 26.10）の開発; ロードマップと音声入力

stonkingのロードマップが公開されました。このロードマップには28.04 LTSまでの全体感が含められており、「⁠次のLTSへの第一歩」としてのstonkingの位置付けが示されています。

まず、28.04 LTSで目指すべきビジョンとして次の4点が挙げられています。

A robust platform built on GNOME（頑強なGNOMEベースのプラットフォーム）
Simple by default, flexible by design（デフォルトではシンプル、設計は柔軟）
A context-aware desktop（コンテキストアウェアなデスクトップ）
A trusted and integrated platform（信頼できる、統合されたプラットフォーム）

それぞれの具体的な説明も行われています。簡単に見ていきましょう。

頑強なGNOMEベースのプラットフォーム：

GNOME 51をstonkingで投入し、dbus-daemonからdbus-brokerへの移行を完了する。
また、RISC-VベースのUbuntu Desktopを投入し、Flutterエコシステムの改善を含めて、WCAG 2.2 AAに準拠するアクセシビリティを提供する。
マルチメディアサポートを改善する。

デフォルトではシンプル、設計は柔軟：

日常的な作業をシンプルにする。
エキスパートが利用する高度な機能を削除するのではなく、柔軟性を提供していく。
パッケージ依存しないApp Centerを開発する。
ドライバー管理機能の改善を行う。
インストーラーの改善によるパーティショニングとストレージ設定のシンプル化、そして初回起動時のオンボーディング体験の更新。

コンテキストアウェアなデスクトップ：

将来の（28.04での）ゴールとして、「⁠ユーザーが何を達成しようとしているのかを理解し、アプリケーション、サービス、そしてデスクトップ環境自体からの情報を組み合わせることで、その達成を支援できるデスクトップ」を開発する。音声認識エンジンによる音声ベースの操作を目指す。オフラインベース。
26.10では音声ベースのテキスト入力機能を実現する。

信頼できる、統合されたプラットフォーム：

authdの強化。Microsoftパスワード認証とMFA認証、そしてIDプロバイダーからUID・GIDを取り込めるようにしつつ、リモート管理アカウントのローカルパスワード認証を無効にする設定を可能にする。
ネットワークにおいてPKCS#11とスマートカード認証をサポートし、YubiKeyなどのハードウェアトークンを用いたVPN認証を実現する。
Ubuntu Certified情報をGNOME設定から参照できるようにする。

またこれら以外に、「⁠Ubuntu Wikiの更新を行い、Windows版Ubuntuのパフォーマンス向上、イメージサイズの最適化、ドキュメントの品質向上、保守性の向上を行う」といったことが示されています。特にポイントとなるのは『コンテキストアウェアデスクトップ⁠』⁠、つまり「ユーザーのやりたいことを先読みする」デスクトップ環境の実現というゴールが設定されていることです。

GNOMEを使う方針とこのゴールが同時に成立するためには、「⁠GNOMEのコンテキスト認識能力を拡張する」という方向性が必須になるはずで、実現すればLinux Desktop業界を大きく動かすことになります（そしてさらに、現時点ではWindowsやmacOS、あるいはUnixlike OSが提供する環境においては「コンテキストアウェア」を実現したものは存在しないので、「⁠それはどういう動作をするデスクトップ環境なのか」という点に、一定の答えを出していく必要があるでしょう⁠）⁠。

stonkingは「このビジョンの一部」という方向性です。具体的にどれがどこまで、という点はまだ明確ではありませんが、開発が順調に進むという前提において、なんらかのローカルAIベースの音声入力機能（Speech To Text）が導入されることになるでしょう。

こうしたロードマップ的なものとは別に、今回もx86-64-v3ベースのパッケージがビルドされていたり、明示されないテストや実験が行われていくことになりそうです。

各種改善と対応の整理

26.04 LTSの振り返りを含めて、いくつかの作業やサマリーの提供が行われています。まず、Ubuntu MATEの26.04での利用法（ISOイメージは提供されないが、パッケージの導入による設定は可能）や後任となる開発者が決まりつつあることが表明されています。

OEMリリースにおける事前テストツールを兼ねたシステムの動作テストツール、Checkbox 7.3.0がリリースされています。AMD Sorano（EPYC 8005シリーズ）への対応とi.MX8MMのカメラデバイスのサポートが謳われており、また、「⁠Ubuntu Core 26向け」と「CE-OEM 26」[1]テストセットが提供されることが示されています。Ubuntu 26.04 LTSやCore 26ベースのOEM製品が出てくる（そして、その一部はUbuntu Certifiedである）ことが予想されます。

OpenJDK 26の提供も26.04向けに開始されています。OpenJDK 26は中間リリースであり、今年の9月までサポートされます。

また、今後の将来の展望を含めて、AMDのROCmについてのリリース状況が整理されています。26.04 LTSで投入された7.1から今後7.2へのインプレースアップグレードが提供されること、そして7.13や8.0も継続的にサポートされること（そしてそのために、Debianを含めてAMDとの共同作業が継続されること）が提示されています。

その他のニュース

Ubuntu 25.10（⁠“⁠Questing Quokka⁠”⁠）が7月9日にEOLを迎えます。現在利用している場合は26.04 LTSにアップグレードしましょう。
RISC-VサポートがRVA23必須となった背景と、RVA23で実現できる機能について。

注目すべきセキュリティー的な視点：可用性と非機能要件

セキュリティのCIA、つまり「機密性（Confidentiality⁠）⁠」⁠「⁠完全性（Integrity⁠）⁠」⁠「⁠可用性（Availability⁠）⁠」と呼ばれる考え方において、可用性は3つの柱のうちの1つとして扱われています。

一方で可用性に強く結びつく冗長構成のたぐいはいわゆる非機能要件に分類されます。どのような状態が希望されるかを考えるには、相応の知識と哲学が必要になる側面があります。今回と次回は、この要素を考えてみましょう。今回は、「⁠非機能要件」というものの厄介さについてです。

極めて素朴な考え方をすると、可用性のゴールには100%が求められます。一方現実としては、どのようなものもいつか必ず壊れるため、100%をゴールにしてしまうと、決して満たされないゴール、つまりは不可能な目標が作られてしまうことになります。不可能な目標を作ってしまった場合、それは目標としては機能しなくなります。ほとんど無限と言えるようなコストを投入することができれば、「⁠表面上」100%の可用性を満たすことは可能かもしれませんが、費用対効果はきわめて悪く、また、真に100%の可用性が実現されているのか、それとも運良く何も起きなかっただけなのか（あるいは「何も起きなかったことになった⁠」⁠）のか、区別が付かない状態となります。言い換えれば、「⁠100%を目指すこと」と「それをゴールとすること」は、現実の運用としては切り離される必要があります。

一方で、どのようなハードウェアにも故障する可能性がありますし、複雑なシステムにおいてはトポロジー変更によってネットワークに影響が出ることもありえます。また、ソフトウェアの各種アップデートにおいては停止と再起動が必要になることは前提ですし、データの整合性を保持するためにはデータストアに静止点が求められることもあります。あるいは、そもそものシステムとして、ノンアトミックな処理を持たないようにすること、あるいは副作用のないリトライを実現することは困難です。

この意味では「必ず障害が起きうるもの」を用いて、しかし「100%の可用性があることが望まれるものを作る」という、現実的に不可能な構造が生まれます。一方でこれは、命題の認識が正しくない、つまりは理解の不足によって生まれる、見た目上の矛盾です。

現実的には、可用性ゴールによって守りたいものは100%の可用性そのものよりは、「⁠利用者が期待する結果が、必要な時間内に返ること」です。Webシステムにおいては「⁠『⁠基本的に』それなりの速度で応答が返ること」が重要である一方、『⁠まれに』「⁠一時的に動作しないこと」は許容されることがあります。ユーザーが同じ操作をもう一度行い、そのタイミングで処理が完了すれば良いからです。あるいはECサイトのようなものであれば、「⁠一時的に注文できない」あるいは「注文はできるが物品が来るまで時間がかかる」といった形で、システム全てが常時、100%の可用性を保持する必要はありません。

一方、車載、特に自動運転のような文脈では、「⁠システムが応答しない」ことは許容できません。十分な速度が出ているときに、必要なタイミングでブレーキが踏まれなければ交通事故が生じることになるからです。このような場合、つまり「ブレーキを効かせられないかもしれない」「⁠システムが正常に動かない可能性がある」といったことを事前に検知し、そもそもエンジンを始動しない、という動作をもたらす必要があります。

こうしたものを整理し、ステークホルダー間で合意を作ることが「非機能要件の整理」と呼ばれるタスクです。非機能要件は「明確な機能ではない」がゆえに、幻想と思い込み、無理解によって過剰な期待が寄せられ、それゆえに妥当なシステムの構築や運用を阻みます。この問題に向き合うためには、無邪気な期待（例：100%の可用性）が現実的には高価につく、という認識のもと、「⁠本当に必要な内容」を整理する必要があります。厄介なものだと言えるでしょう。