GoboLinux、ファイルシステムをパッケージDBとして使う実験的なLinuxディストリビューション
(gobolinux.org)- 従来のLinuxディストリビューションのディレクトリ慣習を大きく変え、システム構成をプログラムごとのディレクトリを中心に理解できるようにする実験的なディストリビューション
- 別個のパッケージデータベースの代わりにファイルシステム自体をデータベースとして使い、プログラムは
/Programs/Nano/8.3のようなパスにバージョンごとに配置される - 最新リリース 017.01 は、前回のISOリリースから約5年ぶりとなるバグ修正アップデートで、この間に見つかったいくつかの重要な問題に対処
- 創設者 Hisham Muhammad は25年間の運営から退き、プロジェクトはGitHubユーザー
@fyrak1sが引き継ぐ - Live環境として直接起動することも、ハードドライブにインストールすることもでき、一般的なディストリビューションとは異なるファイルシステム構造を実際に試せる
ファイルシステムでパッケージを構成する方式
- GoboLinux は、ファイルシステム階層全体を再定義する実験的なLinuxディストリビューション
- 中核となるのは、別個のパッケージデータベースを置かずにファイルシステムをデータベースとして使う構造
- 各プログラムは自身のディレクトリに入る
- 例として
/Programs/Nano/8.3、/Programs/GCC/14.2.0がある
- 一般的なLinuxディストリビューションとは構造が異なるため、初めて触れるユーザーは先にドキュメントを読むとよい
017.01リリースと運営体制の移行
- 現在のバージョンは 017.01
- USBドライブやDVDから起動できるLive環境
- ハードドライブにもインストール可能
- ISOは Downloads から入手できる
- v017.01 は約5年の空白を経て登場したバグ修正アップデート
- 前回のISOリリース以降に発生したいくつかの重要な問題に対処
- 詳細な変更点は release notes で確認できる
- プロジェクト運営も変わった
- 創設者であり25年間GoboLinuxを率いてきた Hisham Muhammad が正式に退任
- プロジェクトは
@fyrak1sの運営のもとで継続される - Lucas Correia Villa Real、別名
paranoiddは2021年6月までHishamとともにGoboLinuxを維持してきた
- コミュニティの拠点はチャット、フォーラム、Wikiに分かれている
- Zulip Chat と
irc.libera.chatの#gobolinuxIRCチャンネル - GoboLinux forum
- GoboLinux wiki
- Zulip Chat と
1件のコメント
Hacker Newsのコメント
GoboLinuxの設計に強い反射的な拒否感を覚える人なら、20年前の「I am not clueless」¹という文書に、その背景と論理がかなり多く含まれている
まだ完全に拒否感が消えたわけではないが、以前ほど強くはなくなった ;)
¹ https://gobolinux.org/doc/articles/clueless.html
「私たちが違うことは分かっている。とても単純だ。慣れていないかもしれないが、理解し扱うのは簡単だ。使わなくてもいい。私たちはこれが好きで満足している」くらいに要約できる
make all programs relocatableの部分で、libprefixを使ってすべてのアプリを書き直す必要があると言っているが、ここでのlibprefixが何を意味するのか気になるWeb検索では使えそうな結果が出てこない
たとえば最初の反応のかなりの部分は大文字表記から来ていて、大文字のPの
ProgramsはWindowsのProgram Filesを思い起こさせ、感情的な拒否感を与えるlibx11の代わりにLibX11と入力しなければならないなら、少しイラッとしそうでもあるLinuxのファイルシステムは通常、大文字小文字を区別するが、パッケージ名は大文字小文字だけが違う重複を避けるだろうし、ユーザーフレンドリーな階層を目指すディストリビューションがルートに大文字小文字だけが違うディレクトリを置く可能性も低そうだ
それでも例が
/packages/libx11/1.6.9、/packages/gcc/9.2.0だったなら、初期反応はずっと少なかっただろうし、そのような名前でも利点はまったく減らなかったはずだGoboLinuxのアイデアが主流のLinuxコミュニティに根付かなかったのは本当に残念だ
Linuxのファイルシステム構造は完全にめちゃくちゃだ
きちんと動作させるのは常に些細なことではなく、効率的にするのはさらに難しい
ここ数年になってようやく、大半のソフトウェア配布について、このモデルが実際に保守可能な水準に近づいたと感じている
GoboLinuxモデルでは
/Programs/Xorg/7.0のようなバージョンディレクトリを手動で管理しなければならないが、Nixはパッケージのインストールパスをビルドレシピのハッシュで決め、その問題をなくしている/homeと/tmpくらいだと思う残りは、置きたいものをどこにでも入れるガラクタ置き場に近い
GoboLinuxは、Linuxでは本当に好きなようにやっていいのだと最初に示してくれたプロジェクトだった
/optと/srv、好みによっては/usr/local/optは、GoboLinuxのように構成要素を1つずつ管理する利点をかなり提供しているディストリビューションの観点では、すべてそれなりに理にかなっている
dpkg -S this-fileと打てば、/usr内のファイルがなぜ存在するのかすぐに分かるし、ディストリビューションが全体像を描く役割を果たしているどの部分が最もめちゃくちゃだと見ているのか気になる
従来のパスをGoboLinuxの対応するパスにマッピングして、Unixの遺産との互換性を透過的に保っている点が興味深い
特別な魔法はなく、
/binは/System/Index/binへのリンクで、/usr/binと/usr/sbinも同様にすべての「バイナリ」ディレクトリが同じ場所を指しているそのおかげで、どの標準パスからアクセスしてもファイルが動作するため、実際のファイルは
/usr/local/bin/fooにあるのにスクリプトが/usr/bin/fooを参照して壊れる一般的なディストリビューションより、むしろ互換性が高いかもしれないよく分かっていないので聞くのだが、macOSはある程度こういう形で動いているのか？
アプリケーションが常にドラッグ＆ドロップで管理する1つの「ファイル」のように見える方式は本当に良かった
Ubuntuで何がどこにあり、どこにインストールされるのか把握しようとすると、自分がバカになったように感じる
なぜそうするのかは理解できる
平均的なLinuxインストールのディレクトリ構造は、技術に詳しい人にとっても紛らわしい迷路であり、主要ディストリビューションが対象にする一般ユーザーにとってはさらにひどい
しかし結局それは原因ではなく症状に対処するやり方であり、もっと多くのLinuxディストリビューションがGoboのようにファイルシステム構造の現代化を真剣に考えるべきだと思う
自分で試してみたい気持ちもある
目標は、合理的に自己説明的で、初心者を危険な領域から遠ざけるよう案内し、ファイルマネージャがほとんど何も隠さなくても問題ない構造を作ること
~/Libraryのような変な場所に何かを散らかすMinecraftランチャーのように、バンドルの中にすべてのものやワールド、保存ファイルまで入っている場合は面白くなる
~/Libraryと/Libraryに複数のファイルを置くmacOSでも、一部のアプリを削除するには複数段階の手動削除手順に従わなければならないことは珍しくない
特にログイン項目を追加するアプリならなおさら重要だ
Windowsの「プログラムの追加と削除」は、少なくともアンインストールを実行する中央の場所を提供しており、ほとんどのアプリがその方式にきちんと従っている
dpkgでも同じことはできないのか？最初のディレクトリ名を大文字で始めるのはあまりよくない
パスを探索するときに余計な作業のように感じるし、毎回文字や数字と一緒に Shift を押さなければならないのは、日常的なコマンドライン利用ではかなり面倒
/Programsの入力は/usrとまったく同じキー入力数だというスラッシュ、小文字の p、Tab で済む
使い勝手を犠牲にして PDP-11 の貴重な tick とメモリを節約しろとは強制しない
「大文字小文字の区別こそ最高！」というファンたちが、それはもともとシステムの制約から生まれた結果にすぎないことを見落としているのは、いつ見てもおかしい
機能ではない
さらに、この点は明示的に扱われている
set completion-ignore-case Onだけでも生活はかなり楽になるGoboLinux を使わなくても、大文字で始まるファイル名ごとに Shift を1回押さずに済むから
あるいは、1977年のまま生き続けてもいい
自分の VT100、自分のルールだ
後で「なぜ通常の移動に bash をそのまま使わず別のシェルを入れるのか」という話を見たが、自分のシェルのこともよく分かっていないということだ
また、どのシェルでも大文字小文字を無視する補完は提供できるし、Fish はデフォルトでやってくれる
Windows っぽさが残る
このプロジェクトには、私たちの認知負荷をかなり減らせる可能性がある
成功してほしい
追記: 今見たら20年もののプロジェクトだった
https://github.com/gobolinux/Recipes/commits/master/
あまりにも合理的で涙が出るほど
ライブラリの複数コピーを重複排除する作業は、本当に必要ならファイルシステムが処理すればよい
結局はファイルレベルの重複なので、そのレベルで解決すべき
非常に出来の悪いクローズドソースアプリケーションは、ユーザーのシステムにあまりにも多くを期待する
Steam クライアントがその例で、
shスクリプトではなくbashスクリプトを提供し、Linux のマウントユーザー空間コンテナ要件のために Debian/Ubuntu 式のファイル配置を強く前提とし、複数のコマンドについて GNU 専用の特殊なオプションまで要求する32ビットライブラリも多い
それでも ABI はまだ制御できているようで、おそらく binutils gas の
.symverディレクティブを使っているのだと思う少なくとも現在の混乱は Steam が私たちの喉元に押し込んでいるもので、ゲームをしないディストリビューションでない限り避けにくい
ゲーマー層の中でも、かなりの人は専用のゲーミング PC を別に持っている可能性が高い
私よりずっと賢い人が、これが snap/Flatpak や NixOS のようなディストリビューションよりなぜ優れているのか、あるいは本当に優れているのかを説明してくれるとありがたい
深く理解していない状態で表面的に見ると、この方式がいちばん単純に見える
もちろん、私の知識不足を前提にした話だ
Flatpak と NixOS がより複雑なのには、それなりの理由がある
たとえば、ディスク上でまったく同じバージョンの依存関係を重複して保存しない
引用符を付けたのは、セキュリティ上の問題があるため
NixOS は既存プログラムとの互換性を壊す一方、Gobo はそうではない
しかし NixOS のパッケージリポジトリは Gobo より圧倒的によく管理されており、Gobo 側は不完全で何年も遅れている
それでも、ここで挙げられているものはすべて、Android がアプリを保存する方式より遅れている
Android では各アプリケーションを配布しやすい単一ファイルとして配布でき、適切にサンドボックス化され、自分のディレクトリを持つ
さらに他の方式が見落としている点として、各アプリは自分の状態を保存するためのアプリディレクトリ配下のサブディレクトリを持ち、ユーザーごとにも分けられている
GoboLinux の開発者たちは、人間が理解できるファイルシステム配置を本当に「賢く」作り上げていた
いま使われている旧式の UNIX 慣習は、8.3 形式のファイル名制限、ストレージ不足、1GB 超のファイル問題といった制約がもはやない時代には、かなり分かりにくいものだと思う
以前、バージョン管理ソフトウェアをホストしていたサーバーで GoboLinux 012〜015 を数年動かしていたが、全体として非常に良かった
障害になったのは、必要なパッケージがない場合にレシピを作らなければならない点だった
GoboLinux のレシピ記述言語自体は理解しやすかったが、1つのパッケージが十数個、あるいは数十個のライブラリに依存していることが多く、それを追跡し、バージョンを合わせ、ライブラリやパッケージの URL を探し、さらにレシピを作るのにかなり時間を取られた
結局 Debian に移行したが、今でも設定ファイルが
/etcにあり、バイナリが/usr/binや/usr/local/binに入っているのを見ると身構えてしまうsystemd は面倒でタコのようなものだと見る立場だ
関連する
.serviceファイルを探すためにfindを使うことはよくあり、1か所にあると信じることもできず、コマンドラインも直感的ではないそれに対して Gobo では、サービスを管理するスクリプト群がとても単純で扱いやすかった
それでも、必要なものを
apt getやdpkg -iですぐインストールできる便利さが、GoboLinux のはるかに合理的で賢い設計を上回った最近はサポートされる Linux ディストリビューションの数が、かつての無数の選択肢から減り、ほぼ常に Debian や Ubuntu が標準で含まれるため、リポジトリ外であってもパッケージやプログラムをインストールできない可能性は低い
macOS も確かに GoboLinux と似た方式をある程度採用しており、そのため最近のかなりユーザーに敵対的なバージョンになる前は、コマンドラインから macOS を扱うのはかなり簡単だった
たとえば USB ドライブは
/Volumesにあり、プログラムの設定ファイルは~/Library以下にあるsystemctl status fooを実行するだけで、2行目以降にどのファイルが関係しているかを正確に教えてくれるたとえば
systemctl status getty@tty1.serviceの出力にはLoaded: loaded (/lib/systemd/system/getty@.service; enabled; preset: enabled)のように表示されるので、/lib/systemd/system/getty@.serviceがすぐ分かる