Indice
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".
Per maggiori informazioni sulle distribuzioni disponibili si veda Sezione 6.1, «Quante distribuzioni di Debian ci sono?».
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.
Se si è un nuovo utente che deve installare su una macchina desktop, iniziare con stable. Parte del software è piuttosto vecchio, ma è l'ambiente di lavoro con meno bug. Si potrà facilmente passare alla più moderna unstable (o testing) una volta che si è più sicuri di sé.
Se si è un utente desktop con molta esperienza del sistema operativo e che non si preoccupa di dover affrontare un bug una volta ogni tanto, usare unstable. Ha tutto il software più recente e all'avanguardia ed i bug sono solitamente risolti prontamente.
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.
Provare a cercare nel web usando un motore di ricerca e vedere se qualcun altro è stato in grado di farlo funzionare in stable. La maggior parte dell'hardware dovrebbe funzionare senza problemi in stable. Se però si ha dell'hardware recentissimo e all'avanguardia, questo potrebbe non funzionare con stable. Se questa è la situazione, si può installare testing o unstable o aggiornare il sistema ad una di esse.
Per i portatili, https://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 [email protected] . È possibile inviare messaggi alla lista anche senza essere iscritti. Gli archivi possono essere letti via https://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.
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.
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.
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...
No. Questa è una questione piuttosto soggettiva. Non esiste una risposta perfetta dato che dipende dal software di cui si ha bisogno, la disponibilità ad affrontare i possibili malfunzionamenti e l'esperienza nell'amministrazione di sistema. Ecco alcuni suggerimenti:
Stable è solida come una roccia. Non diventa difettosa e ha il pieno supporto di sicurezza. Ma potrebbe non avere il supporto per l'hardware più recente.
Testing ha software più aggiornato di Stable e diventa difettosa meno di frequente di Unstable, ma quando lo fa potrebbe volerci parecchio tempo prima che le cose vengano aggiustate. A volte possono volerci giorni e a volte mesi. Inoltre non ha un supporto di sicurezza permanente.
Unstable ha il software più recente e cambia molto. Di conseguenza può danneggiarsi in qualunque momento. Tuttavia, le cose vengono risolte spesso in un paio di giorni ed ha sempre le ultime versioni dei pacchetti software per Debian.
Quando si deve scegliere tra testing e unstable tenere in considerazione che
di potrebbero essere casi in cui sarebbe meglio seguire testing invece di
unstable. Uno degli autori di questo documento si è trovato in una di queste
situazioni a causa della transizione di gcc da gcc3 a gcc4. Stava cercando
di installare il pacchetto labplot
su una macchina con unstable e l'installazione non era lì possibile perché
alcune delle dipendenze avevano già fatto il passaggio a gcc4 ed alcune
no. Il pacchetto in testing però era installabile su una macchina testing
dato che i pacchetti che avevano fatto la transizione a gcc4 non avevano
ancora raggiunto testing.
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).
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 5 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 5 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 5 giorni, XYZ-3.7 da unstable migra in testing.
Perciò il 15 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 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 5 luglio.
Ma il 3 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ò l'8 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 13 luglio.
Dato che si usa testing e dato che XYZ-3.7 è affetta da un bug, sarà probabilmente possibile usare XYZ solo dopo il 13 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. Sebbene lo scenario descritto sopra sia immaginario, cose simili possono verificarsi nella vita reale, anche se raramente.
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.
Questa domanda non aiuta a scegliere una distribuzione Debian, ma prima o poi verrà fatto di porsela.
La distribuzione stable è attualmente bookworm; la prossima versione stable si chiamerà trixie. Consideriamo il caso particolare di ciò che avverrà quando trixie verrà rilasciata come nuova versione stable.
oldstable = bullseye; stable = bookworm; testing = trixie; 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è trixie). I pacchetti in stable (cioè bookworm) 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.
I bug RC nella "testing congelata" sono ridotti a zero oppure, se maggiori di zero, i bug sono contrassegnati come ignorati per il rilascio o sono posposti ad un rilascio minore.
La "testing congelata" senza bug RC viene rilasciata come nuova versione stable. Nel nostro esempio, questo nuovo rilascio stable sarà chiamato trixie.
A questo punto si avrà oldstable = bookworm, stable = trixie. Il contenuto di stable e della "testing congelata" è a questo punto lo stesso.
Una nuova testing viene basata sulla vecchia testing.
I pacchetti iniziano ad arrivare da sid in testing e la comunità Debian lavora ora per fare il prossimo rilascio stable.
Nella maggior parte dei casi scoprirlo è molto semplice. Guardare il file
/etc/apt/sources.list
. Ci sarà una voce simile alla
seguente:
deb http://deb.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.
First of all, please bear in mind that the stable version is the one recommended for servers as well as for desktop computers, not only you will get security updates if you are running stable but also there are less changes which could potentially break the system or your setup.
If you are currently running stable, then in the
/etc/apt/sources.list
file the third field will be
either 'bookworm' or 'stable'. If you want to change to a different
version, you need to change this to the distribution you want to run. If
you want to run testing, then change the third field of
/etc/apt/sources.list
to 'testing'. If you want to run
unstable, then change the third field to 'unstable'.
Attualmente testing si chiama trixie. Perciò, se si cambia il
terzo campo di /etc/apt/sources.list
in
«trixie», si userà anche in questo caso testing. Però si
continuerà ad usare trixie anche quando trixie
diventerà stable.
Unstable si chiama sempre Sid. Perciò se si cambia il terzo campo di
/etc/apt/sources.list
in «sid», si userà unstable.
Currently Debian offers does not offer security updates for testing nor for
unstable. The Debian Security
Team focus their work on stable and old-stable. Nevertheless, just
like any other type of fixes, security fixes in unstable are directly made
to the main archive and trickle down to testing in due course. So if you
are running unstable make sure that you remove the lines relating to
security updates in /etc/apt/sources.list
. If you are
interested in knowing what known security bugs exist in these versions of
the distributions, you will this information in the list
of vulnerable source packages in testing, and unstable.
If there is a release notes document available for the distribution you are upgrading to (even though it has not yet been released) it would be wise to review it, as it might provide information on how you should upgrade to it. You will always find the Release Notes for testing available at the Debian website but depending on how close the testing version is to release the document might not cover all the potential changes or pitfalls.
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 full-upgrade, aptitude safe-upgrade o aptitude full-upgrade. Per maggiori informazioni, leggere le pagine di manuale di apt e aptitude.
The Debian reference manual provides more insight on running testing and unstable in its section Life with eternal upgrades.
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://deb.debian.org/debian/ testing main
o
deb http://deb.debian.org/debian/ trixie 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 trixie 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 "trixie" allora si userà stable (dato che trixie sarà allora la nuova distribuzione stable).
These distributions are not Debian; they are Debian-based. Though there are many similarities and commonalities between them, there are also crucial differences.
Over the years, many distributions have been developed over time reusing and/or rebuilding Debian packages and also adding custom packages on their own. Most of the distributions have been created for specific audiences or purposes. According to Distrowatch, Debian has spawned more than 420 derivatives and more than 120 of them are active at the time of writing.
All these distributions have their own merits and are suited to some specific set of users. For more information, read Debian derivatives available at the Debian website. You can find a complete list of Debian derivatives, including those that are no longer under active development at the Debian derivate Census in the Wiki.
These distributions are Debian-based, but they are not Debian. You will be
still able to use apt package tools by pointing the
/etc/apt/sources.list
file to these distributions'
repositories. In some cases some distributions might even have additional
package managers that are used instead of apt.
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 whereas Debian is designed to be installed on the hard-disk. Knoppix is great if you want to know whether a particular piece of hardware works, or if you want to experience how a GNU/Linux system 'feels' etc., Knoppix is good for demonstration purposes while Debian is designed to run 24/7. Moreover the number of packages available and the number of architectures supported by Debian are far more than that of Knoppix.
If you want Debian, it is best to install Debian from the get-go. Although it is possible to install Debian through other distributions, such as Knoppix, the procedure calls for expertise. If you are reading this FAQ, I would assume that you are new to both Debian and Knoppix. In that case, save yourself a lot of trouble later and install Debian right from the beginning.
You are advised not to use the Debian forums (either mailing lists or IRC) for help on Debian derivatives as people there may base their suggestions on the assumption that you are running a Debian system. These "fixes" might not be suited to what you are running, and might even make your problem worse.
Usare prima i forum della distribuzione specifica che si sta usando. Se non si ottiene aiuto o l'aiuto ottenuto non risolve il problema, si può provare a chiedere nei forum Debian, ma tenere a mente l'avvertimento dato nel paragrafo precedente.
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/
).