[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ weiter ]
Es gibt viele verschiedene Debian-Distributionen. Die richtige auszuwählen, ist eine wichtige Entscheidung. Dieser Abschnitt umfasst einige Informationen, die Benutzern helfen sollen, zu entscheiden, welche Distribution am besten zu ihrem System passt. Darüber hinaus gibt er Antworten auf mögliche Fragen, die während des Entscheidungsprozesses auftauchen können. Es geht also nicht so sehr um das "Warum Sie Debian wählen sollten", sondern um das "Welche Distribution von Debian".
Um mehr Informationen über die verfügbaren Distributionen zu erhalten, lesen
Sie bitte Wie viele
Debian-Distributionen befinden sich in dem dists
-Verzeichnis?,
Abschnitt 6.2.
Die Antwort darauf ist ein wenig kompliziert. Sie hängt sehr davon ab, was Sie zu tun beabsichtigen. Eine Lösung wäre, einen Bekannten zu fragen, der selber Debian verwendet. Aber das bedeutet natürlich nicht, dass Sie keine unabhängige Entscheidung treffen könnten. Tatsächlich sollten Sie genau dazu in der Lage sein, wenn Sie dieses Kapitel bis zum Ende durchgelesen haben.
Wenn Ihnen Sicherheit und Stabilität am wichtigsten sind, dann installieren Sie stable. Das ist üblicherweise der bevorzugte Weg.
Wenn Sie erstmals Debian benutzen, und es auf einem Desktop-Rechner installieren wollen, beginnen Sie mit stable. Ein Teil der enthaltenen Software ist zwar etwas veraltet, dafür handelt es sich um die am wenigsten mit Softwarefehlern belastete Arbeitsumgebung. Sobald Sie es sich dann zutrauen, können Sie mit wenig Aufwand zum etwas moderneren unstable wechseln.
Wenn Sie Desktop-Benutzer sind, bereits über etwas Erfahrung mit Linux verfügen und Sie der eine oder andere seltsame Fehler von Zeit zu Zeit nicht stört, dann benutzen Sie unstable. Es bietet topmoderne Software und Fehler werden üblicherweise rasch behoben.
Wenn Sie einen Server betreiben, besonders einen, an den hohe Anforderungen hinsichtlich der Stabilität gestellt werden oder der über das Internet erreichbar ist, sollten Sie stable installieren. Das ist bei weitem die beste und sicherste Wahl hierfür.
The folgenden Fragen beleuchten die verschiedenen Wahlmöglichkeiten (hoffentlich) etwas detaillierter.
Durchsuchen Sie das Web mithilfe einer Suchmaschine und schauen Sie nach, ob jemand anderes Ihre Hardware zum Laufen gebracht hat. Die allermeiste Hardware sollte gut unter stable funktionieren. Wenn Sie aber bestimmte, sehr neue Hardware haben, kann es sein, dass diese nicht unter stable funktioniert. Sollte das der Fall sein, möchten Sie vielleicht zu unstable upgraden beziehungsweise unstable installieren.
Für Laptops ist die Internetseite http://www.linux-on-laptops.com/
eine sehr gute Anlaufstelle, um herauszufinden, ob jemand Ihr Gerät unter Linux
zum Laufen bekommen hat. Die Internetseite bezieht sich nicht direkt auf
Debian, ist aber dennoch eine große Fundgrube. Eine Internetseite in dieser
Art für Desktop-Rechner ist nicht bekannt.
Eine andere Möglichkeit ist, auf der Mailingliste debian-user nachzufragen,
indem man eine E-Mail an debian-user@lists.debian.org schickt. Nachrichten
können an die Liste geschickt werden, sogar ohne sich dort anmelden zu müssen.
Das Archiv ist unter http://lists.debian.org/debian-user/
einzusehen. Dort finden sich auch alle Informationen, welche die Anmeldung auf
der Liste betreffen. Wir möchten nachdrücklich empfehlen, dass Sie Ihre Fragen
über die Mailingliste schicken, anstatt sie im irc
zu stellen. Die
Nachrichten auf der Mailingliste werden archiviert. Auf diese Weise kann die
Lösung für Ihr Problem auch anderen Benutzern helfen, die die gleichen
Schwierigkeiten haben.
Ja. Unstable hat die aktuellsten (jüngsten) Versionen. Allerdings sind die Pakete in unstable nicht ausführlich getestet und haben möglicherweise Fehler.
Andererseits enthält stable zwar alte Paketversionen, diese sind jedoch ausführlich getestet. Es ist weniger wahrscheinlich, dass sie Fehler enthalten.
Die Pakete in testing stellen den Mittelweg zwischen diesen beiden Extremen dar.
Da könnten Sie recht haben. Das Alter der Pakete in stable hängt davon ab, wann die letzte Veröffentlichung gemacht wurde. Angesichts dessen, dass üblicherweise mehr als ein Jahr zwischen den Veröffentlichungen von Debian liegen, kann es sein, dass Sie den Eindruck gewinnen, dass stable alte Pakete enthält. Allerdings wurden diese durch und durch getestet. Man kann guten Gewissens sagen, dass diese Pakete keine schweren Fehler, Sicherheitslücken und dergleichen enthalten. Diese Eigenschaft ist sehr wichtig für produktive Server, die 24 Stunden am Tag und sieben Tage die Woche funktionieren müssen.
Umgekehrt können Pakete in testing und unstable versteckte Fehler, Sicherheitslöcher und Ähnliches aufweisen. Schlimmer noch, manche Pakete in testing und unstable funktionieren möglicherweise nicht wie beabsichtigt. Für gewöhnlich ziehen Personen, die an einem einzelnen Desktop-Rechner arbeiten, die jüngsten und modernsten Paket-Sets vor. Unstable ist die richtige Wahl für diese Art von Benutzer.
Wie Sie sehen, handelt es sich bei Stabilität und Aktualität um entgegengesetzte Enden eines Spektrums. Wenn Stabilität erforderlich ist, dann installieren Sie die stabile Distribution. Wenn Sie mit den neusten Paketen arbeiten möchten, dann installieren Sie unstable.
Ja, aber das ist eine Einbahnstraße. Sie können von stable --> testing --> unstable wechseln. Aber in umgekehrter Richtung ist das nicht "möglich". Sie sollten Sich also sicher sein, wenn sie planen unstable zu installieren oder ein upgrade zu machen.
Tatsächlich verhält es sich so: Wenn Sie Experte sind und willens etwas Zeit darauf zu verwenden, vorsichtig sind und wissen, was Sie tun, dann kann es möglich sein, von unstable zu testing und von testing dann zu stable zu gehen. Das Installations-Skript ist allerdings nicht dafür entworfen, dergleichen zu tun. Daher kann es passieren, dass während des Vorgangs Ihre Konfigurationsdateien verloren gehen und ...
Das ist eine ziemlich subjektive Angelegenheit. Es gibt darauf keine absolut richtige Antwort, sondern lediglich eine "vernünftige Vermutung", um sich zwischen testing und stable zu entscheiden. Die Sache ist die:
Stable ist "rock solid". Es geht nicht "kaputt".
Testing geht weniger oft kaputt als unstable. Aber wenn es passiert, dann dauert es eine ganze Weile, bis die Dinge wieder im Lot sind. Manchmal kann das Tage dauern, hin und wieder auch Monate.
In unstable ändert sich sehr viel und es kann daher auch jederzeit kaputt gehen. Allerdings werden die Probleme in vielen Fällen binnen Tagen behoben und unstable bietet außerdem immer die neueste für Debian paketierte Software.
Aber manchmal kann es günstiger sein, testing mitzuverfolgen als unstable. Der
Autor dieser Dokumentation erlebte so etwas während dem Wechsel von gcc3 auf
gcc4: Er versuchte, das Paket labplot
auf einem Rechner zu
installieren, der unstable folgte. Das gelang nicht, da nur einige der
Abhängigkeiten im Zuge des gcc-Übergangs bereits erfüllt waren, andere jedoch
nicht. In testing ließ sich das Paket dagegen installieren, da die im Übergang
befindlichen Pakete noch nicht in dort angelangt waren.
Es kann vorkommen, dass sich ein Paket nicht mit den Paketmanagement-Werkzeugen installieren lässt. Manchmal kann es auch sein, dass ein Paket nicht mehr verfügbar ist, vielleicht wurde es (zeitweise) wegen Fehlern oder verletzten Abhängigkeiten entfernt. Oder ein Paket lässt sich zwar installieren, verhält sich aber nicht ordnungsgemäß.
Wenn solche Dinge passieren, sagt man von einer Distribution, dass sie (zumindest in Bezug auf dieses eine Paket) kaputt ist.
Die Fehlerkorrekturen und Verbesserungen aus der Distribution unstable gelangen nur langsam nach einer bestimmten Anzahl von Tagen nach testing. Nehmen wir an, dieser Wert liegt bei zehn Tagen. Die Pakete in unstable gelangen erst nach testing, wenn dafür keine neuen veröffentlichungskritischen Fehler mehr gemeldet werden. Wenn also ein veröffentlichungskritischer Fehler für das Paket vorliegt, wird es auch nicht nach zehn Tagen nach testing gelangen.
Die Idee ist folgende: wenn das Paket irgendwelche Fehler hat, dann würden diese von Benutzern entdeckt werden, die unstable verwenden und würden bereinigt, bevor das Paket nach testing kommt. Das hält testing für die meiste Zeit in einem benutzbaren Zustand. Insgesamt ein brillantes Konzept. Allerdings sind die Dinge nicht immer so einfach. Überdenken Sie folgende Situation:
Stellen Sie sich vor, Sie wären am Paket XYZ.dd interessiert.
Nehmen wir an, dass am 10. Juni die Version XYZ-3.6 in testing ist und Version XYZ-3.7 in unstable.
Nach zehn Tagen wandert XYZ-3.7 von unstable nach testing.
Also haben am 20. Juni sowohl testing als auch unstable XYZ-3.7 in ihren Repositories.
Sagen wir, ein Benutzer der testing-Distribution bemerkt, dass ein neues XYZ-Paket verfügbar ist und macht ein Update von XYT-3.6 zu XYZ-3.7.
Nun entdeckt am 25. Juni jemand der testing oder unstable benutzt einen veröffentlichungskritischen Fehler im XYZ-3.7 und meldet diesen an das BTS.
Der Betreuer von XYZ behebt den Fehler und lädt ein neues Paket nach unstable hoch, sagen wir am 30. Juni. Wir nehmen hierbei an, dass der Betreuer fünf Tage braucht, um den Fehler zu beheben und die neue Version hochzuladen. Die Zahl von fünf Tagen sollte hier nicht falsch verstanden werden. Es kann länger dauern oder auch nicht, in Abhängigkeit von der Schwere des vorliegenden veröffentlichungskritischen Fehlers.
Die neue Version ist nun in unstable. Laut Plan soll XYZ-3.8 daraufhin testing am 10. Juli erreichen.
Aber schon am 5. Juli entdeckt wieder jemand einen veröffentlichungskritischen Fehler in XYZ-3.8.
Nehmen wir an, der Betreuen löst das Problem und lädt die neue Version von XYZ nach fünf Tagen hoch.
Also ist am 10. Juli XYZ-3.7 in testing und XYZ-3.9 in unstable.
Die neue Version XYZ-3.9 soll nach dem neuen Zeitplan nun am 20. Juli in testing ankommen.
Nachdem Sie ja testing verwenden und XYZ-3.7 fehlerhaft ist, könnten sie wahrscheinlich XYZ erst wieder nach dem 20. Juli benutzen. Im Endeffekt hätten Sie dann rund einen Monat lang ein kaputtes Paket XYZ gehabt.
Die Angelegenheit kann noch weitaus komplizierter werden, wenn etwa XYZ von vier anderen Paketen abhängt. Das kann dann zu einer monatelang nicht benutzbaren testing-Distribution führen. Das soeben vorgestellte Szenario ist zwar konstruiert, kann aber im echten Leben tatsächlich vorkommen. Allerdings geschieht das nur selten.
Einer der Gründe, warum viele Leute Debian anderen Linux-Distributionen vorziehen, ist der, dass es nur sehr wenig Verwaltungsaufwand erfordert. Diese Leute wollen ein System, das einfach nur funktioniert. Im allgemeinen kann man sagen, dass stable nur sehr wenig Wartung bedarf, während testing und unstable nach fortwährender Pflege durch den Systemwerwalter verlangen. Wenn Sie stable verwenden, müssen Sie lediglich darauf achten, mit den Sicherheitsupdates Schritt zu halten. Wenn Sie testing oder unstable verwenden, ist es klug, ein Auge auf neu entdeckte Fehler, Fehlerberichtigungen und neue Fähigkeiten in den bereits installierten Paketen zu haben.
Diese Frage wird Ihnen nicht helfen, eine Debian-Distribution auszuwählen, aber früher oder später werden Sie sich dieser Frage doch gegenüber sehen.
Derzeit ist etch die stabile Distribution. Die nächste stabile Veröffentlichung wird lenny heißen. Lassen Sie uns nun den speziellen Fall betrachten, dass lenny als neue stabile Distribution herausgegeben wird.
oldstable = sarge; stable = etch; testing = lenny; unstable = sid
Unstable wird immer sid genannte, unabhängig davon, ob eine Veröffentlichung gemacht wurde, oder nicht.
Pakete wandern fortwährend von sid nach testing (beispielsweise lenny). Aber Pakete in stable (beispielsweise etch) bleiben immer diesselben, außer im Falle von Sicherheitsupdates.
Nach einer bestimmten Zeit wird testing eingefroren; wird aber weiterhin als testing bezeichnet. Von nun an gelangen keine Pakete von unstable nach testing mehr, es sei denn, um veröffentlichungskritische (RC) Fehler zu beheben.
Nachdem testing eingefroren wurde, müssen alle neu eingeführten Fehlerkorrekturen händisch durch die Mitglieder des Veröffentlichungs-Teams überprüft werden. Das soll sicherstellen, dass sich keine ernsthaften Fehler in die eingefrorene testing-Veröffentlichung mehr einschleichen können.
Die RC-Fehler im eingefrorenen testing werden auf Null reduziert.
Das eingefrorene testing wird ohne RC-Fehler als neue stabile Veröffentlichung herausgegeben. In unserem Beispiel würde diese neue Veröffentlichung lenny genannt werden.
Nun ist oldstable = etch, stable = lenny. Zu diesem Zeitpunkt entsprechen sich der Inhalt von stable und eingefrorenem testing.
Ein neues testing wird aus dem derzeitigen stable abgeleitet.
Pakete beginnen wieder aus sid nach testing herunterzukommen und die Debian-Gemeinschaft beginnt auf die nächste Veröffentlichung hinzuarbeiten.
In den meisten Fällen ist das ganz einfach herauszufinden. Werfen Sie einen
Blick auf den Inhalt der Datei /etc/apt/sources.list
. Dort wird
sich ein Eintrag in dieser Art finden:
deb http://ftp.us.debian.org/debian/ unstable main contrib
Das dritte Feld (hier im Beispiel 'unstable') gibt die Debian-Distribution an, der das System gegenwärtig folgt.
Sie können außerdem lsb_release
abfragen (verfügbar über das
lsb-release
Paket). Wenn Sie dieses Programm auf einem System mit
unstable ausführen, erhalten Sie Folgendes:
$ 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
Leider ist es aber nicht immer so einfach. Einige Systeme haben vielleicht
eine sources.list
Datei mit mehreren Einträgen, die sich auf
unterschiedliche Distributionen beziehen. Das kann der Fall sein, wenn der
Systemverwalter verschiedene Pakete aus unterschiedlichen Distributionen
verwendet. So etwas wird häufig als apt-pinning bezeichnet. Solche Systeme
verwenden wahrscheinlich einen Mix aus unterschiedlichen Distributionen.
Wenn Sie derzeitig stable einsetzen, dann wird in der Datei
/etc/apt/sources.list
das dritte Feld entweder etch oder stable
sein. Diesen Eintrag müssen Sie passend zu der Distribution ändern, die Sie
verwenden möchten. Wenn das testing ist, dann ändern Sie das dritte Feld von
/etc/apt/sources.list
in testing. Wenn Sie unstable verwenden
wollen, dann tragen Sie in das dritte Feld unstable ein.
Gegenwärtig wird testing lenny genannt. Wennn Sie das dritte Feld von
/etc/apt/sources.list
in lenny ändern, dann werden Sie künftig
testing verwenden. Aber auch wenn lenny stable wird, werden Sie weiterhin
lenny haben.
Unstable wird immer sid genannt. Wenn Sie also das dritte Feld von
/etc/apt/sources.list
in sid ändern, werden Sie stets unstable
folgen.
Gegenwärtig bietet Debian Sicherheitsupdates für testing aber nicht für
unstable an, da Fehlerkorrekturen für unstable direkt im Hauptarchiv
vorgenommen werden. Wenn Sie also unstable benutzen, sollten Sie
sicherstellen, dass Sie die Zeilen in /etc/apt/sources.list
entfernen, die sich auf Sicherheitsupdates beziehen.
Wenn es für die Veröffentlichung zu der Sie upgraden Veröffentlichungshinweise gibt (möglicherweise auch obwohl die Veröffentlichung noch bevorsteht), wäre es klug, diese durchzusehen. Veröffentlichungshinweise enthalten möglicherweise Informationen über die Art, wie Sie das Upgrade vornehmen sollten.
Dennoch können Sie nachdem sich die obigen Veränderungen vorgenommen haben,
aptitude update
laufen lassen und dann die Pakete installieren,
die Sie haben möchten. Beachten Sie, dass das Installieren eines Pakets aus
einer anderen Distribution möglicherweise automatisch gleich Ihr halbes System
einem Upgrade unterzieht. Wenn Sie einzelne Pakete installieren, haben Sie zum
Schluß ein System, auf denen eine Mischung verschiedener Distributionen läuft.
In bestimmten Situationen ist es daher wahrscheinlich das Beste, ein volles
Upgrade auf die neue Distribution zu machen, indem man apt-get
dist-upgrade
, aptitude safe-upgrade
oder aptitude
full-upgrade
benutzt. Lesen Sie die Handbuchseiten von apt und aptitude
für weiterführende Informationen.
Das hängt von den Einträgen in der Datei /etc/apt/sources.list
ab.
Wenn Sie gegenwärtig testing mitverfolgen, sollt diese Einträge in etwa so
aussehen:
deb http://ftp.us.debian.org/debian/ testing main
oder
deb http://ftp.us.debian.org/debian/ lenny main
Wenn das dritte Feld in /etc/apt/sources.list
'testing' ist, dann
werden Sie auch nach der Veröffentlichung noch testing haben. Nachdem lenny
veröffentlicht wurde, werden Sie eine neue Debian-Distribution mit einem
anderen Codenamen laufen haben. Am Anfang werden die Veränderungen nicht
auffällig sein. Das wird sich aber ändern, sobald neue Pakete von unstable in
die testing-Distribution kommen.
Wenn aber das dritte Feld 'lenny' enthält, dann werden Sie künftig stable installiert haben, weil lenny dann die neue stabile Veröffentlichung sein wird.
Wenn Sie sich unsicher sind, dann wäre wohl die stabile Distribution die beste Wahl.
All diese Distributionen sind nicht Debian. Sie basieren auf Debian. Obwohl es viele Ähnlichkeiten und Gemeinsamkeiten mit ihnen gibt, gibt es aber auch ein paar entscheidende Unterschiede.
All diese Distributionen haben ihre eigenen Vorzüge und sind auf eine bestimmte
Gruppe von Benutzern zugeschnitten. Für mehr Informationen hierzu lesen Sie
die Informationen über auf Debian basierende
Software-Distributionen
auf der Internetseite von Debian.
Diese Distributionen basieren auf Debian, sind aber nicht Debian. Sie können
aber dennoch die apt Paketwerkzeuge zusammen mit einer
/etc/apt/sources.list
Datei verwenden, die auf die Repositories
dieser Distributionen verweist. Aber dann verwenden Sie nicht Debian, sondern
eine andere Distribution. Sie sind nicht das gleiche.
Wenn Sie eine bestimmte Distribution nutzen, sollten Sie auch genau diese benutzen, und nicht versuchen, zusätzlich Pakete aus anderen Distributionen einzumischen. Viele weit verbreitete Probleme rühren daher, dass Benutzer eine Distribution verwenden und versuchen, Pakete aus einer anderen Distributionen zu installieren. Die Tatsache, dass alle dasselbe Format und den gleichen Namen (.deb) verwenden, macht die Pakete mitnichten automatisch kompatibel zueinander.
Beispielsweise handelt es sich bei Knoppix um eine Linux-Distribution, die als Live-CD entworfen wurde, wohingegen Debian für die Installation auf der Festplatte gedacht ist. Knoppix ist hervorragend geeignet, wenn Sie ermitteln wollen, ob eine bestimmte Hardware funktioniert oder wenn Sie herausfinden möchten, wie sich ein Linux-System 'anfühlt'. Knoppix ist ein gutes Vorführ-System, während Debian entworfen wurde, um 24 Stunden am Tag und 7 Tage die Woche zu laufen. Darüber hinaus ist die Anzahl der verfügbaren Pakete und die Zahl der unterstützten Prozessorarchitekturen bei Debian weitaus größer als bei Knoppix.
Wenn Sie Debian wollen, ist es das Beste, es frisch zu installieren. Auch wenn es möglich ist, Debian über andere Distributionen wie etwa Knoppix zu installieren, erfordert das etwas Sachverstand. Angesichts dessen, dass Sie dieses FAQ lesen, nehmen wir an, dass Debian und Knoppix neu für Sie sind. In diesem Fall ersparen Sie sich besser den späteren Ärger und installieren Sie Debian sauber von Grund auf neu.
Wir raten Ihnen, nicht die Debian-Foren zu benutzen (weder die Mailinglisten noch den IRC), da die Leute, die Ihnen helfen wollen, glauben würden, Sie benutzten ein Debian-System. Die "Lösungen", die Sie so erhalten, passen möglicherweise nicht zu Ihrem System. Es könnte sogar sein, dass dadurch Ihre Probleme nur noch größer werden.
Benutzen Sie statt dessen vorrangig die Foren der entsprechenden Distribution. Wenn Sie dort keine Hilfe finden, oder die Lösungen Ihr Problem nicht beheben, können Sie noch immer in Debian-Foren nachhaken. Behalten Sie jedoch das zuvor gesagte im Hinterkopf.
Betrachten Sie den Wechsel von einer auf Debian basierenden Distribution zu Debian als Wechsel von einem Betriebssystem zu einem anderen. Sie sollten Sicherungskopien Ihrer Daten anlegen und das Betriebssystem von Grund auf neu installieren. Sie sollten nicht versuchen, ein "Upgrade" auf ein Debian mithilfe der Paketwerkzeuge zu machen, da Sie am Ende möglicherweise mit einem unbrauchbaren System dastehen.
Wenn sich all Ihre Benutzerdaten (beispielsweise /home
) auf einer
gesonderten Partition befinden, ist der Umstieg auf Debian ziemlich einfach.
Sie müssen das Installationssystem lediglich anweisen, diese Partition bei der
Neuinstallation einzubinden (aber nicht zu formatieren). Sicherungskopien
Ihrer Daten ebenso wie der Konfigurationsdateien (etwa /etc/
und
vielleicht auch /var/
) anzulegen, ist dennoch ratsam.
[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ weiter ]
Die Debian GNU/Linux-FAQ
Version 4.0.4+nmu1, 3 January 2010