"Perché Debian?", si potrebbe domandare. Debian é una delle tante distribuzioni GNU/Linux, e uno dei tanti sistemi operativi Unix-like. Che cosa la rende migliore delle altre distribuzioni? E perché poi bisognerebbe usare Linux? Bene, questo documento spiega tutto:

https://people.debian.org/~srivasta/talks/why_debian/talk.html

Questo documento è archiviato qui per garantire che sia accessibile a tutti.

Perché Linux? Perché Debian?

Di Manoj Srivastava (srivasta at debian.org)

Probabilmente non sono la persona più indicata per fare un paragone spassionato tra sistemi operativi, in parte perché ho alcuni pregiudizi e in parte a causa della mia limitata esperienza con qualsiasi sistema operativo diverso da quello che è la mia scelta favorita. Inoltre non sono la persona particolarmente indicata per promuovere le mie scelte, dato che le ragioni per le quali ho scelto ciò che mi piace non sono affatto ragioni universali, e l'ambiente in cui ho preso inizialmente la mia decisione (perché vi è una briciola di inerzia storica che mi ha portato ad essere dove sono) non esiste più.

Tuttavia, ho provato a dare una prospettiva più ampia della mia sola visuale e ho sollecitato le opinioni di altre persone che hanno fatto la mia stessa scelta, ma dato che l'argomento è estremamente soggettivo, parlerò principalmente dalla mia prospettiva e dalla prospettiva delle persone che hanno già scelto Debian.

Data la natura dei destinatari principali di questo discorso, non passerò troppo tempo spiegando perché si dovrebbe scegliere un sistema operativo simil-UNIX anziché un sistema operativo Microsoft. Basti dire che i criteri seguenti mi hanno portato inesorabilmente lontano da Windows: Sicurezza. Flessibilità. Controllo delle funzionalità. Filosofia. Costi. Velocità. Efficienza. Affidabilità. Disponibilità e possibilità di scelta nelle applicazioni software. Suscettibilità ai worm e ai virus. Disponibilità e velocità di risoluzione dei difetti conosciuti. Clustering. Sistema operativo multi-utente. Possibilità di non avere una GUI o un browser HTTP come parte integrante del sistema operativo.

https://www.michaelhorowitz.com/Linux.vs.Windows.php fornisce un confronto relativamente obiettivo tra Linux e Windows e può servire come introduzione a Linux per gli utenti Windows. Ha un taglio più commerciale di quanto sia appropriato per questo documento (il concetto del successo di mercato delle distribuzioni/compagnie Linux, ad esempio).

Filosofia e comunità

Fondamentalmente, la filosofia alla base dei sistemi operativi che noi consideriamo ne è il criterio di differenziazione più stabile; i valori delle prestazioni cambiano, la facilità di utilizzo, l'affidabilità, la disponibilità di programmi: tutte queste caratteristiche cambiano nel corso del tempo ed è necessario rivalutare nel corso del tempo.

Devo confessare che ciò che inizialmente mi ha fatto passare dalla parte di Linux, e poi di Debian, è stata proprio la filosofia e la comunità che li caratterizzano; penso che questi ne siano ancora gli aspetti più importanti e spesso sottovalutati.

Perché il software libero è una buona cosa? Nel corso di quasi due decenni da che sono entrato nel mondo del software libero, ho fatto alla gente questa domanda (e spesso sono rimasto sorpreso dalla risposta). La risposta comune sembra essere che il software libero è una buona cosa perché è fico o perché non costa nulla. Anche le motivazioni degli autori sono varie, ma la cosa più importante è spesso il riconoscimento, il plauso del gruppo dei pari o l'esperienza che può essere poi utilizzata sul luogo di lavoro.

Ma io penso che ci sfugga la ragion d'essere cruciale del software libero: l'aspetto di stare sulle spalle dei giganti. Vorrei usare come analogia il modo in cui viene condotta la ricerca accademica. Se i ricercatori fossero condannati a re-inventare la ruota e scoprissero da soli ogni cosa al di là di ciò che esiste nei libri di testo, allora il progresso nella comunità della ricerca sarebbe bloccato. La maggior parte dei miei pari ha iniziato la propria carriera nella ricerca facendo ricerche in letteratura, cercando ricerche interessanti e magari collegando articoli non legati tra loro, lavorando sulle base delle idee e delle tecniche di altri ricercatori dello stesso campo. Nella maggior parte dei laboratori, la segretezza sulle ricerche esiste solo fino al momento della pubblicazione, dopodiché le persone condividono i loro metodi, le loro idee, i loro risultati: la riproducibilità è davvero uno dei maggiori criteri del successo.

Se si paragona questo atteggiamento con il software proprietario, in cui tutti devono ripartire da zero: credo che ci si potrebbe innalzare tutti in volo, se solo potessimo liberamente condividire e potessimo costruire sulla base delle idee e dal lavoro degli altri. Questo ridurrebbe il tempo, lo sforzo e il costo dell'innovazione, permetterebbe lo sviluppo e la maturazione di pratiche migliori e migliori modelli costruttivi e ridurebbe il lavoro di programmazione noioso e umile che alza le barriere contro lo sviluppo di soluzioni interne.

Dobbiamo solo assicurare che continuino ad esistere incentivi per i risultati e i successi (e non è necessario che siano puramente motivi di profitto).

