Der Plan: Alle binären Dateien in /bin, /sbin /lib und /lib64 nach /usr verschieben. Aus Gründen der Kompatiblität werden noch symbolische Links zu den binären Dateien angelegt. Angeschoben wurde diese Idee vom Fedora-Projekt. Bei Fedora ist bereits der Umzug voll im Gange. Greg Kroah-Hartman (greg k-h) hat diesen Vorschlag einfach mal in die Mailingliste openSUSE Factory gestellt und wird zur Zeit heiß diskutiert.

Warum macht man das? Die Verzeichnisse /bin, /sbin, /lib und /lib64 waren damals wichtig, wo noch Festplattenspeicher sehr knapp waren. Die Tools und die Bibliotheken standen auf dem System immer zur Verfügung, während man das Verzeichnis /usr aus Platzgründen auf einer anderen Festplatte ausgelagert hatte. Falls das System die Festplatte/Partition für /usr nicht mounten konnte, so hat man noch ein funktionsfähiges System. Außerdem hat man immer noch die Werkzeuge zur Verfügung, um das System zu reparieren.

Würden wir die Trennung weiterhin beibehalten, so muss ich sagen, dass das heutige Linux-System (aus der Sicht von damals) mehr kaputt als ganz ist. Eine Shellanweisung macht es sogar deutlich, wie abhängig wir heute schon vom /usr Verzeichnis sind.

for i in `find /bin /sbin /lib* -type f -executable`; do ldd ${i} 2>/dev/null | grep usr > /dev/null && echo ${i}; done

Auf einem openSUSE 12.1 (64-bit) sieht so aus:

/bin/systemd-notify
/bin/systemctl
/bin/rpm
/sbin/install-info
/lib/systemd/systemd-stdout-syslog-bridge
/lib/systemd/systemd-uaccess
/lib/systemd/systemd-shutdownd
/lib/systemd/systemd-readahead-collect
/lib/systemd/systemd-initctl
/lib/systemd/systemd-readahead-replay
/lib/systemd/systemd-kmsg-syslogd
/lib/udev/iphone-set-info
/lib/udev/udisks-part-id
/lib/udev/ipod-set-info
/lib/udev/mtp-probe
/lib/udev/udisks-probe-sas-expander
/lib/udev/udisks-dm-export
/lib/udev/udev-acl
/lib/udev/udev-configure-printer
/lib/udev/udisks-probe-ata-smart
/lib/libnss_wins.so.2
/lib64/libgudev-1.0.so.0.1.0
/lib64/security/pam_systemd.so
/lib64/security/pam_pwcheck.so
/lib64/security/pam_smbpass.so
/lib64/security/pam_userdb.so
/lib64/security/pam_cracklib.so
/lib64/security/pam_ck_connector.so
/lib64/libnss_wins.so.2

Auch auf einer älteren openSUSE 11.4 (64-bit) sieht es nicht besser aus:

/bin/rpm
/sbin/install-info
/lib/udev/udisks-probe-ata-smart
/lib/udev/mobile-action-modeswitch
/lib/udev/hid2hci
/lib/udev/udisks-part-id
/lib/udev/udev-configure-printer
/lib/libnss_wins.so.2
/lib64/libnss_wins.so.2
/lib64/security/pam_cracklib.so
/lib64/security/pam_ck_connector.so
/lib64/security/pam_pwcheck.so
/lib64/security/pam_userdb.so

Sogar andere Distributionen sind betroffen: I’m interesting in, how much different Linux distributions are broken.

Das würde bedeuten, dass diese Tools bzw. Bibliotheken bei einem fehlenden /usr Verzeichnis nicht mehr funktionieren.

Wie ist es heute? Mittlerweile haben wir mehr als ausreichende Festplattenkapazität und können gleich ein komplettes Linux-System auf die Platte ziehen oder sogar mehrere Linux-Systeme. Sollte das Linux-System einmal ausfallen, haben wir immer noch unsere Rettungs-CDs, Sicherheitskopien oder sogar ein zweites Linux-System auf der Festplatte, um das System wiederherzustellen. Daher wird dieses Argument als Rettungssystem nicht mehr ziehen.

Was sind eigentlich die Vorteile? Theoretisch können mehrere Linux-System das Verzeichnis /usr teilen, so hat man 2 Fliegen mit einer Klappe geschlagen. Man senkt nicht nur den Wartungsaufwand, sondern auch den benötigten Speicherplatz. Man kann so auch viel leichter einen Snapshot vom /usr Verzeichnis erstellen.

Gibt es irgendwelche Nachteile? Bisher sind keine gravierenden Nachteile bekannt. Es gibt aber einige kleinere Nachteile. Beim Bau der Pakete sind noch die alten Installationspfade /bin, /sbin, /lib und /lib64 enthalten und müssen entsprechend gepatcht werden. Sobald die Verzeichnisse /bin, /sbin, /lib und /lib64 in naher Zukunft endgültig entfernt werden, kann es passieren das einige schlampig geschriebenen Skripten oder proprietäre Programme nicht mehr funktionieren. Die andere Seite der Medaille ist, dass es evtl. zu einem Bruch bei der FHS (Filesystem Hierarchy Standard) und bei der LSB (Linux Standard Base) kommt, die den Standard der Dateisystemordnung sowie den Ort für die binären Dateien vorschreibt. Hier müsste die Linux Foundation die FHS/LSB-Spezifikation abändern, sonst ist die Zertifizierung in Gefahr, was für die kommerziellen Linux-Systeme wie z.B. die „SUSE Linux Enterprise“ Produkte und auch „Red Hat Enterprise Linux“ Produkte hart treffen könnte.

Fazit: Meiner Meinung nach ist der Umzug der binären Dateien längst überfällig. Somit schneiden wir endlich alte Zöpfe ab, die in heutiger Zeit mehr störend als nützlich empfunden wird. Man kann sich viel mehr darauf verlassen, dass die binären Dateien genau da sind, wo sie eigentlich hingehören. Auch die einfachere Wartung über mehrere Linux-Systeme hinweg, sollte man berücksichtigen.

Weitere Informationen und Diskussionen zu diesem Thema:
http://en.opensuse.org/UsrMerge
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
http://0pointer.de/blog/projects/the-usr-merge.html
https://fedoraproject.org/wiki/Features/UsrMove
http://thread.gmane.org/gmane.linux.redhat.fedora.devel/155511/focus=155547
http://thread.gmane.org/gmane.linux.debian.devel.general/165785
http://thread.gmane.org/gmane.linux.gentoo.devel/72128
http://harald.fedorapeople.org/downloads/usrmove/