Chiariamoci con tutte le cartelle bin e sbin (dallo standard della gerarchia dei filesystem):

• /bin è per i binari a livello di sistema
• /sbin è per altri file binari a livello di sistema principalmente per boot loader e amministratori di sistema
• /usr/bin non è per i binari non essenziali
• /usr/sbin- è qui che inizia il disordine - non strumenti essenziali per gli amministratori di sistema? Cosa significa? Per esperimenti?
• /usr/local/bin - nessuna parola su questa cartella
• /usr/local/sbin- programmi di amministrazione del sistema installati localmente. Ancora? Che ne dici /usr/sbin?

Quindi la domanda è: perché ci sono così tante directory e quali sono i significati di /usr/sbin, /usr/local/sbine /usr/local/bin?

Molti programmi sono distribuiti attraverso archivi e dobbiamo costruirli dal codice sorgente. Di solito hanno makefile quindi è abbastanza facile. Questo processo prevede la creazione di file in usr / local / lib, usr / local / bin ... usr / local / qualunque cosa senza creare cartelle specifiche per un determinato programma.

Perché è così?

Penso che non sia giusto perché se dobbiamo rimuovere il programma dobbiamo eliminare manualmente tutti i suoi file se il creatore del programma non se ne è occupato.

1. Struttura della directory

Questo dovrebbe essere trattato nel Filesystem Hierarchy Standard ( 2.3 PDF )

/ bin / binari di comando essenziali che devono essere disponibili in modalità utente singolo;
            per tutti gli utenti, ad esempio cat, ls, cp

/ sbin / File binari di sistema essenziali, ad es. init, ip, mount.

/ usr / bin / File binari di comando non essenziali (non necessari in modalità utente singolo); 
            per tutti gli utenti

/ usr / sbin / File binari di sistema non essenziali, ad es. demoni per vari servizi di rete.

Gerarchia / usr / local / Tertiary per dati locali, specifici per questo host. 
            In genere ha ulteriori sottodirectory, ad esempio bin /, lib /, share /

2. Installazione

Uso un gestore di pacchetti ove possibile (ad es. Yum o apt-get). Questo è possibile per un numero molto elevato di applicazioni, in alcuni casi potrebbe essere necessario aggiungere un repository. La mia seconda scelta sarebbe pacchetti di livello inferiore come RPM e la compilazione dal sorgente sarebbe la mia ultima risorsa (ma alcune persone preferiscono questo)

Alcuni gestori di pacchetti possono installare da RPM (ad es. yum install oddity.rpm)

Se stai compilando dal sorgente, probabilmente non è un grande passo per creare il tuo pacchetto in modo che il programma di installazione del sistema sappia cosa hai fatto.

Quindi il tuo problema si riduce ad es yum remove packagename

L'alternativa è conservare una buona documentazione su tutte le attività di amministratore di sistema intraprese (tengo comunque un diario in un file di testo)

Le cose in tutte le directory * / sbin tendono ad essere utili solo per gli amministratori di sistema. Puoi tenerli fuori dal tuo PERCORSO se sei un normale utente.

Le diverse directory non hanno molto senso se si dispone di una sola macchina unix su un singolo disco, ma ha più senso se si dispone di un sistema grande e di partizioni diverse. Ricorda che molte di queste abitudini sono state fatte negli anni '80 e '90 quando i sistemi erano un po 'diversi.

/sbintende ad essere molto piccolo. Queste sono utility di cui hai bisogno quando sei davvero hosed. Lo inseriresti su una partizione root minima con / root e / lib. Le cose in / sbin erano tutte collegate staticamente, poiché se la tua partizione / usr viene cancellata, tutte le app collegate dinamicamente sono inutili. fsck è qui e staticamente collegato. Se hai una dipendenza da / usr, ovviamente non puoi fsck / usr /. Ovviamente, se la partizione di root viene cancellata, sei molto fregato. Questo è il motivo per cui si tratta di una partizione così piccola: abbassa le probabilità di un blocco disco errato usando pochissimi blocchi qui.

/usr/sbini binari sono strumenti generali di amministratore di sistema in cui è possibile almeno accedere alla modalità utente singolo e montare tutti i volumi. Possono essere collegati dinamicamente.

Le partizioni separate per / sbin (beh, / sbin on / partition) e / usr hanno anche più senso se ricordi che il backup era molto costoso sia in tempo che per il nastro. Se fossero su partizioni separate, potresti pianificarle in modo diverso.

/usr/localpuò essere un filesystem di rete. Quindi gli strumenti sysadmin scritti localmente che possono essere condivisi su molte macchine a volte vanno in / usr / local / sbin. Ovviamente nessuna utility di riparazione della rete può andare lì.

Ancora una volta, molte cose avevano più senso su grandi macchine in un ambiente di rete su macchine gestite con più volumi, meno con una macchina Linux su una singola partizione di root.

Dovresti davvero avere la tua seconda domanda essere una domanda separata qui su Superuser. Non è correlato al primo.

Sì, avere file dappertutto fa schifo. Ecco perché ci sono molte soluzioni di imballaggio. RedHat ha creato RPM che viene utilizzato ovunque. Solaris aveva il formato del pacchetto. HP / UX avevano il loro, e c'è apt e molti altri formati di pacchetto. Tieni le cose nei posti giusti (/ usr / bin, / usr / lib) come appropriato, ma consenti una facile aggiunta e rimozione.

