Die Woche: Alte Zöpfe abschneiden

Einige Fedora-Entwickler wollen die traditionelle Struktur des Linux-Dateisystems vereinfachen. Eine gute Idee, findet Oliver Diedrich: Man muss sich auch mal trauen, alte Zöpfe abzuschneiden.

In Pocket speichern vorlesen Druckansicht 284 Kommentare lesen
Lesezeit: 4 Min.
Von
  • Dr. Oliver Diedrich

Derzeit diskutieren die Fedora-Entwickler, die Struktur des Linux-Dateisystems umzukrempeln: Alle ausführbaren Programme sollen nach /usr/bin. Keine Unterscheidung mehr zwischen /bin und /usr/bin, und auch die Differenzierung zwischen /sbin und /bin respektive /usr/sbin und /usr/bin soll bei dieser Gelegenheit fallen – alles wird eins. Gute Idee, finde ich: Man muss sich auch mal trauen, alte Zöpfe abzuschneiden.

sbin, das stand in der Unix-Welt ursprünglich mal für "static binaries", also statisch gelinkte Programme (im Unterschied zu Programmen, die beim Start dynamisch gegen Bibliotheken gelinkt werden). Statisch gelinkte Binaries kommen aber schon lange kaum noch vor, daher hat sich die Bedeutung von sbin zu "system binaries" gewandelt: Hier gehören laut dem nicht mehr ganz frischen Filesystem Hierarchy Standard 2.3 "Programme zur Systemverwaltung (und andere 'root-only'-Programme)" hin (auch der kommende FHS 3.0 differenziert noch zwischen sbin und bin).

Lange war es daher üblich, dass /sbin und /usr/sbin nur bei root im Pfad der ausführbaren Programme stehen – alle anderen User mussten lspci explizit mit Pfadangabe als /usr/sbin/lspci aufrufen, um eine Liste der PCI-Geräte zu sehen. root-only, also auf Superuser-Rechte angewiesen, sind nämlich keineswegs alle Programme in sbin, da sind die Linux-Distributionen schon seit jeher wenig konsequent. Und seit man sich kaum noch als root einloggt, sondern Systemverwaltungaufgaben mit sudo aus einem normalen Account heraus erledigt, stehen /sbin und /usr/sbin bei den meisten Distributionen auch im Pfad der normalen User. Die sowieso ziemlich artifizielle Trennung zwischen bin und sbin ist damit in der Praxis völlig bedeutungslos geworden.

Auch dass es die Verzeichnisse bin, sbin und lib zweimal gibt – einmal im Root-Verzeichnis, einmal in /usr –, hat historische Gründe: /usr kann wie jedes andere Verzeichnis auch auf ein eigenes Dateisystem ausgelagert werden, das beim Systemstart zunächst von einer lokalen Platte oder übers Netz eingebunden werden muss. Hardwaretreiber und die Systemprogramme zum Aufsetzen des Netzes und zum Mounten dürfen also nicht unter /usr liegen; ebenso wenig wie die Shell und die wichtigsten Tools zur Arbeit auf der Kommandozeile, falls das Mounten von /usr nicht klappt und man das System reparieren muss.

Ein wirklich funktionierendes Linux-System kriegt man heutzutage ohne /usr freilich gar nicht mehr zusammen – schauen Sie sich mal an, wie viele Programme in /usr/bin oder /usr/sbin von Init-/Upstart-/Systemd-Skripten oder Udev-Regeln aufgerufen werden: Ohne /usr erhält man heutzutage lediglich ein rudimentäres System mit einer Shell und den wichtigsten Tools zur Systemwartung, mehr nicht. Ein solches Reparatursystem steht aber schon in der Init-RAM-Disk zur Verfügung. Dort kann man neben dem Root-Dateisystem auch – falls nötig – /usr mounten, bevor der Init-Prozess startet, und bei Problemen eine Shell zur ersten Hilfe bereitstellen.

Das Charmante an der /usr/bin-Idee: Linux wird einfacher. Praktisch der gesamte unveränderliche Teil des Betriebssystem würde in /usr stecken, die (rechnerspezifische) Konfiguration in /etc, die (ebenfalls rechnerspezifischen) zum Booten nötigen Teile in /boot. System-Updates würden nur noch diese drei Verzeichnisse betreffen, die Installation zusätzlicher Programme meist nur /usr. Mit einem modernen Dateisystem wie Btrfs kann man so vor Updates oder der Installation neuer Programme sehr einfach einen Snapshots anlegen, um bei Problemen zum vorherigen Stand zurückkehren zu können. Und nicht zuletzt hat die Idee das Potenzial, die diversen Linux-Distributionen ein bisschen weiter zu harmonisieren – die sind sich nämlich keineswegs einig darin, was nach sbin und was nach bin, was nach / und was nach /usr gehört.

Und was spricht dagegen? Die hässlichen Details – beispielsweise Unmengen von Shell-Skripten, die mit #!/bin/sh starten. Die zahlreichen Programmpakete, die angepasst werden müssten. Programme zur Systemdiagnose, die sich darauf verlassen, dass sie fdisk in /sbin finden. Aber all diese Probleme lassen sich mit symbolischen Links, die nach /usr/sbin zeigen, erschlagen. Der Rest ist dann Fleißarbeit. Und den Filesystem Hierarchy Standard kann man anpassen: Version 3.0 ist nur ein Draft und noch nicht verabschiedet. (odi)