Ci sono molte diverse distribuzioni Debian. Scegliere la distribuzione Debian adatta è una decisione importante. Questa sezione fornisce alcune informazioni utili per gli utenti che desiderano fare la scelta più adatta per il loro sistema e inoltre risponde ad alcune possibili domande che potrebbero nascere al momento della scelta. Non parla del "perché si dovrebbe scegliere Debian" ma piuttosto di "quale distribuzione di Debian scegliere".
Quale distribuzione Debian (stable/testing/unstable) è meglio per me?
La risposta è piuttosto complessa. Dipende veramente da cosa si ha in mente di fare. Una soluzione potrebbe essere chiedere ad un amico che usa Debian. Ma ciò non significa che non è possibile prendere una decisione in modo autonomo. Di fatto, si dovrebbe essere in grado di fare una scelta una volta completata la lettura di questo capitolo.
-
Se la sicurezza o la stabilità sono aspetti di una qualche importanza: installare stable. Punto. Questa è la scelta consigliata.
-
If you are a new user installing to a desktop machine, start with stable. Some of the software is quite old, but it's the least buggy environment to work in. You can easily switch to the more modern unstable (or testing) once you are a little more confident.
-
If you are a desktop user with a lot of experience in the operating system and does not mind facing the odd bug now and then, or even full system breakage, use unstable. It has all the latest and greatest software, and bugs are usually fixed swiftly.
-
Se si gestisce un server, specialmente uno per cui la stabilità è un requisito importante o che è esposto ad Internet, installare stable. Questa è di gran lunga la scelta più sicura e affidabile.
Le domande che seguono forniscono, si spera, ulteriori dettagli su queste scelte. Dopo aver letto tutte queste FAQ, se ancora non si è in grado di prendere una decisione, optare per la distribuzione stable.
È stato suggerito di installare stable, ma in essa l'hardware pincopallino non viene rilevato o non funziona. Cosa fare?
Try to search the web using a search engine and see if someone else is able to get it working in stable. Most of the hardware should work fine with stable. But if you have some state-of-the-art, cutting edge hardware, it might not work with stable. If this is the case, you might want to install/upgrade to either testing or unstable.
Per i portatili, http://www.linux-on-laptops.com/
è un sito web molto buono per vedere se qualcun altro è stato in grado di farli funzionare con Linux. Il sito non è specifico per Debian, ma ciò nonostante è una risorsa preziosissima. Non conosco un sito web simile per i desktop.
Un'altra opzione sarebbe chiedere nella mailing list debian-user inviando un messaggio di posta elettronica a debian-user@lists.debian.org . È possibile inviare messaggi alla lista anche senza essere iscritti. Gli archivi possono essere letti via http://lists.debian.org/debian-user/
. Informazioni relative all'iscrizione alla lista sono reperibili all'indirizzo degli archivi. È caldamente consigliato porre le proprie domande sulla mailing-list piuttosto che su IRC
; i messaggi della mailing-list sono archiviati perciò la soluzione ai propri problemi potrà aiutare altri nella stessa situazione.
Nelle differenti distribuzioni ci sono versioni diverse dei pacchetti?
Sì. Unstable ha le versioni più recenti, ma i suoi pacchetti non sono ben testati e potrebbero avere dei bug.
D'altro canto, stable contiene versioni vecchie dei pacchetti, ma esse sono ben testate ed è meno probabile che abbiano un qualche bug.
I pacchetti in testing sono una via di mezzo tra questi due estremi.
Le distribuzioni stable contengono pacchetti veramente datati. Basta guardare Kde, Gnome, Xorg o persino il kernel: sono molto vecchi. Perché?
Beh, questo può essere vero. L'età dei pacchetti in stable dipende da quando è stato fatto l'ultimo rilascio. Dato che di solito trascorre più di 1 anno da un rilascio all'altro, stable potrebbe contenere versioni vecchie dei pacchetti. Tuttavia sono state testate per diritto e per rovescio. Si può dire a ragion veduta che i pacchetti non hanno alcun bug importante noto, falle di sicurezza, ecc. I pacchetti in stable si integrano perfettamente gli uni con gli altri. Queste caratteristiche sono molto importanti per server di produzione che devono essere in funzione 24 ore al giorno, 7 giorni alla settimana.
I pacchetti in testing o unstable, d'altra parte, possono avere bug nascosti, falle di sicurezza, ecc. Inoltre alcuni pacchetti in testing e unstable potrebbero non funzionare come atteso. Di solito le persone che lavorano su una singola macchina desktop preferiscono avere l'insieme di pacchetti più recente e moderno. Unstable è la soluzione adatta per loro.
Come si può vedere, la stabilità e l'estrema modernità sono ai capi opposti dello spettro. Se è necessaria la stabilità, installare la distribuzione stable. Se si vuole lavorare con i pacchetti più recenti, allora installare unstable.
Se si decidesse di passare ad un'altra distribuzione, sarebbe possibile farlo?
Sì, ma è un processo unidirezionale. Si può fare il passaggio stable --> testing --> unstable. La direzione inversa invece non è "possibile". Perciò è bene essere sicuri se si ha intenzione di installare unstable o di aggiornare il sistema ad essa.
In realtà, se si è esperti, si è disposti a spenderci del tempo, si è molto cauti e si sa quello che si sta facendo, allora potrebbe essere possibile passare da unstable a testing e successivamente a stable. Gli script di installazione non sono pensati per fare questo; perciò, nel farlo, i propri file di configurazione potrebbero andar perduti e...
Could you tell me whether to install stable, testing or unstable?
No, this is a rather subjective issue. There is no perfect answer as it depends on the software needed, the users' needs and the experience of its system administrator. Here are some tips:
-
Stable is rock solid. It does not break and has full security support. But it not might have support for the latest hardware.
-
Testing has more up-to-date software than Stable, and it breaks less often than Unstable. But when it breaks, it might take a long time for things to get rectified. Sometimes this could be days and it could be months at times. It also does not have permanent security support.
-
Unstable has the latest software and changes a lot. Consequently, it can break at any point. However, fixes get rectified in many occasions in a couple of days and it always has the latest releases of software packaged for Debian.
When deciding between testing and unstable bear in mind that there might be times when tracking testing would be beneficial as opposed to unstable. One of this document's authors experienced such situation due to the gcc transition from gcc3 to gcc4. He was trying to install the labplot
package on a machine tracking unstable and it could not be installed in unstable as some of its dependencies have undergone gcc4 transition and some have not. But the package in testing was installable on a testing machine as the gcc4 transitioned packages had not "trickled down" to testing.
È stato detto che testing si può rompere. Cosa significa?
A volte, un pacchetto può non essere installabile tramite gli strumenti di gestione dei pacchetti. Altre volte, un pacchetto può proprio non essere disponibile: forse è stato (temporaneamente) rimosso a causa di bug o di dipendenze non soddisfatte. Altre volte ancora, un pacchetto si installa ma non si comporta nel modo corretto.
Quando ciò avviene, si dice che la distribuzione è rotta (almeno per quel che riguarda il pacchetto in questione).
Why is it that testing could be broken for months? Won't the fixes introduced in unstable flow directly down into testing?
Le soluzioni dei bug e le migliorie introdotte nella distribuzione unstable passano in testing dopo un certo numero di giorni. Diciamo che la soglia è di 10 giorni. I pacchetti in unstable passano in testing solo quando non ci sono segnalazioni di bug critici per il rilascio che li riguardano. Se viene segnalato un bug critico per il rilascio riguardante un pacchetto in unstable, questo non passa a testing allo scadere dei 10 giorni.
L'idea è che, se il pacchetto ha dei problemi, questi vengono scoperti da coloro che usano unstable e vengono risolti prima che il pacchetto entri in testing. Ciò mantiene testing in uno stato usabile per la maggior parte del tempo. Nel suo insieme il concetto è impeccabile, a mio parere. Ma le cose non sono sempre così semplici. Prendiamo per esempio la situazione seguente:
-
Immaginiamo di essere interessati al pacchetto XYZ.
-
Ipotizziamo che al 10 giugno la versione in testing sia XYZ-3.6 e quella in unstable sia XYZ-3.7.
-
Dopo 10 giorni, XYZ-3.7 da unstable migra in testing.
-
Perciò il 20 giugno entrambe testing e unstable hanno nei loro repository XYZ-3.7.
-
Diciamo che un utente della distribuzione testing vede che è disponibile un nuovo pacchetto XYZ e aggiorna la propria versione XYZ-3.6 a XYZ-3.7.
-
Ora diciamo che il 25 giugno qualche utente di testing o unstable scopre che c'è un bug critico per il rilascio in XYZ-3.7 e lo segnala nel BTS.
-
Il manutentore di XYZ corregge il bug e carica la versione corretta in unstable, diciamo il 30 giugno. Qui è stato ipotizzato che ci vogliano 5 giorni prima che il manutentore corregga il bug e carichi la nuova versione. Il numero 5 non deve essere preso letteralmente: potrebbe essere di più o di meno a seconda del grado di severità del baco critico in questione.
-
L'entrata in testing di questa versione nuova in unstable, XYZ-3.8, è pianificata per il 10 luglio.
-
Ma il 5 luglio qualcun altro scopre un altro bug critico per il rilascio in XYZ-3.8.
-
Diciamo che il manutentore di XYZ risolve questo nuovo bug critico e carica la nuova versione di XYZ dop 5 giorni.
-
Perciò il 10 luglio testing ha XYZ-3.7, mentre unstable ha XYZ-3.9.
-
L'entrata in testing di questa versione nuova, XYZ-3.9, è ora pianificata per il 20 luglio.
-
Dato che si usa testing e dato che XYZ-3.7 è affetta da un bug, sarà probabilmente possibile usare XYZ solo dopo il 20 luglio. Cioè, fondamentalmente ci si è ritrovati con una versione guasta di XYZ per circa un mese.
La situazione può complicarsi ulteriormente se, per esempio, XYZ dipende da 4 altri pacchetti. Ciò potrebbe risultare in una distribuzione testing inutilizzabile per mesi. Lo scenario dipinto sopra, inventato dall'autore, può avverarsi nella vita reale. Ma ciò è raro.
Dal punto di vista di un amministratore, quale distribuzione richiede più attenzioni?
Una delle ragioni principali per cui molte persone scelgono Debian invece di altre distribuzioni Linux è il fatto che richiede molto poca amministrazione. Le persone vogliono un sistema che semplicemente funzioni. In generale si può dire che stable richiede molto poca manutenzione mentre testing e unstable richiedono una manutenzione costante da parte dell'amministratore. Se si usa stable, tutto ciò di cui ci si deve preoccupare è il tenere traccia degli aggiornamenti di sicurezza. Se si usa testing o unstable è una buona idea tenersi al corrente dei nuovi bug scoperti nei pacchetti installati, delle nuove risoluzioni di bug, delle funzionalità introdotte, ecc.
Cosa succede quando viene fatto un nuovo rilascio?
Questa domanda non aiuta a scegliere una distribuzione Debian, ma prima o poi verrà fatto di porsela.
La distribuzione stable è attualmente jessie; la prossima versione stable si chiamerà stretch. Consideriamo il caso particolare di ciò che avverrà quando stretch verrà rilasciata come nuova versione stable.
-
oldstable = wheezy; stable = jessie; testing = stretch; unstable = sid
-
Ci si riferisce ad unstable sempre come a sid indipendentemente dal fatto che venga fatto o meno un rilascio.
-
I pacchetti migrano continuamente da sid a testing (cioè stretch). I pacchetti in stable (cioè jessie) però rimangono gli stessi tranne che per gli aggiornamenti di sicurezza.
-
Dopo un certo periodo testing viene congelata nello stato di freeze; ma continuerà ad essere chiamata testing. A questo punto nessun pacchetto nuovo può migrare da unstable a testing a meno che non contenga la soluzione ad un bug critico per il rilascio (RC).
-
Quando testing è in freeze, tutte le nuove risoluzioni dei bug introdotte devono essere controllate manualmente dai membri del team per il rilascio. Ciò viene fatto per assicurare che non vi sarà alcun problema serio sconosciuto nella versione testing congelata.
-
RC bugs in 'frozen testing' are reduced to either zero or, if greater than zero, the bugs are either marked as ignored for the release or are deferred for a point release
-
La "testing congelata" senza bachi RC viene rilasciata come nuova versione stable. Nel nostro esempio, questo nuovo rilascio stable sarà chiamato stretch.
-
A questo punto si avrà oldstable = jessie, stable = stretch. Il contenuto di stable e della "testing congelata" è a questo punto lo stesso.
-
A new testing is based on the old testing.
-
I pacchetti iniziano ad arrivare da sid in testing e la comunità Debian lavora ora per fare il prossimo rilascio stable.
Ho un desktop/cluster in funzione con installata Debian. Come fare a sapere quale distribuzione è in esecuzione?
Nella maggior parte dei casi scoprirlo è molto semplice. Guardare il file /etc/apt/sources.list
. Ci sarà una voce simile alla seguente:
deb http://ftp.us.debian.org/debian/ unstable main contrib
Il terzo campo ("unstable" nell'esempio precedente) indica la distribuzione Debian a cui il sistema sta attualmente facendo riferimento.
Si può anche usare lsb_release
(disponibile nel pacchetto lsb-release
). Se si esegue tale programma in un sistema unstable si ottiene:
$ lsb_release -a
LSB Version: core-2.0-noarch:core-3.0-noarch:core-3.1-noarch:core-2.0-ia32:core-3.0-ia32:core-3.1-ia32
Distributor ID: Debian
Description: Debian GNU/Linux unstable (sid)
Release: unstable
Codename: sid
Tuttavia non è sempre così facile. Alcuni sistemi possono avere file sources.list
con voci multiple che corrispondono a distribuzioni diverse. Ciò può accadere se l'amministratore tiene traccia di pacchetti diversi da distribuzioni Debian diverse. Questa azione viene spesso chiamata apt-pinning. Questi sistemi possono avere in esecuzione un mix di distribuzioni.
Al momento sto usando stable. Posso passare a testing o unstable? Se sì, come?
Se si sta attualmente usando stable, allora nel file /etc/apt/sources.list
il terzo campo sarà o jessie o stable. È necessario cambiarlo e mettere la distribuzione che si vuole usare. Se si vuole usare testing, allora modificare il terzo campo di /etc/apt/sources.list
in testing. Se si vuole usare unstable, allora modificare il terzo campo in unstable.
Attualmente testing si chiama stretch. Perciò, se si cambia il terzo campo di /etc/apt/sources.list
in stretch, si userà anche in questo caso testing. Quando stretch diventerà stable, però, si continuerà ad usare stretch.
Unstable si chiama sempre Sid. Perciò se si cambia il terzo campo di /etc/apt/sources.list
in sid, si userà unstable.
Attualmente Debian offre aggiornamenti di sicurezza per testing ma non per unstable, dato che le risoluzioni dei problemi in unstable vengono direttamente fatte all'archivio principale. Perciò se si usa unstable assicurarsi di rimuovere dal file /etc/apt/sources.list
le righe relative agli aggiornamenti di sicurezza .
Se è disponibile un documento con le note di rilascio per la distribuzione a cui si sta per fare l'aggiornamento (anche se non ne è ancora stato fatto il rilascio) sarebbe saggio leggerlo, dato che potrebbe fornire informazioni su come fare l'aggiornamento.
Ciò nonostante, una volta fatti i cambiamenti detti sopra si può eseguire aptitude update
e poi installare i pacchetti desiderati. Notare che l'installazione di un pacchetto da una distribuzione diversa può aggiornare automaticamente metà del sistema. Se si installano pacchetti singoli si finirà per avere in esecuzione un sistema con un mix di distribuzioni.
Potrebbe essere meglio in alcune situazioni aggiornare semplicemente l'intero sistema alla nuova distribuzione eseguendo apt-get dist-upgrade
, aptitude safe-upgrade
o aptitude full-upgrade
. Per maggiori informazioni, leggere le pagine di manuale di apt e aptitude.
Attualmente sto usando testing (stretch). Cosa succederà quando verrà fatto un rilascio? Continuerò ad usare testing o la macchina userà la nuova distribuzione stabile?
Dipende dalle voci nel file /etc/apt/sources.list
. Se si sta attualmente usando testing, tali voci saranno simili a una di queste due:
deb http://ftp.us.debian.org/debian/ testing main
o
deb http://ftp.us.debian.org/debian/ stretch main
Se nel terzo campo in /etc/apt/sources.list
c'è "testing" allora si continuerà ad usare testing anche dopo un avvenuto rilascio. Perciò dopo che stretch sarà rilasciata, si starà usando una nuova distribuzione Debian che avrà un nome in codice diverso. I cambiamenti potrebbero non essere evidenti all'inizio, ma lo diverranno non appena nuovi pacchetti passeranno dalla distribuzione unstable a testing.
Se però il terzo campo contiene "stretch" allora si userà stable (dato che stretch sarà allora la nuova distribuzione stable).
Sono ancora confuso. Cosa hai detto che devo installare?
Se non si è sicuri, la scelta migliore sarebbe la distribuzione stabile.
E per quanto riguarda Knoppix, Linex, Ubuntu e altre?
Non sono Debian; sono basate su Debian. Benché ci siano molte somiglianze e cose in comune tra di esse, vi sono anche differenze fondamentali.
Tutte queste distribuzioni hanno i propri meriti e sono adatte a particolari tipi di utenti. Per maggiori informazioni, consultare la pagina sulle distribuzioni software basate su Debian
disponibile sul sito web di Debian.
So che Knoppix/Linex/Ubuntu/... è basata su Debian. Perciò dopo l'installazione sull'hard disk, posso usare con essa gli strumenti "apt" per i pacchetti?
Queste distribuzioni sono basate su Debian. Ma non sono Debian. Sarà comunque possibile usare gli strumenti apt per i pacchetti facendo puntare il file /etc/apt/sources.list
agli archivi di queste distribuzioni. Ma non si starà in quel caso usando Debian, si starà usando una distribuzione diversa. Non sono la stessa cosa.
Nella maggior parte delle situazioni, se si usa una distribuzione si dovrebbe rimanere legati ad essa e non mescolare pacchetti da altre distribuzioni. Molti problemi di funzionamento comuni derivano dall'uso di una distribuzione insieme al tentativo di installare pacchetti Debian da altre distribuzioni. Il fatto che usino lo stesso tipo di formato e lo stesso nome (.deb) non significa che siano automaticamente compatibili.
For example, Knoppix is a Linux distribution designed to be booted as a live CD where as Debian is designed to be installed on hard-disk. Knoppix is great if you want to know whether a particular hardware works, or if you want to experience how a linux system 'feels' etc., Knoppix is good for demonstration purposes while Debian is designed to run 24/7. Moreover the number of packages available, the number of architectures supported by Debian are far more than that of Knoppix.
Se si desidera Debian, la cosa migliore è installare Debian sin dall'inizio. Anche se è possibile installare Debian passando per altre distribuzioni, come Knoppix, la procedura richiede esperienza. Se si sta leggendo questa FAQ è lecito ipotizzare che si è alle prime armi sia con Debian sia con Knoppix. In questo caso, ci si risparmierà un sacco di problemi futuri se si installerà subito Debian.
Ho installato Knoppix/Linex/Ubuntu/... sul mio hard disk. Ora ho un problema. Cosa devo fare?
You are advised not to use the Debian forums (either mailing lists or IRC) for help as people might advice you thinking that you are running a Debian system and the "fixes" they provide might not be suited to what you are running. They might even worsen the problem you are facing.
Use the forums of the specific distribution you are using first. If you do not get help or the help you get does not fix your problem you might want to try asking in Debian forums, but keep the advice of the previous paragraph in mind.
Sto usando Knoppix/Linex/Ubuntu/... e ora voglio usare Debian. Come migro a Debian?
Considerare il passaggio da una distribuzione basata su Debian a Debian come qualsiasi altro passaggio da un sistema operativo ad un altro. Si dovrebbe fare il backup di tutti i dati e reinstallare il sistema operativo da zero. Non si deve cercare di "aggiornare" a Debian usando gli strumenti di gestione dei pacchetti dato che ci si potrebbe ritrovare con un sistema non funzionante.
Se tutti i propri dati utente (cioè la propria /home
) sono in una partizione separata la migrazione a Debian è in realtà piuttosto semplice, basta semplicemente dire al sistema di installazione di montare (ma non riformattare) quella partizione al momento della reinstallazione. È sempre caldamente consigliato fare il backup di tutti i propri dati oltre che della configurazione del sistema precedente (cioè /etc/
e, forse, /var/
).
Se ti è piaciuto l'articolo , iscriviti al feed cliccando sull'immagine sottostante per tenerti sempre aggiornato sui nuovi contenuti del blog
Nessun commento:
Posta un commento
Non inserire link cliccabili altrimenti il commento verrà eliminato. Metti la spunta a Inviami notifiche per essere avvertito via email di nuovi commenti.