Newsgroup: it.comp.retrocomputing
Titolo: Origini del filesystem *NIX

Ho letto un'interessante (nonché divertente) articolo sulle origini dell'incatricchiato filesystem degli *NIX che ci stiamo trascinando dietro da oltre 30 anni:
 
http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split
 
 
Buona lettura.
 

 Buona lettura.
 
Mah... guadagnandomi il pane facendo l'amministratore di sistemi unix
dal 1995, non sono interamente d'accordo con questa visione.
C'e' da dire che con le attuali distribuzioni linux si e' persa un po'
la filosofia che c'era dietro ad alcune divisioni. Un esempio per
tutti:
 
sbin sta per static-binary, cioe' in /sbin e /usr/sbin in origine
risiedevano tutti quei binari compilati staticamente e cioe' che non
avevano bisogno ne' di un linker dinamico funzionante ne' ovviamente
di alcuna libreria aggiuntiva per funzionare. Questi binari spesso
aiutavano a salvare un sistema morto per upgrade sbagliati e/o
disastri quasi totali sui dischi. Adesso questa sana presenza di
binari statici si e' persa, quindi personalmente eliminerei del tutto /
sbin e /usr/sbin, modifica che sarebbe quasi indolore se qualcuno
volesse farla...
 
Poi e' vero che molte altre "particolarita'" dell'alberatura Unix e
Unix-like deriva dalla necessita' in tempi andati di usare piu' hard
disk fisici diversi per farci stare tutto e contemporaneamente
riuscire a recuperare un sistema che presentava problemi ad uno o piu'
dischi senza dover reinstallare tutto da tape.
 
F

 
http://www.osnews.com/story/25556/Understanding_the_bin_sbin_usr_bin_usr_sbin_Split
 
 
  Il solito imbecille che "per me le cose andrebbero fatte in questo
modo, chi non è d'accordo con me non capisce una mazza ed è un povero
scemo".  Chissà perché non si è preoccupato d'informarsi dei processi
decisionali dietro agli standard dei filesystem UNIX e Linux.  No, loro
fanno così solo perché, secondo lui, sono dei poveri burocrati che non
sanno fare le cose bene come lui.  Inutile nel migliore dei casi.
 
 
  Ciao,
 
 
-- 
Alessandro Selli 
http://alessandro.route-add.net
 
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.

 sbin sta per static-binary,
 
  Io sapevo stesse per "System binary", ossia pensati per essere usati
dal superutente, piuttosto che dagli utenti non privilegiati.


 sanno fare le cose bene come lui.  Inutile nel migliore dei casi.
 
concordo che e' un imbecille. se odia il fs *nix, che dovrebbe dire, ad. 
es. dell' AI(D)X ??
 
dal sito kossovaro sono disponibili le manualistiche AI(D)X per il 
pc/rt, e dopo averli letti, devo dire che non mi entutiasma....
 
e per la sua bordata su cp, ls, mv & le coreutils in generale, lo 
obbligherei a lavorare su un 7090 sotto JCL....
 
Saluti,
dott. Piergiorgio
(che ha avuto un pomeriggio estremamente sgradevole, quindi l' acidita' 
e' normale)
 


Fedora dalla prossima versione eliminerà /bin e /lib

 scemo".
 
Beh, ora arrivare a dire che è un imbecille, mi sembra eccessivo.
Vediamola dal suo punto di vista, in ambiente embedded il fs *nix 
meriterebbe di essere snellito.
Sono d'accordo che al giorno d'oggi questo avrebbe senso e, come dice 
Somebody, qualcuno sta già cominciando a farlo (ma sto divagando).
 
E' interessante capire le ragioni "storiche" di questo ammassarsi di 
directory ;-)

 directory ;-)
 
Veramente è tutto spiegato nell'articolo in questione e nei relativi link: 
che poi corrisponda a verità non lo so, ma è comunque una storia 
interessante :-)
Poi, che la struttura del file system possa piacere o meno è un altro 
discorso: personalmente sono abbastanza d'accordo con l'articolo e propendo 
più per il "non mi piace" che per il "mi piace", in quanto effettivamente lo 
reputo un po' incasinato, ma è un giudizio del tutto personale.
 
Ciao.
Roberto
 
 

 dal superutente, piuttosto che dagli utenti non privilegiati.
 
 
no, confermo, static binary. Dai tempi del pdp-11. Ho anche i dump
delle versioni 3, 4 e 5 (si trovano in rete insieme agli emulatori
PDP) e si evince facilmente che sono tutti statici in quelle
directory.
Inoltre nelle distribuzioni *BSD fino almeno a 5-6 anni fa erano
ancora tutti statici.
 
 F

 no, confermo, static binary. Dai tempi del pdp-11.
 
  Eh, questo quando non esistevano ancora i binary lincati
dinamicamente.  Ma da uin po' di tempo (qualche decennio) le cose sono
cambiate:
 
http://www.pathname.com/fhs/pub/fhs-2.3.html#SBINSYSTEMBINARIES
 
 
Filesystem Hierarchy Standard
Filesystem Hierarchy Standard Group
Edited by
Rusty Russell
Daniel Quinlan
Christopher Yeoh
 
Copyright Š 1994-2004 Daniel Quinlan
 
Copyright Š 2001-2004 Paul 'Rusty' Russell
 
Copyright Š 2003-2004 Christopher Yeoh
 
This standard consists of a set of requirements and guidelines for file
and directory placement under UNIX-like operating systems.
 
[...]
 
/sbin : System binaries
Purpose
 
Utilities used for system administration (and other root-only commands)
are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin contains
binaries essential for booting, restoring, recovering, and/or repairing
the system in addition to the binaries in /bin. [18] Programs executed
after /usr is known to be mounted (when there are no problems) are
generally placed into /usr/sbin. Locally-installed system administration
programs should be placed into /usr/local/sbin. [19]


 dinamicamente.
 
  Vabbé, no, non può essere.  Resta il atto che gli standard dei
filesystem UNIX dicono chiaramente che sbin vuol dire System binary.


 filesystem UNIX dicono chiaramente che sbin vuol dire System binary.
 
beh non so chi siano questi di FHS, mai sentiti sinceramente.
In ogni caso si parlava delle origini dei nomi delle directory e
l'origine di sbin e' quella.
Se vai a vedere una vecchia immagine anche di System V o qualche *BSD
non troppo recente ci troverai solo binari linkati staticamente, in
modo che in casi di emergenza (niente librerie magari perche' /lib o /
usr/lib stavano su un filesystem a parte che non si monta piu' oppure
perche' qualche upgrade ha sovrascritto una libreria a caso o un
sysadmin poco attento ha fatto un rm di troppo... ecc...) si potesse
operare per ripristinare il sistema.
Provate oggi a perdere /lib o solo la libc.so.
 
Poi standardizzare al giorno d'oggi potrebbe anche essere un bene, ma
non avrei mai creduto che qualcuno ritenesse questa una priorita' :-)
 
F

L'articolo originale
http://pdos.csail.mit.edu/6.828/2004/readings/ritchie74unix.pdf
 
non cita proprio /sbin
e neanche il libro "The Unix Programming Environment" (Kernighan/Pike, 
1984 Bell Labs-Prentice-Hall), dunque dev'esser un'introduzione 
sucessiva ...