Esistono la versione breve e la versione lunga della tua risposta ...
Versione breve:
Come il tuo link già detto, /usr
è un posto per livello di sistema , di sola lettura dei file. Quindi tutto il software installato va lì. Non duplica alcun nome di /
tranne /bin
e /lib
, ma, in origine, con uno scopo diverso: /bin, /lib
è solo per i binari e le librerie necessari per l'avvio , mentre /usr/bin, /usr/lib
è per tutti gli altri eseguibili e librerie. (ora sii un bravo ragazzo e non chiedertelo /sbin
, dopo tutto questa è la versione breve)
Al giorno d'oggi, la distinzione tra "richiesto per l'avvio" e non è diminuita, dal momento che la maggior parte delle distro moderne, tra cui Ubuntu, non può avviarsi correttamente senza diversi file da /usr
. Ed è per questo che c'è un forte movimento verso la fusione /usr/bin
e /bin
, quindi probabilmente nel prossimo futuro (forse Ubuntu 12.10?) /bin
Sarà un collegamento simbolico a /usr/bin
.
Ma forse sei confuso /usr
e /usr/local
? Perché sì, ci sono (e dovrebbero esserci) molti nomi di directory duplicati. Ne parleremo più avanti ...
Versione lunga:
Negli anni '70, in Unix (sì, Unix, molto prima di Linux), i floppy avevano poco spazio (no HD, ricordi?), E ad un certo punto i binari del sistema sono cresciuti troppo in numero e dimensioni a un punto che non avrebbero adattarsi a un singolo disco e gli sviluppatori hanno dovuto dividerli su più supporti e quindi creare nuovi punti di montaggio per loro. /bin
filesystem era pieno, così hanno installato i nuovi binari a ... /usr/bin
. Ed /usr
era, a quel tempo, la loro ... directory utente !
Dopo che è avvenuta la divisione (quasi imbarazzante e spesso raccontata come una barzelletta / tradizione), hanno iniziato a creare giustificazioni (e criteri) "artificiali" per decidere cosa sarebbe andato /bin
e cosa sarebbe andato /usr/bin
. La regola informale era: le cose "essenziali" vanno a /bin
, "il resto" va a /usr/bin
. Lo stesso con /lib
. Non passò molto tempo prima che /usr
diventasse affollato di dir relativi al sistema, mescolati con dir utente. Così /home
è nato, per mantenere tutte le directory relative all'utente e mantenere /usr
pulite solo le "cose" del sistema.
Questo era molto prima che esistesse FHS. Quando è stato creato, ha abbracciato (e formalizzato) la tradizione attuale e mantenuto il nome /usr
, anche se a quel tempo non aveva più nulla a che fare con "utente". Quindi sì, i nomi di fantasia " U NIX s ource r epository" o " U NIX s istema r Pagine Ingrosso" sono tutti nomi inventati, ed è troppo tardi per rinominare comunque. (ma non troppo tardi per unirci /bin
)
"Ok, che dire /usr/sbin
?" , tu chiedi. Accidenti, speravo che ti fossi dimenticato. Ok ... /usr/sbin
è per i comandi che possono essere (o sono significativi solo quando) eseguiti root
dall'utente, come mount
e fdisk
.
"Ma non è quasi uguale /bin
?" . Sì certo, ma ...
"Aspetta, allora perché c'è /sbin
anche un ? Non ha alcun senso!" . Beh, questo è a causa di ... err .. humm ..
Guarda, una scimmia a 3 teste dietro di te!
Ok, si spera, ti sei distratto abbastanza. Andare avanti...
(se pensi che io stia tradendo, sì, hai ragione. Ma lo sono anche i comandi essenziali "risposta ufficiale" che possono essere eseguiti solo da root e devono essere disponibili anche prima di montare /
"). La verità è: la linea è davvero sfocata, e ci sono molti nomi legacy che sono semplicemente "bloccati" e ora è abbastanza difficile liberarsene.
Maggiori informazioni sul caso per l' /usr
unione , dai systemd
documenti:
La giustificazione storica per / bin, / sbin e / lib separata da / usr non si applica più oggi. Sono stati divisi per avere strumenti selezionati su un disco rigido più veloce (che era piccolo, perché era più costoso) e per contenere tutti gli strumenti necessari per montare la partizione più lenta / usr. Oggi, una partizione / usr separata deve già essere montata dagli initramfs durante l'avvio iniziale, rendendo così la giustificazione per un moot diviso. Inoltre, molti strumenti in / bin e / sbin nello status quo hanno già perso la capacità di funzionare senza un pre-montato / usr. Non esiste più alcun motivo valido per distribuire il sistema operativo su più gerarchie, ha perso il suo scopo.
E una lettura straordinaria sulla /usr
scissione e la sua logica, di Rob Landley:
Comprensione bin, sbin, usr / bin, usr / sbin split
Al giorno d'oggi
Attualmente, per quanto riguarda le directory di installazione, il modo migliore per capire è pensare in questo modo:
/usr
- tutti i file di sola lettura e di sistema installati dal (o forniti dal) sistema operativo
/usr/local
- file di sola lettura a livello di sistema installati dall'amministratore locale (di solito tu). Ed è per questo che la maggior parte dei nomi di directory da /usr
è duplicata qui.
/opt
- un'atrocità intesa per software a livello di sistema, di sola lettura e autonomo . Cioè, il software che non dividere i propri file su bin
, lib
, share
, include
come ben educati software dovrebbe.
~/.local
- la controparte per utente di /usr/local
, ovvero: software installato da (e per) ciascun utente
~/.local/opt
- la controparte per utente di /opt
Quindi dove installare il software?
L'elenco sopra è già metà della risposta alla tua domanda Oracle JDK, almeno fornisce diversi indizi. L'elenco di controllo per "Dove devo installare il software X?" passa per:
È un software completamente autonomo, a directory singola, come Eclipse IDE e altre app java scaricate, e vuoi che sia disponibile per tutti gli utenti? Quindi installare in/opt
Come sopra, ma non ti interessano gli altri utenti e voglio installarlo solo per il tuo utente? Quindi installare in~/.local/opt
I suoi file sono suddivisi su più dir, come bin
e share
, come i software tradizionali compilati e installati ./configure && make && sudo make install
, e dovrebbero essere disponibili per tutti gli utenti? Quindi installare in/usr/local
Come sopra, ma solo per il tuo utente? Quindi installare in~/.local
Software installato dal sistema operativo o tramite gestori di pacchetti (come Software Center) e, soprattutto, quali modifiche locali potrebbero essere sovrascritte quando Update Manager lo aggiorna a una nuova versione ? Va a/usr
Appunti:
Questo spiega perché il prefisso di installazione predefinito per il software compilato è /usr/local
e perché è necessario modificarlo ./configure --prefix=$HOME/.local
quando si installa il software solo per il proprio utente
Potresti aver notato che tutte le directory sopra sono di sola lettura (tranne, ovviamente, quando installi / rimuovi software). I file scrivibili (come i file di configurazione) di solito vanno in /etc
(per il software a livello di sistema) e ~/.config
(per le impostazioni per utente). Anche se molti software legacy (e, purtroppo, anche alcuni moderni) usano ~/.<software-name>
, ingombra la cartella home con miliardi di dir e file.
~/.local
e ~/.config
non fanno parte delle specifiche FHS. FHS non si occupa della cartella principale dell'utente. Sono un tentativo di XDG, un'altra organizzazione standard orientata verso gli ambienti desktop (come Gnome, KDE e Unity), per cercare di stabilire alcune convenzioni riguardanti una struttura della casa dell'utente. Non tutto il software lo aderisce (ad esempio, ~/.local/bin
non è predefinito dall'utente $PATH
, mentre per logica dovrebbe) e nessun utente è costretto a seguirlo, ma entrambi ottengono molti vantaggi di interoperabilità se lo fanno.
Spero che questo aiuti a chiarire un po 'le cose. Sentiti libero di chiedere qualsiasi cosa così posso migliorare la risposta!
(e spero anche che i puristi non mi uccidano per un linguaggio e una spiegazione estremamente informali. Era intenzionale e sicuramente ha molte inesattezze, ma credo che sia un buon modo per fare in modo che un nuovo arrivato abbia una breve visione d'insieme sull'installazione directory razionali)