| Precedente :: Successivo |
| Autore |
Messaggio |
{utente anonimo}
Ospite
|
 Inviato: 19 Ott 2005 22:59 Oggetto: Linux vs BSD/Solaris |
 |
|
| Salve, sto seguendo un corso professionale di x amministratore di rete e buona parte del corso è basata su linux. Ho una domanda: visto che linux viene sbandierato come unix like, aldilà della sua struttura incasinata uguale, quando si deve gestire una rete utilizza gli stessi comandi e file di configurazione di unix tanto che il passaggio risulta trasparente o no ? Studiando su linux, se avessi un giorno da configurare una solaris sarei in grado di farlo senza dovermi studiare tutto da capo ? |
|
| Top |
|
 |
dAb
Dio minore
Registrato: 21/06/05 23:15
Messaggi: 858
Residenza: montana e piovosa
|
| Inviato: 19 Ott 2005 23:28 Oggetto: |
|
|
No. I vari *nix sono relativamente simili fra loro, ma un passaggio trasparente e` impossibile. Ci sono differenze nel partizionamento, nel filesystem, nella struttura della hierarchy, nei comandi di shell, nell'organizzazione degli script e un sacco di altre cose.
Su SCO anche la semplice installazione di un nuovo hard disk e` una pena. Su BSD c'e` da diventare matti col partizionamento. IRIX in rete e` un incubo da amministrare. AIX ti porta via due giorni solo per essere installato. Solaris ha un supporto hardware disastroso. QNX lo conoscono in due.
Va detto che ad oggi Linux e` lo unix based piu` facilmente amministrabile, per quanto complicato possa apparire, e che puo` aiutare molto nel passaggio a uno unix.
In sintesi: un sistemista Linux non e` un sistemista unix. |
|
| Top |
|
|
{utente anonimo}
Ospite
|
| Inviato: 19 Ott 2005 23:40 Oggetto: E pensare... |
|
|
| ...che dovrebbero essere parenti stretti... |
|
| Top |
|
|
dAb
Dio minore
Registrato: 21/06/05 23:15
Messaggi: 858
Residenza: montana e piovosa
|
| Inviato: 19 Ott 2005 23:53 Oggetto: |
|
|
Diciamo.. cugini di secondo grado 
Comunque una buona conoscenza di Linux riduce parecchio la curva di apprendimento per i "parenti". |
|
| Top |
|
|
{Fofò}
Ospite
|
| Inviato: 20 Ott 2005 20:03 Oggetto: Struttura incasinata...???? |
|
|
| Ma che dici! La struttura di linux sembra incasinata solo a chi vuole restare in superficialità. E' molto più ordinata di quello che si pensa. Basta leggere il "Filesystem Hierarchy Standard" per rendersene conto! |
|
| Top |
|
|
{utente anonimo}
Ospite
|
| Inviato: 20 Ott 2005 21:17 Oggetto: E oltre a quello ? |
|
|
E oltre alle intenzioni di un documento cosa c'è di ordinato in linux ?
Comandi, nomi di file di sistema e cartelle in ostrogoto che assolutamente non aiutano ad essere comprese "ad occhio" (salvo non essersi letti prima qualche centinaio di pagine di guide, how to ecc.)
50 programmi diversi che configurano le stesse cose e poi vanno in conflitto allegramente. Stesso discorso nelle desktop dove, caso principe, kde esegue delle impostazioni puntualmente disattese da ogni programma. In teoria non esiste nulla di più ordinato di linux ma solo in teoria |
|
| Top |
|
|
dAb
Dio minore
Registrato: 21/06/05 23:15
Messaggi: 858
Residenza: montana e piovosa
|
| Inviato: 20 Ott 2005 23:04 Oggetto: Re: Struttura incasinata...???? |
|
|
| {Fofò} ha scritto: | | Ma che dici! La struttura di linux sembra incasinata solo a chi vuole restare in superficialità. E' molto più ordinata di quello che si pensa. Basta leggere il "Filesystem Hierarchy Standard" per rendersene conto! |
Hai toccato un tasto dolente. L'attuale FHS e` proprio uno dei grandi limiti di linux e degli *nix in genere: e` obsoleta, dispersiva, inutile ed eccessivamente complicata.
/root, /bin, /sbin e /lib non hanno piu` bisogno di essere nella root directory da almeno una ventina d'anni. Lo scopo originario della loro esistenza in / era quello di poter avviare un sistema ko avendo comunque a disposizione degli strumenti minimali presenti in /, montato per sicurezza in un volume a se` stante. Oggi non servono piu` a nulla in quella posizione: avvii da un cd, o alle brutte da un floppy, e sei in grado di ricostruire il sistema senza troppi problemi. Su qualunque sistema per qualunque architettura. I tempi in cui / era una decina di metri di nastro su bobina da 10,5 pollici sono trascorsi da un pezzo.
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. Imporli sulle directory di sistema per poi permettere comunque all'utente di lanciare i comandi in /sbin includendo il path completo e` una cosa priva di ogni logica. Ai tempi dei tempi l'unico motivo della distinzione era ridurre le dimensioni della variabile PATH per gli utenti normali. Si tenga presente che sto parlando di tempi in cui anche i singoli byte erano importanti.
Installazione dei programmi: a che pro disperdere un programma nell'intera struttura mettendone un po' in /usr/share, un po' in /etc, un po' in /usr/share/man eccetera solo perche` certi programmi si aspettano di trovare certi file sempre negli stessi posti? (/bin, /usr/bin eccetera)
E ancora: condividere le librerie comuni ad altri programmi per risparmiare spazio? Con in commercio hard disk da 200Gb? Quarantamila volte piu` grandi dei supporti su cui nacque unix?
Risultato degli ultimi due punti: i programmi si disperdono nell'intera struttura, e file appartenenti a diversi programmi si ritrovano nelle stesse directory. Da questa conseguenza, e qui arriva la parte divertente, arriva la pronta soluzione: il sistema di packaging. Bellissimo, comodissimo, funzionale. Peccato che: a) ne` l'utente ne` a volte l'amministratore di sistema abbiano la minima idea di dove vadano a finire i file dei programmi una volta installati; come possa un sysadmin molto sensibile alla sicurezza del sistema installare con tutta tranquillita` un programma che si disperde nell'intero filesystem resta un mistero. b) non c'e` soluzione pratica per i programmi installati da sorgente. Anche qui non si capisce con quale fiducia si dia un make install per programmi trovati chissa` dove. Ne` esiste un modo pratico per rimuovere un programma installato da sorgente. Certo, e` possibile a volte trovare la direttiva uninstall nel makefile. E se disgraziatamente quell'uninstall si porta via anche altri file che non appartengono al programma installato, o magari si porta via una versione di un file utilizzato da un altro programma che funzionava solo con quella versione come la mettiamo?
Non si puo` dare cieca fiducia ai sorgenti: occorre un modo per installarne il risultato in una singola posizione nel tree. Ma questa singola posizione nell'originale fhs non esiste. Ah, momento, c'e` la soluzione anche a questo! configure --enable-installdir. Si`, come no. Provate a farlo con XFree.
Ed ecco che arriva la soluzione da parte della hierarchy: /opt! Questa directory nacque parecchio tempo dopo l'originale fhs, cosi` come tutta la fhs e` stata rattoppata e revisionata nel corso degli anni. /opt dovrebbe permettere di installare gruppi di applicazioni separate dal resto. Momento: ma non si era detto che i programmi dovevano stare un po' qui e un po' la`? E allora /opt che ci sta a fare? Semplicemente, nulla: e` la tacita ammissione del fallimento nella concezione della struttura delle directory. E` una contraddizione in termini con la stessa filosofia della fhs.
Montaggio filesystem remoti: vediamo un po', cosa costruisco oggi? Un bell'application server! Dunque, lo monto remotamente su /usr, che bello, funziona. Ho bisogno di un altro application server! Lo monto su /opt.. ehi, me ne servirebbe un terzo.. e dove lo monto? Semplice: su una directory creata allo scopo in /. Cosa che, guarda un po', non rispetta gli standard della fhs. Ed e` proprio cosi` che funziona negli ambienti di produzione: la fhs non viene mai rispettata. E` impossibile. Per inciso, non e` nemmeno rispettata da diverse distro linux, che la interpretano ognuna a modo proprio.
Denominazione dei comandi: cose come ls, rm, cp e mv nel 21esimo secolo non hanno ragione di esistere. I comandi su *nix sono nati originariamente brevi per un unico motivo: risparmio memoria. Risparmiare un carattere significava risparmiare un preziosissimo byte. Nondimeno, era un carattere in meno da stampare. Utilita` attuale: zero.
Se un utente che si approccia a Linux trova la struttura complicata non e` per via di inesperienza e superficialita`: e` per via del fatto che la filesystem hierarchy E` complicata. Inutilmente complicata, ad essere precisi.
Questa dovrebbe essere una struttura semplice e ordinata? Una struttura con una dozzina di directory di sistema in /? Una struttura concepita quasi quarant'anni fa, per sistemi di quasi quarant'anni fa, e usata su sistemi del XXI secolo?
Il documento che descrive la FHS e` pura teoria: una volta messo in pratica crea strutture obsolete e impossibili da mantenere fedeli nel tempo alla teoria descritta. Non e` certo questa la struttura del futuro.
Il futuro nella struttura dell'albero delle directory riguarda cose come le gerarchie circolari dove un file e` raggiungibile da qualunque punto dell'albero. Il futuro non e` sicuramente l'FHS, che sarebbe da rimuovere totalmente dalla famiglia *nix, se non fosse che per questioni di retrocompatibilita` si tratterebbe di un'impresa titanica. |
|
| Top |
|
|
{Fofò}
Ospite
|
| Inviato: 21 Ott 2005 17:02 Oggetto: Quanto meno opinabile... |
|
|
| Quello che tu dici, caro dAb è opinabile in molti punti. Traspare che non hai seguito gli ultimi sviluppi. Concordo che a volte è farraginoso e che il tutto è migliorabile, ma io non riesco più ad allontanarmi da quella pratica costruzione. Che, per me (e per migliaia di sviluppatori), non è per nulla inutilmente complicata. |
|
| Top |
|
|
dAb
Dio minore
Registrato: 21/06/05 23:15
Messaggi: 858
Residenza: montana e piovosa
|
| Inviato: 21 Ott 2005 18:19 Oggetto: |
|
|
Saro` ben lieto di vedere discussi i punti a cui ti riferisci. Questo spazio e` messo a disposizione per i commenti, sfruttiamolo 
Non nego che in quasi vent'anni di *nix possa essermi sfuggito qualcosa, infatti ignoro totalmente a quali ultimi sviluppi tu ti riferisca.
All'introduzione di /opt, giugno '98? All'introduzione di /media e /srv due anni e mezzo fa? O altro? Attendo lumi.
Purtroppo il fatto che per te e che per migliaia di sviluppatori non sia complicata e` proprio la causa dei guai di questa struttura: il problema non sussiste perche` lo si ignora (non nel senso di ignoranza ma nel senso che non gli si da` peso). |
|
| Top |
|
|
{utente anonimo}
Ospite
|
| Inviato: 22 Ott 2005 14:46 Oggetto: Ammazza.. |
|
|
| Non immaginavo ci fosse tanto casino dentro il fs dei *nixma allora il futuro qual'è ? Una riorganizzazione stile BeOS che solo per motivi di port tiene ancora un layerino piccolo piccolo di compatibilità con posix ? |
|
| Top |
|
|
dAb
Dio minore
Registrato: 21/06/05 23:15
Messaggi: 858
Residenza: montana e piovosa
|
| Inviato: 22 Ott 2005 15:56 Oggetto: |
|
|
BeOS e` stato un grosso passo avanti in questo senso, ma uno dei suoi problemi e` stato proprio la retrocompatibilita` che citi: riscrivere da zero una gerarchia significa creare un sistema chiuso, a meno di arzigogolate acrobazie come l'approccio studiato da quel geniaccio incompreso di Hisham per GoboLinux.
Il futuro, per ora su carta e in linea del tutto teorica, e` il filesystem circolare ad oggetti: un ulteriore livello di astrazione per i filesystem odierni dove il concetto di file e directory e` trasparente all'utente. In un sistema del genere ogni cosa e` un oggetto (un po' come sugli *nix ogni cosa e` un file): programmi, documenti, dispositivi hardware, tutti raggiungibili e gestibili attraverso un singolo percorso da qualunque punto ci si trovi nel sistema. Non un'organizzazione ad albero, compito del layer sottostante, ma un'organizzazione sferica, un po' come se ogni ramo dell'albero fosse collegato rigidamente ad ogni altro ramo. Pura accademia per ora, e negli ambienti accademici se ne sta parlando molto ma molto poco. Dubito che vedremo implementato nulla di simile entro i prossimi vent'anni. |
|
| Top |
|
|
{utente anonimo}
Ospite
|
| Inviato: 22 Ott 2005 23:14 Oggetto: Però nel frattempo... |
|
|
...si potrebbe creare una versione di linux che si preoccupi di nominare in maniera più chiara il file system e gli dia una bella ordinata:
/
/root (file e app dell'admin)
/home/xxxxx (file e app dell'utente singolo compresa di cestino a se)
/home/all (file e app disponibili a tutti gli utenti)
/linux (cartella del sistema)
Così già non mi spiacerebbe e per ragioni di compatibilità si infila nel sistema un qualcosa che traduce in tempo reale le chiamate dei programmi dall'*nix classico al nuovo linux organizzato.
Impossibile come cosa ? Secondo me no ma non sono programmatore quindi non posso avere certezze |
|
| Top |
|
|
dAb
Dio minore
Registrato: 21/06/05 23:15
Messaggi: 858
Residenza: montana e piovosa
|
| Inviato: 22 Ott 2005 23:33 Oggetto: |
|
|
Possibilissimo, GoboLinux funziona quasi cosi`
Usa un sistema molto complicato di link simbolici per nascondere all'utente la reale fhs sottostante. In / contiene:
Depot
Files
Programs
System
Users
Se ne era parlato qui: http://forum.zeusnews.com/viewtopic.php?t=11884 |
|
| Top |
|
|
{utente anonimo}
Ospite
|
| Inviato: 23 Ott 2005 14:09 Oggetto: Però tutti sti link simbolici alla fine... |
|
|
...non è detto che portino vantaggi...
bah forse forse l'unica cosa che serve è avere il coraggio di dare un taglio con il passato e modernizzarsi del resto se il sistema in se è valido perchè dovrebbe perdere utenti se volesse migliorarsi ? |
|
| Top |
|
|
dAb
Dio minore
Registrato: 21/06/05 23:15
Messaggi: 858
Residenza: montana e piovosa
|
| Inviato: 23 Ott 2005 16:47 Oggetto: |
|
|
Infatti le prestazioni sono leggermente ridotte rispetto a un Linux "puro", lo stesso Hisham sostiene di aver implementato il tutto puramente per sensibilizzare la comunita` di sviluppatori. Finora non e` stato molto ascoltato 
Il taglio col passato non e` facile da dare, sempre per questioni di compatibilita` col software esistente. Il problema non e` tanto la costruzione del sistema in se`, ma gli applicativi: non si puo` pretendere di riscriverli tutti da zero, ne` sarebbe molto semplice per l'ipotetico nuovo sistema offrire un livello di retrocompatibilita` col software attuale. |
|
| Top |
|
|
{utente anonimo}
Ospite
|
| Inviato: 23 Ott 2005 22:23 Oggetto: Sostituire qualche percorso di file |
|
|
| Non è riscrivere da zero un programma |
|
| Top |
|
|
dAb
Dio minore
Registrato: 21/06/05 23:15
Messaggi: 858
Residenza: montana e piovosa
|
| Inviato: 23 Ott 2005 23:18 Oggetto: |
|
|
Vero, da zero no, ho mirato troppo in alto
Per cominciare sarebbe necessario riscrivere i Makefile, i configure script e togliere dai sorgenti tutti i riferimenti rigidi alle varie usr, lib e compagnia (solo per le gcc, che sono poco meno di 50 mega di sorgenti, ce ne sono circa un migliaio). Al pensiero di farlo per XOrg (e quindi unicamente per la parte server di X, tralasciando il lato client) mi verrebbe da piangere.
Ok, non da zero. Facciamo da 50/100? |
|
| Top |
|
|
{utente anonimo}
Ospite
|
| Inviato: 24 Ott 2005 09:05 Oggetto: Capito... |
 |
|
| ...bisogna rimboccarsi le maniche e/o sperare in qualche volenteroso progetto come mockup |
|
| Top |
|
|
|
FAQ
Cerca
Lista utenti
Gruppi
Registrati
Profilo
Messaggi privati
Log in
