Diskussion:Filesystem Hierarchy Standard

aus Wikipedia, der freien Enzyklopädie

Verzeichnisnamen?

Wofür steht die Bezeichnung /etc?

  • bin = binary
  • boot = boot
  • dev = device
  • etc = ? ? configuration?
  • lib = library
  • media = media
  • mnt = mounted
  • opt = optional
  • sbin = system binary
  • srv = server
  • tmp = temporary
  • usr = user
  • var = variable

das ist jetzt geraten. Die hinweise wären aber noch ganz interessant, denke ich. --Night Ink 00:39, 6. Okt 2004 (CEST)

Hmmm...gute Frage :) "et cetera" vielleicht? Sind ja nicht nur Konfigdateien in dem Verzeichnis zu finden, sondern auch Startskripte (zumindest bei Linux; bei Solaris und FreeBSD müsste ich nachgucken) -- Hauke 00:42, 6. Okt 2004 (CEST)
Das mach aber irgendwie keinen sinn: /und weitere? Dann wohl eher /cetera, aber da passt die Abkürzung nicht mehr. hmm.. --Night Ink 02:09, 6. Okt 2004 (CEST)
Wieso ergibt das keinen Sinn? "etc." ist eine Standardabkürzung, wobei "cetera" besser mit "das Übrige" zu übersetzen ist. Laut älteren Usenet-Threads wurde historisch dort Kleinkram ablegt, der sonst nirgends hinpasste, d.h. eben nicht nur Konfigurationsdateien. --Cyclonus 00:01, 18. Jul 2005 (CEST)
/etc steht IMHO für "et cetera", also alles, was sonst nirgendwo reingepaßt hat. Früher waren da auch Logdateien drinnen. --Uhw (Diskussion) 09:27, 5. Feb. 2019 (CET)
usr steht für unix system resources nicht für user --LittleJoe 13:16, 21. Nov 2004 (CET)
Kannst Du das belegen? Ich halte das für ein Backronym. Historisch steht es wohl wirklich für "user", da dort die Daten der Benutzer ablegt wurden. Allerdings kann ich mich da nur der Meinung anderer anschließen, ohne es zu belegen. --Cyclonus 00:01, 18. Jul 2005 (CEST)
usr steht tatsächlich für unix system resources. Eine Quelle wäre: Peer Heinlein: LPIC-1 Vorbereitung auf die Prüfung des Linux Professional Institute.--Stammtisch 17:27, 21. Aug. 2007 (CEST)
unix system resources ist quatsch. usr stand für user. Auf der root-Platte war alles drauf, um das System hochzufahren und zu warten. Die für den Betrieb des Systems unwichtigen Daten der Anwender lagen auf der User-Platte (/usr). Das waren hauptsächlich die Home-Directories (z. Bsp. /usr/fritz; das Home-Directory von root war /) sowie die Programme der Anwender (/usr/bin, /usr/lib, etc). /usr wurde erst gemounted, wenn in den Multiuser-Mode gewechselt wurde. -- Flobber 2008-08-24, einer, der /home für neumodischen Schnickschnack hält ;-)
(nicht signierter Beitrag von 91.1.26.74 (Diskussion) 02:20 24. Aug 2008 (CEST))
der Teil (englisch:user; die Deutungswandlung zu user system ressources wird zwar immer mehr akzeptiert, ist aber im FHS nicht enthalten) is ja wohl n witz. user system ressources ist heutzutage die einzig korrekte bedeutung von /usr. Das es ursprünglich mal für user stand ist zwar richtig, interessiert heutzutage aber keine sau mehr! Und was das FHS betrifft, so ist auch die Deutung als user nicht enthalten. Genaugenommen macht das FHS (zumindest in den aktuellen Versionen, wie es in älteren aussieht weiß ich nicht) garkeine Aussage darüber für was /usr nun letztendlich steht! Und /etc wird heutzutage oft auch als edit this carefully gedeutet, was ich persönlich schöner und sinnvoller finde als editable text configuration (ist text nicht grundsätzlich editierbar?! ;) ) -- Klugscheißer 2009-09-24 11:10 (CEST) (ohne Benutzername signierter Beitrag von 77.188.109.147 (Diskussion | Beiträge) )
Wieso denn "system resources"? Was soll das denn? Wenn irgendwo „Systemresourcen“ zu finden sind, dann ja wohl allenfalls in /dev. --95.113.18.6 23:01, 5. Jun. 2010 (CEST)
Eine Ressource definiert sich nicht zwingend durch ihre hardwaremäßige Präsenz. Ein Unix ohne z. B. Binaries in /usr/bin wäre nur recht eingeschränkt benutzbar. --Poc 11:00, 6. Jun. 2010 (CEST)
Wer soll das festgelegt haben, dass /usr plötzlich für "unix system resource" oder user system resources" stehen soll. Gibt es da Quellen zu? Die ursprüngliche Ableitung vom englischen "user" ist gut belegt. Zum Beispiel in diesen Notizen von Dennis Ritche von 1972: [1] Woher kommt überhaupt das Bedürfnis, das durch ein Akronym zu erklären? Wofür stehen denn dann home, lib, var oder tmp? --188.100.29.196 19:49, 24. Okt. 2012 (CEST)

Haupverzeichnisse

Die können doch nicht alle "historisch" sein! --Uhw (Diskussion) 09:27, 5. Feb. 2019 (CET)

/usr/local?

