Premessa: questo e` un thread (ispirato da qui.. Andrea, non ce l'ho fatta, alla fine ho ceduto :/ ) dove si evidenziano dei limiti del sistema, se vuoi farti venire un fegato cosi` e` il posto giusto
Ma se proprio devi flammare, fallo argomentando ; )
Ordunque, partiamo da qui. Che roba e`? E` la Filesystem Hierarchy Standard, un documento che descrive dei dettami per la struttura dell'albero delle directory in un sistema *nix, seguito abbastanza con rigore da Linux. Oggi la FHS e` arrivata alla release 2.3, che sommariamente descrive un albero di questo tipo:
Di tale albero, due directory si ramificano in:codice:/bin /boot /dev /etc /home /lib /media /mnt /opt /proc /root /sbin /srv /tmp /usr /var
ecodice:/usr/X11R6 /usr/bin /usr/include /usr/lib /usr/local /usr/local/share /usr/sbin /usr/share /usr/src
Lo scopo di ogni directory e` indicato dettagliatamente nel link.codice:/var/account /var/cache /var/cache/fonts /var/cache/man /var/crash /var/games /var/lib /var/lock /var/log /var/mail /var/opt /var/run /var/spool /var/tmp /var/yp
A che serve tutto cio`? Principalmente a far si` che un programma progettato per essere installato su un sistema *nix possa distribuirsi nel filesystem allo stesso modo su _tutte_ le versioni che rispettano tale struttura e si aspetti di trovare quanto gli serve sempre _negli stessi posti_.
Ma c'e` un problema: questa struttura e` paurosamente obsoleta.
Facciamo un po' di storia e torniamo indietro di quasi quarant'anni. E' il 1969 e ai laboratori Bell ci sono due tizi, tali Dennis Ritchie e Ken Thompson, che insieme ad altri simpatici smanettoni tirano fuori un sistema operativo della madonna progettato per l'allora fantascientifico PDP-7. I punti fermi della progettazione erano:
- sistema portabile (in grado di girare su piu` architetture)
- multitasking (in grado di eseguire piu` processi contemporaneamente)
- multiutente (in grado di eseguire processi di piu` utenti diversi contemporaneamente)
- sicuro (in grado di proteggere gli elementi di un utente da accessi indesiderati)
- stabile (in grado di proteggere se` stesso da eventi indesiderati)
- riparabile (in grado di essere recuperabile agevolmente da un crash)
- dotato di filesystem gerarchico
Riguardo all'ultimo punto, che significava? Col termine si indicano due cose:
- lo hierarchical filesystem introdotto da apple nell'85, che non e` di nostro interesse
- la struttura gerarchica degli elementi del filesystem cosi` come appaiono nel livello di astrazione immediatamente superiore al fs. In soldoni, la struttura ad albero delle directory.
In altre parole, indica che ogni elemento del filesystem tranne / deve essere raggiunto tramite l'elemento precedente. Niente di strano, e` una struttura che siamo abituati a vedere piu` o meno in ogni os. Oggi la diamo per scontata, ma tocca tener presente che esistono os dove questa struttura nemmeno esiste, o addirittura os dove nemmeno esiste un filesystem.
Nelle menti di R., T. & company nasce subito un problemino: come caspita la organizziamo 'sta struttura, fermi restando i punti precedenti? Intanto prendiamo spunto da multics, poi qualcosa ci inventiamo. Et voila`:
Beh, tutto qui? Eh gia`. Per una struttura cosi` come la conosciamo oggi ci vorra` ancora molto, molto tempo.codice:/bin /dev /etc /lib /tmp unix /usr
bin: binaries, i comandi di sistema.
dev: devices, i device file.
etc: et cetera (tutto il resto), la config di sistema, il database delle password utente, i comandi riservati all'amministratore e tutto cio` che non trovava gia` una giusta collocazione nelle altre directory. Era una bolgia infernale fatta directory.
lib: libraries, le librerie di sistema.
tmp: temporary, i file temporanei.
unix: il kernel! (una decina di K)
usr: le directory utente erano qui (indovinate perche` si chiamava usr?), incluse due directory source (piu` avanti src) e include per i sorgenti.
Perche` questa organizzazione? Per essere a prova di crash. Ogni cosa era montata su un filesystem separato, in modo che se si schiantava / si poteva comunque avere accesso a un sistema minimale da cui agire per il recovery. Non esisteva nemmeno il concetto di "avvio da floppy e monto / su un punto di mount creato al volo".
Da UnixV5 in poi inizia il caos.
Mano a mano che il sistema si ingrandisce e l'hardware si evolve nascono esigenze nuove: bisogna separare i comandi di sistema dai comandi riservati all'utente, ci vuole un posto per i file di log, uno per montare i filesystem temporanei, bisogna dar modo agli utenti di accedere alle proprie librerie ma non a quelle di sistema, ci vuole un posto per i file recuperati dopo un crash, i file dell'utente root devono stare totalmente separati dal resto, eccetera. Nascono nuove versioni di Unix, ognuna con la sua struttura. Questo era un Minix nell'84:
Questo uno Xenix nell'89:codice:/bin boot /dev /etc /minix /mnt /root /tmp /usr
Questa la prima pre-alpha di Debian nel '93:codice:/bin /dev /etc /tmp unix /usr
A meta` anni '90 si decide di mettere ordine nel caos. Nasce la FHS, una serie di linee guida per l'organizzazione delle directory, con cui si cerca di riorganizzare il tutto con due obiettivi principali:codice:/bin /boot /dev /etc /home /lib /lost+found /mnt /proc /root /sbin /tmp /usr /var vmlinuz
- retrocompatibilita`
- estensione
Il primo punto e` di immediata comprensione: ogni struttura deve essere pienamente retrocompatibile con quelle esistenti, in modo da poter sfruttare agevolmente i vecchi programmi sulle strutture attuali. Il secondo e` l'esatto opposto e riguarda le strutture future, che dovranno essere adeguate ai programmi esistenti. Una prima versione imponeva che _al minimo_ un sistema fhs compliant dovesse contenere:
/root e /home, ad esempio, erano opzionali. Col tempo sono proliferate una marea di distribuzioni, ed ognuna ha interpretato la fhs a modo suo, a volte aggiungendo e a volte togliendo elementi dalla fhs.codice:/bin /boot /dev /etc /lib /mnt /proc /sbin /tmp
Ecco come appare una debian oggi:
Qual e` il problema di una simile struttura? Che _non serve piu` a niente_. E` dispersiva, confusionaria e inutilmente complicata.codice:/bin /boot /dev /etc /home /initrd /lib /lost+found /media /mnt /opt /proc /root /sbin /srv /sys /tmp /usr /var
/root, /bin, /sbin e /lib non hanno piu` bisogno di essere nella root directory da almeno una ventina d'anni. Se lo scopo era la separazione su piu` filesystem in modo da risolvere agevolmente un disaster event tramite un sistema minimale, oggi dove sta la difficolta` nell'avviare un sistema da floppy o da cd? Utilita` attuale: zero.
Allo stesso modo la distinzione fra /bin, /sbin, /usr/bin e /usr/sbin non ha piu` alcun senso: per decidere chi puo` fare cosa esistono i permessi sui file.
Condividere le librerie per risparmiare spazio su disco? Con in commercio hd da 500Gb e con programmi che funzionano solo con una data versione della libreria e con quella successiva non si sa? Col versioning system si risolve anche il problema del ridondante caricamento in ram.
A che pro disperdere un programma nell'intera struttura solo perche` certi programmi si aspettano di trovare certi file sempre negli stessi posti? Ma qui ci viene in aiuto il sistema di packaging, tipico di ogni distribuzione Linux: peccato che non fosse mai stato previsto niente di simile, il sistema di packaging stesso e` semplicemente una toppa a una struttura che per la sua stessa esistenza comporta che sia necessario un aiuto dal sistema per sapere cosa viene installato dove.
C'e` chi a tutto questo sta provando a dire basta. Si tratta del mantainer di Gobolinux, una distribuzione che prevede una riorganizzazione totale e moderna dell'albero delle directory:
Depot
Files
Programs
System
Users
Semplice, ordinato, pulito. Se non fosse che per questioni di retrocompatibilita` coi programmi esistenti significherebbe un nuovo caos. A questo proposito Mac Os X ha tanto, ma veramente tanto da insegnare.
Questo e` quanto. Stiamo usando un sistema con una struttura obsoleta, siamo onesti e prendiamone atto. Oppure preparate qualche cassetta di pomodori mentre il sottoscritto va a farsi una birra
Rispondi quotando
.
