Was ist der Grund für das Verzeichnis '/ usr'?

88

Was ist der Grund für die "Unix-Systemressourcen" oder das /usr -Verzeichnis, wie hier hier beschrieben, das viele Duplikate enthält der Verzeichnisnamen im Stammverzeichnis / ?

Mein Ziel: Ich installiere Oracle JDK zum x-ten Mal und entschied dieses Mal, es einfach unter /home/user zu setzen, und ich lese nur ein wenig herum, um zu sehen, ob es eine schlechte Idee auf einem einzelnen Benutzer-Rechner ist .

    
H2ONaCl 02.05.2012, 18:46

1 Antwort

133

Es gibt die kurze Version und die lange Version Ihrer Antwort ...

Kurzversion:

Wie bereits erwähnt, ist /usr ein Platz für systemweite , schreibgeschützte Dateien. So geht all Ihre installierte Software dorthin. Es kopiert keine Namen von / außer /bin und /lib , aber ursprünglich mit einem anderen Zweck: /bin, /lib ist nur für Binärdateien und Bibliotheken erforderlich zum Booten , während /usr/bin, /usr/lib ist für alle anderen ausführbaren Dateien und Bibliotheken. (jetzt sei ein guter Junge und frag nicht nach /sbin , das ist schließlich die Kurzversion)

Heutzutage hat sich die Unterscheidung zwischen "erforderlich zum Booten" verringert, da die meisten modernen Distributionen, einschließlich Ubuntu, nicht ohne mehrere Dateien von /usr booten können. Und deshalb gibt es eine starke Bewegung zum Zusammenführen von /usr/bin und /bin , also wahrscheinlich in naher Zukunft (Ubuntu 12.10 vielleicht?)% Co_de% wird ein Symlink zu /bin sein.

Aber vielleicht verwirren Sie /usr/bin und /usr ? Denn ja, es gibt (und sollte) ein Los von doppelten Verzeichnisnamen. Mehr dazu später ...

Lange Version:

In den 70ern hatten Disketten in Unix (ja, Unix, weit vor Linux) wenig Platz (keine HD, erinnerst du dich?), und zu einem bestimmten Zeitpunkt wuchsen die Systembinärdateien zu sehr in Anzahl und Größe sie würden nicht auf eine einzelne Festplatte passen, und Entwickler mussten sie auf mehrere Medien aufteilen und so neue Bereitstellungspunkte für sie erstellen. /usr/local Dateisystem war voll, also installierten sie die neuen Binärdateien bei ... /bin . Und /usr/bin war zu dieser Zeit ihr ... user Verzeichnis!

Nachdem die Trennung (fast peinlich und oft als Scherz erzählt) begann, begannen sie, "künstliche" Rechtfertigungen (und Kriterien) zu erstellen, um zu entscheiden, was zu /usr und was zu /bin gehen würde. Die informelle Regel lautete: "essentielles" Zeug geht zu /usr/bin , "der Rest" geht an /bin . Gleiches mit /usr/bin . Es dauerte nicht lange, bis /lib mit systembezogenen Verzeichnissen, gemischt mit Benutzerverzeichnissen, überfüllt war. Also wurde /usr geboren, um alle benutzerbezogenen Verzeichnisse beizubehalten und /home nur für System-Sachen zu behalten.

Das war lange bevor FHS existiert. Als es erstellt wurde, nahm es die aktuelle Tradition auf (und formalisierte) und behielt den Namen /usr , obwohl es zu diesem Zeitpunkt noch nichts mit "user" zu tun hatte. Also ja, die ausgefallenen Namen " U NIX s ource r Repository" oder " U NIX s System r esources "sind alle erfundenen Namen, und es ist zu spät, um es trotzdem umzubenennen. (aber nicht zu spät, um /usr damit zu verbinden)

"Ok, was ist mit /bin ?" , fragst du. Verdammt, ich hatte gehofft, du hättest es vergessen. Ok ... /usr/sbin ist für Befehle, die nur vom /usr/sbin Benutzer ausgeführt werden können (oder nur dann sinnvoll sind), wie root und mount .

"Aber ist das nicht fast dasselbe wie fdisk ?" . Ja, sicher, aber ...

"Warte, warum gibt es auch /bin ? Macht keinen Sinn!" . Nun, das ist wegen ... äh .. humm ..

Schau, ein dreiköpfiger Affe hinter dir!

Ok, hoffentlich hast du genug abgelenkt. Weiter ...

(wenn du denkst, ich betrüge, ja, du hast recht. Aber so ist die "offizielle" Antwort "essentielle Befehle, die nur von root ausgeführt werden können und müssen verfügbar sein, bevor du% co_de mounten kannst % "). Die Wahrheit ist: Die Linie ist in der Tat verschwommen, und es gibt viele Legendennamen, die einfach "hängen geblieben" sind und jetzt ist es ziemlich schwer loszuwerden.

Mehr zum Fall für die /sbin Zusammenführung , von / docs:

  