Per l'origine, c'erano strumenti che ti permettevano di configurare e installare in un sottodir di / usr / local e che gestiva i collegamenti simbolici a / usr / local / bin per te. Poiché l'ampia proliferazione di strumenti di pacchetto, questo è meno necessario e ho dimenticato i loro nomi.

Ad alcune persone piace installare in / opt / nomepacchetto e tenere tutto insieme. Il buono: tutto è in una directory e una disinstallazione è rm -rf /opt/packagename. Gli svantaggi di questo sono l'aggiunta di / opt / nomepacchetto / bin al PERCORSO di tutti e il fatto che le persone di solito non inseriscono / optano in una partizione separata e si compila la partizione di root.

La mia opinione sul significato delle directory (dall'esperienza con Debian GNU Linux) è questa:

Prima distinzione: sè per superutente

sprima che una bindirectory indichi che contiene strumenti che sono normalmente utili solo agli amministratori. Si noti che ad esempio ifconfigappartiene anche a questa categoria e mi piace invocare ifconfigcome utente normale (per verificare se ho un indirizzo IP / connettività di rete) che rende questa distinzione non così difficile come potrebbe sembrare.

Seconda distinzione: localè per "Dati locali"

In pratica, la distinzione più importante qui è che i gestori di pacchetti del sistema operativo (come APT) installano i pacchetti nella /usrstruttura normale e lasciano /usr/localinalterati. Ciò consente di collocare pacchetti compilati localmente o script interni all'azienda forniti dall'amministratore di sistema in modo /usr/localche non interferiscano mai con i file correttamente impacchettati.

È discutibile se /usr/localdebba sovrascrivere i file esistenti dalla /usrstruttura normale , vedi È pericoloso avere / usr / local / bin davanti a / usr / bin nel proprio PERCORSO? per alcuni dettagli su questo.

Terza distinzione: livello superiore /bine /sbindirectory.

Su Debian, in realtà esiste un cosiddetto UsrMerge . C'era la differenza che /bined /sbinera disponibile nel processo di avvio in precedenza (penso di /usressere su un dispositivo di rete o su una diversa partizione, RAID ecc.), Ma oggigiorno pochi sistemi Linux si avviano bene senza il /usrquale prenderei in considerazione la distinzione tra top- livello e /usrdirectory per essere in gran parte di interesse storico per Linux.

Infine: i meriti e i problemi dei file "scattering".

Non esiste davvero una "vera risposta" a questo. I vantaggi del file system sparso di Linux sono questi:

• Tutti i binari risiedono in poche directory. Ciò significa che è possibile chiamare tutti i programmi dalla shell. Confronta Windows, dove è sempre necessario modificare la %PATH%variabile di ambiente per aggiungere qualsiasi programma di interesse. Ho visto ambienti con percorsi molto lunghi su Windows.

• Tutte le biblioteche si trovano in una posizione centrale. Ciò significa che non devono essere installati due volte se utilizzati da più applicazioni.

• Poiché Linux è progettato per la maggior parte dei file di sistema tracciati da un gestore di pacchetti , non è necessario mantenere una visione d'insieme dei file dal punto di vista dell'utente.

• A causa della FHS la standardizzazione, la documentazione risiede anche in luoghi centrali sistemi che consentano amano man, infoei file README di supporto a funzionare come previsto.

• È più semplice fare affidamento su un programma installato in un luogo fisso. Tutti scrivono #!/bin/sh -eo simili all'inizio degli script e funziona . Considera un sistema in cui la shell andrebbe in una directory diversa: come si può sapere quale nome prenderà? Se interessati, controlla i vari modi per installare Perl o LaTeX su Windows per vedere quanto può essere complicato ...

Gli svantaggi che ho trovato finora sono questi:

• Normalmente, è più difficile eseguire le applicazioni "in modo portabile" nel senso di "applicazioni portatili per Windows". Su Linux, non è così semplice copiare il programma su un altro computer ... è necessario disporre del pacchetto (che richiede i permessi di root) o occuparsi LD_LIBRARY_PATHdi puntare le applicazioni verso percorsi di ricerca diversi per le librerie richieste.

• L'installazione di più versioni dello stesso programma deve essere supportata esplicitamente, mentre sui sistemi con "una directory per programma" questo è spesso meno problematico.

• La gestione dei file senza un gestore pacchetti è soggetta a errori (come già accennato).

Per rispondere alla tua seconda domanda: di
solito i programmi sono distribuiti con un cosiddetto gestore di pacchetti . Un gestore di pacchetti di solito recupera pacchetti binari (software compilato per una determinata piattaforma) e lo lancia in directory (ci sono alcuni che scaricano il codice sorgente, lo compilano sul computer e lo installano). Pertanto, il gestore pacchetti sa dove risiedono i file appartenenti a determinati "programmi" (pacchetto) e quando si desidera rimuovere il pacchetto, il gestore pacchetti si occupa di ripulire tutto.
Anche quando compili il codice sorgente da solo

make

e installalo con

make install

di solito puoi farlo

make uninstall

che elimina i file dal file system.