Questi principi mi hanno portato a sposare il punto di vista della GPL e della Fondazione per il Software Libero in contrasto con la licenze BSD, che sono anch'esse licenze libero per il software, e mi hanno da ultimo portato a scegliere Debian. Per la mia personale opinione, la licenza BSD è più legata all'orgoglio personale di aver scritto software libero, senza preoccuparsi di che fine fa il software; io voglio di più. Io voglio che il frutto del mio lavoro sia di aiuto nel costruire una comunità sinergica, che confluisca in un fiume di software utile.

Debian è un esempio pratico di costruzione comunitaria di un fienile: insieme, si può fare molto di più di ciò che si potrebbe fare da soli. Il Contratto sociale Debian è un fattore importante nella mia scelta di Debian, con la sua miscela di dedizione al software libero e riconoscimento pragmatico del fatto che ci sono casi in cui l'usabilità richiede software che non è conforme alle nostre linee guida.

L'altra ragione che mi ha fatto scegliere Linux invece di BSD è la sua comunità. Quando mi sono guardato intorno alla ricerca di un sistema operativo libero in stile UNIX da installare sul mio nuovo 386 fornitomi dall'università, i BSD erano molto più robusti e avevano prestazioni molto migliori e avevo amici che li raccomandavano molto caldamente. Quello che mi ha tenuto lontano era il sistema di casta che permeave la comunità BSD; c'erano gli sviluppatori principali lassù in alto e tu ti ritrovavi giù giù come basso pivellino contributore principiante. La comunità Linux, benché chiassosa, sembrava molto più aperta all'accettazione: il proprio pedigree contava meno del codice prodotto. E io ho potuto immediatamente contribuire a sviluppare il sistema operativo che avrei usato. Penso che questo sia un altro motivo per cui mi piace Debian: ne faccio parte da abbastanza tempo per averlo guidato ad essere il sistema operativo che è fatto secondo le mie idee.

Utilità e facilità d'uso

Assumendo di non aver già perso i lettori pragmatici, i criteri che la grande maggioranza di persone ritiene più importanti nella scelta di un sistema operativo sono, dopo il costo, l'utilità e la facilità d'uso. L'utilità dipende naturalmente da quali siano i propri obiettivi e le proprie necessità, ma ci sono argomenti generali che possiamo affrontare.

Un sistema operativo è più di un kernel con una miscela varia di software messo sopra: l'integrazione dei sistemi è un argomento a cui si dà poca importanza quando si discutono i meriti di un sistema. Ma un sistema ben integrato, in cui ciascun pezzo si incastra e si adatta alle altre parti del sistema, ha un'utilità molto maggiore rispetto ad uno che non lo è.

Debian, per la mia esperienza, e per l'esperienza di svariati delle persone da me interpellate, è is sistema meglio integrato disponibile. I pacchetti Debian tengono traccia delle loro relazione gli uni con gli altri, non attraverso semplicemente un meccanismo unidimensionale di dipendenze e conflitti, ma con un insieme più ricco di relazioni sfumate: pre-dipendenze, dipendenze comuni, raccomandazioni, suggerimenti, conflitti e relazioni migliorate. A parte questo, i pacchetti sono organizzati in categorie in base alla loro priorità (da essenziali ad extra) e alla loro funzione. Questa ricchezza di relazioni, di cui il sistema di pacchettizzazione è al corrente e a cui presta attenzione, è indice del livello in cui i pacchetti si completino gli uni con gli altri.

Debian viene sviluppata da circa 1000 volontari. Ciò significa che ciascun sviluppatore è libero di mantenere i programmi ai quali è interessato o di cui ha bisogno per compiti particolari nella vita di tutti i giorni. Questo è il motivo per cui Debian è capace di coprire diversi campi di specializzazione: i suoi sviluppatori desiderano solo risolvere i propri problemi particolari. Questa vasta gamma di interessi è diversa da quella delle distribuzioni commerciali che cercano di coprire solo i compiti più comuni.

Ho scoperto che le macchine Debian in funzione hanno bisogno di meno manutenzione manuale e sono più facili da aggiornare e semplicemente non si danneggiano così spesso come le macchine Red Hat e Mandrake che amministro. Mi è stato detto, per esempio, che avere a che fare con SunOS è molto più, diciamo, interessante.

Una delle ragioni per scegliere Debian rispetto ad altre distribuzioni è la enorme dimensione del progetto che suggerisce fortemente il fatto che non sparirà da un momento all'altro lasciando gli utenti senza supporto. Debian non può fare bancarotta. Il suo contratto sociale non permette al progetto di decidere su due piedi di non dare più il supporto per le versioni non commerciali della distribuzione. Non voglio che il mio SO sia tenuto in ostaggio dal piano commerciale di chicchessia.

Si può regolare con precisione la quantità di rischi che si vuole prendere, dato che Debian ha tre rilasci separati: Stable, Testing e Unstable. Su alcune delle nostre macchine (il server, le macchine chiosco) usiamo 'stable'. Alcuni degli altri sistemi (postazioni di lavoro individuali) hanno svariate combinazioni di testing/unstable. (Notare che non ci sono aggiornamenti di sicurezza per testing) Sulla mia postazione di lavoro personale ho in esecuzione alcune cose da experimental. Ciò che è bello è la capacità di prendere decisioni dettagliate per macchine diverse che hanno diverse funzioni. Ma anche le scelte più avventurose sono abbastanza solide da virtualmente non danneggiarsi mai. E 'stable' proprio non si guasta mai ;-).