Die historische Begründung für a / bin, / sbin und / lib getrennt von / usr gilt heute nicht mehr. Sie wurden aufgeteilt, um auf einer schnelleren Festplatte (die klein war, weil sie teurer war) ausgewählte Tools auszuwählen und alle Tools zu enthalten, die zum Mounten der langsameren / usr-Partition notwendig waren. Heute muss eine separate / usr-Partition bereits während des frühen Bootens von den initramfs gemountet werden, wodurch die Begründung für einen Split-Off-Moot gegeben ist. Außerdem haben viele Tools in / bin und / sbin im Status quo bereits die Fähigkeit verloren, ohne pre-mounted / usr zu laufen. Es gibt keinen triftigen Grund mehr, das Betriebssystem auf mehrere Hierarchien zu verteilen, es hat seinen Zweck verloren.

Und eine erstaunliche Lektüre über die /usr split und ihre Begründung, von Rob Landley:

Verständnis der bin, sbin, usr / bin, usr / sbin Split

Heutzutage

Gegenwärtig ist der beste Weg, um Installationsverzeichnisse zu verstehen, folgendermassen zu denken:

  • systemd - alle systemweiten schreibgeschützten Dateien, die vom Betriebssystem installiert werden (oder von ihm bereitgestellt werden)

  • /usr - systemweite schreibgeschützte Dateien, die vom lokalen Administrator (normalerweise Sie) installiert werden. Und deshalb sind die meisten Verzeichnisnamen von /usr hier doppelt vorhanden.

  • /usr/local - eine Grausamkeit, die für systemweite, schreibgeschützte und in sich geschlossene Software gedacht ist. Das heißt, Software, die ihre Dateien nicht über /usr , /opt , bin , lib wie gut erzogene Software aufteilen sollte.

  • share - das pro-Benutzer-Gegenstück von include , das heißt: Software, die von (und für) jedem Benutzer installiert wird

  • ~/.local - das pro-Benutzer-Gegenstück von /usr/local

Wo installieren Sie Software?

Die obige Liste ist schon die halbe Antwort auf Ihre Oracle JDK Frage, zumindest gibt es einige Hinweise. Die Checkliste zu "Wo installiere ich Software X?" wird folgendermaßen angezeigt:

  • Handelt es sich um eine vollständig eigenständige Software mit einem einzigen Verzeichnis, wie Eclipse IDE und anderen heruntergeladenen Java-Apps, und Sie möchten, dass sie für alle Benutzer verfügbar ist? Dann installiere in ~/.local/opt

  • Wie oben, aber Sie interessieren sich nicht für andere Benutzer und ich möchte für Ihren Benutzer allein installieren? Dann installiere in /opt

  • Die Dateien sind auf mehrere Verzeichnisse aufgeteilt, wie /opt und ~/.local/opt , wie traditionelle Software, die mit bin kompiliert und installiert wurde und für alle Benutzer verfügbar sein sollte? Dann installiere in share

  • Wie oben, aber nur für Ihren Benutzer? Dann installiere in ./configure && make && sudo make install

  • Software, die vom Betriebssystem oder über Paket-Manager (wie Software Center) installiert wird, und vor allem , bei der jede lokale Änderung möglicherweise überschrieben wird, wenn der Update Manager sie auf eine neue Version aktualisiert. ? Es geht zu /usr/local

Hinweise:

  • Dies erklärt, warum das Standardinstallationspräfix für kompilierte Software ~/.local ist und warum Sie es bei der Installation von Software nur für Ihren eigenen Benutzer in /usr ändern sollten

  • Sie haben vielleicht bemerkt, dass alle obigen Verzeichnisse schreibgeschützt sind (außer natürlich, wenn Sie Software installieren / entfernen). Die beschreibbaren Dateien (wie Konfigurationsdateien) gehen normalerweise zu /usr/local (für systemweite Software) und ./configure --prefix=$HOME/.local (für benutzerspezifische Einstellungen). Obwohl viele Legacy-Software (und leider auch einige moderne) verwenden Sie /etc , überfüllen Sie Ihren Home-Ordner mit Milliarden von Verzeichnissen und Dateien.

  • ~/.config und ~/.<software-name> sind nicht Teil der FHS-Spezifikation. FHS behandelt nicht den Benutzerordner des Benutzers. Sie sind ein Versuch von XDG, einer anderen Standardorganisation, die auf Desktopumgebungen ausgerichtet ist (wie Gnome, KDE und Unity), um zu versuchen, einige Konventionen bezüglich einer Struktur des Heims des Benutzers festzulegen. Nicht alle Software hält sich daran (zum Beispiel ist ~/.local nicht im Standard ~/.config des Benutzers, während es logisch ist) , und kein Benutzer ist gezwungen, ihm zu folgen, aber beide gewinnen viele Interoperabilität Vorteile, wenn sie tun.

Ich hoffe, das hilft, die Dinge ein wenig zu klären. Fühlen Sie sich frei, etwas zu fragen, damit ich die Antwort verbessern kann!

(und ich hoffe auch, dass mich Puristen nicht wegen einer so extrem informellen Sprache und Erklärung töten. Es war beabsichtigt, und es hat sicherlich viele Ungenauigkeiten, aber ich glaube, dass es ein guter Weg ist Ein Neuankömmling hat einen kurzen Überblick über die Grundprinzipien von Installationsverzeichnissen.

    
MestreLion 11.05.2012, 22:49

Tags und Links