| Hoofdstuk 3. Een Debian-distributie kiezen | ||
|---|---|---|
 |  | |
| Hoofdstuk 3. Een Debian-distributie kiezen | ||
|---|---|---|
| | | |
Inhoudsopgave
Er bestaan veel verschillende Debian-distributies. De geschikte Debian-distributie kiezen is een belangrijke beslissing. Dit onderdeel bevat wat nuttige informatie voor gebruikers die de voor hun systeem best geschikte keuze willen maken en het geeft ook antwoorden op mogelijke vragen die tijdens dit proces kunnen opduiken. Het handelt niet over de vraag "waarom kiezen voor Debian" maar eerder over "welke distributie van Debian kiezen".
Lees voor bijkomende informatie over de beschikbare distributies Paragraaf 6.1, “Hoeveel distributies van Debian zijn er?”.
Het antwoord is een beetje ingewikkeld. Het hangt echt af van wat u wilt doen. Een mogelijkheid is raad te vragen aan een vriend die Debian gebruikt. Maar dit wil niet zeggen dat u niet autonoom zou kunnen beslissen. In feite zou u in staat moeten zijn een beslissing te nemen na het lezen van dit hoofdstuk.
Indien veiligheid en stabiliteit voor u zeer belangrijk zijn, installeer dan stable. Punt. Dit is het meest verkieslijk.
Indien u een nieuwe gebruiker bent en een installatie op een desktopcomputer uitvoert, begin dan met stable. Sommige software is wat ouder, maar het is de minst foutgevoelige omgeving om in te werken. U kunt gemakkelijk overschakelen naar het modernere unstable (of testing) eens u er wat meer vertrouwd mee bent.
Indien u een desktopgebruiker bent met veel ervaring met het besturingssysteem er er niet om geeft af en toe geconfronteerd te worden met een vreemde bug of zelfs met een volledig onklaar geraakt systeem, gebruik dan unstable. Dat bevat al de recentste en geweldigste software en bugs worden meestal snel gerepareerd.
Indien u een server beheert, in het bijzonder wanneer er hoge eisen inzake stabiliteit aan gesteld worden of wanneer hij met het internet verbonden is, installeer dan stable. Dit is veruit de beste en veiligste keuze.
Via de volgende vragen gaan we (hopelijk) dieper in op deze keuzes. Indien u na het lezen van de volledige FAQ nog steeds geen beslissing kunt nemen, houd u dan bij stable als distributie.
Probeer met een zoekmachine op het web te zoeken om te zien of iemand anders erin geslaagd is die hardware in stable te laten functioneren. Maar indien u bepaalde hypermoderne hardware heeft, het nieuwste van het nieuwste, dan is het mogelijk dat die niet werkt met stable. Indien dit het geval is, wit u misschien testing of unstable installeren of ernaar opwaarderen.
Voor laptops is https://www.linux-on-laptops.com/ een heel goede website om te weten of iemand anders de hardware onder Linux aan de praat kreeg. De website richt zich niet specifiek op Debian, maar is desondanks een geweldige bron van informatie. Voor desktops is me geen dergelijke website bekend.
Een andere mogelijkheid is om de vraag te stellen op een debian-user mailinglijst door een e-mail te sturen naar [email protected] (Engelstalig) of naar [email protected] (Nederlandstalig). Zelfs zonder dat u op de lijst geabonneerd bent, kunt u een e-mail sturen. Via https://lists.debian.org/debian-user/ kunt u de archieven van de mailinglijst inkijken. Informatie over het intekenen op de lijst vindt u op de plaats waar u de archieven vindt. Het wordt sterk aangeraden om uw vragen op de mailinglijst te stellen, eerder dan op irc. De berichten van de mailinglijst worden gearchiveerd, zodat een oplossing voor uw probleem ook anderen kan helpen die met hetzelfde geconfronteerd worden.
Ja. Unstable bevat de meest recente (nieuwste) versies. Maar de pakketten in unstable zijn niet grondig getest en kunnen bugs bevatten.
Anderzijds bevat stable oude versies van pakketten. Maar deze pakketten zijn grondig getest en er is minder kans dat ze bugs bevatten.
De pakketten in testing vallen tussen deze beide uitersten in.
Welnu, u zou wel eens gelijk kunnen hebben. De leeftijd van de pakketten in stable is afhankelijk van het tijdstip waarop de laatste release gebeurde. Aangezien er tussen releases gewoonlijk meer dan 1 jaar verloopt, is het mogelijk dat u moet vaststellen dat stable oude versies van pakketten bevat. Zij werden evenwel door en door getest. Men kan met stelligheid beweren dat die pakketten geen gekende ernstige bugs, gaten in de beveiliging, enz. hebben. De pakketten in stable integreren naadloos met de andere stabiele pakketten. Deze eigenschappen zijn erg belangrijk voor productieservers die 24 uur per dag en 7 dagen per week moeten functioneren.
Pakketten in testing en unstable van hun kant kunnen verborgen bugs, gaten in de beveiliging, enz. hebben. Bovendien kunnen sommige pakketten in testing en unstable mogelijk niet naar behoren werken. Gewoonlijk verkiezen mensen die op een eenvoudige desktop werken om de recentste en meest moderne reeks pakketten te hebben. Unstable biedt voor deze groep mensen een oplossing.
Zoals u merkt, zijn stabiliteit en nieuwigheid de twee uitersten van een spectrum. Indien stabiliteit een vereiste is, installeer dan de stabiele distributie. Indien u met de recentste pakketten wilt werken, installeer dan unstable.
Jazeker, maar dit werkt maar in één richting. U kunt van stable --> testing --> unstable overgaan. Maar de omgekeerde richting is "onmogelijk". U kunt dus maar best zeker van uw stuk zijn als u van plan bent unstable te installeren of ernaar op te waarderen.
Eigenlijk, als u een expert bent en als u bereid bent om wat tijd te investeren en als u echt voorzichtig te werk gaat en als u weet wat u doet, dan zou het mogelijk kunnen zijn dat u van unstable overgaat naar testing en daarna naar stable. De installatiescripts zijn niet ontworpen om dat te doen. Dus kunnen in de loop van dit proces uw configuratiebestanden mogelijk verloren gaan en...
Nee. Dit is eerder een subjectieve keuze. Een perfect antwoord is niet mogelijk, omdat het afhankelijk is van uw softwarebehoeften, uw bereidheid om af te rekenen met mogelijke defecten en uw ervaring op het gebied van systeembeheer. Hierna volgen enkele tips:
Stable is zeer stabiel. Er treden geen defecten op en het wordt volledig ondersteund op het gebied van beveiliging. Maar mogelijk ondersteunt het niet de recentste hardware.
Testing heeft meer recente software dan Stable en er doen zich minder defecten voor dan in Unstable. Maar als er een defect optreedt, kan het lang duren voor de zaak rechtgezet wordt. Soms kan het gaan om dagen, maar dit kunnen soms ook maanden zijn. Er is ook geen permanente beveiligingsondersteuning voor voorzien.
Unstable heeft de recentste software en ondergaat veel wijzigingen. Een gevolg is dat het op elk moment defect kan geraken. In veel gevallen zetten reparaties de zaak terug recht binnen enkele dagen en de distributie bevat steeds de recentste releases van de voor Debian verpakte software.
Wanneer u wilt kiezen tussen testing en unstable, dan moet u in gedachten
houden dat er momenten kunnen zijn dat het voordeliger is om testing in
plaats van unstable op te volgen. Een van de auteurs van dit document heeft
een dergelijke situatie meegemaakt ten gevolge van de transitie van gcc van
gcc3 naar gcc4. Hij probeerde het pakket labplot te installeren op een machine die
unstable gebruikte, maar dat lukte niet omdat sommige van de pakketten die
dit pakket vereiste, de transitie naar gcc4 reeds doorgemaakt hadden en
andere nog niet. Maar op een machine die testing gebruikte, kon het pakket
wel geïnstalleerd worden, omdat de pakketten die de overgang naar gcc4
gemaakt hadden, nog niet "doorgesijpeld" waren naar testing.
Soms kan het zijn dat een pakket niet geïnstalleerd kan worden via de hulpmiddelen voor pakketbeheer. Soms kan een pakket helemaal niet beschikbaar zijn, misschien omdat het (tijdelijk) verwijderd werd omwille van bugs of niet-voldane vereisten. Soms lukt het om een pakket te installeren, maar functioneert het niet naar behoren.
Als zich dergelijke zaken voordoen, wordt gezegd dat de distributie defect is (althans voor dit pakket).
De reparaties van bugs en de verbeteringen die in unstable ingebracht worden, sijpelen door naar testing na een bepaald aantal dagen. Laten we stellend at de drempelwaarde 5 dagen is. De pakketten in unstable komen testing enkel binnen wanneer er tegen hen geen RC-bugs (bugs die het ongeschikt maken om uitgebracht te worden) gerapporteerd werden. Als er tegen een pakket een RC-bug ingediend werd, zal dat pakket testing niet binnenkomen nadat de 5 dagen verstreken zijn.
De achterliggende gedachte is dat indien een pakket eventuele problemen vertoont, die ontdekt zullen worden door mensen die unstable gebruiken en gerepareerd zullen worden vooraleer het testing binnenkomt. Dit houdt testing voor het merendeel van de tijd in een bruikbare toestand. Een volslagen briljant concept, als u het mij vraagt. Maar de zaken zijn niet steeds zo eenvoudig. Neem bijvoorbeeld de volgende situatie:
Stel u voor dat u geïnteresseerd bent in pakket XYZ.
Laten we aannamen dat de versie in testing op 10 juni versie XYZ-3.6 is en in unstable XYZ-3.7.
Na 5 dagen komt XYZ-3.7 vanuit unstable testing binnen.
En dus bevindt versie XYZ-3.7 zich op 15 juni zowel in het archief van testing als in dat van unstable.
Let's say, the user of testing distribution sees that a new XYZ package is available and updates the XYZ-3.6 to XYZ-3.7.
Op 25 juni merkt nu een gebruiker van testing of unstable een RC-bug in XYZ-3.7 en rapporteert dit in het BTS (het bugopvolgingssysteem).
De pakketonderhouder van XYZ repareert de bug en plaatst het in unstable op laten we zeggen 30 juni. Hier veronderstellen we dat het de pakketonderhouder 5 dagen tijd gekost heeft om de bug te repareren en de nieuwe versie te uploaden. Het getal 5 moet hier niet letterlijk genomen worden. Dit had minder of meer kunnen zijn, afhankelijk van de ernst van de betrokken bug.
Deze nieuwe versie in unstable, XYZ-3.8, staat gepland om op 5 juli testing binnen te komen.
Maar op 3 juli ontdekt iemand anders nog een andere RC-bug in XYZ-3.8.
Nemen we aan dat de onderhouder van XYZ deze nieuwe RC-bug repareert en een nieuwe versie van XYZ uploadt na 5 dagen.
Op 8 juli heeft testing dus versie XYZ-3.7 en unstable versie XYZ-3.9.
Dze nieuwe versie XYZ-3.9 staat nu gepland om op 13 juli testing binnen te komen.
Welnu, vermits u testing gebruikt en vermits XYZ-3.7 fouten vertoont, zult u XYZ wellicht pas na 13 juli kunnen gebruiken. Dit betekent dat u uiteindelijk ongeveer gedurende een maand met een defect XYZ gezeten heeft.
De situatie kan nog veel ingewikkelder worden als XYZ laten e zeggen 4 andere pakketten vereist. Dit kan op zijn beurt leiden tot het gedurende maanden onbruikbaar worden van de distributie testing. Hoewel het hierboven geschetste scenario theoretisch is, kunnen zich dergelijke situaties ook in het echt voordoen, al is dat uitzonderlijk.
Een van de belangrijkste redenen waarom veel mensen Debian kiezen boven andere Linux distributies is dat het heel weinig onderhoud vraagt. Mensen willen een systeem dat gewoon werkt. Over het algemeen kan men stellen dat stable heel weinig onderhoud vraagt, terwijl testing en unstable een voortdurend onderhoud van de systeembeheerder vragen. Indien u met stable werkt, is het enige waar u aandacht voor moet hebben, het opvolgen van beveiligingsupdates. Indien u testing of unstable gebruikt, doet u er goed aan op de hoogte te blijven van pas ontdekte bugs in de pakketten die u gebruikt, van bugreparaties, van toegevoegde nieuwe functionaliteit, enz.
Deze vraag zal u niet helpen bij het kiezen van een Debian-distributie. Maar vroeg of laat zult u hiermee geconfronteerd worden.
De distributie stable is momenteel bookworm. De volgende stabiele distributie zal trixie genoemd worden. Laten we nu eens concreet bekijken wat er gebeurt als trixie uitgebracht wordt als de nieuwe stabiele versie.
oldstable = bullseye; stable = bookworm; testing = trixie; unstable = sid
Naar unstable wordt steeds verwezen met de naam sid, ongeacht of er een nieuwe release uitgebracht werd of niet.
Palletten schuiven constant door van sid naar testing (m.a.w. trixie). Maar pakketten in stable (m.a.w. bookworm) blijven ongewijzigd, behalve voor beveiligingsupdates.
Na een bepaalde tijd wordt testing bevroren. Maar het zal nog altijd testing heten. Op dit punt kunnen geen nieuwe pakketten meer doorschuiven van unstable naar testing, tenzij ze reparaties bevatten voor RC-bugs (release-critical bugs, d.w.z. bugs die het pakket ongeschikt maken voor release).
Wanneer testing bevroren is, moeten alle nieuwe bugreparaties die toegevoegd worden, handmatig gecontroleerd worden door de leden van het release-team. Dit gebeurt om te garanderen dat de bevroren testing geen niet-gekende ernstige problemen zou hebben.
In het 'bevroren testing' wordt het aantal RC-bugs ofwel teruggebracht op nul, of als dat getal groter dan nul blijft, worden de bugs ofwel gemarkeerd als 'buiten beschouwing te laten voor de release' of wordt de reparatie ervan uitgesteld tot een tussenrelease.(point release).
De 'bevroren testing' wordt dan zonder RC-bugs uitgebracht als de nieuwe stabiele versie. In ons voorbeeld zal die nieuwe stabniele release trixie genoemd worden.
In deze fase is oldstable = bookworm, stable = trixie. De inhoud van stable en 'bevroren testing' is op dat ogenblik hetzelfde.
Een nieuwe testing wordt op de oude testing gebaseerd.
Pakketten beginnen vanuit sid testing binnen te komen en de Debian-gemeenschap begint te werken aan het realiseren van de volgende stabiele release.
In de meeste gevalle valt dit gemakkelijk uit te zoeken. Ga eens kijken in
het bestand /etc/apt/sources.list. Daarin zal een regel
te vinden zijn zoals deze:
deb http://deb.debian.org/debian/ unstable main contrib
Het derde veld ('unstable' in het bovenstaande voorbeeld) geeft aan welke Debian-distributie het systeem momenteel opvolgt.
U kunt ook het commando lsb_release (te vinden in het
pakket lsb-release)
gebruiken. Indien u dat programma uitvoert op een systeem met unstable, zult
u het volgende krijgen:
$ 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
Het is echter niet altijd zo gemakkelijk. Sommige systemen hebben mogelijk
een bestand sources.list met verschillende regels die
overeenkomen met verschillende distributies. Dit is mogelijk als de
systeembeheerder verschillende pakketten uit verschillende
Debian-distributies opvolgt. Hiernaar wordt vaak verwezen met de term
apt-pinning (apt-verankering). Op deze systemen kan een mix van distributies
functioneren.
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'.
Momenteel heet testing trixie. Indien u dus het derde veld van
/etc/apt/sources.list verandert in 'trixie',
zult u ook testing gebruiken. Maar ook wanneer trixie de stabiele
distributie wordt, zult ge nog altijd trixie opvolgen.
Unstable blijft steeds Sid heten. Indien u dus het derde veld van
/etc/apt/sources.list verandert in 'sid', zult u
unstable opvolgen.
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.
Maar u kunt, eens u de bovenvermelde wijzigingen heeft aangebracht,
aptitude update uitvoeren en dan de pakketten
installeren die u wenst. Merk op dat het installeren van een pakket van een
andere distributie tot gevolg zou kunnen hebben dat de helft van uw systeem
opgewaardeerd wordt. Indien u afzonderlijke pakketten installeert, zult u
een systeem bekomen dat werkt met gemengde distributies.
In sommige gevallen kan het beter zijn om gewoon volledig up te waarderen naar de nieuwe distributie met de opdracht apt full-upgrade, aptitude safe-upgrade of aptitude full-upgrade. Raadpleeg de man-pagina's van apt en aptitude voor bijkomende informatie.
The Debian reference manual provides more insight on running testing and unstable in its section Life with eternal upgrades.
Dit is afhankelijk van de regels in het bestand
/etc/apt/sources.list. Indien u momenteel testing
opvolgt, dan zien die regels er ofwel als volgt uit:
deb http://deb.debian.org/debian/ testing main
of als volgt:
deb http://deb.debian.org/debian/ trixie main
Indien het derde veld in /etc/apt/sources.list
'testing' is, dan zult u ook na het uitbrengen van een release testing
blijven opvolgen. Dus nadat trixie uitgebracht werd, zult u een
nieuwe distributie van Debian met een andere codenaam
gebruiken. Aanvankelijk zullen geen verschillen merkbaar zijn, maar die
zullen duidelijk worden van zodra nieuwe pakketten vanuit unstable naar de
nieuwe testing-distributie overkomen.
Maar als het derde veld 'trixie' bevat, dan zult u 'stable' opvolgen (aangezien 'trixie' dan de nieuwe stabiele distributie zal zijn).
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.
Als u het bij een distributie houdt, zou u in de meeste gevallen deze moeten gebruiken en ze niet mengen met pakketten uit andere distributies. Veel van de vaak voorkomende defecten ontstaan door het feit dat mensen die een bepaalde distributie gebruiken, Debian-pakketten uit andere distributies trachten te installeren. Het feit dat ze dezelfde indeling en naam (.deb) hebben, maakt ze nog niet onmiddellijk compatibel.
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.
Gebruik eerst de forums die specifiek bedoeld zijn voor de distributie die u gebruikt. Indien u er geen hulp krijgt, of indien de gekregen hulp geen oplossing biedt voor uw probleem, kunt u proberen om uw vraag te stellen op forums van Debian, maar houd de aanbeveling uit de vorige paragraaf in gedachten.
Beschouw de overstap van een op Debian gebaseerde distributie naar Debian juist gelijk een overstap van het ene besturingssysteem naar het andere. U moet een reservekopie maken van al uw gegevens en het besturingssysteem helemaal opnieuw herinstalleren. U moet niet proberen om naar Debian "op te waarderen" met behulp van de instrumenten voor pakketbeheer, aangezien u uiteindelijk misschien een onbruikbaar systeem bekomt.
Indien al uw gebruikersgegevens (d.w.z. uw /home) zich
o een aparte partitie bevinden, is overstappen naar Debian eigenlijk heel
eenvoudig. U moet bij het herinstalleren het installatiesysteem enkel
opdragen om die partitie aan te koppelen (maar niet te
formatteren). Reservekopieën maken van uw gegevens evenals van de
configuratie van uw vroegere systeem (d.w.z. /etc/ en
misschien /var/) blijft aanbevolen.
| | | |
| Hoofdstuk 2. Debian GNU/Linux verkrijgen en installeren |  | Hoofdstuk 4. Compatibiliteitskwesties |