GoboLinux, eine experimentelle Linux-Distribution, die das Dateisystem als Paketdatenbank nutzt

 (gobolinux.org)
3 Punkte von GN⁺ 2024-03-01 | 1 Kommentare | Auf WhatsApp teilen
  • Eine experimentelle Distribution, die die Verzeichnis-Konventionen klassischer Linux-Distributionen stark verändert und es ermöglicht, die Systemstruktur anhand von programmbezogenen Verzeichnissen zu verstehen
  • Anstelle einer separaten Paketdatenbank dient das Dateisystem selbst als Datenbank; Programme werden versionsbezogen in Pfaden wie /Programs/Nano/8.3 abgelegt
  • Das aktuelle Release 017.01 ist ein Bugfix-Update, das rund fünf Jahre nach dem vorherigen ISO-Release erscheint und einige wichtige Probleme aus dieser Zeit behebt
  • Gründer Hisham Muhammad zieht sich nach 25 Jahren aus dem Betrieb zurück, und das Projekt wird von GitHub-Nutzer @fyrak1s weitergeführt
  • Das System lässt sich direkt als Live-Umgebung ausführen oder auf einer Festplatte installieren, sodass sich die von üblichen Distributionen abweichende Dateisystemstruktur praktisch ausprobieren lässt

Pakete über das Dateisystem organisieren

  • GoboLinux ist eine experimentelle Linux-Distribution, die die gesamte Dateisystem-Hierarchie neu definiert
  • Der Kern ist eine Struktur, die das Dateisystem als Datenbank verwendet, statt eine separate Paketdatenbank zu führen
    • Jedes Programm befindet sich in seinem eigenen Verzeichnis
    • Beispiele sind /Programs/Nano/8.3 und /Programs/GCC/14.2.0
  • Da sich die Struktur von typischen Linux-Distributionen unterscheidet, sollten neue Nutzer am besten zuerst die Dokumentation lesen

Release 017.01 und Wechsel der Projektleitung

  • Die aktuelle Version ist 017.01
    • Eine Live-Umgebung, die von USB-Laufwerken und DVDs gestartet werden kann
    • Kann auch auf einer Festplatte installiert werden
    • Das ISO ist unter Downloads verfügbar
  • v017.01 ist ein Bugfix-Update, das nach einer Pause von rund fünf Jahren erschienen ist
    • Es behebt einige wichtige Probleme, die seit dem vorherigen ISO-Release aufgetreten sind
    • Detaillierte Änderungen finden sich in den release notes
  • Auch die Projektorganisation hat sich verändert
    • Gründer und langjähriger Leiter von GoboLinux, Hisham Muhammad, ist offiziell zurückgetreten
    • Das Projekt wird unter der Leitung von @fyrak1s fortgeführt
    • Lucas Correia Villa Real, alias paranoidd, hat GoboLinux bis Juni 2021 gemeinsam mit Hisham gepflegt
  • Die Community ist auf Chat, Forum und Wiki verteilt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-01