Debian fornisce una grande quantità di feedback agli autori a monte. Il progetto XFree, per esempio, non mantiene o fa il debug esso stesso di X su tutte le architetture supportate da Debian: si appoggia a Debian per quello. Ci sono state diverse risoluzioni di problemi seri di libc (c'è stato di recente un errore nel conteggio dei riferimenti in glibc durante dlopen di un oggetto condiviso con certe dipendenze ELF scoperto dagli sviluppatori Debian). Questa attenzione per i dettagli è difficile da eguagliare per ogni altra distribuzione Linux. Il livello di aiuto preparato, veloce ed amichevole disponibile per gli utenti finali è semplicemente straordinariio; non ho trovato nulla capace di tenere il paragone a partire dalle aziende commerciali vecchio stile come DEC, a meno di non pagare veramente grandi somme. Questo può fornire supporto da terze parti senza esperti interni, per le attività commerciali che si basano su Debian.

Per i sistemi derivati, DFSG e "main" semplificano la costruzione di sistemi con licenze predicibili.

Qualità dell'implementazione

Le persone spesso raccontano come sono arrivate a Debian per apt-get o che apt è l'applicazione vincente di Debian. Ma apt-get non è quello che rende l'esperienza Debian grande: apt-get è una funzionalità che è stata prontamente riprodotta (e in mia opinione mai eguagliata) da altre distribuzioni: che venga chiamata urpmi, apt4rpm, yum o quello che sia. Il fattore distintivo è la politica Debian e il processo scrupoloso di garanzia della qualità del formato dei pacchetti (pensiamo a cose come apt-listchanges, apt-list-bugs, dpkg-builddeps, pbuilder, pbuilder-uml, nessuna delle quali potrebbe essere implementata così facilmente in mancanza di una politica (si immagini listchangelog senza un formato robusto per i changelog)). È davvero molto facile installare software su una macchina Debian.

Ciò ricorda le religioni basate sul culto del cargo): apt-get è cioè l'aspetto visibile del sistema delle politiche Debian, nello stesso modo in cui i culti del cargo hanno visto le strade ed altre caratteristiche come sorgente dei beni occidentali ("cargo") e hanno costruito le loro repliche complete di telefoni di legno finti per le torri di controllo. Similmente altre distribuzioni hanno creato aspetti visibili e superficiali dell'infrastruttura di gestione dei pacchetti di Debian, senza affrontare i problemi profondi della politica. Peggio: il conflitto tra requisiti tecnici e imperativi di marketing/economici spesso lavorano in antagonismo; in modo meno perverso per altre distribuzioni GNU/Linux che per il software proprietario, ma sono comunque presenti.

Red Hat, Mandrake e altre distribuzioni simili hanno installazioni di base veramente enormi. Perché? Penso che sia perché installare software è una esperienza dolorosa. Anche con RPM, è una procedura frammentaria, impossibile da codificare. Con Debian è una passeggiata.

Perciò l'applicazione vincente è in realtà la politica Debian, il team di sicurezza, il meccanismo formale di priorità dei bug e la politica sui bug (cioè qualsiasi binario senza una pagina di manuale ha automaticamente una segnalazione di bug; qualsiasi interazione con l'utente che non usi debconf è un bug). Come dice la pagina Wiki Why Debian Rocks:

Questo è il punto cruciale, il nartece, il cuore pulsante di Debian e ciò che la rende così immensamente superiore a tutti gli altri sistemi operativi. La politica è definita. È chiara. Viene fatta rispettare attraverso gli strumenti che si usano tutti i giorni. Quando si usa il comando apt-get install pippo, non si sta semplicemente installando del software; si sta applicando una politica e lo scopo di quella politica è di fornire il sistema migliore possibile.

Ciò che la Politica definisce sono i limiti di Debian, non le azioni dell'utente sul sistema. La politica dice quali parti del sistema possano essere cambiate dal sistema di gestione dei pacchetti e quali non possano, come gestire i file di configurazione, ecc. Limitare l'azione della distribuzione, rende possibile per l'amministratore di sistema fare modifiche al di fuori di quei limiti senza paura che i pacchetti Debian modifichino quei cambiamenti. Essenzialmente la Politica introduce una nuova classe di bug: i bug di politica. Questi sono bug critici per il rilascio: un pacchetto che viola la politica non viene incluso nel rilascio Debian stabile ufficiale.

Lasciate che mi ripeta perché questo è il vero segreto: un pacchetto che viola la politica non viene incluso nel rilascio Debian stabile ufficiale.

Si aggiunga a tutto ciò il team QA (garanzia di qualità) di Debian che fa i NMU, gli aggiornamenti non del manutentore, aiuta con la soluzione dei bug, esegue aggiornamenti di sicurezza e assicura che ci sia qualcuno che controlli il sistema nel suo complesso e che lavori per creare un SO integrato, invece di risolvere semplicemente i problemi di pacchetti individuali in modo disgiunto. Questo è ciò che fa sì che le persone mettano la mano sul fuoco per Debian. Ci sono molti strumenti nel sottosistema di garanzia di qualità che aiutano gli sviluppatori ad occuparsi dei propri pacchetti: basta guardare https://qa.debian.org/developer.php?login=srivasta

