Axel Bruns - UNIX bis Linux

oldstable ist der Vorgänger der jeweils aktuellen stable, solange Sicherheitsupdates zur Verfügung gestellt werden. Debian empfiehlt zwar, mit der jeweils aktuellen stable zu arbeiten, unterstützt oldstable aber noch mindestens ein weiteres Jahr mit Sicherheitsaktualisierungen.

stable ist die jeweils aktuelle offizielle Version. Dort sind alle Pakete gründlich getestet und aufeinander abgestimmt, Sicherheitsaktualisierungen sind schnell verfügbar. Debian veröffentlichte seit 2000 etwa alle zwei Jahre eine neue stable. Danach wird die Vorgänger-stable als oldstable noch weiterunterstützt. stable gilt daher als geeigneter Kandidat für Server-Systeme, die lange Zeit zuverlässig laufen müssen und einen Einsatz im Unternehmensumfeld ermöglichen.

Testing ist der Kandidat für die nächste stable. Direkt nach der Veröffentlichung einer neuen stable sind testing und stable identisch. Während sich die stable danach – abgesehen von Sicherheitsaktualisierungen – nicht mehr ändert, werden in testing nach und nach Aktualisierungen bzw. Fehlerkorrekturen und neue Anwendungspakete eingebunden. testing entwickelt sich also ständig weiter. Dabei bleibt das System im Normalfall aber voll einsatzfähig; die installierten Pakete können täglich auf Aktualisierungen geprüft und diese gegebenenfalls aufgespielt werden. Dieses Verfahren wird häufig für Arbeitsplatzrechner genutzt, wo man weniger auf Stabilität als auf neueste Software und Unterstützung aktueller Hardware Wert legt.

Beispielsweise konnte die Unterstützung von OpenDocument in stable erst rund zwei Jahre später als in anderen Distributionen angeboten werden, während es für die Anwender von testing zu keiner wesentlichen Verzögerung kam.

Einige Monate vor der Veröffentlichung einer neuen stable-Version wird testing in Bezug auf neue Programme und Programmversionen eingefroren („freeze“). Änderungen beziehen sich dann in der Regel nur noch auf die Beseitigung von beim Test aufgetretenen Fehlern. Für die Veröffentlichung müssen „als schwer eingestufte“ Fehler behoben sein, wodurch sich diese bisweilen um mehrere Monate verzögern kann.

Die ständigen Änderungen an testing bergen das Risiko von Installationsfehlern, die das laufende System beeinträchtigen können. Wie dieses Risiko im Vergleich zu den ebenfalls nicht fehlerfreien statischen Veröffentlichungen anderer Distributionen einzuschätzen ist, ist Gegenstand emotionaler Diskussionen.

Unstable ist der erste Anlaufpunkt für neue Versionen von Paketen und Programmen, bevor sie in testing integriert werden. Dort werden sie auf Fehler geprüft. unstable ist weniger für den produktiven Einsatz gedacht als für das Testen neuer Paketversionen. Wer unstable verwendet, muss damit rechnen, mit Programmfehlern konfrontiert zu werden, die aus mangelndem Zusammenspiel mit anderen Softwarekomponenten resultieren. Wurden innerhalb der Testzeit (meistens zehn, gelegentlich fünf, bei dringenden Paketen zwei oder sogar null Tage) keine schweren, für das Release entscheidenden Fehler („release-critical bugs“, „RC-Bugs“) gefunden und sprechen keine anderen Gründe wie das Zurückhalten einzelner Pakete durch das Release-Team oder nichterfüllte Abhängigkeiten dagegen, wird das Paket in testing aufgenommen.

Experimental wird als Vorstufe für unstable benutzt. In experimental werden Änderungen ausprobiert, die umfangreiche Auswirkungen auf das gesamte System haben können. So wurde der Übergang des X Window Systems von XFree86 auf X.Org in experimental erprobt. experimental ist keine vollständige Sammlung von Paketen. Es enthält nur, was gerade einer besonderen Untersuchung bedarf.

Jede Version hat einen Codenamen, der von Charakteren des Films Toy Story stammt. Derzeit ist „Squeeze“ (6.0) oldstable, „Wheezy“ (7.0) stable und „Jessie“ (8.0) der Name des testing-Zweigs. unstable wird immer „Sid“ genannt. Sid war im Film Toy Story der Junge von nebenan, der Spielzeuge kaputtgemacht hat. Viele sehen es auch als Backronym für „still in development“ (noch in Entwicklung) oder als rekursives Akronym für „sid is dangerous“ (sid ist gefährlich).

Der Codename Buzz (Debian 1.1, 17. Juni 1996) war die erste Debian-Veröffentlichung mit einem Aliasnamen. Sie wurde, wie bis jetzt alle weiteren, nach einer Figur des Films Toy Story benannt, in diesem Fall nach Buzz Lightyear. Zu diesem Zeitpunkt hatte Bruce Perens die Leitung des Projekts von Ian Murdock übernommen. Bruce arbeitete bei Pixar, der Firma, die den Film produzierte.

Zeitweise lagen große Zeiträume zwischen den Veröffentlichungen. Darauf gab es verschiedene Reaktionen, etwa wurden Pakete verschiedener Veröffentlichungen gemischt. Dies wird jedoch unmöglich, wenn sich zentrale Teile des Systems zu stark unterscheiden. So gab es zwischen Sarge und Etch eine Änderung der glibc-ABI, die für die meisten Pakete eine Aktualisierung nötig machte. Für einige Aufgaben wie Spam- und Virenerkennung bot Debian zeitweise eine Paketquelle namens „volatile“ (unbeständig) an, die mit Squeeze durch eine neue Paket-Quelle „updates“ ersetzt wurde. Für einige Programme kann man sich auch mit sogenannten Backports behelfen. Das sind Pakete von neueren Programmversionen, die für eine alte Veröffentlichung kompiliert wurden.

Innerhalb eines Releases enthält die Abteilung main das eigentliche Debian-System. main besteht komplett aus freier Software und sonstigen Werken gemäß DFSG. Es ist möglich, allein mit Paketen aus main ein funktionstüchtiges System zu installieren. non-free enthält Software, die proprietär ist, und contrib beherbergt Software, die selbst frei ist, jedoch ohne Software aus non-free nicht lauffähig ist, wie früher Java-Programme, die die Java-Laufzeitumgebung von Sun Microsystems benötigten. contrib und non-free sind kein offizieller Teil von Debian, werden jedoch unter anderem durch Bereitstellung der für main üblichen Infrastruktur unterstützt.

Debian unterstützt eine Anzahl verschiedener Hardware-Architekturen. Dabei wird zwischen offiziellen Release-Architekturen und Ports unterschieden. Um als Release-Architektur offiziell unterstützt zu werden, muss eine Anzahl Bedingungen erfüllt sein. So ist ein ausreichend großes Team nötig, eine ausreichende Anzahl entsprechender Rechner muss dem Debian-Projekt zum Erstellen von Paketen zur Verfügung stehen, und fast alle Pakete müssen auf der Architektur gebaut werden können und die Software benutzbar sein. Jede Architektur wird zunächst als Port unterstützt und kann zu einer offiziell unterstützten Architektur aufgewertet werden. Umgekehrt kann eine offizielle Release-Architektur zum Port abgewertet werden, wenn die Anforderungen an Release-Architekturen nicht mehr erfüllt sind. Für Ports gibt es keine stable-Veröffentlichungen, sondern es existiert nur die unstable-Variante.

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.