"Diese Hierarchie ist nach der grundlegenden Installation leer und dient als Platz für weitere Programme. Die meisten Installationsprogramme von zusätzlicher Software verwenden dieses Verzeichnis. /usr/local/<programmname> enthält die Dateien des Programms, während in /usr/local/bin und /usr/local/lib meistens Links zu den Binärpaketen und Bibliotheken zu finden sind."

Der FHS sagt da aber was anderes. (FHS V2.2)

The following directories, or symbolic links to directories, must be in /usr/local

"/usr/local" bin games include lib man sbin share src "Local hierarchy" Local binaries Local game binaries Local C header files Local libraries Local online manuals Local system binaries Local architecture-independent hierarchy Local source code

Im FHS 2.3 steht das selbe! ([2])

Das "must" impliziert doch eigentlich, dass die Hierarchie sofort angelegt sein muß.

Sollte der Artikel dahingehend geändert werden?

(nicht signierter Beitrag von 217.91.7.229 (Diskussion) 12:22, 11. Jän 2007 (CET))

/usr/local wurde 1989 in Apsprache aller UNIX Hersteller zu Gunsten von /opt/<vendor> abgeschafft. --Schily 10:42, 10. Aug. 2010 (CEST)

welche Distros?

Lässt sich irgendwie rausbekommen, welche Distribution sich wie genau an den FHS hält? Vergleich Debian, Suse, Redhat, usw. wäre interessant. (nicht signierter Beitrag von TheReaper~dewiki (Diskussion | Beiträge) 20:25, 14. Apr 2007 (CEST))

Ich sehe mein alter Vorschlag ist nicht so richtig aufgegriffen worden. :) Zeit für einen neuen Vorschlag, wie wäre es mit einem Link in der art "Vergleich des FHS in verschiedenen Distributionen"? Dann könnte man dort auch Gobolinux und NixOS erwähnen, die ja beide etwas radikal anders machen
(nicht signierter Beitrag von 80.108.103.172 (Diskussion) 13:10, 11. Mär 2008 (CET))

ftp bzw. tftp in /bin?

Hallo,

Alle weiteren Kommandos, die zur Wiederherstellung benötigt werden, wie z. B. ftp, tftp oder diverse Archivierungsprogramme, haben hier ebenfalls ihren Platz.

Also... ich kenne zumindest von verschiedenen Linux-Distributionen "ftp" eher in /usr/bin. Über tftp läßt sich da noch streiten (obwohl hier auch unter /usr/bin), weil es für Network-Boot benutzt wird, aber ftp ist doch definitv ein Zusatz-Tool und hat so erst mal mit dem System nichts zu tun, oder sehe ich das falsch? Jabo 17:29, 21. Jan. 2008 (CET)

/usr

Der Artikel /usr ist ein schlechtes Duplikat von Filesystem Hierarchy Standard#Die „zweite Ebene“ der Verzeichnisstruktur (/usr)

Lustigerweise funktioniert ein direkter Wiki-Link auf /usr nicht. Gibt aber auch noch die Redirekt-Seiten Verzeichnis/usr und Verzeichnis /usr.

-- Alba7 13:55, 30. Jan. 2008 (CET)

Ich wäre übrigens dafür, das wir die historische Grundlage der Verzeichnisstruktur auch berücksichtigen. Hier ein interessanter Link dazu http://ask.slashdot.org/askslashdot/07/03/03/028258.shtml#comment_body_18220458 - man muss sich dann auch fragen, warum manche meinen das "usr" nicht "user" sondern "unix system resource" heissen soll
(nicht signierter Beitrag von 80.108.103.172 (Diskussion) 13:11, 11. Mär 2008 (CET))
Gute Idee. Allerdings ist der Slashdot-Beitrag keine brauchbare Quelle. Und "usr" enthält laut http://atat.at/fhs/?0 die persönlichen Dateien des Admins. :-)
--Alba7 17:27, 18. Mär. 2008 (CET)
Ist "The Unix Programming Environment" von Kernighan/Pike eine geeignete Quelle? Ich besitze das Buch selber nicht, aber hier wird es zitiert: http://linux.derkeiler.com/Newsgroups/comp.os.linux.misc/2005-12/msg02154.html (nicht signierter Beitrag von 82.83.110.189 (Diskussion | Beiträge) 13:01, 2. Jun. 2009 (CEST))
Ist denn noch verifizierbar, ab wann es "/home" gibt? Denn auf heutigen Systemen ist ja wohl wirklich nicht die Korrespondenz mit Tante Frida in "/usr", sondern da sind Programme. Zwar für User-Space nutzbar, aber eben nicht die Ergüsse einzelner angemeldeter Leute.
Ich habe mal kurz in den Manpages zu SunOS nachgeschaut. In SunOS 3.5 wird für Benutzerverzeichnisse noch "/usr/name" angegeben, die Version bei SunOS 4.0 verweist dafür auf /home. Das war etwa 1988. --188.100.29.196 19:49, 24. Okt. 2012 (CEST)
Nun geht ja BSD auf Unix zurück, also wäre interessant, ob das evtl. mal für Nutzer gedacht war und ab wann man gemerkt hat, daß es sinnvoll ist, Programme von persönlichen Daten zu trennen, wobei diese ja auch Programme sein können.
So ist ja sinnvollerweise "/home/xy" nicht in der Umgebungsvariable $PATH bei dem User von "/home/xyz". Diese Trennung sollte doch aber recht früh als sinnvoll erschienen sein in einem System, das mangels ausreichend ausgestatteter Einzelplatzrechner für den Betrieb von Terminals an Servern konzipiert wurde und das deshalb soviel Wert auf Vernetzung legt.
Ich hab einige Unix-Bücher angeschaut, was aber schon so lange her ist, daß ich hier aus dem Kopf nichts zitieren kann, ich erinnere mich aber daran, daß ich mir eins aus der hamburger StaBi geholt habe damals extra zur Unix-Geschichte. Da stand auch schon "unix system resource". Daran erinnere ich mich, weil ich es bis dahin auch für "user" hielt, weil das aus deutscher Sicht sprachlich so nahe liegt.
Weiß jemand, ab wann $PATH etabliert ist und diesen Unterschied macht? Dabei ist auch die Sache mit dem Punkt interessant: "./<Befehl>" statt einfach "<Befehl>". Die Idee ist ja dabei, daß Befehle in $PATH ohne das gefunden werden und selbst gleichlautende Scripte im aktuellen Verzeichnis (z.B. eigenes /home) übergangen werden. Die Programme in /usr sind aber in $PATH. Seit wann? Hatte man früher tatsächlich "/usr/peter" und nicht "/home/anna"? --Jabo 11:19, 7. Jun. 2009 (CEST)