Il processo di valutazione che ciascun pacchetto deve subire nella distribuzione unstable prima di passare in testing aumenta la qualità del prodotto finito. Una volta che un pacchetto ha dimostrato di non avere problemi importanti per un certo periodo di tempo, passa nella distribuzione testing. Questa distribuzione è la candidata al rilascio per la futura distribuzione stabile, che viene rilasciata solamente quando tutti i bug critici sono stati risolti. Questo attento processo di test è la ragione per cui Debian ha cicli di rilascio più lunghi di altre distribuzioni. Tuttavia, in termini di stabilità, questo è un vantaggio. (Nota: RH Enterprise Linux sembra si stia orientando a cicli di rilascio di 12 - 24 mesi; un valore vicino a quello storico di Debian.)

Il fatto che Debian supporti così tante architetture aumenta anch'esso la qualità dei pacchetti: il port del software spesso scopre errori nel codice sottostante. Aggiungere il fatto che tutto il software in Debian passa attraverso circa 10 demoni di compilazione automatici, che deve essere senza bug quando viene compilato in questi ambienti diversi, e che richiede script di compilazione e installazione molto rubusti e un tracciamento molto stringente delle dipendenze di compilazione. Aggiungere inoltre i mirror degli archivi sorgente e il tracciamento delle versioni e si ottiene un sistema piuttosto robusto (snapshot.debian.org fornisce rollback facili).

Il sistema di tracciamento bug di Debian è un punto chiave della qualità della distribuzione. Il fatto che i rilasci sono collegati al numero di bug critici per il rilascio nel sistema, assicura che la qualità dei rilasci sia migliore di quella di qualsiasi UNIX proprietario che io abbia usato. Il Gestore di rilasci è piuttosto brusco nell'eliminazione di ogni pacchetto non essenziale con bug critici di rilascio se questi non vengono risolti, oppure ritarda il rilascio se è un pacchetto fondamentale ad avere il bug.

In confronto alle distribuzioni Linux commerciali, Debian ha un rapporto molto più alto tra sviluppatori e pacchetti. Se si aggiunge la mancanza di scadenze imposte da questioni commerciali, Debian tende a fare le cose per bene, piuttosto di farle in modo di avere una nuova versione disponibile per Natale.

In base ad una recente storia su Slashdot, ci sono più distribuzioni basate su Debian ora di quelle basate sul leader di mercato RedHat (63 e stanno aumentando, incluse Ubuntu, Xandros, Knoppix, Lycoris, Lindows (Lind--s ?), Libranet, mophix ...).