Hacker-News-Meinungen

  • Wenn man beim Design von GoboLinux eine starke spontane Abwehrreaktion verspürt, enthält das 20 Jahre alte Dokument „I am not clueless“¹ ziemlich viel Hintergrund und Logik dazu.
    Ganz verschwunden ist diese Abwehr bei mir noch nicht, aber sie ist nicht mehr so stark wie früher ;)
    ¹ https://gobolinux.org/doc/articles/clueless.html

    • Der Ton des Textes erinnert an die Dokus von HTMX oder Tailwind.
      Zusammengefasst etwa: „Wir wissen, dass wir anders sind. Es ist sehr einfach. Es mag ungewohnt sein, ist aber leicht zu verstehen und zu handhaben. Man muss es nicht nutzen. Uns gefällt es so und wir sind zufrieden.“
    • Im verlinkten Artikel heißt es im Abschnitt make all programs relocatable, man müsse alle Apps mit libprefix neu schreiben; ich frage mich, was hier mit libprefix gemeint ist.
      Über die Websuche finde ich dazu keine brauchbaren Ergebnisse.
    • Ich frage mich, ob ein großer Teil dieser reflexhaften Ablehnung nicht eher vom äußeren Design als von funktionalen Aspekten kommt.
      Zum Beispiel rührt ein großer Teil der ersten Reaktion von der Großschreibung her: Programs mit großem P erinnert an Windows’ Program Files und löst emotional Ablehnung aus.
      Wenn man statt libx11 LibX11 eingeben müsste, wäre das wohl auch etwas nervig.
      Linux-Dateisysteme unterscheiden normalerweise Groß- und Kleinschreibung, aber Paketnamen werden wohl Duplikate vermeiden, die sich nur dadurch unterscheiden, und bei einer Distribution, die eine benutzerfreundliche Hierarchie anstrebt, scheint es auch unwahrscheinlich, dass sie im Root Verzeichnisse anlegt, die sich nur in der Groß-/Kleinschreibung unterscheiden.
      Trotzdem: Wenn die Beispiele /packages/libx11/1.6.9 und /packages/gcc/9.2.0 gewesen wären, wäre die erste Reaktion wohl deutlich schwächer ausgefallen, und die Vorteile wären mit solchen Namen überhaupt nicht geringer gewesen.

  • Es ist wirklich schade, dass sich die Ideen von GoboLinux in der Mainstream-Linux-Community nicht durchgesetzt haben.
    Die Dateisystemstruktur von Linux ist ein komplettes Durcheinander.

    • Zustimmung, aber es freut mich zu sehen, dass Nix, Guix und Spack, womit ich am meisten arbeite, im Grunde dieselbe Richtung einschlagen und immer mehr an Fahrt gewinnen.
      Es korrekt zum Laufen zu bringen ist nie trivial, und es effizient zu machen ist noch schwieriger.
      Erst in den letzten Jahren habe ich das Gefühl, dass dieses Modell für die Verteilung der meisten Software tatsächlich in die Nähe eines wartbaren Zustands gekommen ist.
    • Nix wird immer beliebter.
      Beim GoboLinux-Modell muss man Versionsverzeichnisse wie /Programs/Xorg/7.0 manuell verwalten; Nix beseitigt dieses Problem, indem es den Installationspfad eines Pakets aus dem Hash des Build-Rezepts ableitet.
    • Im Moment ergeben für mich konsistent eigentlich nur /home und /tmp Sinn.
      Der Rest ist eher eine Rumpelkammer, in die man alles irgendwo hineinlegt.
    • Diese Ideen haben mich auf jeden Fall inspiriert.
      GoboLinux war das erste Projekt, das mir gezeigt hat, dass man unter Linux wirklich machen kann, was man will.
    • /opt und /srv sowie je nach Geschmack /usr/local/opt bieten durchaus einige der Vorteile, Komponenten wie bei GoboLinux einzeln zu verwalten.
      Aus Sicht einer Distribution ergibt das alles auf seine Weise Sinn.
      Wenn man dpkg -S this-file eingibt, sieht man schnell, warum eine Datei unter /usr existiert, und die Distribution übernimmt die Rolle, das Gesamtbild zu zeichnen.
      Ich frage mich, welchen Teil du für das größte Durcheinander hältst.

  • Interessant ist, dass die Kompatibilität mit dem Unix-Erbe transparent erhalten bleibt, indem traditionelle Pfade auf die entsprechenden GoboLinux-Pfade abgebildet werden.
    Es gibt keine besondere Magie: /bin ist ein Link auf /System/Index/bin, und /usr/bin sowie /usr/sbin ebenso, sodass alle „Binary“-Verzeichnisse auf denselben Ort zeigen.
    Dadurch funktioniert eine Datei unabhängig davon, über welchen Standardpfad man darauf zugreift; damit kann es sogar kompatibler sein als eine normale Distribution, bei der eine Datei tatsächlich unter /usr/local/bin/foo liegt, ein Skript aber /usr/bin/foo referenziert und dadurch bricht.

  • Aus Unwissen gefragt: Funktioniert macOS bis zu einem gewissen Grad so?
    Ich fand es wirklich gut, dass Anwendungen immer wie eine einzelne „Datei“ wirken, die man per Drag-and-drop verwaltet.
    Wenn ich unter Ubuntu herausfinden will, wo etwas liegt und wohin es installiert wird, fühle ich mich wie ein Idiot.

    • Das Problem, unter Ubuntu herauszufinden, was wo liegt und wohin es kommt, wird dadurch noch schlimmer, dass Linux-Dateimanager versuchen, Teile des Dateisystems auszublenden, die nicht der Home-Ordner oder gemountete Laufwerke sind.
      Ich verstehe, warum sie das tun.
      Die Verzeichnisstruktur einer durchschnittlichen Linux-Installation ist selbst für technisch versierte Leute ein verwirrendes Labyrinth, und für die normalen Nutzer, auf die große Distributionen zielen, erst recht.
      Am Ende behandelt das aber Symptome statt Ursachen, und ich denke, mehr Linux-Distributionen sollten ernsthaft darüber nachdenken, die Dateisystemstruktur so zu modernisieren wie Gobo.
      Ich hätte auch Lust, das selbst auszuprobieren.
      Ziel wäre eine Struktur, die vernünftig selbsterklärend ist, Anfänger von gefährlichen Bereichen fernhält und bei der es kein Problem ist, wenn der Dateimanager fast nichts versteckt.
    • Die Bundles von macOS waren und sind eine gute Idee, aber Apps verstreuen trotzdem normalerweise Dinge an seltsamen Orten wie ~/Library.
      Interessant wird es bei Fällen wie dem Minecraft-Launcher, bei dem alles inklusive Welten und Spielständen im Bundle steckt.
    • Im Prinzip stimme ich zu, dass Anwendungen wie eine einzelne „Datei“ wirken, aber in der Praxis legen viele Apps diverse Dateien in ~/Library und /Library ab.
      Auch unter macOS ist es nicht selten, dass man zum Entfernen mancher Apps mehrstufigen Anleitungen zum manuellen Löschen folgen muss.
      Besonders relevant ist das bei Apps, die Login-Items hinzufügen.
      „Programme hinzufügen/entfernen“ unter Windows bietet immerhin eine zentrale Stelle, um die Deinstallation auszuführen, und die meisten Apps halten sich ordentlich daran.
    • Unter Fedora ist die Abfrage der rpm-Datenbank einfach.
      Kann man mit dpkg nicht dasselbe tun?
    • Genau das hasse ich am Mac wirklich.

  • Dass der erste Verzeichnisname mit einem Großbuchstaben beginnt, gefällt mir nicht besonders.
    Beim Navigieren durch Pfade fühlt es sich wie zusätzlicher Aufwand an, und jedes Mal zusammen mit einem Buchstaben oder einer Zahl die Umschalttaste drücken zu müssen, ist im alltäglichen Kommandozeilengebrauch ziemlich lästig.

    • Laut dem oben verlinkten Artikel braucht die Eingabe von /Programs in einer richtig konfigurierten Shell, wie der Standard-Shell von GoboLinux, exakt genauso viele Tastenanschläge wie /usr.
      Slash, kleines p, Tab reicht.
    • Warum stört das beim Navigieren in PowerShell oder cmd.exe überhaupt nicht? Weil die Shell hilft.
      Sie zwingt einen nicht, Usability zu opfern, um die kostbaren Ticks und den Speicher eines PDP-11 zu sparen.
      Ich finde es immer wieder amüsant, dass die Fans von „Groß-/Kleinschreibung ist das Beste!“ übersehen, dass das ursprünglich nur aus den Beschränkungen des Systems entstanden ist.
      Das ist kein Feature.
      Außerdem wird dieser Punkt ausdrücklich behandelt.
      Schon set completion-ignore-case On macht das Leben deutlich angenehmer.
      Denn dann muss man auch ohne GoboLinux bei jedem Dateinamen, der mit einem Großbuchstaben beginnt, einmal weniger Shift drücken.
      Oder man lebt eben weiter wie 1977.
      Dein VT100, deine Regeln.
      Später habe ich dann die Aussage gesehen: „Warum installiert man eine andere Shell, statt für normales Navigieren einfach bash zu verwenden?“ — das heißt im Grunde, dass man nicht einmal die eigene Shell richtig kennt.
    • Als Konvention, mit der man auf einen Blick erkennt, ob es ein Verzeichnis oder eine normale Datei ist, gefällt es mir.
      Außerdem kann jede Shell eine Auto-Vervollständigung ohne Beachtung der Groß-/Kleinschreibung anbieten, und Fish macht das standardmäßig.
    • Die Großschreibung dient dazu, Konflikte mit FSH-/Legacy-Verzeichnissen zu vermeiden.
    • Gefällt mir nicht.
      Wirkt nach Windows.

  • Dieses Projekt hat das Potenzial, unsere kognitive Last deutlich zu senken.
    Ich hoffe, es hat Erfolg.
    Edit: Wie ich jetzt sehe, ist das ein 20 Jahre altes Projekt.

  • So vernünftig, dass einem fast die Tränen kommen.
    Das Deduplizieren mehrerer Kopien von Bibliotheken sollte, wenn es wirklich nötig ist, vom Dateisystem erledigt werden.
    Am Ende ist es Duplikation auf Dateiebene, also sollte sie auf dieser Ebene gelöst werden.

  • Wirklich schlechte Closed-Source-Anwendungen stellen viel zu viele Erwartungen an das System des Nutzers.
    Der Steam-Client ist so ein Beispiel: Er liefert kein sh-Skript, sondern ein bash-Skript, setzt wegen der Anforderungen an Linux-Mount-User-Space-Container stark ein Debian/Ubuntu-artiges Datei-Layout voraus und verlangt sogar GNU-spezifische Sonderoptionen für mehrere Befehle.
    Dazu kommen viele 32-Bit-Bibliotheken.
    Immerhin scheint die ABI noch unter Kontrolle zu sein, vermutlich verwenden sie die .symver-Direktive von binutils gas.
    Zumindest wird das aktuelle Chaos gerade von Steam in unseren Rachen gedrückt, und wenn eine Distribution nicht gerade ohne Spiele auskommt, ist es schwer zu vermeiden.

    • Die meisten Menschen spielen nicht, und selbst unter Linux-Nutzern werden viele vermutlich von vornherein keine proprietären Apps verwenden.
      Selbst innerhalb der Gamer-Gruppe dürfte ein erheblicher Teil einen separaten, dedizierten Gaming-PC haben.

  • Ich wünschte, jemand, der viel klüger ist als ich, würde erklären, warum das besser ist als snap/Flatpak oder Distributionen wie NixOS, oder ob es das überhaupt ist.
    Ohne es tief verstanden zu haben, wirkt dieser Ansatz äußerlich am einfachsten.
    Natürlich sage ich das unter der Annahme meiner eigenen Wissenslücken.

    • Wenn es nur darum geht, jede App in ihren eigenen Ordner zu legen, reicht das allein nicht für Isolation aus und kann, je nachdem, wie weit man es treibt, enorm verschwenderisch sein.
      Dass Flatpak und NixOS komplexer sind, hat gute Gründe.
      Zum Beispiel speichern sie exakt dieselbe Version von Abhängigkeiten nicht mehrfach auf der Festplatte.
    • snap und Flatpak sind stärker auf Distribution ausgerichtet und „sandboxed“.
      Die Anführungszeichen setze ich wegen der Sicherheitsprobleme.
      NixOS bricht die Kompatibilität mit bestehenden Programmen, Gobo dagegen nicht.
      Allerdings ist das Paket-Repository von NixOS überwältigend viel besser gepflegt als das von Gobo; bei Gobo ist es unvollständig und hinkt um Jahre hinterher.
      Trotzdem liegen alle hier erwähnten Ansätze hinter der Art zurück, wie Android Apps speichert.
      Unter Android kann jede Anwendung als einfach zu verteilende Einzeldatei ausgeliefert werden, ist ordentlich sandboxed und hat ihr eigenes Verzeichnis.
      Ein weiterer Punkt, den die anderen Ansätze übersehen: Jede App hat unter ihrem App-Verzeichnis ein Unterverzeichnis zum Speichern ihres eigenen Zustands, und das ist zudem pro Nutzer getrennt.

  • Die GoboLinux-Entwickler haben ein für Menschen verständliches Dateisystem-Layout wirklich „intelligent“ umgesetzt
    Die heute noch verwendeten alten UNIX-Konventionen wirken ziemlich schwer durchschaubar in einer Zeit, in der es Einschränkungen wie 8.3-Namenslimits, knappen Speicherplatz oder Probleme mit Dateien über 1 GB nicht mehr gibt
    Früher lief auf einem Server, auf dem Versionsverwaltungssoftware gehostet wurde, einige Jahre lang GoboLinux 012 bis 015, und insgesamt war das sehr gut
    Der Haken war, dass man ein Rezept erstellen musste, wenn ein benötigtes Paket fehlte
    Die Rezept-Sprache von GoboLinux selbst war leicht zu verstehen, aber ein einzelnes Paket hing oft von einem guten Dutzend oder mehreren Dutzend Bibliotheken ab, sodass viel Zeit dafür draufging, diese nachzuverfolgen, Versionen abzugleichen, URLs für Bibliotheken und Pakete zu finden und daraus wieder Rezepte zu bauen
    Am Ende bin ich zu Debian gewechselt, zucke aber immer noch zusammen, wenn ich sehe, dass Konfigurationsdateien in /etc liegen und Binärdateien in /usr/bin oder /usr/local/bin landen
    systemd sehe ich eher als lästig und krakenartig an
    Es kommt häufig vor, dass man find benutzt, um die zugehörige .service-Datei zu finden; man kann sich nicht darauf verlassen, dass sie an einer Stelle liegt, und auch die Kommandozeile ist nicht intuitiv
    Im Gegensatz dazu war Gobos Bündel von Skripten zur Verwaltung von Diensten sehr schlicht und leicht zu handhaben
    Trotzdem schlägt die Bequemlichkeit, Benötigtes einfach per apt get oder dpkg -i installieren zu können, das deutlich vernünftigere, intelligente Design von GoboLinux
    Heute ist die Zahl der unterstützten Linux-Distributionen von der früher riesigen Auswahl geschrumpft; fast immer sind Debian oder Ubuntu standardmäßig enthalten, sodass es unwahrscheinlich ist, dass man ein Paket oder Programm nicht installieren kann, selbst wenn es außerhalb der Repositories liegt
    Auch macOS nutzt eindeutig bis zu einem gewissen Grad einen ähnlichen Ansatz wie GoboLinux, und deshalb ließ sich macOS vor den jüngsten, ziemlich nutzerfeindlichen Versionen auf der Kommandozeile recht gut bedienen
    Zum Beispiel liegen USB-Laufwerke unter /Volumes, und Konfigurationsdateien von Programmen unter ~/Library

    • Nebenbei: Wenn ein Dienst geladen ist, reicht systemctl status foo, um ab der zweiten Zeile genau zu erfahren, welche Dateien beteiligt sind
      Zum Beispiel steht in der Ausgabe von systemctl status getty@tty1.service etwas wie Loaded: loaded (/lib/systemd/system/getty@.service; enabled; preset: enabled), sodass man /lib/systemd/system/getty@.service direkt kennt