Grafische Überischt

Jeder der sich mit unixoiden Betriebssystemen auskennt hat das FHS-Verzeichnis im Kopf. Applikationen, Quellcode, Konfigurationen, er weiß wo was sein soll. Die Dokumentation benötigt er lediglich um die genaue Definition der Verzeichnisse zu rezitieren. Anfänger auf dem Gebiet, zu denen ich mich ebenfalls zähle, haben damit Schwierigkeiten in gewissen Situationen den richtigen Ort zu finden, wo denn nun was liegt. Es ist meist unumgänglich die Dokumentation permanent im Hintergrund geöffnet zu halten.

Was wir Anfänger brauchen ist ein Poster. Ein Blatt, DINA4 oder A3, welches an der Wand hängt oder griffbereit auf dem Schreibtisch liegt.

Ich habe keines Gefunden, weder mit Google noch hier. Weiß jemand ob es so etwas gibt? Es sollte in jedem Fall mehr Informationen enthalten also so etwas: [3] Falls es so etwas nicht gibt würde ich eines machen, natürlich lasse ich es dann von einigen Unix-Gurus inhaltlich überarbeiten und stelle es hier unter einer freien Lizenz zur Verfügung.

Falls jemand eine geeignetere Stelle kennt, kann er meine Anfrage gerne weiter tragen. TF-infinity 12:41, 2. Dez. 2009 (CET)

erwähnung von /dev/(u)random

im Artikel zu /dev/random steht, dass diese datei im fhs nicht standardisiert sei. sollte man dann hier die erwähnung nicht entfernen und stattdessen auf beispiele zurückgreifen, die im standard stehen? -- Blaimi 08:22, 25. Feb 2011 (CET)

/run

Bitte /run hinzufügen: http://www.pro-linux.de/news/1/16882/distributionen-fuehren-neues-verzeichnis-run-ein.html (oder ist das ein distributionsspezifisches Verzeichnis?) --WonderBlood 10:22, 5. Apr. 2011 (CEST)

Distributionsspezifisch nur bedingt (abhängig von der verwendeten Init-Methode), gehört aber auch nicht zum FHS. Ich schätze aber mal dass der FHS irgendwann mal dahingehend geändert wird.... --Vanger !–!? 15:21, 5. Apr. 2011 (CEST)

/usr Merge

Vielleicht sollte man die Vorstöße und Diskussion, /(s)bin und die lib-Verzeichnisse in /usr zu bündeln, hier auch erwähnen. In Solaris wurde das bereits umgesetzt und jetzt auch in Fedora 17. Es ist zwar nicht Bestandteil des FHS, könnte aber zukünftig größere Bedeutung bekommen. Leider fehlen mir als Teilzeit-Linuxer die tieferen Einsichten, um das prägnant und klar ins Lemma einzubringen. Hier mal zwei Links dazu:

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

http://fedoraproject.org/wiki/Features/UsrMove

--91.22.174.42 15:37, 30. Mai 2012 (CEST)

Das ist inzwischen also weit mehr und müsste dem Artikel ne ganz neue Note geben, wenigstens aber Erwähnung finden wie in der engl. Version. So ist das veraltet. Mir selbst fehlt der Überblick. -ZT (Diskussion) 07:22, 17. Jul. 2021 (CEST)
Ich finde das auch relevant, führe die Diskussion aber mal weiter unten in dem Abschnitt "usrmerge" weiter. --TheEldestEdit (Diskussion) 16:05, 28. Aug. 2022 (CEST)

erwähnung von /proc

Keine ahnung ob /proc auch in dem FHS festgelegt ist, vielleicht ist eine kurze erwähnung trotzdem hilfreich! (nicht signierter Beitrag von 141.20.45.54 (Diskussion) 15:40, 10. Mär. 2015 (CET))

/proc ist Linux-spezifisch. Siehe FHS-2.3 (englisch) unter Punkt 6. Operating System Specific Annex. ‣Andreas•⚖ 16:34, 15. Mär. 2015 (CET)

Kritik

Man müsste noch ergänzen das außer Linux-Distributionen kein unixoides System diesen Standard umsetzt, weder Solaris noch eines der BSD. Zmd. bei FreeBSD gibts hier das diese ersetzt.--Darktrym (Diskussion) 18:19, 5. Jun. 2015 (CEST)

proc sys

