Unter Windows verfügt das Systemlaufwerk C:
über ein Verzeichnis program_files
, unter dem jedes Programm ein eigenes Verzeichnis hat.
In Linux, unter /usr/
und /usr/local/
gibt es /bin, /etc, /share, /src
etc.
In Windows sind also alle Dateien jedes Programms in demselben Verzeichnis gruppiert, während sich unter Linux Dateien desselben Typs aus allen Programmen befinden.
Ich bin der Meinung, dass die Art und Weise, wie Windows die installierten Programme organisiert, logischer ist als die von Linux, und daher sind installierte Programme einfacher manuell zu verwalten.
Was ist der Vorteil der Art und Weise, wie Linux die Dateien installierter Programme organisiert? Vielen Dank.
Ich habe diese Frage, wenn ich das Problem habe, wie installierte Programme in $ HOME für Shell organisiert werden, um sie beim Ausführen zu suchen. , wo ich versuche, meine Programme nach $HOME
Windows zu organisieren, aber Probleme beim Festlegen der Suchpfade für die Programme habe.
Antworten:
Unter Linux spiegeln die verschiedenen Speicherorte normalerweise, wenn sie gut gepflegt sind, eine gewisse Logik wider. Z.B.:
/bin
enthält die grundlegendsten Werkzeuge (Programme)/sbin
enthält die grundlegendsten VerwaltungsprogrammeBeide enthalten die elementaren Befehle, die beim Booten und bei der grundlegenden Fehlerbehebung verwendet werden. Und hier sehen Sie den ersten Unterschied. Einige Programme sind nicht für normale Benutzer gedacht.
Dann schauen Sie doch mal rein
/usr/bin
. Hier sollten Sie eine größere Auswahl an Befehlen (Programmen) finden, normalerweise mehr als 1000 davon. Sie sind Standardwerkzeuge, aber nicht so wichtig wie die in/bin
und/sbin
./usr/bin
enthält die Befehle, während sich die Konfigurationsdateien an anderer Stelle befinden. Dies trennt sowohl die funktionalen Entitäten (Programme) als auch deren Konfigurations- und andere Dateien. In Bezug auf die Benutzerfunktionalität ist dies jedoch praktisch, da die Befehle, die nicht mit anderen Elementen vermischt sind, die einfache Verwendung derPATH
Variablen ermöglichen, die auf die ausführbaren Dateien verweist. Es führt auch Klarheit ein. Was auch immer ist, sollte ausführbar sein.Schau dir meine an
PATH
,Es gibt genau sechs Speicherorte, die die Befehle enthalten, die ich direkt aufrufen kann (dh nicht anhand ihrer Pfade, sondern anhand der Namen ihrer ausführbaren Dateien).
/home/tomas/bin
ist mein privates Verzeichnis in meinem Home-Ordner für meine privaten ausführbaren Dateien./usr/local/bin
Ich werde unten separat erklären./usr/bin
ist oben beschrieben./bin
ist auch oben beschrieben./usr/local/games
ist eine Kombination aus/usr/local
(weiter unten zu erklärenden) und Spielen/usr/games
sind Spiele. Um nicht mit ausführbaren Dienstprogrammen gemischt zu werden, haben sie separate Speicherorte.Nun zu
/usr/local/bin
. Dieser ist etwas rutschig und wurde bereits hier erklärt: Was ist / usr / local / bin? . Um dies zu verstehen, müssen Sie wissen, dass der Ordner/usr
möglicherweise von vielen Computern gemeinsam genutzt und von einem Netzspeicherort aus bereitgestellt wird. Die dortigen Befehle werden beim Booten nicht benötigt, wie bereits erwähnt, im Gegensatz zu denen in/bin
, sodass der Speicherort in späteren Phasen des Bootvorgangs bereitgestellt werden kann. Es kann auch schreibgeschützt montiert werden./usr/local/bin
Auf der anderen Seite ist für die lokal installierten Programme und muss beschreibbar sein. Während viele Netzwerkcomputer möglicherweise das allgemeine/usr
Verzeichnis gemeinsam nutzen, wird auf jedem von ihnen ein eigenes/usr/local
im gemeinsamen Verzeichnis bereitgestellt/usr
.Schauen Sie sich zum Schluss
PATH
meinen Root-Benutzer an:Es enthält diese:
/usr/local/sbin
, der die admin-Befehle des Typs enthält/usr/local
/usr/local/bin
Dies sind die gleichen, die der normale Benutzer verwenden kann. Auch hier kann ihr Typ beschrieben werden als/usr/local
./usr/sbin
sind die nicht wesentlichen Verwaltungsdienstprogramme./usr/bin
sind die nicht wesentlichen Verwaltungs- und regulären Benutzerdienstprogramme./sbin
sind die wesentlichen Admin-Tools./bin
sind die wesentlichen Tools für Administratoren und reguläre Benutzer.quelle
/home/tomasz/bin/
, siehe unix.stackexchange.com/questions/431793/…/bin
und/usr/bin
tatsächlich Probleme mit netzwerkmontierten/usr
Verzeichnissen zu vermeiden war , die Trennung von/usr
und/usr/local
zur Unterscheidung zwischen vom Hersteller bereitgestellten Dateien (/usr
) und manuell auf dem Computer selbst installierten Dateien (/usr/local
) dient und nichts damit zu tun hat die Probleme bei der Netzwerkmontage. Ist das richtig?/usr
-off-a-Network (vs/usr/local
, na ja, lokal ) nicht ungewöhnlich von.Heutzutage denke ich, dass dies ein historisches Erbe des klassischen UNIX ist.
In den ersten UNIX-Versionen waren die Programme nicht so groß wie heute. Die Programme bestanden häufig aus einer ausführbaren Datei, die Systembibliotheken verwendet. Daher dachte niemand an Programme, die aus einigen eigenen Bibliotheken bestehen werden. Die Hauptbibliothek war die C-Bibliothek, und jedes Programm wusste über den Speicherort Bescheid.
Außerdem wurde die UNIX-Umgebung als fertiges Produkt betrachtet (zur Vorbereitung der Dokumentation). Daher wurde der Pfad zu allen Werkzeugen festgelegt.
Einige Vorteile von festen Pfaden in HDD-Tagen (Hard Disk Drive) sind heutzutage vorhanden. Wenn FSH (File System Hierarchy) auf separate Festplattenpartitionen aufgeteilt und Partitionen mit Binärdateien und Bibliotheken in der Nähe der primären Sektoren der Festplatte platziert werden, ist der Zeitpunkt des Programmstarts etwas kürzer.
quelle
/usr/bin
, statischen Datendateien/usr/share
und Dateien, die geändert werden können,/var
oder/usr/var
bedeutet, dass Sicherheitsmaßnahmen verwendet werden können, um zu erzwingen, dass nichts inshare
odervar
ausführbar ist (indemnoexec
Flags für ihre Bereitstellungen verwendet werden); dass nichts außerhalbvar
geändert werden kann (auf einem System, dasdm_verity
oder ähnliche Maßnahmen zur Erzeugung signierter, schreibgeschützter Medien verwendet); usw.Was Sie als modernes Unix-ähnliches System sehen, ist nicht wirklich traditionell.
Normalerweise würde es ziemlich minimal
/
und/usr
Hierarchien mit nur Systemprogrammen und Programme werden dann getrennt in ein Unterverzeichnis installiert/usr/local
, und dann durch die Schaffung von symbolischen Links zur Verfügung gestellt.Ein sehr typisches Setup für GNU-Software war das Kompilieren und Installieren mit
Das GNU- Dienstprogramm zum Verstauen erstellt symbolische Links, um die Software auf dem Standardpfad verfügbar zu machen, ohne der PATH-Variablen Verzeichnisse hinzufügen zu müssen (wie dies bei Windows der Fall ist und sich Cruft dort ansammelt).
Moderne Linux-Distributionen liefern jedoch alles als vorgefertigte Pakete aus, sodass Programme Teil des "Systems" geworden sind. Da sich der Paketmanager um die Installation kümmert, sind keine symbolischen Verknüpfungen erforderlich, und das Trennen von Programmen dient keinem nützlichen Zweck (würde jedoch den Programmstart verlangsamen, da viele kleine Verzeichnisse gescannt werden müssten).
Wenn Sie Software in Ihrem Home-Verzeichnis installieren möchten, empfehlen wir Ihnen, auch GNU stow zu verwenden. Auf diese Weise können Sie Ihre Programme getrennt halten. Dies ist sinnvoll, wenn Sie keinen Paketmanager verwenden.
Meine traditionelle Setup für das ist ein Verzeichnis ,
~/software/DIR
dass ich Programme installieren , in, dann innen mit versenkbarenDIR
zu erstellen~/software/bin
,~/software/share
usw. Das bedeutet , ich nur hinzufügen müssen ,~/software/bin
um das PATH - Variable , um all meine installierte Software.Verwenden:
zu installieren, wenn das Programm den GNU-Konventionen entspricht.
quelle
Sie sprechen anscheinend über den Stil der Aufteilung einzelner Dateien nach Zweck (
/usr/bin
für ausführbare Dateien,/usr/lib
für Bibliotheken) und nicht nach Anwendungspaket (C ++ - Compiler in einem Verzeichnis, Bildbearbeitungsprogramme in einem anderen). Während in Unix-Systemen ein Großteil des Grundes für diese Geschichte liegt, gibt es auch aktuelle Kräfte, die dazu neigen, Unix-ähnliche Systeme dazu zu neigen: Paketmanager, die die meisten Programme auf einem System verwalten.Unter Windows waren Anwendungen in der Vergangenheit und heute noch ziemlich dafür verantwortlich, ein eigenes Installationsprogramm und insbesondere ein Deinstallationsprogramm bereitzustellen, und registrieren sich auch jetzt noch häufig nicht bei einer zentralen Anwendungsliste. In einer solchen Situation ist es für eine Anwendung im Allgemeinen besser, ein "eigenes" Verzeichnis für so viele Dateien wie möglich zu haben. Dies hilft, Konflikte mit anderen Anwendungen zu vermeiden, obwohl dies nicht immer funktioniert (insbesondere bei DLLs ).
Unix-Systeme hingegen haben seit den 90er Jahren im Allgemeinen jeweils einen einzigen akzeptierten Paketmanager und eine Gruppe, die über diesen Paketmanager eine große Menge häufig verwendeter Software bereitstellt. (Offizielle Paketmanager für verschiedene Unices umfassen
yum
undapt
für Linux-Systeme,pkgsrc
für NetBSD undports
für FreeBSD. Häufig verfügen kommerzielle Unix-Systeme auch über einen inoffiziellen, aber weithin akzeptierten Paketmanager, z. B.brew
für MacOS.)Diese Paketmanager haben den Vorteil, dass sie jede Datei auf dem System in den verschiedenen Unterverzeichnissen verfolgen können, die sie "besitzen". Da eine einzelne Gruppe hier den Namen und den Speicherort jeder Datei zuweist, können sie alle einen kleinen Satz von Verzeichnissen verwenden, die von ihnen gemeinsam genutzt werden. Dies bietet verschiedene Vorteile, insbesondere in den Bereichen der gemeinsamen Nutzung von Dateien zwischen Anwendungen und der Verringerung der Anzahl der Pfade, die Sie für die Suche nach Bibliotheken und ausführbaren Dateien benötigen.
Trotzdem gibt es eine lange Tradition der Installation von "Separates Verzeichnis pro Anwendung" auch unter Unix, normalerweise unter dem
/opt
Verzeichnis.quelle