1. Struttura della directory
Questo dovrebbe essere trattato nel Filesystem Hierarchy Standard (2.3 PDF)
/bin/ Essential command binaries that need to be available in single user mode;
for all users, e.g., cat, ls, cp
/sbin/ Essential system binaries, e.g., init, ip, mount.
/usr/bin/ Non-essential command binaries (not needed in single user mode);
for all users
/usr/sbin/ Non-essential system binaries, e.g. daemons for various network-services.
/usr/local/ Tertiary hierarchy for local data, specific to this host.
Typically has further subdirectories, e.g., bin/, lib/, share/
2. Installazione
Uso un gestore di pacchetti ove possibile (ad esempio 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 sarebbero i pacchetti di livello inferiore come gli RPM e la compilazione dai sorgenti sarebbe la mia ultima risorsa (ma alcune persone lo preferiscono)
Alcuni gestori di pacchetti possono installare da RPM (ad esempio yum install oddity.rpm )
Se stai compilando dal sorgente, probabilmente non è un passo enorme creare il tuo pacchetto in modo che l'installatore di sistema sappia cosa hai fatto.
Quindi il tuo problema si riduce ad es. yum remove packagename
L'alternativa è tenere 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 utente normale.
Le diverse directory non hanno molto senso se hai una singola macchina unix su un singolo disco, ma hanno più senso se hai un grande sistema e diverse partizioni. Ricorda che molte di queste abitudini risalgono agli anni '80 e '90, quando i sistemi erano un po' diversi.
/sbin tende ad essere molto piccolo. Queste sono utilità di cui hai bisogno quando sei davvero ubriaco. Lo metteresti su una partizione root minima con /root e /lib. Le cose in /sbin erano tutte collegate staticamente, poiché se la tua partizione /usr è bloccata, tutte le app collegate dinamicamente sono inutili. fsck è qui e collegato staticamente. Se hai una dipendenza da /usr, ovviamente non puoi fsck /usr/. Ovviamente, se la partizione di root è stata cancellata, sei molto fottuto. Questo è il motivo per cui si tratta di una partizione così piccola:riduci le probabilità di un blocco del disco danneggiato utilizzando pochissimi blocchi qui.
/usr/sbin i binari sono strumenti generali di amministrazione di sistema in cui puoi almeno accedere alla modalità utente singolo e montare tutti i tuoi volumi. Possono essere collegati dinamicamente.
Anche le partizioni separate per /sbin (beh, /sbin su / partizione) e /usr hanno più senso se si ricorda che il backup era molto costoso sia in termini di tempo che di nastro. Se fossero su partizioni separate, potresti programmarle diversamente.
/usr/local può essere un filesystem di rete. Quindi gli strumenti di amministrazione di sistema scritti localmente che possono essere condivisi su molte macchine a volte vanno in /usr/local/sbin. Ovviamente nessuna utilità 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 root.
Dovresti davvero fare in modo che la tua seconda domanda sia 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 loro formato di pacchetto. HP/UX aveva il suo, e ci sono apt e molti altri formati di pacchetto. Mantieni le cose nei posti giusti (/usr/bin, /usr/lib) come appropriato, ma consenti facili aggiunte e rimozioni.
Per i sorgenti, c'erano strumenti che ti permettevano di configurare e installare in una sottocartella di /usr/local e gestiva i collegamenti simbolici a /usr/local/bin per te. A causa dell'ampia proliferazione di strumenti per i pacchetti, questo è meno necessario e ho dimenticato i loro nomi.
Ad alcune persone piace installare in /opt/nomepacchetto e tieni tutto insieme lì. Il buono:tutto è in una directory e una disinstallazione è rm -rf /opt/packagename . Gli svantaggi di questo sono l'aggiunta di /opt/packagename/bin al PERCORSO di tutti e il fatto che le persone di solito non mettono /opt su una partizione separata e tu riempi la partizione di root.