eigentlich würde man erwarten dass man hier etwas zu /proc und /sys erfährt auch wenn/ z.B. dass die nicht zu dem FHS gehören. --Quetsch mich aus, ... itu (Disk) 19:34, 20. Feb. 2017 (CET)

/var/local?

Wo kommt denn /var/local in der Aufzählung her? Das taucht weder in 2.3 noch in 3.0 auf, und die englische Version nennt es auch nicht. Sollte man mindestens als veraltet kennzeichnen, wenn es das je offiziell gegeben hat. --94.222.36.205 16:21, 27. Mär. 2019 (CET)

Ich habe /var/local auch noch nie gesehen. Programme in /usr/local speichern ihre variablen Daten in den Standard-Pfaden unter /var, wie alle anderen Programme auch. Neu für mich war /usr/local/etc bzw. /etc/local, das kannte ich noch nicht. Analog dazu könne man natürlich auch /var/local für variable Daten (temporäre Dateien) nutzen, aber wozu? Das wäre am Sinn von /usr/local vorbei, wenn es um ein Backup geht, da diese Daten vermutlich irrelevant sind. Wenn nicht, wären sie als Sonderfall in ein Backup aufzunehmen.
Langer Rede, kurzer Sinn: ich kann /var/local auch nirgends als Standard finden. Das sollte gelöscht werden. ‣Andreas•⚖ 10:43, 17. Jul. 2021 (CEST)
Habe es jetzt (endlich) gelöscht. ‣Andreas•⚖ 20:56, 17. Okt. 2021 (CEST)

usrmerge

ganz grosse Fehlanzeige wohl ... --Quetsch mich aus, ... itu (Disk) 19:26, 17. Okt. 2021 (CEST)

Wie bitte? ‣Andreas•⚖ 20:57, 17. Okt. 2021 (CEST)
Sehr relevantes Thema: [4] . --Quetsch mich aus, ... itu (Disk) 21:12, 17. Okt. 2021 (CEST)
Alter Hut. Die Frage, die sich mir stellt, ist, inwieweit soetwas wirklich relevant ist. Linux kann man sich so bauen, wie man will. Dieses Lemma behandelt jedoch den FHStandard, und um den zu erfüllen, bedarf es eben eines /bin und eines /usr/bin. Punkt. Darum wohl auch die symbolischen Verknüpfungen. Außerdem kann man /usr wirklich als separate Partition einhängen (Nachtrag: siehe dazu auch hier ‣Andreas•⚖ 21:31, 17. Okt. 2021 (CEST)) – ob das nun zeitgemäß ist oder nicht, steht auf einem anderen Blatt. Für ein Basissystem wäre dann /bin wirklich praktisch, aber auch da hat sich mittlerweile ja mit initrd bzw. initramfs viel getan, und das Basissystem steckt nun dort drinnen, weshalb man auf /bin und /sbin usw. wohl auch getrost verzichten kann.
Wo ist aber nun die Fehlanzeige? Weil es im Artikel fehlt? Steht es denn bei der FHS-Spezifikation irgendwo? ‣Andreas•⚖ 21:27, 17. Okt. 2021 (CEST)
„Es geht um den Usrmerge [1], der den Filesystem Hierarchy Standard (FHS) [2] ändert.“[5] --Quetsch mich aus, ... itu (Disk) 21:55, 17. Okt. 2021 (CEST)
Ja, so steht es im Artikel. Aber ist denn der FHS geändert? Ich sehe noch keine Änderung diesbezüglich... Eine weitere Quelle wäre schön – oh, hab eine: LWN. Offenbar wird ja gerade der Standard nicht geändert, indem das vereinigte /bin, /sbin und /lib als Symlink wieder gem. FHS zugänglich bleibt. Oder was habe ich da verpasst? ‣Andreas•⚖ 22:28, 17. Okt. 2021 (CEST)
Offenbar ist es eine wesentliche Änderung, die auch keineswegs mit dem Anlegen von drei Symlinks erledigt ist. --Quetsch mich aus, ... itu (Disk) 22:51, 17. Okt. 2021 (CEST)
Quelle? Ich finde nur FHS 3.0 von 2015. Da ist es nicht zu finden, allerdings schließt der Standard auch nicht aus, dass /bin, /sbin und /lib symlinks zu den entsprechenden Verzeichnissen in /usr sind. Aus dem LWN-Artikel geht selbiges hervor. ‣Andreas•⚖ 23:12, 17. Okt. 2021 (CEST)
Zunächst möchte ich kurz auf den obigen Diskussionsabschnitt "/usr Merge" verweisen in dem das auch bereits diskutiert worden ist. Ich führe das aber mal hier fort:
Das "Fehlen" dieser Thematik ist mir gestern ebenfalls aufgefallen. Nachdem ich erfolglos nach einer Erwähnung in anderen Artikeln gesucht hatte, habe ich - leider ohne vorher hier noch danach zu schauen - mal einen entsprechenden Abschnitt verfasst, dessen Qualität aber vmtl. noch verbessert werden kann. Ich habe dazu folgende Überlegungen angestellt:
  • Die Abweichung eines Programms (oder im Kontext einer Distro) von einem Standard rechtfertigt keinen (erklärenden) Eintrag in der Wikipedia, selbst dann nicht, wenn das Programm/Dirstro sehr verbreitet und die Änderung sehr relevant ist. Wir sind schließlich nicht die Dokumentation der Software.
  • Nachdem mittlerweile einige große (Fedora, Solaris, Arch, Ubuntu, Debian, ...) - um nicht zu sagen die Größten - Distributionen (und mit ihnen vmtl. viele Kleine) einen Usrmerge durchgeführt haben, ist es meines Erachtens für jeden (administrativen) Nutzer dieser Distros notwendig den Usrmerge und seine Bedeutung zu kennen (wenn vlt. auch nicht unter dem Namen). Angesichts der Anzahl dieser Nutzer halte ich dieses Wissen daher für ebenso allgemeingültig und relevant wie den FHS. Insbesondere, wenn man berücksichtigt, dass diese Distros gem. Anmerkung 1 nicht mehr FHS konform sind und der FHS damit wesentlich an Bedeutung verliert.
  • Der Artikel zum FHS erweckt den Eindruck, dass dieser ein aktiver, angewendeter Standard ist. Dies ist wegen des Usrmerge bei weiten Teilen seiner ehemaligen Anwender nur noch begrenzt der Fall. Diese Tatsache muss im Artikel Erwähnung finden.
  • Der Usrmerge ist kein Bestandteil des FHS, vielmehr steht er in einem gewissen Widerspruch zu diesem (vgl. Anmerkung 1). Es scheint daher prinzipiell nicht passend Usrmerge in den Artikel zum FHS aufzunehmen.
  • Usrmerge steht in einem sehr engen Verhältnis zum FHS. Nicht nur beruht er auf dem FHS, sondern das Anliegen des Usrmerge ist es, weiterhin größtmögliche Kompatibilität zum vorherigen Stand (und damit den Vorgaben des FHS) zu wahren und die Prinzipien und weitestgehend auch die Vorgaben das FHS beizubehalten, bei gleichzeitiger Fortentwicklung und Vereinfachung. Beide stehen daher unbestreitbar in einer großen inhaltlichen Nähe.
  • Usrmerge begründet im (von mir verfassten) Umfang und in der Relevanz meines Erachtens zur Zeit (noch) keinen eigenen Artikel. Wegen obiger Anführungen hielt ich eine Beschreibung jedoch für notwendig und thematisch am passendsten im Artikel zum FHS. Ich habe dabei - um die Abgrenzung zu gewährleisten - mehrfach erwähnt, dass Usrmerge prinzipiell kein Teil des FHS ist. Da beides jedoch nicht identisch ist und die Artikel ggf. zukünftig getrennt werden könnten, habe ich ein entsprechendes Lemma "Usrmerge" angelget (als Weiterleitung).
