Im File Hierarchy Standard hieß es mal, dass man die Trennung zwischen /bin und /usr/bin bzw. /sbin und /usr/sbin deswegen macht, damit man /usr als Netzlaufwerk einbinden konnte und man nur ein kleines Basissystem zum Booten auf den Clientrechnern benötigte.
Ein weiterer Vorteil war durch diese Methode auch, dass man bei Hotplugfähigen Systemen einfach den Datenträger, der nach /usr eingebunden wurde, mit einem Hardware Schreibschutz versehen konnte und dann beim laufenden System diesen aushängen, den Schreibschutz ausschalten und die Disk wieder einhängen konnte um dann bspw. Updates durchzuführen und danach das gleiche in umgekehrter Reihenfolge noch einmal. Damit hatte Schadsoftware, solange der HW Schreibschutz bestand, keine Chance sich nach /usr festzusetzen. Natürlich konnte man so, das Update auch auf einem zweiten System durchführen.
Insofern halte ich es für einen Fehler, dass man das nun alles ändert und diese Trennung nicht mehr vorsieht.
Und da man dann auch noch Symlinks anlegt, hat es nicht einmal aus Usersicht einen Vorteil, der sich mit zu vielen Verzeichnissen in / vielleicht überfordert gefühlt haben könnte.
Im File Hierarchy Standard hieß es mal, dass man die Trennung zwischen /bin und /usr/bin bzw. /sbin und /usr/sbin deswegen macht, damit man /usr als Netzlaufwerk einbinden konnte und man nur ein kleines Basissystem zum Booten auf den Clientrechnern benötigte.
Das kleine Basissystem ist bei nahezu allen Distributionen über eine Initrd realisiert. Das wird einfach zusammen mit dem Kernel-Image über PXE ausgeliefert und dann macht die Initrd den Rest.
Im File Hierarchy Standard hieß es mal, dass man die Trennung zwischen /bin und /usr/bin bzw. /sbin und /usr/sbin deswegen macht, damit man /usr als Netzlaufwerk einbinden konnte und man nur ein kleines Basissystem zum Booten auf den Clientrechnern benötigte.
Den gleichen Effekt erhält man mit initrd.
Außerdem bietet initrd auch andere Vorteile. Zum Beispiel ist die grundlegende Partitionierung einfacher, da sie weniger Restriktionen unterliegt. Somit muss man sich bei der Installation weniger Gedanken um die Partitionierung machen und es steht effektiv mehr Speicher platz zur Verfügung, wenn man die Anzahl der nötigen Partitionen reduziert.
Warum also diese ansonsten künstliche Trennung (Komplexität) aufrecht erhalten? Was hindert Sie daran initrd zu verwenden?
Ein weiterer Vorteil war durch diese Methode auch, dass man bei Hotplugfähigen Systemen einfach den Datenträger, der nach /usr eingebunden wurde, mit einem Hardware Schreibschutz versehen konnte und dann beim laufenden System diesen aushängen, den Schreibschutz ausschalten und die Disk wieder einhängen konnte um dann bspw. Updates durchzuführen und danach das gleiche in umgekehrter Reihenfolge noch einmal. Damit hatte Schadsoftware, solange der HW Schreibschutz bestand, keine Chance sich nach /usr festzusetzen. Natürlich konnte man so, das Update auch auf einem zweiten System durchführen.
Die neueren Entwicklungen diesbezüglich (zustandslose Systeme), z.B. CoreOS/Silverblue (OSTree), MicroOS/Kubic (transactional update mittels Btrfs), unterstützen und verwenden das sogar ab Werk.
Halten Sie es insofern weiterhin "für einen Fehler, dass man das nun alles ändert und diese Trennung nicht mehr vorsieht"?
Und da man dann auch noch Symlinks anlegt, hat es nicht einmal aus Usersicht einen Vorteil, der sich mit zu vielen Verzeichnissen in / vielleicht überfordert gefühlt haben könnte.
Da ist in der Tat etwas dran, aber ist eher Teil der UX. Wenn man das geschickt umsetzt, stellt das kein Problem mehr dar. Siehe z.B. Android oder macOS, wo der normale Endanwender nichts von alldem sieht, weil es nicht angezeigt wird, obwohl auch dort dieses "Verwirrungspotential" existiert. Bei GNOME müsste ein Normalanwender auch erstmal die Wurzel des Verzeichnisbaums suchen, um diese symlinks zu sehen. Auch bei GoboLinux gibt es da vielversprechende Ansätze, die allerdings den FHS verletzen. Dort gibt es standardmäßig sogar ein Kernelmodul namens GoboHide, dass jene Ordner aus rein ästhetischen Gründen "ausblendet", d.h. sie tauchen nicht in stat(2) auf.
Im File Hierarchy Standard hieß es mal, dass man die Trennung zwischen /bin und /usr/bin bzw. /sbin und /usr/sbin deswegen macht, damit man /usr als Netzlaufwerk einbinden konnte und man nur ein kleines Basissystem zum Booten auf den Clientrechnern benötigte.
Ein weiterer Vorteil war durch diese Methode auch, dass man bei Hotplugfähigen Systemen einfach den Datenträger, der nach /usr eingebunden wurde, mit einem Hardware Schreibschutz versehen konnte und dann beim laufenden System diesen aushängen, den Schreibschutz ausschalten und die Disk wieder einhängen konnte um dann bspw. Updates durchzuführen und danach das gleiche in umgekehrter Reihenfolge noch einmal.
Damit hatte Schadsoftware, solange der HW Schreibschutz bestand, keine Chance sich nach /usr festzusetzen.
Natürlich konnte man so, das Update auch auf einem zweiten System durchführen.
Insofern halte ich es für einen Fehler, dass man das nun alles ändert und diese Trennung nicht mehr vorsieht.
Und da man dann auch noch Symlinks anlegt, hat es nicht einmal aus Usersicht einen Vorteil, der sich mit zu vielen Verzeichnissen in / vielleicht überfordert gefühlt haben könnte.
Außerdem bietet initrd auch andere Vorteile. Zum Beispiel ist die grundlegende Partitionierung einfacher, da sie weniger Restriktionen unterliegt. Somit muss man sich bei der Installation weniger Gedanken um die Partitionierung machen und es steht effektiv mehr Speicher platz zur Verfügung, wenn man die Anzahl der nötigen Partitionen reduziert.
Warum also diese ansonsten künstliche Trennung (Komplexität) aufrecht erhalten?
Geht das nicht mehr?Was hindert Sie daran initrd zu verwenden?
Die neueren Entwicklungen diesbezüglich (zustandslose Systeme), z.B. CoreOS/Silverblue (OSTree), MicroOS/Kubic (transactional update mittels Btrfs), unterstützen und verwenden das sogar ab Werk.
Halten Sie es insofern weiterhin "für einen Fehler, dass man das nun alles ändert und diese Trennung nicht mehr vorsieht"?
Da ist in der Tat etwas dran, aber ist eher Teil der UX. Wenn man das geschickt umsetzt, stellt das kein Problem mehr dar. Siehe z.B. Android oder macOS, wo der normale Endanwender nichts von alldem sieht, weil es nicht angezeigt wird, obwohl auch dort dieses "Verwirrungspotential" existiert. Bei GNOME müsste ein Normalanwender auch erstmal die Wurzel des Verzeichnisbaums suchen, um diese symlinks zu sehen. Auch bei GoboLinux gibt es da vielversprechende Ansätze, die allerdings den FHS verletzen. Dort gibt es standardmäßig sogar ein Kernelmodul namens GoboHide, dass jene Ordner aus rein ästhetischen Gründen "ausblendet", d.h. sie tauchen nicht in stat(2) auf.