もうdistro-hoppingはしない ~ yeah ~ Ubuntuは再インストールなしで一年以上もった。LVMを有効にして、二つのハードディスクをつなぎ合わせたおかげで、容量不安がなくなったからだと思う。
そしてArch LinuxとFedoraに対する私の態度はこうだ：もう麻痺した。こういうシステムは本当にメイン環境では使えない。あまり使わない別のノートパソコンにインストールして、毎週一回更新するだけでも何かが壊れる。もう呆れるしかない。欲もこだわりもなく、デフォルトのGNOMEやXFCEデスクトップで満足できるユーザーでもないかぎり、ローリングリリースを長く安心して使えるとは期待しないほうがいい。
1. KDEが必要だ、だが安定性も必要だ#
答えのない答え。
KDEを使ったら本当に戻れない。KDEエコシステムのプログラムは、複雑な作業をするとき本当に使いやすい。何度もGNOMEを使おうとはしたが、そのデザインは…すまない、私は芸術家ではないので、デスクトップPCで使うには本当に向いていない。あまり起動しないノートパソコンでたまに使うくらいでいい。
そして私は、KDEにはずっと「サプライズ」をもたらすシステムであってほしい。どう言えばいいか、Pixelスマホユーザーが不定期にPixel Dropのサプライズパックを受け取れるような感覚だ。更新のたびにユーザーへ新しい体験を与え続ける。GNOMEのように要素の位置を少し動かすだけではない。たとえば最近のKDE 6.4の更新では、スクリーンショットツールSpectacleに、画像内のQR Codeを自動認識する便利機能が追加された。さらにDolphinの右クリックには、フォルダーへ色ラベルを付ける機能も追加された！だから私が以下のような操作をするのも、理解しがたいことではない。
現在使っているシステムはUbuntuとKDE Neonの混合体だ（よい子は真似しないでね）。うん、当初はUbuntu 22.04 ISOでインストールした。LVMを有効にしやすかったからだ。大バージョンアップで24.04へ移行するのも無事に乗り切った。それからKDEデスクトップが欲しくなり、手動でkubuntu-desktopをインストールし、GNOMEデスクトップを削除した。その後また更新が遅すぎると感じた。Kubuntu 24.04はまだPlasma 5.27だったので…KDE NeonのISOでシステムを再インストールするのも面倒だった。そこで、最新のPlasma 6を取得できるように、手動でAPTにKDE Neonのパッケージリポジトリを追加した。
參考：加入套件庫，將Kubuntu轉換為KDE Neon，安裝最新版Plasma桌面套件
その結果、デスクトップ環境はローリング更新で、それ以外のパッケージは安定更新というシステムになった。
実際のところ、この使い方は妙に安定している。KVM仮想マシン、Docker、Podmanといった基本的なシステムコンポーネントは安定版を維持しつつ、最新KDEデスクトップを試せる。
本来ならDebianでもこの操作を実現できたはずだ。Norbert Preiningという開発者がいて、最新版KDEパッケージをDebian Stable向けに提供していた。しかし数年前、彼はもうやらないと言った（詳しくはFuture of “my” packages in Debian | There and back again）。だから私はUbuntuを使うしかなかった。実のところ、Snapの脅威はまだそこまで深刻ではない。多くのプログラムにはdebファイルが見つかるし、彼らはそこまで早くUbuntuに同化されてはいない。
将来、KDE開発チームはコードネームProject BananaのKDE Linuxディストリビューションをリリースする予定だ。Ubuntu LTSのパッケージが古すぎて、KDE開発者が旧版パッケージ向けにpatchを当てないとビルドを通せないという苦境を解決するためである。では、そのときKDE Neonは見捨てられるのだろうか？immutable distroになるらしいが、私はまだその設計を受け入れられるほど進歩していないんだあああ。見守ろう。
はいはい、実際のところUbuntu + KDE Neonのパッケージリポジトリというのは、非常に不安定な構成だ。KDE Neonのパッケージ更新は頻繁すぎて、確かにKubuntu LTSよりbugが出やすい。そこへWaylandという要素が加わるとさらに不安定になる。たとえばファイル移動後にアイコンをクリックして確認するとタスクバーがクラッシュする（今はSDDM画面へ戻るのではなく、自動で再起動する）。あるいはFcitx5で入力するとクラッシュする。最悪の場合はKWinがクラッシュして、ついでにすべてのウィンドウを道連れにする。さらにKDE 6の細部設計は数か月ごとに一度変わるので、再適応が必要になる。
この使い方は非常に運に左右される。特定のいくつかのKDEバージョンは安定していても、次の更新でまた狂ったようにクラッシュし始めるかもしれない。だから将来的には、もう少し安定したデスクトップ環境へ戻すか、KDE X11セッションを使い続けることを考えるかもしれない —— これはローリング更新のモードであっても壊れにくい。
2. Waylandの安定性について#
GNOMEはかなり早い段階から人々にWaylandを使わせてきたが、今やKDEもようやく追いついた。私が言っているのは、安定性で人を説得するということであって、X11を廃棄して無理やり使わせるということではない。
GNOME開発者はGNOME 50でX11セッションを完全に捨てる準備をしている。現在のGNOME 48は、すでにX.Orgパッケージへ依存しなくてもビルドできる。さらにGNOME 42以降、ほとんどの時期で安定したWaylandセッションになっているので、彼らには確かにそうする資格がある。これは私がサブPCでFedoraを数年使って得た感想だ。X11旧時代のものの中には、Waylandにまだ対応するプロトコルがないものもある（たとえば色管理プロトコルは最近ようやくmergeされたし、QT6 WaylandはGNOME Waylandでのテーマ描画が少し変だ）。それでもGNOME Waylandは、X11より劣っていると気づかせないほどには安定している。
しかも、ますます多くのものがWaylandへ寄ってきている。たとえばタッチジェスチャーや自動画面回転（タブレットユーザーには比較的実感があるだろう）、アニメーションもより滑らかだ。X11へ戻すと、かえって遅れた体験を得ることになる。開発者が旧版機能のメンテナンスにまで気を取られるなら割に合わない。それなら消し去ったほうがいい。
ここで良いニュースを一つ差し込む：上流Bug Trackerの報告によると、Chromium 141バージョンはついにデフォルトでWaylandを使って起動するようになった。これで大量のElectronプログラムの性能も、今後数年以内に改善されるだろう。
KDEについては、X11セッション廃棄の明確なスケジュールはまだない。KDE Plasma 7で削除されるのではないかと推測する人もいるが、それだとまた五年待つことになる。これはローリングリリースのスケジュールだけの話で、固定リリースのディストリビューションではさらに長く待たなければならない。
KDE Plasma 6以降、今ではほとんどの時間でWaylandを使っており、画面ティアリング問題を完全に回避している。過去に遭遇した多くのbug、たとえばフォントのぼやけやGTKテーマの乱れも徐々に修正されてきた。今では一か月以上Waylandを使い続けてもX11へ戻さずに済んでいる。Bugの数はすでに耐えられる程度まで減った。
もちろん、私がWaylandは安定していると言うとき、それはKDE 6 Waylandを指している。旧版KDE 5 Waylandは使わないほうがいい。またKDE Neonパッケージがローリング更新である都合上、あるバージョンの更新でWaylandに問題が出た場合、私は相対的に安定しているX11セッションへ切り替える。
KDEの著名なコントリビューターの一人であるNateは、自身のブログAbout Plasma’s X11 sessionで、彼らは今後もしばらくX11をメンテナンスし続けると書いている。なぜなら、有名なSteamOSを含め、まだ多くのディストリビューションがKDE X11をデフォルトオプションとしているからだ。
私は奇妙なグラフィックbugを避けるため、さらに時々Nvidia GPUを全力で搾り取ってAIを走らせる必要があるため、現在もIntelにメイン画面出力を担当させ、Nvidiaをサブモニターに使うという奇妙な方式でコンピューターを操作している。Nvidia PRIMEを利用して、GPU演算が必要なプログラムを走らせている。
3. FreeDesktop標準の重要性を理解し、認識する#
この一年、私は多くの記事にFreeDesktop Specificationsというタグを付けた。標準の重要性を皆に知ってほしかったからだ。だからLinuxの使い方のコツに関する記事を書くとき、どうやるかを説明するだけでなく、なぜそうするのかも説明している。
Linux基金会のFHS（ファイルシステム階層標準）がLinuxルートディレクトリ下の各パスの用途を定めているのに対し、freedesktop.orgの標準がより注目している部分は、グラフィカルインターフェースの操作である。
Linuxプログラムの設定ファイルパスの配置、テーマパス、自動起動プログラムのパス、デスクトップショートカット、デフォルトプログラムの設定にはすべて理由がある。理由もなくそこに置かれているわけではない。各デスクトップ環境は、FreeDesktopが制定した一連のXDG標準に従って設計されており、アプリケーションが従うべき標準を確保している。そうすることで、各自が勝手に作るだけになり、他者と協力する可能性を無視する事態を避けられる。
従うべき標準があることは、Wayland時代においてさらに重要だ。XDG Portalの存在により、Flatpakアプリケーションは統一された経路で機能を呼び出せる。たとえば画面アクセスの申請、スクリーンショット、ファイル読み取り、USBデバイスへのアクセスなどである。
Linuxの断片化問題が深刻であることは知っているし、標準があっても全員に従わせる方法はない。しかし開発者がより多くのディストリビューションのユーザー層を考慮するなら、自分たちでそれに応じた調整を行うだろう。結局、誰もがsuckless.orgエンジニアの思考をしているわけではない。いずれ潮流に従うものだ。
4. コンテナ化について進歩もあり、反省もある#
進歩した部分として、私は徐々にDockerからPodmanへ移行している。Podsの概念の影響を受け、K8sのより高度なコンテナ管理概念を学ぶことも考え始めた。実際のところ私の需要はそこまで大きくないが —— Immichアルバムのようなself-hostedなhobby projectを動かしたいだけだ。ただ、兄貴分のRedHatはPodmanの宣伝にリソースを投資する意欲が比較的あると感じるので、私も歩調を合わせるべきなのだろうと思っている。ただし非常に難しく、Portainerほど使いやすい代替品はまだ見つかっていない。
ああ、CanonicalのSnapは相変わらずクソだ、BJ4。時間があればUbuntu Coreを入れて遊んでみるかもしれない。このシステムは全体がSnapで構成されていると称しており、Linuxカーネルすら一つのSnapで、他のimmutable distroよりも小さなモジュールへ分割できる。ただし彼らはデスクトップ市場には興味がなさそうだ。そうなると、Vanilla OS、openSUSE MicroOS、Fedora Atomicのほうが、より人気のある試用対象かもしれない。
進歩に対する反省として、過去の私はしばらく、すべてのプログラムをFlatpakでコンテナ化すべきだと固執していた。unofficial portのものまで皆に使うよう勧め、それがだめならDistroboxのPodman方式でプログラムを走らせ、ネイティブパッケージマネージャーを消滅させようとしていた。immutable distroを使っているわけでもないのに、彼らのやり方を完全に真似し、この極度に前衛的なやり方を追求していた。
しかし今はもう、そこまで固執していない。Flatpakとデスクトップ統合の技術はずっと改善され続けているが、それでもプログラム開発者が最初からサポートする意欲を持つかどうか次第だ。
思うに、開発者がWine BottlesのようにFlatpakの普及に熱心な人でないかぎり、Flatpakがネイティブパッケージを置き換えられると無理に求めるべきではない。
Flatpakの問題はどこにあるのか？たとえばSteamはいまも半端な状態で、デスクトップへショートカットを追加するにはまだいくつかのquirksを使う必要がある。だから私はユーザーにFlatpak版Steamのインストールを勧めなくなった。
またAndroid Studioもそうだ。プログラムがホームディレクトリのあちこちにゴミを撒き散らす行為はうっとうしいが、Flatpakを使うと開発に余計な困難を増やすだけだ。Visual Studio Codeも同じで、開発作業中にシステムのlibへアクセスしにくいというのは、どう考えても自業自得だろう。
こうした進歩理念に固執しすぎることで生じるshenanigansについては、やはり人民大衆の実際の需要を考慮してから、適切なインストール方法を選ぶほうがよいと思う。だからdebファイルとinstall scriptには今なお用途がある。
簡単に言えば、Flatpakを使うかどうかは、やはり状況次第で決めるべきだ。
しかし、これでも一つの問題は解決できないではないか？Ubuntuのパッケージバージョンが古すぎる場合はどうするのか？どうしようもない、卵炒めでも作るしかない。本当に新バージョンのソフトウェアがどうしても必要なら、ソースコードからコンパイルしてインストールしよう。インストール先のパスを慎重に観察し、記録しておくことだ。私はパッケージマネージャー外のプログラムをすべて~/Applicationsというディレクトリへ放り込み、統一して追跡している。そうすれば後日の管理がしやすい。
どうせLinuxを学ぶ過程で、無数のrm -rf、重要なシステムコンポーネントの誤削除、パッケージ依存関係の爆破によるシステム再インストールを経験すれば、自分のシステムをどう手入れするべきか学ぶことになる。