Anmerkungen:
  1. Ich bin im Übrigen der Ansicht, dass Usrmerge und FHS formal unvereinbar sind, da der FHS ein Starten ohne /usr beabsichtigt, welches nach Usrmerge nicht mehr möglich ist. Folgender Quelle zufolge war Debian somit aber bereits vor dem Usrmerge nicht FHS konform. https://lists.debian.org/debian-devel/2018/11/msg00374.html vgl. vorletzter Absatz im Abschnitt "Merged /usr on end-user systems"
  2. Name: Offensichtlich ist nicht eindeutig, ob es nun /usr-merge, /usr merge, usrmerge oder Usermerge heißt (vlt. Internetrecherche, Quellen im Artikel). Wie mir scheint, wird im Englsichen zumeist von /usr merge gesprochen (vereinzelt auch mit Bindestrich). Im Deutschen wird hingegen die Bezeichnung usrmerge bzw. Usrmerge verwendet, wobei ich der Ansicht bin - wenn man das als eingeteutschte Form sieht - dass es dann auch groß geschrieben werden muss. Daher habe ich im Artikel die (meines Erachtens nach) "deutsche" Form mit Großschreibung gewählt, ebenso für das Lemma. Da diese jedoch nicht direkt ersichtlich ist und mir zudem die englische Form auch naheliegend erscheint, habe ich zusätzlich ein Lemma "/usr merge" angelegt.
  3. Lemma Weiterleitungen: Das zum Thema gehörige Lemma zeigt per Weiterleitung auf den entsprechenden Abschnitt im Artikel FHS. Das alternative Lemma sollte nach den Vorgaben eigentlich auf das "richtige" (ggf. Diskussion erforderlich) Lemma zeigen. Dies führt jedoch zu einer Weiterleitung auf eine Weiterleitung. Daher zeigen derzeit beide Lemma direkt auf den jeweiligen Abschnitt im FHS Artikel.
--TheEldestEdit (Diskussion) 17:36, 28. Aug. 2022 (CEST)
Danke für deine Bearbeitung. Aber wo steht denn bitte, dass der FHS und der Usrmerge unvereinbar wären? Im Gegenteil lese ich doch immer wieder, dass es gerade durch die Symlinks zum Standard kompatibel bleibt.
Wie ein Betriebssystem den Startvorgang regelt, ist grundsätzlich nicht wirklich Teil (oder Ziel) des FHS. Oder doch? Wo wäre das definiert?
‣Andreas•⚖ 18:04, 28. Aug. 2022 (CEST)
Wie in Anmerkung 1 beschrieben, ist das mein Verständnis des FHS:
  • Genau genommen steht in Abschnitt 3.1 Pupose folgender Satz (1): "The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system." * Im darauf folgenden Stichpunkt heißt es dann im letzten Satz (2): "/usr, /opt, and /var are designed such that they may be located on other partitions or filesystems.", wobei sich "other" hier auf die "root partition" bezieht.
  • Gemäß (2) müssen zwar nicht, aber können die Verzeichnisse also in einem anderen als dem root Dateisystem liegen also kann es insb. sein, dass sie nicht im root Dateisystem selbst liegen.
  • Gemäß (1) müssen die Inhalte des root Dateisystems aber zum booten ausreichen.
  • Daraus folgt nach bestem Verständnis für mich, dass ein booten ohne /usr, /opt und /var möglich sein muss. Dies ist gemäß der oben genannten Aussage des Debian Entwicklers (vgl. Anmerkung 1) jedoch - zumindest für Debian - nicht möglich.