Il recupero da situazioni problematiche è assolutamente il migliore, senza paragoni. (Vedere http://www.linuxworld.com/story/32607.htm) Vedere anche lo script http://linuxmafia.com/faq/Debian/package-database-rebuild.html per il recupero di un sistema Debian quando non si ha un backup di /var/lib/dpkg.

Insieme di funzionalità e selezione di programmi

Debian ha attualmente più di 29.000 pacchetti. Molto probabilmente qualsiasi cosa di cui si ha bisogno è già pacchettizzata e integrata nel sistema ed ha una persona incaricata di mantenerla (insieme ad un piccolo numero di altri pacchetti) aggiornata, integrata e libera da bug.

Debian ha un enorme sforzo di internazionalizzazione, che traduce non solo la documentazione (ci sono persone che mi inviano pagine di manuale tradotte per i pacchetti di cui sono manutentore), ma anche gli script di configurazione ed installazione (tutta l'interazione di debconf può essere completamente internazionalizzata). Avere una comunità così vastamente distribuita geograficamente aiuta: abbiamo persone di madrelingua per un'enormità di lingue. Penso che lo sforzo di internazionalizzazione in Debian sia paragonabile a quello di Gnome e KDE.

Altre cose degne di nota, per le quali non ho abbastanza tempo per trattarle in dettaglio, sono: il progetto di documentazione di Debian, Alioth, l'installatore Debian, i CD Debian, Lintian e il sistema di tracciamento dei pacchetti.

Alcune altre cose che fanno sì che io continuerò ad usare Debian fino a che non siano supportate da qualcos'altro sono:

  1. debconf e la possibilità di fare il pre-seed del database
  2. make-kpkg con tutti i prompt disabilitati durante l'installazione
  3. /usr/share/doc/{Changelog.Debian,changelog,copyright,README.Debian}

Debian inoltre ha un vasto insieme di strumenti per gli hacker di kernel e della distribuzione e strumenti di integrazione del sistema come debbootstrap, chroots, user mode Linux, Xen. Tutti i tipi di bei strumenti per aiutare a smanettare sui meccanismi di installazione, su kernel e driver.

Ci sono diverse comunità di nicchia che hanno trovato in Debian una casa; sono sotto-progetti: Debian-Jr, Debian-med, Debian-Edu, Debian-non-profit e Debian-lex. Svariati sviluppatori Debian sono non vedenti e, quindi, Debian è piuttosto amichevole per i ciechi. C'è materiale aggiuntivo su Debian Pure Blend

Kernel

I kernel BSD, da quanto si sente, sembrano essere più stabili e avere una migliore qualità di quelli Linux. I kernel BSD sono più facili da leggere e comprendere. D'altro canto, i kernel Linux sono più ricchi di funzionalità e la loro qualità è migliorata significativamente, sembrano avere prestazioni molto migliori e un migliore supporto hardware di quelli BSD. Ho sentito commenti sostenere che, per ciò che riguarda il supporto per i driver, i BSD sono dove Linux era 5 anni fa. Parlerò di più sul supporto hardware in seguito. Personalmente la supposta presenza di bug dei kernel Linux non ha superato la mia soglia di accettabilità e, tutto sommato, non credo che una macchina Debian si comporti in modo meno robusto e stabile di una macchina FreeBSD per esempio. Naturalmente il recente boom di buchi nei kernel Linux sta iniziando a rendere la situazione tesa. (Tuttavia dobbiamo tenere a mente che avere più funzionalità è un fattore che conta: le due falle più recenti erano nella chiamata mremap(2) che non è disponibile in nessun *BSD.)

Debian Gnu/FreeBSD può fornire, ovviamente, il meglio di entrambi i mondi.

Spazio utente

Lo spazio utente BSD è diverso da quello GNU. Sono cresciuto con lo spazio utente GNU installato su macchine Ultrix/Aix/HP-UX per coerenza e per me risulta molto più comodo.

Si dovrebbe notare che si può installare lo spazio utente GNU su una macchina BSD e svariate persone lo fanno (/usr/local/gnu/*, per esempio). Per ciò che riguarda le installazioni che hanno entrambi gli insiemi di utilità installati, i rapporti dicono che la base degli utenti usa le utilità GNU in modo preferenziale nella stragrande maggioranza dei casi, anche se non sono quelle predefinite. In gnerale le utilità FreeBSD sembrano essere più leggere ma povere di funzionalità e sull'hardware moderno il piccolo risparmio in termini di memoria non ha importanza.

Non aiuta inoltre il fatto che non forniscono un buon aiuto sulla riga di comando; è molto più facile dire ad un principiante che se digita pippo --help otterrà qualcosa che può essere utile.

Lo spazio utente di base di OpenBSD è piuttosto completo. Preferisco quello GNU perché vi sono abituato, ma il sistema di base di OBSD è piuttosto utilizzabile. FBSD è una storia diversa: in esso si sono sforzati di fare un sistema di base minimale e non solo si aspettano che le persone lo usino, ma anche che ne installino molti port. FreeBSD diventa il sistema più simile a Debian nella famiglia BSD: si ha un sistema di base e su quello si costruisce. Il suo spazio utente è qualsiasi cosa si voglia che esso sia.

Mantenimento e amministrazione

È stato detto che il vantaggio fondamentale di Debian sono gli aggiornamenti. Più che per qualsiasi altro SO, la rete è il meccanismo di distribuzione e aggiornamento di Debian. La politica, l'attenzione posta negli script dei manutentori e i modi in cui possono essere richiamati, l'intero ordinamento della topografia sulla rete di dipendenze di apt e simili, tutto lavora in accordo per assicurare che gli aggiornamenti avvengano in modo corretto (non ho mai dovuto reinstallare le mie macchine, nonostante alcune siano state aggiornate sul posto per più di 5 anni). In un percorso raccomandato di aggiornamento di BSD non è impossibile trovare reinstallazioni (a partire da 2.8 o 2.9, OpenBSD ha detto almeno due volte agli utenti i386 "aggiornamento non supportato/non raccomandato, fare un'installazione pulita").

Questa facilità di aggiornamento ha un ruolo anche nella sicurezza del sistema; gli aggiornamenti di sicurezza sono molto più comodi in Debian di quanto non siano negli altri sistemi, grazie al team di sicurezza. Per noi meri mortali non iscritti a vendor-sec, avere security.debian.org nei nostri elenchi di fonti sources.list ci assicura che le nostre macchine vengano aggiornate comodamente e velocemente dopo che un punto vulnerabile viene reso noto al pubblico, dato che il team di sicurezza stava già lavorando ad una soluzione prima che i dettagli divenissero pubblici. Ciò significa che i sistemi vengono aggiornati in minuti, mentre il metodo raccomandato per fare un aggiornamento su un sistema operativo BSD comporta la ricomapilazione dell'intero sistema (almeno il "mondo").

Debian cerca di assicurare aggiornamenti puliti anche nel passaggio tra rilasci principali che è una cosa che non ho visto fare da nessuna altra parte. Ritorno sempre alla qualità del sistema dei pacchetti.

La ragione principale per cui la maggior parte delle persone rimane fedele a Debian è la sua amministrazione. Non conosco nessun'altra distribuzione in cui si possa digitare apt-get install sendmail e ritrovarsi con un server di posta completemente funzionante, completo di SASL e TLS, pienamente configurato, completo di certificati. Tutta l'amministrazione può essere fatta via SSH con velocità dial-up.

Debian garantisce che i cambiamenti fatti dall'utente ai file di configurazione vengano preservati e il fatto che tutti i file di configurazione siano posti in /etc (invece di essere sparsi per tutto il file system) fa sì che i backup siano più facili (ho la mia /etc in un sistema di controllo delle versioni).

Debian è conforme con FHS e la conformità a LSB è un obiettivo di rilascio.

La natura distribuita dello sviluppo e della distribuzione Debian rendono veramente facile la creazione di un repository separato di pacchetti personalizzati che possono essere distribuito internamente; inoltre la politica e i meccanismi di compilazione assicurano che terze parti possano compillare il sistema altrettanto facilmente in modo riproducibile.

Portabilità e supporto hardware

Linux tende a supportare più hardware insolito rispetto a BSD; se questo sia un problema dipende dalle proprie necessità. Il supporto per l'hardware di altà qualità è quasi lo stesso. Un'eccezione degna di nota è l'hardware RAID: le schede RAID 3ware iniziano ora ad essere supportate in BSD, ma lo sono in Linux da un bel po'. La garanzia del supporto per Linux di IBM per tutto il proprio hardware e quella di HP sono anch'esse un vantaggio di Linux. Inoltre mi piaciono i diversi file system con journaling che sono apparsi in Linux recentemente. Per i desktop, il fattore fondamentale sono i driver. E Linux lascia gli altri Unix X86 distaccati di miglia.

Quando si tratta di parlare di portabilità, NetBSD dovrebbe esserne la personificazione. Tuttavia io ho guardato bene e a lungo ciò che è supportato da NetBSD e da Debian: ho trovato che Debian supporta IBM s/390 e ia64, mentre NetBSD ha il supporto per sun2 (m68010), PC532 (qualunque cosa sia [a quanto pare una macchina personalizzata di cui sono stati prodotti solo 200 modelli]), e VAX. Non ho dubbi di quale insieme sia per me il più interessante (nonostante potrebbe essere carino avere VAX che lavora in cantina). Si noti che ciò che NetBSD chiama architetture sono spesso definite sotto-architetture da Debian e perciò non vengono conteggiate nel numero delle 11 architetture supportate.

Compilazione dai sorgenti

Ho letto molte cose sul meccanismo dei port di BSD e sul sistema dei port di gentoo. Ho sentito anche di come persone abbiano problemi a far sì che le cose vengano effettivamente compilate nei sistemi portati. A parte il fatte che compilare tutto diventa presto noioso (l'ho fatto anch'io, quando usavo la distribuzione Soft Landing Systems (SLS) nel '93).

Non è che non sia possibile fare un port come compilazione automatica di Debian: abbiamo compilatori automatici per 11 architetture che lo fanno, di continuo, ogni giorno; la questione è piuttosto perché si dovrebbe volerlo fare? Devo ancora vedere un singolo test riproducibile che dimostri un miglioramento percepibile delle prestazioni derivante da compilazioni locali su misura ottimizzate; inoltre di certo nulla di questo giustifica, ai miei occhi, il tempo speso aggiustando e compilando il software in lungo e in largo.

Qualcuno ha detto che quando era più giovane e aveva voglia di fare uno scherzo modificava un qualche parametro insignificante sul computer di qualcun altro e gli diceva "questo lo farà girare più veloce di circa il 5%, ma probabilmente non te ne accorgerai". Una tale sfida risultava di solito nella totale convinzione che la macchina aveva notevolmente migliorato e che la differenza del 5% poteva essere percepita!

La comune esperienza sembra indicare che le prestazioni totali del sistema migliorino di meno dell'1%. Tuttavia programmi specifici possono trarre grande beneficio ed è sempre possibile in Debian aggiustare un'applicazione critica secondo le proprie esigenze. Penso che qualunque risparmio di tempo nell'eseguire un sistema ottimizzato venga più che compensato dal tempo speso nella compilazione del sistema e nella compilazione degli aggiornamenti per il sistema (ho sentito di persone che fanno il loro aggiornamento giornaliero sullo sfondo mentre fanno altre cose in primo piano.).

Per non parlare di come soffra l'integrazione per non avere una posizione centrale in cui l'interoperabilità dei componenti possa essere testata bene, dato che ogni sistema differisce di molto da quello di riferimento.

Un sistema compilato dai sorgenti è anche molto più problematico quando si tratta di aggiornamenti importanti: ho prove aneddottiche di come non sia così sicuro e solido come il meccanismo di aggiornamento Debian.

Tuttavia, se voglio compilare in Debian pacchetti dai sorgenti, posso usare apt-get source -b, apt-src o uno di molti strumenti. Inoltre quando si fanno compilazioni locali posso aver fiducia nel fatto che i deb compilati localmente verrano installati in modo sicuro e corretto, sostituendo in modo appropriato le vecchie cose. Le dipendenze di compilazione richiamano qualsiasi dipendenza richiesta per la compilazione e io compilo abitualmente in pbuilder-user-mode-linux per assicurare compilazioni uniformi.

Il vero punto è che Gentoo è una distribuzione per gli hobbisti e per gli utenti Linux iper-smanettoni o super puristi che possono spendere del tempo nella compilazione delle loro applicazioni. So che Gentoo fornisce anche binari precompilati, ma ciò non va contro il suo presunto vantaggio? Per un ambiente produttivo in cui il tempo di inutilizzo costa denaro, ciò è semplicemente inammissibile e Debian rappresenta la soluzione migliore. Quelli di noi che amministrano più di una manciata di macchine possono apprezzare veramente come sia comodo essere in grado di fare apt-get update && apt-get upgrade in un solo colpo invece di dover scaricare, configurare, compilare e installare il software macchina per macchina, senza alcun tipo di aiuto automatizzato (non sto rendendo completamente giustizia a emerge / portage, ma il punto è chiaro, spero). Posso sottolineare la cosa: per un uso "serio"/produttivo, le distribuzioni binarie sono migliori e sono la sola soluzione ragionevole; tra di esse Debian (non solo per APT, ma anche per tutto il duro lavoro fatto dai DD per assicurare la correttezza del sistema di pacchettamento) è la migliore [ho praovato SuSE, RedHat e Mandrake e non ci tornerei neanche se mi offrissero molti soldi; anche Gentoo non è un'opzione valida].

Sicurezza e affidabilità

C'è sempre un compromesso tra sicurezza e comodità: il computer completamente sicuro è quello che non viene mai acceso. Sicuro, ma non molto utile. Si deve decidere dov'è la propria zona di serenità.

Cosa si pensa quando si dice Sicurezza e sistemi operativi in stile Unix? OpenBSD, con alcune giustificazioni. È testato ed ha una piccola dimensione, pochi requisiti di sistema E un'installazione basata su puro testo. Se ci si limita all'installazione base, si ottiene un sistema ben testato con nessun servizio abilitato in modo predefinito e la sicurezza che non vi siano falle nell'installazione predefinita che possano portare alla compromissione da remoto di root. Tuttavia, si tenderà a ritrovarsi con software vecchio e l'installazione predefinita fa veramente molto poco. [...] e protezione contro stackoverflow (?ProPolice) su OpenBSD https://www.openbsd.org/33.html, e exec-shield e patch Adamantix (PaX) per Linux (potrebbe essere necessario ricompilare il proprio kernel in Debian per queste). La maggior parte delle persone è d'accordo sul fatto che la porzione sicura e ben testata di OpenBSD non fornisce tutto il software di cui hanno bisogno. Inoltre le prestazione di OpenBSD sono, ahem.. povere in confronto a quelle di SELinux su un kernel 2.6.3.

La reputazione di sicurezza di OpenBSD è giustificata, ma solo quando si conosce il progetto, quando si ha familiarità con ciò che realmente copre. OpenBSD può essere un grande firewall, forse persino un server di posta o web statico; fintanto che ci si tiene lontati dall'albero delle porte si ha un sistema testato e orientato alla sicurezza. Conosco tuttavia poche applicazioni per un sistema di questo tipo. Le porte in spazio utente di OpenBSD non fanno ufficialmente parte del sistema e se dovesse apparire un problema di sicurezza per esse ci si dovrebbe aggiustare da soli.

Si può dire che Debian stable uguagli o superi proprio questi aspetti; inoltre sembra esserci veramente poca differenza nel mondo reale tra Debian e OpenBSD al momento. Uno deve lavorare un po' per rafforzare l'installazione predefinita di Debian con i sili pacchetti di priorità standard, ma questo è un lavoro di qualche minuto solamente per gli amministratori con esperienza. I test sul codice sono in uno stadio più avanzato di quelli per OpenBSD; anche se si deve tenere a mente che, a dispetto di tutti i testi, ci sono stati bug di alto profilo in OpenSSH recentemente: perciò considerare l'etichetta di sistema testato con un pizzico di buon senso.

La distribuzione Debian GNU/Linux si concentra fortemente sulla sicurezza e sulla stabilità. Abbiamo un team di sicurezza, sistemi di compilazione automatici per aiutare il team di sicurezza a compilare velocemente versioni per tutte le architetture che sono supportate e una politica indirizzata a questi obiettivi. Altro su un confronto tra OpenBSD e Debian orientato alla sicurezza può essere trovato qui.

Anche se non è proprio necessaria una serie di strumenti per ciascun sistema BSD finale per fare la distribuzione degli aggiornamenti di sicurezza ("make release" o "make package" per compilare su una macchina e installare altrove), è abbastanza più scomodo che non nel sistema dei pacchetti di Debian. Debian gestisce la distribuzione dei pacchetti binari in modo molto migliore. Si può avere un proprio archivio per apt e farlo usare da tutti i server di produzione usando i meccanismi nativi di Debian.

Quando si parla di vera sicurezza, tuttavia, senza controlli obbligatori sugli accessi si hanno molte poche garanzie. Perciò SELinux (e la nascente TrustedBSD) sarebbe una scelta molto migliore di OpenBSD o della Debian stable di base.

Anche senza SELinux, trovo la stabilità solida come una roccia di Debian stable, insieme alla tranquillità che deriva dal backport delle risoluzioni dei problemi di sicurezza fornito dal team di sicurezza, molto persuasiva. È facile per un utente non esperto tenersi aggiornato con la sicurezza e ciò riduce la probabilità di compromissione. Ciò è molto importante in un ambiente aziendale con un grande numero di computer, in cui è importante che il software NON venga aggiornato ad intervalli di pochi mesi.

C'è un altro beneficio del team di sicurezza Debian per ciò che riguarda distribuzioni stabili. C'è tuttavia solo una versione dell'albero dei port. Mentre in Debian si hanno versioni multiple di, per esempio, apache, KDE e X11, una per ogni suite con aggiornamenti di sicurezza per la suite stable, non c'è una cosa simile in FreeBSD. Benché, naturalmente, il makefile del port sarà aggiornato se viene trovata una vulnerabilità in un dato pacchetto, l'unico modo di tappare la falla sul proprio sistema in una situazione simile è di installare la nuova versione del pacchetto con tutti i possibili problemi che ciò può comportare. Si confronti la cosa con Debian in cui si ha la possibilità di installare la stessa versione del software con il backport della risoluzione del problema di sicurezza. Inoltre, se si sta lavorando con una versione installata da port del pacchetto vulnerabile, si rimane vulnerabili per tutto il tempo della compilazione il che può essere o meno un tempo considerevole.

Ho alcuni dati che confrontano le distribuzioni Linux e il tempo per risolvere vulnerabilità di sicurezza note; mancano però i dati per BSD. Sono disponibili su https://people.debian.org/~jfs/debconf3/security/data/.

Scalabilità e prestazioni

Non volevo inizialmente parlare per nulla di prestazioni e numeri, dato che questi hanno avuto poca importanza per me personalmente e che i valori delle prestazioni variano da rilascio a rilascio. Tuttavia ho capito che sono un criterio importante di decisione per alcune persone e ho cercato di trovare un'analisi recente dei numeri.

L'insieme completo dei benchmark, completo del codice, è disponibile qui. Ecco le sue parole, dalla sezione sulle conclusioni, aggiornate per riflettere i test più recenti.

Linux 2.6 ottiene O(1) in tutti i test. Non riesco a trovare parole su quanto ciò sia impressionante. Se si sta usando Linux 2.4, passare a Linux 2.6 immediatamente!

NetBSD ha una migliore scalabilità di FreeBSD.

FreeBSD 5.1 ha prestazioni e scalabilità veramente notevoli. (Notare che non è ancora stato rilasciato.) Ho dato stupidamente per scontato che tutti i BSD stessero nella stessa classe per ciò che riguarda le prestazioni, perché tutti condividono molto codice e possono incorporare il codice uno degli altri liberamente. Mi sbagliavo. FreeBSD ha la seconda prestazione migliore dei BSD e si avvicina persino a Linux 2.6.

Linux 2.4 non è malaccio, ma ha una cattiva scalabilità per mmap e fork.

OpenBSD 3.4 ha avuto prestazioni molto deludenti in questi test. Le prestazioni del disco sono pessime, il kernel era instabile e per ciò che riguarda la scalabilità di rete è stato persino superato da suo padre: NetBSD. OpenBSD perde inoltre punti per il sabotaggio che è stato fatto al suo stack IPv6. Se si sta usando OpenBSD, si dovrebbe abbandonarlo subito.

Conclusioni

Non c'è nessun altro sistema operativo o distribuzione che io conosca che ha questo insieme di proprietà (facilità di mantenimento, accessibilità, stabilità, dimensione, personalizzazione, supporto robusto). Per lo più non ho voglia di dover smanettare e fare il debug della mia postazione di lavoro, voglio poter fare il mio lavoro facilmente, in sicurezza e con una preoccupazione minima per l'infrastruttura che sto usando. Debian mi aiuta ad ottenere proprio questo.

E questa è tutt'ora la ragione principale per cui la uso, da un punto di vista tecnico. L'installazione e l'aggiornamento del software. I pacchetti sono di altissima qualità; di regola si installano e aggiornano perfettamente. La manutenzione del software è ancora una grande parte del lavoro di qualsiasi amministratore di sistema e con Debian è semplicemente banale. È un non problema. Non tiratela in ballo quando si parla di problemiin Debian, non ne vale la pena... praticamente senza difetti.

Ringraziamenti

  1. Wouter Verhelst <wouter@grep.be>

  2. José Luis Tallón <jltallon@adv-solutions.net>

  3. Andrew Suffield <asuffield@debian.org>

  4. Javier Fernández-Sanguino Peña <jfs@computer.org>

  5. Russell Coker <russell@coker.com.au>

  6. Andreas Metzler <ametzler@downhill.at.eu.org>

  7. Steve <sgbirch@imsmail.org>

  8. Toni Mueller <toni@debian.org>

  9. Marc Haber <mh+debian-devel@zugschlus.de>

  1. George Danchev <danchev@spnet.net>

  2. Lionel Elie Mamane <lionel@mamane.lu>

  3. Greg Folkert <greg@gregfolkert.net>

  4. Rudy Godoy <rudy@kernel-panik.org>

  5. Andreas Tille <tillea@rki.de>

  6. Nathanael Nerode <neroden@twcny.rr.com>

  7. Mark Ferlatte <ferlatte@cryptio.net>

  8. Gunnar Wolf <gwolf@gwolf.cx>

  9. Jim ?McCloskey <mcclosk@ucsc.edu>

  10. Bill Wohler <wohler@newt.com>

  11. Bill Richardson <bill@bothan.net>

  12. Alex Perry <alex.perry@qm.com>

  13. Woodrow Kirton <wkirton@surfwayx.net>

  14. David B Harris <dbharris@eelf.ddts.net>

  15. Joost van Baal <joostvb@mdcc.cx>

  16. Bill Allombert <allomber@math.u-bordeaux.fr>

  17. <root.man@earthlink.net>

  18. Viktor Rosenfeld <rosenfel@informatik.hu-berlin.de>

  19. "Adrian 'Dagurashibanipal' von Bidder <avbidder@fortytwo.ch>

  20. Razvan Petrescu <rpetrescu@montran.ro>

  21. s. keeling <keeling@spots.ab.ca>

  22. Karsten M. Self <kmself@ix.netcom.com>

Grazie anche a coloro che hanno partecipato alla discussione sulla mailing-list degli sviluppatori per il loro contributo.

Altre risorse


CategoryQuickIntroduction