Meinungen zu /usr-merge

soturi

Member
Hi,

Spiele mit dem Gedanken auf FreeBSD primär umzusteigen, halte aber irgendwie an meine Arch-Linux fest. Mir ist schon öfters aufgefallen, dass in Arch-Linux /usr, /sbin, /lib und /lib64 nach /usr gelinkt sind und wollte dann wissen was der Grund dafür war.

https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

- Solaris hat damit angefangen
- Die Trennung ist historisch und hat heute keine große Bedeutung mehr
- Ein komplettes /usr mit allem ist einfacher in der Handhabung

Lassen wir mal das so stehen. Ich interessierte mich, wie es bei diesem Thema in FreeBSD aussieht.

https://forums.freebsd.org/threads/27582/

Dort war man nicht gut darauf zu Sprechen.

Ist dadurch die Trennung zu /usr/local beeinflusst?
Ist die Idee dahinter so undurchdacht?

Was haltet Ihr davon? Lohnt es sich?

soturi
 
Auch wenn ich Fan der 1e Partition Lösung bin (bzw. eine die nur den /boot enthält und eine verschlüsselte für alles Andere), würde ich das nicht ändern.

Die Trennung von `/usr/local` sehe ich nicht betroffen. Aber mir geht es um den Erhalt der Semantik. Und die etablierte (jedenfalls verstehe ich die Dokumentation so) Semantik ist, dass in /usr Dinge liegen die nicht für den Single-User Mode benötigt werden.

Angesichts heutiger Speicherdichten ist diese Unterscheidung nicht mehr notwendig. Aber sie gibt immer noch Struktur die das mentale Modell des Systems unterstützt.
 
Die Argumente stehen ja in dem verlinkten Artikel. Würde auch für FreeBSD gelten. Ich meine, die meisten neuen FreeBSD Installationen dürften auf ZFS laufen wo das ganze noch hinfälliger wird. Bei FreeBSD Leuten löst das Wort "ändern" gerne mal einen Beiß-Reflex aus. Das führt halt auch gerne zu weniger schönen Situationen (z.B. Upgrade von PostgreSQL unter FreeBSD ist kompliziert, mit PKG noch komplizierter).

Auch für mich müsste es diese feingranulare Einteilung nicht mehr geben. Ich nehme als Beispiel gerne meinen Server bei Hetzner. Wenn der Probleme macht bringt mir der Single-User Modus einen scheiß. Dazu müsste ich eine LARA (Remote Konsole) bestellen und darüber arbeiten. Da boote ich schneller und flexibler einfach ein mfsBSD mittels ein paar Klicks und fertig.
 
Ach, ich weiß es nicht. Ich habe nichts gegen Änderungen. Ich stehe auf Seite derer, die für FreeBSD 12.0 gerne einen etwas größeren Bruch sehen würden. Aber ich kann nach etlichen Diskussionen zu Thema sagen, dass Änderungen nur dann akzeptiert werden, wenn sie für einen Großteil der Nutzer sichtbare Vorteile bringen. Eine Änderung von hier(7) tut das sehr wahrscheinlich nicht. Die Dateien liegen plözlich an anderen Orten, statt Verzeichnissen gibt es plötzlich Symlinks. Je nach dem wie kaputt Scripte und Anwendungen sind, sind sie transparent oder führen zu Problemen, was Anpassungen bedeutet. Die Standard-Nerds werden darauf hinweisen, dass FHS klar zwischen / und /usr trennt. /usr/src bildet die Dateisystem-Hierarchie ab, man müsste also auch dort umsortieren. Allein der Gedanke daran führt bei einigen Downstream-Nutzern mit fragwürdigen VCS regelmäßig zu gequälten Aufschreien... Kurz um, / und / usr zusammenzufassen wäre eine zähe Diskussion und eventuell viel Arbeit bei überschaubaren Vorteilen und einigen Nachteilen. Die Zeit investiert man besser woanders.
 
In meinen kurzen Versuchen mit Ubuntu musste ich ja lernen, entsprechend umzudenken. Das dauerte etwa drei Millisekunden und war natürlich nicht von dauerhaftem Erfolg. Bei der nächsten Suche brauchte ich wieder diese drei Millisekunden, aber das ist auch schon alles, was mir dabei aufgefallen ist.
Es bringt keine Vorteile oder Nachteile. Wie auch immer man das realisiert.

Wer unbedingt viele Partitionen haben möchte (es gibt ja auch Leute, die manche Verzeichnisse auf Servern im Netzwerk bereit halten), der kann diese doch nach wie vor realisieren. Ob dabei die Einteilung bei FreeBSD ein tatsächlicher Vorteil ist, weil man einen Zweig mehr hat, den man da exportieren könnte, bezweifele ich. In der Praxis dürfte das eher irrelevant sein.
 
Funktionierende Standards zu ersetzen wird kein Problem lösen.
 
Zurück
Oben