Damit ergibt sich für mich eine formale Unvereinbarkeit von FHS und Usrmerge. Das sie in der Anwendung sehr wohl kompatibel bleiben will ich nicht bestreiten. Oder anders formuliert würde ich etwas unpräzise sagen, dass der Usrmerge (bzw. entsprechende Systeme) zwar zu den Zielen des FHS, nicht aber zu dessen exakten Vorgaben für die Umsetzung kompatibel ist. Im Übrigen bezeichnet auch folgende (von mir im Artikel genannte) Quelle beides (indirekt) als inkompatibel: https://www.linux-community.de/ausgaben/linuxuser/2019/08/zusammengefasst/, vgl. letzter Absatz vor "Wurzelbehandlung". Welche gegenteiligen Quellen hast du denn gefunden?
Den Startvorgang eines Betriebssystems zu regeln ist mit Sicherheit nicht Ziel des FHS. Ob der FHS durch seine Vorgaben ggf. jedoch ein bestimmtes Vorgehen beim Start möglich oder unmöglich macht will ich jetzt so pauschal nicht beurteilen. Dafür kenne ich mich auch bei Weitem nicht gut genug mit dem Bootvorgang aus.
Anmerkung: Mit den ersten Ausführungen habe ich natürlich Theoriefindung betreieben. Diese ist aber nicht teil des Artikels, sondern diente nur der Verifikation der Aussage in der im Artikel genannten Quelle. --TheEldestEdit (Diskussion) 21:12, 28. Aug. 2022 (CEST)
Ok, ich will hier nochmal meine Position klar machen, die da wäre: ich halte den Usrmerge nicht für sehr relevant, da er für die Anwender eines Betriebssystems keine größeren Auswirkungen hat bzw. zumindest kleinere als z.B. die Umstellung von Codepages auf Unicode/UTF, oder die von a.out auf ELF. Ja, natürlich sind das Details, die man erwähnen kann, die auch wichtig sein können. Aber im Rahmen der Wikipedia halte ich es nicht für allzu relevant.
Es hat immer schon Konfigurationen von Unix (wie BSD oder Linux) gegeben, die "unmöglich" waren, d.h. womit es Probleme beim Booten gibt/gab. Das ist aber dann das Problem desjenigen, der diese Konfiguration einrichtet. Bei einer Distribution ist es hingegen egal, denn wenn z.B. das Booten mit einem getrennt gemounteten /usr nicht geht, dann unterstützt es diese Distribution einfach nicht. Ähnliche "unmögliche" Konfigurationen gibt es auch bei anderen Betriebssystemen, etwa bei Windows, macOS, FreeBSD etc.
Und der FHS ist eigentlich eine Auflistung von Konventionen "after the fact" – Unix war eben so, und Unix-Anwendungen sind an diese Pfade angepasst. Wer sich also nicht daran hält, wird zwangsläufig inkompatibel. Aber es ist nicht der FHS, der das festlegt, sondern dieser "Standard" hat den bereits existierenden Standard "bloß" verschriftlicht. "They're more guidelines than actual rules."
So, das war jetzt meine (mit großer Wahrscheinlichkeit subjektive) Position.
Objektiv betrachtet ist die Quellenlage zwar vorhanden, aber doch eher überschaubar. Obwohl dieser "Usrmerge" oder "/usr merge" bei vielen Linux-Distributionen bereits vor ~10 Jahren in Angriff genommen wurde, waren dessen Auswirkungen und vor allem die Rezeption dazu (die Medienberichte, Fachartikel, etc.) eher gering. Wäre es "wichtiger" gewesen, gäbe es weit mehr Artikel darüber. Wie immer wieder betont ist es ja nicht nur das Zusammenführen (engl. "merge") von /[s]bin und /usr/[s]bin sowie von /lib und /usr/lib, das für sich genommen Probleme bereiten würde – es ist eher der Umstand, dass diese Separierung bereits schon vorher keinen Sinn mehr gemacht hatte, da mit shared libraries meist ohnehin keine klare Trennung mehr möglich war, zumindest nicht so einfach.
Und wenn wir schon bei (neu eingeführten) Inkompatibilitäten sind, so ist die Nutzung von [/usr]/lib oder [/usr]/lib32 für 32-Bit-x86 und [/usr]/lib64 für 64-Bit-x86 ebenfalls nicht gerade unproblematisch oder gar "ein Standard". Soweit ich mich erinnere gab es durchaus auch Distributionen, die [/usr]/lib für die jeweilige Architektur nutzen wollen – also entweder für 32- oder 64-Bit, je nachdem, was für ein System eben gerade läuft. Auch die Unterteilung in [/usr]/lib32 und [/usr]/lib64 für Multi-Lib-Systeme wurde einmal genutzt, war aber mit existierender (32-Bit-)Software inkompatible, da diese die Libraries eben in [/usr]/lib erwartete – ein Symlink hätte das zwar korrigieren können, aber inzwischen hat sich wohl [/usr]/lib für 32-Bit-x86 (IA-32) und [/usr]/lib64 für 64-Bit-x86 (x64, amd64 oder x86-64) durchgesetzt.
Generell gilt gerade bei Linux, dass es unzählige Arten und Weisen gibt, etwas zu machen. Wer nur Open-Source-Software einsetzt, der kann ohnehin von jedem Standard abweichen, denn die Pfade lassen sich ja im Quelltext normalerweise recht einfach anpassen. Bei Binary-Software gibt es dann aber Probleme – was dann wohl für einen Filesystem Hierarchy Standard spricht.
Der Artikel aus Linux User ist übrigens nicht schlecht, aber der Titel "Wurzelbehandlung" für den Absatz ist natürlich nur ein reißerischer Titel für einen trockenen Umstand. Und das ist der letzte Absatz davor:
Das Home-Verzeichnis sieht der FHS als optional an, ebenso wie /root, /lib32 und /lib64. Seit 2015 ist der FHS mit der Linux Standard Base (LSB) unter dem Dach der Linux Foundation vereint. Distributionen, die den Usrmerge umsetzen, sind damit nicht mehr LSB-konform.
LSB, die Linux Standard Base, ist aber nicht der Filesystem Hierarchy Standard. Was der Satz aussagt, ist, dass sowohl der FHS aus auch die LSB seit 2015 von der Linux Foundation betreut werden.ref Dass /home, /root, /lib32 und /lib64 optional sind, obwohl zumindest drei davon in nahezu jeder mir bekannten Linux-Distribution vorhanden sind, spricht nicht gerade für den FHS. Obwohl, FHS wird von zumindest Debian GNU/Linux noch ernster genommen als die LSB: Debian dropping the Linux Standard Base (30. September 2015).
Und ich komme immer noch nicht umhin, auf Abschnitt 3.2 des FHS 3.0 hinzuweisen. Denn ich verstehe werterhin nicht, wo denn genau das Problem bei dem "Usrmerge" im Bezug auf die FHS-Kompatibilität bestehen würde? Abschnitt 3.2 sagt doch ganz klar (fett markiert von mir):
The following directories, or symbolic links to directories, are required in /.ref
Nun, beim "Usrmerge" ist nun doch /bin, /lib, /sbin ein Symlink auf das gleichlautende Verzeichnis unter /usr, wo wäre also der Bruch mit dem FHS?
‣Andreas•⚖ 22:30, 28. Aug. 2022 (CEST)
Also ich möchte nicht auf alles eingehen, aber auf folgendes:
  • Genau den von dir zitierten Abschnitt meinte ich. In dem letzten Satz heißt es: "Distributionen, die den Usrmerge umsetzen, sind damit nicht mehr LSB-konform." Das Wort damit dürfte sich dabei auf den vorherigen Satz beziehen, also auf die Aufnahme des FHS in die LSB. Das Distros mit Usrmerge durch diese Tatsache also die LSB-konformität verlieren (nicht mehr impliziert ja, dass sie es vorher waren), kann ich mir nur so erklären, dass sie zu dem neu in die LSB aufgenommene Standard nicht konform sind. Das wäre eben der FHS. [Die Überschrift Wurzelbehandlung hatte ich nur der besseren Auffindbarkeit halber erwähnt.] Allerdings stelle ich mir gerade die Frage, ob der Satz zuvor tatsächlich die Aufnahme des FHS in die LSB meint, wie ich es verstanden habe. Eine kurze Recherche dazu bringt ein klares "Jain" als Antwort: Laut Linux Foundation verweist die LSB auf den FHS, wodurch dieser - in dem Sinne, wie ich es verstanden habe - Teil der LSB wird (Sprich: LSB-Konformität benötigt FHS-Konformität). Vgl. https://wiki.linuxfoundation.org/lsb/fhs
  • Ich stimme dir zu, dass Usrmerge nicht mit FHS 3.0 Abschnitt 3.2 im Widerspruch steht. Aber eben mit Abschnitt 3.1, wie oben erwähnt. Die von dir angeführten Anforderungen über die existenz bestimmter "Ablageorte" als Verzeichnis oder Symlink, welche in Abschnitt 3.2 definiert sind, erfüllt Usrmerge. Wie ich beschrieb, definiert Abschnitt 3.1 aber, dass booten ohne /usr (und /opt und /var) möglich sein soll. Das wird als Ziel definiert, dieses Ziel kann aber mit Usrmerge nicht mehr erreicht werden. Hier läge der Bruch mit FHS. [Anmerkung: Ich denke, dass diese Zielformulierung schlecht oder zumindest nicht mehr zeitgemäß ist, aber es ist eben als Zielvorgabe im Standard genannt.]
