tenacious（Ubuntu 27.04）の開発：渋滞の緩和とUbuntu Core Desktopのリブート
tenaciousの開発がスタートしました。……しかし、Ubuntuのお約束である「Debian sidからの自動的な取り込み」（AutoSync）は有効にされていません。これにより、現状のtenaciousは「ほとんど26.10と差がない」状態です。
これは前回（26.10）の開発において、各種の大規模トランジションが肥大化した結果、-proposedに大量のバックログが生まれ、ある種の「渋滞」が起きた（そして開発終盤になってから一気に「流れ込む」ことになった）問題への対処として事前に整理してからAutoSyncを有効にするというアプローチが採用されているためです。
今回の対応としては、「まず目に見えている小さな問題をクリアリングする」「ffmpeg8から9への移行『だけ』を行う」「boost-defaultを変更する」といった形で行われる見込みです。
また、ubuntu-minimalメタパッケージにおいて、rsyslogを除外することが検討されています。いわく、「Debianではすでに最小構成ではrsyslogは含まれない」「systemd journaldがデフォルトのsyslogエンジンとして十分に機能している」「同じような役割を果たすソフトウェアを複数導入するのは容量のムダ以上にアタックサーフェースを増やすことになる」「ログの調べ方が複数存在するのは混乱のもと」といったもので、どちらかというとなくす方向で議論が進められています。
こうした比較的地味な対応とは別に、大きな開発テーマとしてUbuntu Coreによるイミュータブルデスクトップ、つまりUbuntu Core Desktopの開発のリブートが検討されています。新しいプランでは「汎用のデスクトップ」よりも具体的な3つのターゲットユースケースとして、「Webブラウザーをメインにした環境」「開発者用ワークステーション」「ゲーム用」というテーマが提示されています。
現時点ではまだ「デザインを開始する前」の段階で、「3つのテーマを満たすようにアーキテクチャを検討すること」「『デスクトップ』という機能を実現するために適切に境界を区切り、複数のsnapパッケージを準備すること[1]」「GNOME以外のデスクトップ環境にも対応できるようにすること」などを実現できるようにしたい、という形で目標がセットされ、これから検討が始まります。
なお、「現在のUbuntu Desktopがなくなるわけではない」（Ubuntu Desktop in its present form is not going away）ということも明示されていること、そして道のりが長いことも宣言されており、すぐになにかが置き換わるわけではなさそうですし、tenaciousで完了するようなものでもなさそうです。
まず最初のフェーズとしては、Ubuntu Core 26（26.04をベースにしたUbuntu Core）を利用した「core26」を中心にした「デスクトップ」と、過渡期に利用されるであろう「classic snapを動作させるためのアプローチの探求」[2]となりそうです。野心的なプロジェクトなので、実用的な環境になるかどうかはこれから時間をかけて見いだされることになるでしょう。
[1] 以前に試験的に作られたUbuntu Coreデスクトップは、「デスクトップ」という概念を一つのsnapパッケージに押し込む（Firefoxすらも同じsnapパッケージにひとまとめ）というもので、「必要なパーツをsnapベースで集める」という部分がまったく実現できていませんでした。
[2] snapパッケージは現状無数に存在しますが、多くはclassic confinementを利用したものです。これは新しく開発されるUbuntu Core Desktop環境が期待する「モジュラー構造的な動作が可能な形」ではなく完全に隔離されてしまうだけですし、おそらく画面に表示させることすら厳しい、ということが予想されます。これは既存のパッケージ環境（aptやflatpakなどなど）も同様です。この問題への対応として、Windows上でWSLg上で動作するアプリケーションが「WSL上で動いていてもWindows側でGUIの表示や操作ができる」ように振る舞うのと類似した形で、「表示だけ」Ubuntu Core Desktop上に持ち込ませるという方法が検討されることが示されています。これが実際にどこまで適切に動作するのか、あるいは、いつ試せるようになるのか、といった部分はこれから明らかになるでしょう。
その他のニュース
セキュリティ的な視点：パッケージの自作を検討する
PHPや各種暗号ライブラリなど、様々なソフトウェアに多くの脆弱性が発見されています。Ubuntuのパッケージはこれらに比較的短い対応期間で追従できていますが、対応のための時間を稼ぐために、サービスを停止してメンテナンスにするという判断が行われることもあるでしょう。
一方、そう簡単にメンテナンスに入れるわけにはいかない、常時、必ずサービスが提供されている必要があるサービスというものも相当存在するはずです。最も単純なのは、インターネット経由のサービスを停止し、他の手法によるアクセスだけに限るという方法です。事前にメンテナンスポリシーやビジネス的な判断を決めておけるのであれば、これがもっとも低コストです。
ビジネスのコアがWebベースのサービスの場合、停止する、という判断が取れないこともありえるでしょう。こうした場合は、「最低限の機能」を提供するある種のメンテナンスモードを設計しておき、強い必要のない（しかしセキュリティ的にリスクが生じる）機能を一時的に止める縮退モードを準備しておく、というのが正道です。
しかし、そのような形で防御を固めていたとしても、キーとなるコア機能を止めることが困難であるケースもありえます。そして、そうしたコア機能を構成するソフトウェアの脆弱性対応において、「新しいパッケージが出てくるまでに時間がかかる」ということもありえます。Ubuntuにおいてはuniverseにあるソフトウェアはセキュリティ対応がされるとは限りませんし、mainにあるものであっても、どれぐらいの時間で新しいパッケージを入手できるかはケースバイケースです（“php2shell”のケースでは数十分のオーダーで新しいパッケージが提供されましたが、すべてのケースでここまで速やかにパッケージが投入されるとは限りません）。
こうした場合は「コア機能を構成するパッケージを自組織でも作成できるようにしておく」という方法で、サービス継続性を維持することが定石のひとつです。パッケージの作成には一定の専門知識が必要でしたが、現在では各種コーディングエージェントを用いることで、「自家製パッチ版パッケージ」を作ることは難しくありません。CI/CDや自動テストが十分に充実しているのであれば、リスクを制御した形で利用することもできるでしょう。PHPなどの各種言語処理系、あるいはImageMagickのような画像を処理するもののうち、メモリ安全な言語で書かれていないもの（つまりCやC++を基底とするもの）に依存しているサービスの場合、そしてそれらの処理系がビジネスのコアである場合は、「最後の手段」として準備しておくことを検討しても良いでしょう。