Fermate la stampa Fermate la stampa Fermate la stampa......Novembre 1998

Qusto documento ha avuto origine quando la FUD contro Linux era al suo massimo. Che ora i giornalisti siano meglio informati, o più attenti a controllare nei fatti ciò che dicono, o cos'altro, sta di fatto che tale FUD è stata decisamente in calo negli ultimi due mesi. Durante questo stesso periodo è apparso un interessante documento, gli ormai famosi Documenti di Halloween, e questo disegna un'interessante scenario. Chi volesse saperne di più sul successore della FUD, oltre a leggere i Documenti di Halloween, può dare un'occhiata a:

SS Tactics

Un grande sforzo è stato fatto per rendere questo documento il più accurato possibile. Le mie scuse per qualsiasi errore rimasto.
Commenti, correzioni, suggerimenti:
 irwin@mail.com
 

Per informazioni più generali su Linux:
 www.linux.org
 www.linuxresources.com
 

The LINUX FUD factor FAQ

Mettiamo un freno alle malelingue
 
Linux gode di una popolarità crescente, di conseguenza trova posto sempre più frequentemente nelle chiacchiere quotidiane e all'interno dei mezzi di comunicazione. Sfortunatamente, la maggior parte di queste chiacchiere è male informata. Questo documento presenta alcuni dei più citati 'miti' riguardanti Linux e il software open-source in generale.
Mitologia:
           
  • I vari UNIX si stanno frammentando in una pletora di versioni incompatibili. Si stavano frammentando, circa 15 o 20 anni fa, mentre durante gli ultimi dieci c'è stata una convergenza. Un sistema 'tipo-UN*X' vale l'altro. Ci sono meno differenze tra i differenti UN*X che tra, poinamo, Windows 3.1 -> Windows 95 -> Windows NT, in più i sistemi UN*X aderiscono in larga parte agli standard ANSI e POSIX, che permettono al software di essere compatibile a livello sorgente con svariate piattaforme, dai microcontrollori embedded ai super computer. La Open Software Foundation (OSF), di cui sono membri i produttori di tutti i maggiori sistemi operativi, ha portato la standardizzazione ancora oltre, con lo standard X/Open. Questo permette la completa compatibilità del codice sorgente E un ambiente desktop comune tra tutte le piattaforme. Lo standard X/Open fu creato da un conglomerato di standard esistenti ed è oggi ben solido e funzionale (vedi più sotto per altri aspetti della questione Linux X/Open). X/Open non esclude l'utilizzo di standard alternativi su un particolare sistema, ma permette agli sviluppatori di scrivere un singolo codice sorgente che potrà esere compilato ed eseguito su tutte le piattaforme conformi, e allo stesso tempo offre l'uso di un window manager standard, cosicché gli utenti ritrovano la stessa interfaccia indipendentemente dal sistema che stanno utilizzando. Una vera compatibilità binaria può essere offerta solo su piattaforme hardware compatibili, e perfino in questo campo si stanno facendo progressi. Sulla piattaforma x86, per esempio, Linux può eseguire binari SCO, così come su FreeBSD girano binari Linux, e c'è un ampio gruppo che comprende molti implementatori di unix su PC che sta cercando di ottenere compatibilità binaria completa tra tutte le loro piattaforme. Atre conversioni [port nell'originale, NdT] di Linux stanno lavorando su aspetti che riguardano il formato binario, ad esempio la versione di Linux per SUN eseguirà la maggior parte dei binari SunOS e la versione per DEC ALPHA supporta i binari Digital Unix.
 
  • Linux si sta frammentando.E' difficile rispondere a questa affermazione in quanto non c'è alcuna evidenza che ciò stia accadendo. Possiamo solo notare che, sebbene i distributori di versioni commerciali di Linux differenzino i propri prodotti, questi ultimi sono compatibili tra di loro e le diverse aziende collaborano 'amichevolmente' in modi non comuni nel mondo del software. Adottano tutte uno stesso Standard per la Gerarchia del Filesystem [Filesystem Hierarchy Standard nell'originale, NdT] (che determina la configurazione del sistema), ed utilizzano kernel e sorgenti delle stesse serie. L'errata convinzione che un pacchetto debba essere distribuito in una differente versione per ciascuna distribuzione è pura FUD.
 
  • Linux non è conforme allo standard X/Open. La risposta, in breve, è che Linux è conforme, ma non è autorizzato a dirlo! Chiariamo questo punto. X/Open essenzialmente richiede un sistema POSIX con le librerie GUI OSF Motif ed il window manager del CDE (Common Desktop Environment - [ambiente desktop comune, NdT]) (vedi sopra, 'UNIX si sta frammentando', per ulteriori informazioni su X/Open). Le librerie Motif e il CDE non sono open-source quindi non possono essere incluse in una distribuzione libera, ma sono comunque disponibili. Molti ditributori commerciali di Linux e terze parti vendono pacchetti Motif/CDE per Linux con una licenza OSF (questi pacchetti non sono port ma eseguibili, compilati dal codice OSF originale). Non c'è alcuna certificazione (non ancora), ma molte persone non sono disturbate da ciò, in quanto è semplice verificare che Linux con un pacchetto Motif/CDE compila suite di test OSF complete, e ne ha lo stesso look-and-feel [veste grafica ed ergonomia, NdT]. Molti sviluppatori per piattaforme X/Open utilizzano Linux come piattaforma di sviluppo. Il problema è burocratico, in quanto la struttura dell'OSF e il suo programma di certificazione non era stato concepito per sistemi open-source. Questo non vuol dire che la OSF sia ostile a Linux, essi hanno convertito Linux per il loro microkernel (e ciò viene sfruttato per far girare Linux sulle piattaforme Power Mac e HP). Una recente conferenza ha dimostrato il desiderio unanime, da parte dei membri dell'X/Open, di trovare un modo per portare il marchio X/Open (quindi UNIX) verso il sistema operativo Linux, e si è giunti alla conclusione che una soluzione dovrebbe essere possibile. Forse è importante chiarire un altro punto, in quanto possiamo aver dato l'impressione che Linux non può far girare software sviluppato per X/Open a meno di acquistare una licenza X/Open. In realtà, programmi motif possono essere distribuiti in una forma collegata staticamente [alle librerie Motif, NdT] senza alcuna necessità di una licenza, e molte comuni applicazioni Linux (come Netscape e Acrobat) sono liberamente distribuite per Linux in questo modo. Le aziende che vendono grandi pacchetti motif generalmente assumono che colui che paga molte migliaia di dollari per il loro software non si tirerà indietro all'idea di una quota di 100 dollari per una licenza OSF.
 
  • Linux non ha direzione. Spesso chi dice questo non specifica se intende 'direttore' o 'obiettivi a lungo termine'. Confutiamo entrambe le interpretazioni. Linus Torvalds, il 'Presidente' onorario del movimento Linux, ha enunciato chiaramente l'obiettivo a lungo termine di Linux, la dominazione del mondo. Sì, un uomo che vuole dominare il mondo per mezzo del suo software. Quindi Linux non è diverso dagli altri principali Sistemi Operativi. E questo è tutto.
 
  • Linux è composto da tanti piccoli gruppi che procedono in direzioni differenti. Linux è composto da tanti piccoli gruppi che procedono nella stessa direzione. Questo è assicurato da diversi di meccanismi. Il più importante è forse internet. Le persone che lavorano su Linux discutono costantemente tra loro per mezzo di newsletter e siti web, cosicché ognuno sa cosa spetta ad ogni altro. Chi vuole iniziare un nuovo progetto può cercare nei siti Linux principali se qualcuno sta già facendo qualcosa ad esso collegato, e può inviare le proprie idee alle relative newsletter per ottenere risposte e scambiare idee con chi sviluppa i meccanismi con i quali il suo progetto dovrà interfacciarsi. Questo approccio informale funziona bene nella maggior parte dei casi. Per risolvere i conflitti esistodo due meccanismi formali. Tutte le modifiche al kernel di Linux passano attraverso il 'presidente' del kernel, Linus Torvalds, quindi egli ha l'ultima parola su cosa deve o non deve essere incluso. Linus detiene anche il trademark del nome Linux, quindi se qualcosa non viene approvato da lui, quella cosa non è Linux. Uso il termine 'presidente' perchè Linux non è un prodotto interamente di proprietà di Linus. Il copyright di ciascun pezzo di software rimane agli autori, ma essi debbono rilasciare i programmi sotto una licenza che ne permetta la libera copia e il libero aggiornamento affinché diventi una parte standard del kernel (questo non vale, naturalmente, per le applicazioni). Nessuno può essere 'proprietario' di Linux, e nel caso Linus non dovesse essere più disponibile, c'è un ampio numero di sviluppatori coinvolti nello sviluppo del kernel in modo abbastanza approfondito da ricoprire la carica presidenziale. Un altro meccanismo è 'Linux-international', un gruppo senza fini di lucro composto da organizzazioni che si occupano di Linux, supportato dai suoi membri commerciali. I membri di Linux international includono distributori commerciali di Linux come Red-Hat e SuSE, aziende di software applicativi come Sunsoft e Netscape, e aziende di hardware, sia a livello di sistema, come Digital, sia produttori di periferiche, come Adaptec. Analogamente agli altri gruppi industriali, Linux international deve la sua autorità al fatto che le organizzazioni membro si attengono alle conclusioni prese in seno ad esso per quanto riguarda le questioni legate a Linux. Linux international è controllato da un'assembleda votata dai membri.
 
  • Linux non è leader nella tecnologia, sta solo giocando a 'rimpiattino'. Questo è un po' come dire che la NASA è solo l'ennesima azienda aerospaziale. Certamente la comunità Linux non fa annunci pomposi riguardo quello che farà, né pianifica il proprio lavoro così avanti nel futuro che quando la data finalmente arriva nessuno ricorda più cosa era stato promesso. Linux è fatto da persone che fanno ciò che vogliono fare. La sua apertura lo rende un ottimo 'laboratorio' per testare nuove idee, e l'orgoglio degli hacker del kernel di Linux rende l'introduzione di nuove tecniche una sfida personale. Linux girava a 64 bit sul DEC ALPHA fin dal primo giorno. Gira anche sulle piattaforme a 64 bit della Sun. Supporta il SMP e può essere usato in cluser. Si può connettere una stanza di economici dual-pentium pro per realizzare un supercomputer a basso costo. Il rendering del film Titanic fu eseguito da 100 computer DEC-Alpha su cui ha funzionato Linux a 64 bit 24 ore al giorno per diversi mesi. Quando la gente ha cominciato ad utilizzare Linux sui portatili, PCMCIA e il risparmio energetico hanno presto trovato posto nei kernel stabili. In generale, le nuove soluzioni techiche e le nuove tecnologie trovano posto nelle versioni di sviluppo del kernel molto rapidamente, spesso prima che siano disponibili per altri sistemi operativi. Nuove tecnologie desiderate fortemente dagli utenti sono spesso rese disponibili come 'aggiornamenti non ufficiali del kernel', in modo che gli utenti stessi possano provare nuovi 'giocattoli' con kernel che, per il resto, sono stabili. Se la domanda è forte, il nuovo 'giocattolo' verrà utilizzato molto e in poco tempo verrà sottposto ad un debugging sufficiente per farlo diventare un elemento standard delle versioni stabili del kernel. Se, come a volte succede, la nuova idea non piace, semplicemente scompare nelle viscere dei tar-ball e può non apparire mai più come caratteristica dei kernel stabili. Ci sono molti elementi, come il supporto all'USB, che sono stati sviluppati per un po' di tempo, e stanno solo aspettando che una domanda sufficientemente ampia li riporti alla ribalta.
 
  • Il kernel sarà avanzato, ma le applicazioni sono vecchi port di seconda mano. Molte aziende possono solo sperare che questo sia vero. Certamente gli utenti linux fanno ampio uso di vecchie e fidate applicazini unix che sono state portate su linux, esse sono molto ben conosciute ed estremamente affidabili. Ma l'eccellenza di Linux come piattaforma per lo sviluppo di software ne ha fatto la scelta primaria da parte di sviluppatori che coltivavano nuove idee, e un'occhiata all'interno degli archivi Linux mostrerà interi regni di idee innovative. Molte di esse non sono ancora sviluppate a sufficienza per un utilizzo pratico, e naturalmente molte 'innovazioni' non danno frutti. Ma è molto più probabile che il prossimo 'multiplan' salti fuori da una piattaforma Linux che da qualsiasi altri sistema operativo. Una caratteristica importante di Linux è la sua modularità, che rende più facile sperimentare lo sviluppo di applicazioni. Per esempio, nel momento in cui scrivo Microsoft ha in beta test il suo Windows 98. Per provarlo devi caricare per intero il nuovo sistema operativo ed usarlo così com'è, o riavviare la macchina ed utilizzare il vecchio Windows 95, senza miglioramenti. Per contrasto, anche una GUI sperimentale, il desktop 'K' [ovvero KDE, NdT], che ha anche un desktop basato sull'HTML simile a quello di Windows 98, è in beta test, ma puoi provarla mentre usi la tua solita distribuzione Linux. Puoi lanciare singole applicazioni K con la tua vecchia GUI (per esempio usare il file manager K sotto il 'classico' window manager fvwm2), e puoi addirittura lanciare una sessione del desktop K su un diverso schermo virtuale, sicché puoi saltare tra le due con la semplice pressione di un tasto. Eseguendo software sperimentale come utente normale, il tuo sistema è protetto da possibili danni.
 
  • Solo NT può essere un server di dominio. C'è del vero in questa affermazione. In un dominio NT, il server primario deve essere un NT, o almeno qualcosa con codice per i domini autorizzato da MS (Questo era vero al tempo in cui questo documento fu scritto, ma le cose stanno cambiando, come vedremo più avanti). Server secondari possono essere non NT, ma le cose di fanno complicate senza codice autorizzato MS. Questo, comunque, non è un problema tecnico. Si possono fare le cose che fa un dominio NT senza utilizzare i domini NT, ma se si segue la strada di NT, risulta poi molto difficile tornare indietro, o integrare con essa altre soluzioni. Inoltre, W9x (che è ciò che molti server debbono servire) è fortemente orientato ai domini NT. La ragione per cui il codice deve essere autorizzato da MS è che MS stessa ha fatto grandi sforzi per rendere i domini NT un complesso e labirintico scambio di messaggi che non aderisce ad alcuno standard, e i cui dettagli sono un segreto custodito gelosamente. I meccanismi sono tali da poter essere resi ancor più complessi con i service pack, in modo tale che se ad un certo punto terze parti dovessero risolvere il labirinto, è sufficiente rilasciare un service pack di aggiornamento per spostare un po' più avanti tale traguardo. Il fine è ovvio: nell'espandersi, le aziende compreranno per sempre nuove licenze NT. Se un'azienda vuole aggiungere un nuovo gruppo di lavoro dipartimentale, PUO' valutare diverse soluzioni che potrebbero costare meno e/o essere tecnicamente superiori, ma i problemi di integrazione con il dominio 'segreto' rendono NT la più sempclie opzione 'plug-and-play'. E' buffo come molte aziende che hanno felicemente detto addio alle soluzioni proprietarie degli anni '70 e '80 stiano ora ripercorrendo la stessa strada nel campo del software, e come stiano sprecando più soldi per essere intrappolate in software proprietari di quanti ne avrebbero persi comprando hardware completamente non-standard. Qualcuno ha paragonato i domini NT ad un 'virus', ma forse sono più simili alla dipendenza da cocaina: all'inizio tutto sembra meraviglioso, ma a lungo andare...

    Da quando ho steso la versione orignale di questo documento, il gruppo SAMBA (che produce codice libero compatibile SMB per sistemi UNIX) ha sciolto l'intreccio di un primary domain controller NT, e ha cominciato a offrire supporto per questo nel proprio codice. Molti amministratori di rete sono felicissimi per questo 'sblocco' dei domini NT, ma molti altri sono rimasti indifferenti, in quanto non hanno nessuna intenzione di implementare tali metodi indipendentemente da chi li fornisce, in quanto il protocollo è ancora proprietario ed eccessivamente complesso. Molti amministratori guardano a soluzioni aperte, in particolare Kerberos, e mettono in evidenza che NT5 usa Kerberos per l'autenticazione di dominio. Sembra sempre più probabile che l'utilizzo di protocolli proprietari nei domain controller sia destinato a scomparire.

 
  • Linux è non è sicuro. Questa è la frase preferita da quelli che usano FUD per denigrare Linux, in quanto non può essere confutata direttamente (dato che gli amministratori di sistema sono riulttanti ad ammettere gli accessi non autorizzati ai propri sistemi, non è possibile compilare statisatiche in base alle quali confrontare obiettivamente diversi sistemi operativi). Linux è, per essere precisi, un kernel, e il kernel di un sistema operativo è intrinsecamente sicuro in quanto non ha mezzi propri per comunicare con il mondo esterno. Le intrusioni avvengono tramite programmi di supporto che offrono specifici servizi di rete, ed è in questi programmi che normalmente si verificano buchi per la sicurezza. Questo potrebbe sembrare un ragionamento pedante, ma è comunque importante in quanto praticamente tutto il codice di rete (ftp, server web, email, ecc.) utilizzato su Linux non è specifico di Linux, ma è software disponibile per qualsiasi piattaforma UNIX, e in questo senso la sicurezza di Linux può essere considerata non diversa dalla sicurezza di UNIX in generale. Su questo punto bisogna però fare una precisazione: Linux è disponibile in molte distribuzioni; alcune sono indirizzate ad utenti domestici e hacker, che mettono facilità d'uso e flessibilità davanti alla sicurezza, e come tali possono essere prive di shadow password e possono attivare, di default, dei protocolli esoterici notoriamente rischiosi. Ma, dice il saggio, non annulli la tua vacanza in Florida a causa degli uragani in Giappone. Le principali distribuzioni Linux sono più attente, e offrono di default un livello standard di sicurezza. Al contrario, alcune distribuzioni sono progettate specificamente per essere robuste, come nel caso del progetto Linux Router, specializzato nella realizzazione di sistemi dedicati per il routing/firewalling, o il RedHat Secure Server, progettato per l'e-commerce con trattamento criptato delle carte di credito. Come sempre, il buon senso è un prerequisito fondamentale nella configurazione di un sistema sicuro, ma debolezze fondamentali all'interno di Linux non sono conosciute.

    Alcuni sostengono che UNIX in sé è vulnerabile, ma alla base di questa affermazione sta l'alto numero di avvisi riguardanti la sicurezza rilasciati per il software UNIX che fornisce servizi di rete. Al tempo stesso va però ricordato che il 70% del traffico internet è destinato a server di tipo UNIX, mentre il resto è distribuito su una varietà di sistemi proprietari. UNIX è anche il sistema predominante sui server universitari (dove sedicenti attackers tecnicamente dotati non sono certo una rarità). Molti altri sistemi stanno dietro firewall o si trovano in reti chiuse, o semplicemente sono così insignificanti che non vale nemmeno la pena tentare un attacco. E' impossibile comparare i sistemi UNIX con altri sistemi in termini di vulnerabilità perché nessun altro sistema ne raggiunge lontanamente il livello di esposizione o il numero di servizi offerti.

    Procedure come la certificazione C2 costituiscono un aiuto nella configurazione di un sistema sicuro, ma non significano che esso lo sia realmente, né la mancanza di un tale certificato (e Linux ne é privo) rendono un sistema insicuro. Un certificato C2 viene emesso quando un'azienda sottopone a test un sistema, e dichiara NON "questo sistema è sicuro" ma "per raggiungere il livello di sicurezza C2 con questo sistema, è stata utilizzata questa configurazione" (questa non è la dicitura esatta del certificato, ma una interpretazione degli autori). Il fatto è che non si può dichiarare che un sistema operativo è sicuro in generale, perché la sicurezza dipende fortemente da quali protocolli vengono offerti e dalla configurazione del sistema. In base allo stesso ragionamento, non si può dire che un particolare sistema operativo è insicuro.

    Il tema della sicurezza è considerato molto seriamente dalla comunità Linux. Deve esserlo: molti sistemi Linux sono in prima linea e non durerebbero un secondo se i problemi non fossero affrontati adeguatamente. Quando vengono rilasciati avvisi riguardanti la sicurezza, le correzioni arrivano molto rapidamente (se non nello stesso momento). I distributori di Linux, i consulenti, e i grandi siti in cui Linux viene sviluppato hanno persone dedicate alla sicurezza, e come sempre nel mondo Linux, queste persone collaborano. Allo stesso tempo il motto base di Linux è flessibilità e possibilità di scelta per l'utente. Si può costruire (o comprare) un sistema sicuro con Linux. Ma dal momento che la sicurezza è inversamente proporzionale alla flessibilità e facilità d'uso, si può decidere di abbassarne il livello ed avere un sacco di 'gadget' di rete. In una rete chiusa, o dietro un firewall, in cui gli utenti sono conosciuti (in effetti questo è il caso di molti server), c'è molto da dire in favore dell'utilizzo di protocolli meno sicuri. La scelta è nelle mani degli utenti, sicuro o flessibile, e tra tutti i sistemi Linux offre quello che è probabilmente il più ampio spettro di scelte possibile.

 
  • Linux non è Y2K-compliant. L'unità base del tempo in Linux (e nella maggior parte dei sistemi UNIX) è time_t. Questo formato esprime il tempo come il numero di secondi trascorsi dalla mezzanotte del primo gennaio 1970. Non ha perciò alcuna cognizione dell'anno 2000, che passerà come qualsiasi altra unità di tempo. time_t è alla base del conteggio del tempo nel kernel, della data e ora dei file, degli uptime [tempo trascorso dal boot della macchina, NdT], downtime [tempo di indisponibilità del server, NdT], ecc., quindi, finché è in gioco il kernel, non c'è nessun problema. Naturalmente nulla impedisce ad un'applicazione di interpretare male i dati, ma questo vale per qualsiasi sistema operativo. Detto questo, le librerie, sia dinamiche che statiche, fornite di serie con Linux (dunque utilizzate per compilare praticamente ogni applicazione Linux) sono compatibili con l'anno 2000, così come lo sono le librerie alternative che vengono utilizzate, ad esempio, per il SMP [supporto alle macchine multiprocessore, NdT]. Dato che Linux si è evoluto recentemente, in un periodo di attenzione generale al problema 'anno 2000', è difficile che anche le perfino le applicazioni minori non siano compatibili con l'anno 2000. Il problema della compatibilità con l'anno 2000 esiste per Linux così come per ogni altro sistema operativo in questo periodo, e nessuno può garantire che non vi sia alcuna applicazione 'difettosa' disponibile per il proprio sistema operativo, ma naturalmente se si è basato il proprio sistema mission-critical su oscuri programmi di utilità non compatibili con l'anno 2000, se disponiamo dei sorgenti possiamo al limite essere noi stessi a garantirci che il problema verrà risolto! E' appena il caso di notare che in generale il problema dell'anno 2000 interessa maggiormente le applicazioni elettroniche che i computer in sè. Molti 'orologi real-time' utilizzati in dispositivi embedded hanno l'anno memorizzato con 2 cifre, e il firmware usa questo valore direttamente, senza prendere in considerazione possibili problemi. Unix utilizza time_t perché essa è parte di un insieme di funzioni standard per la gestione del tempo in C (C e UNIX sono nati e cresciuti insieme), ma l'utilizzo del C si estende ben al di là di UNIX. Il C è usato per scrivere la maggior parte delle applicazioni su tutte le piattaforme. E' il linguaggio più probabilmente utilizzato per le librerie dei linguaggi interpretati, è dappertutto. Naturalmente non c'è alcun obbligo per i programmatori di utilizzare le funzioni basate su time_t, ma in generale esse vengono usate. Quindi il vero 'appuntamento col destino' del mondo del software non è l'anno 2000, ma il momento in cui time_t si 'esaurirà' [rollover nell'originale, cioè tornerà a zero, NdT]. Se, come è convenzione, time_t è un valore con segno di 32 bit, questo avverrà nel 2038. Naturalmente, se i programmatori si sono attenuti alle regole sarà necessaria una semplice ridefinizione di time_t a livello di sistema e una ricompilazione del codice per rimettere le cose a posto. Inoltre, data la corsa attuale verso l'obiettivo dei 64 bit, è abbastanza probabile che time_t venga definito comunque come una quantità a 64 bit nei nuovi sistemi (come è già successo nelle versioni di Linux per i DEC Alpha). Un time_t di 64 bit si 'esaurirà' in qualche istante verso la fine dell'universo..
 

Siti riguardanti argomenti correlati:

 Linux Myth Dispeller (Traduzione)
 
  The Cathedral and the Bazaar
 
  What is FUD ? (Traduzione)

Copyright Roger Irwin 1998. Questo documento può essere liberamente copiato e ri-distribuito, purché il contenuto non venga modificato.
Traduzione a cura di Marcello Romani. Commenti, suggerimenti, contributi alla traduzione a: marcello.romani@libero.it
Ultimo aggiornamento: 9 feb 2001. Il collegamento al documento originale si trova nella pagina iniziale.
Prec. (keeping an open mind) Pagina iniziale Succ. (Linux myths dispeller)