ABER tatsächlich stelle ich fest, dass du viel technischer an die Sache heranzugehen scheinst, als ich es tue - oder zumindest ursprünglich getan habe. Ganz praktisch sehe ich die Sache wie folgt: Menschen, die keine Ahnung von Linux/UNIX haben, die mit einem GUI namens Windows aufgewachsen sind und für die eine Konsole [ich übertreibe] das Loch des Grauens ist, suchen im Internet nach Anleitungen und Hilfe (so wie ich vor gar nicht all zu langer Zeit). Irgend wann stellen sie fest: "Ah die schlauen Menschen (die wissen, wie man einen Computer mit einer Konsole bedient) wissen immer "wo sie sind" und wo sie etwas suchen müssen, weil es dafür einen Standard gibt und sie den im Kopf haben." Und dann schaut man als Neuling eben nach, wie dieser Standard denn aussieht. Natürlich landet man dann bei diesem Artikel und schaut sich diesen an. Mein Ziel war es deshalb einfach, dass - wenn es in diesem Bezug Informationen bei Wikipedia zu finden gibt - diese Informationen möglichst vollständig und natürlich auch korrekt sind. [Wobei vollständig hier nicht unbedingt alle Details meint, aber zumindest eine Einordnung worauf sich die angegebene Information bezieht d.h., ob der Standard überall umgesetzt ist, ob alle sich strikt daran halten (müssen) und ob es gängige Abweichungen gibt. Zu Letzteren zähle ich Usrmerge.]
Du hast generell recht, wenn du sagst, dass man als gewöhnlicher Desktopuser weder /bin noch /usr/bin in der täglichen Arbeit regelmäßig durchstreift. Dennoch bin ich der Auffassung, dass die Informationen über den FHS allein ein unvollständiges, jedoch scheinbar vollständiges (also gewissermaßen trügerisches) Bild abgeben und der Artikel FHS diese Tatsache in irgend einer angemessenen Weise wiederspiegeln sollte.
In der Hoffnung, dass das jetzt nicht despektierlich klingt, denke ich aber das damit jetzt zumindest von meiner Seite das Meiste gesagt sein dürfte und die Position klar ist. Ich bestehe nicht darauf, dass der Artikelinhalt meiner Auffassung entspricht. Wenn du meine Einschätzungen der Quellen für falsch/unzureichend/... hältst, kannst du ihn gerne überarbeiten.
Viele Grüße --TheEldestEdit (Diskussion) 00:38, 29. Aug. 2022 (CEST)
Ich denke, der logische Fehler in Abschnitt 3.1 ist, dass du davon ausgehst, dass /usr in jedem Fall eine separate Partition wäre. Wenn sie das nicht ist, dann ist auf dem root filesystem auch /usr zu finden, also zum Boot-Zeitpunkt alles da, was das System braucht, um hochzufahren. Der Satz /usr, /opt, and /var are designed such that they may be located on other partitions or filesystems ist also kein Wiederspruch zu Abschnitt 3.2, denn wenn sich /usr auf der root-Partition befindet und es symbolische Links auf /[bin|sbin|lib|...] dazu gibt, dann ist Abschnitt 3.1 vollkommen korrekt – nur weil es ein solches Design gibt, heißt das noch lange nicht, dass es in jedem Fall auch derart getrennt sein muss. Es bestünde geschichtlich begründet und im FHS abgebildet jedoch die Möglichkeit, /bin und /usr/bin (usw.) zu trennen, wenn ein separates /usr (andere Partition, Netzwerklaufwerk) gewünscht ist.
Hier beißt sich die sprichwörtliche Katze in den Schwanz, denn das geht schon länger nicht mehr einfach so, denn mit shared libraries sind die Abhängigkeiten einfach zu kompliziert, oder man verwendet statisch gelinkte binaries für /bin und /sbin, was aber – vor allem, wenn /usr ohnehin auf der root-Partition liegt – dem Sinn von shared libraries entgegensteht (und obendrein erhöhten Arbeitsspeicherbedarf bedeutet).
Ich nutze übrigens Gentoo Linux, ohne Usrmerge. Mein Grundsystem lässt sich ohne initrd/initramfs booten, allerdings ist bei mir /usr auf derselben Partition, also auf dem root filesystem, untergebracht. Ob es auch bei separatem /usr-Volume funktionieren würde? Keine Ahnung. Das ist genau jener Fall, bei dem seinerzeit systemd nicht funktioniert hatte...ref
Ich habe übrigens doch noch Rezeptionen in der deutschen Fachpresse zum Usrmerge finden können:
Aber wirklich große Auswirkungen hatte das, wie gesagt, keine...
Zum weiteren Vorgehen: Ich werde deine Bearbeitung derzeit nicht angreifen, sondern so belassen, wie sie ist, da ich keine Zeit habe für qualitativ gute Artikelarbeit (Diskussionen sind um einiges leichter). Wenn ich aber dazu komme, werde ich sicher das eine oder andere ändern. Aber vielleicht hast bis dahin ja auch du weiter an deiner Artikelarbeit gefeilt? Das würde mich jedenfalls freuen.
Es bleibt also das Danke, dass du beigetragen hast. Gruß,
‣Andreas•⚖ 01:26, 29. Aug. 2022 (CEST)
In Ordnung. Wenn es sich ergibt, werde ich gerne noch etwas verbessern. Auch von mir noch ein Dank für den Austausch und einen Gruß! --TheEldestEdit (Diskussion) 01:32, 29. Aug. 2022 (CEST)
Gerne!
Noch ein Nachtrag zu Debian: But Debian's not throwing all of the LSB overboard: we're still firmly standing behind the FHS (version 2.3 through Debian Policy; although 3.0 was released in August this year) and our SysV init scripts mostly conform to LSB VIII.22.{2-8}. But don't get me wrong, this src:lsb upload is an explicit move away from the LSB.ref
Debian hielt sich damit 2015 weiterhin an den FHS, aber eben nicht an die LSB. Nachdem diese vorher ohnehin getrennt waren, ist das "not that big of a deal" im Bezug auf FHS, aber eben ein deutliches "Nein" zur LSB (die ja ein standardisiertes Binary-ABI bereitstellen will). ‣Andreas•⚖ 01:35, 29. Aug. 2022 (CEST)
Abgerufen von „https://de.wikiup.org/index.php?title=Diskussion:Filesystem_Hierarchy_Standard&oldid=225723589“