[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ successivo ]
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 Quante distribuzioni di Debian ci sono?, Sezione 6.1.
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é.
If you are a desktop user with a lot of experience in the operating system and do 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.
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, 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.
Another option would be to ask in the debian-user mailing list by sending an
email to debian-user@lists.debian.org. Messages can be posted to the list even
without subscribing. The archives can be read through http://lists.debian.org/debian-user/
.
Information regarding subscribing to the list can be found at the location of
archives. You are strongly encouraged to post your questions on the
mailing-list rather than on irc
. The mailing-list messages
are archived, so the solution to your problem can help others with the same
issue.
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.
On the other hand, packages in testing or unstable can have hidden bugs, security holes etc. Moreover, some packages in testing and unstable might not be working as intended. Usually people working on a single desktop prefer having the latest and most modern set of packages. Unstable is the solution for this group of people.
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.
Actually, if you are an expert and if you are willing to spend some time and if you are real careful and if you know what you are doing, then it might be possible to go from unstable to testing and then to stable. The installer scripts are not designed to do that. So in the process, your configuration files might be lost and...
No. This is a rather subjective issue. There is no perfect answer as it depends on your software needs, your willingness to deal with possible breakage, and your experience in system administration. Here are some tips:
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).
The bug fixes and improvements introduced in the unstable distribution trickle down to testing after a certain number of days. Let's say this threshold is 5 days. The packages in unstable go into testing only when there are no RC-bugs reported against them. If there is a RC-bug filed against a package in unstable, it will not go into testing after the 5 days.
The idea is that, if the package has any problems, it would be discovered by people using unstable and will be fixed before it enters testing. This keeps testing in a usable state for most of the time. Overall a brilliant concept, if you ask me. But things aren't always that simple. Consider the following situation:
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.
After 5 days, XYZ-3.7 from unstable migrates into testing.
So on June 15, both testing and unstable have XYZ-3.7 in their repositories.
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.
This new version in unstable, XYZ-3.8 is scheduled to enter testing on July 5th.
But on July 3rd some other person discovers another RC-bug 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.
So on July 8th, testing has XYZ-3.7 while unstable has XYZ-3.9.
This new version XYZ-3.9 is now rescheduled to enter testing on July 13th.
Now since you are running testing, and since XYZ-3.7 is buggy, you could probably use XYZ only after July 13th. That is you essentially ended up with a broken XYZ for about one month.
The situation can get much more complicated, if say, XYZ depends on 4 other packages. This could in turn lead to an unusable testing distribution for months. While the scenario above is immaginary, similar things can occur in real life, though they are rare.
One of the main reasons why many people choose Debian over other Linux distributions is that it requires very little administration. People want a system that just works. In general one can say that stable requires very little maintenance, while testing and unstable require constant maintenance from the administrator. If you are running stable, all you need to worry about is keeping track of security updates. If you are running either testing or unstable it is a good idea to be aware of the new bugs discovered in the installed packages, new bugfixes/features introduced etc.
Questa domanda non aiuta a scegliere una distribuzione Debian, ma prima o poi verrà fatto di porsela.
The stable distribution is currently jessie; The next stable distribution will be called stretch. Let's consider the particular case of what happens when stretch is released as the new stable version.
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).
When testing is frozen, all the new bugfixes introduced have to be manually checked by the members of the release team. This is done to ensure that there won't be any unknown severe problems in the frozen testing.
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.
The 'frozen testing' with no rc-bugs will be released as the new stable version. In our example, this new stable release will be called stretch.
A questo punto si avrà oldstable = jessie, stable = stretch. 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://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.
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».
Currently testing is called stretch. So, if you change the third field of
/etc/apt/sources.list
to 'stretch', then also you will be running
testing. But even when stretch becomes stable, you will still be tracking
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 full-upgrade
,
aptitude safe-upgrade
o aptitude full-upgrade
. Per
maggiori informazioni, leggere le pagine di manuale di apt e aptitude.
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).
If unsure, the best bet would be the stable distribution.
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.
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 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, 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.
You are advised not to use the Debian forums (either mailing lists or IRC) for help 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/
).
[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ successivo ]
The Debian GNU/Linux FAQ
versione 8.1-0.rb1, 24 January 2017