staging.inyokaproject.org

Linux-Distributionen frieren, sofern sie nicht dem Rolling-Release Modell folgen, ihren Paketpool mit einem neuen Release ein und veröffentlichen für die entsprechenden Versionen nur noch Bugfixes und vor allem Sicherheitsupdates. Bei den Distributionen mit sechsmonatigem Releasezyklus fällt das nicht sonderlich auf, da viele Benutzer binnen weniger Monate auf eine aktualisierte Version updaten. Anders sieht es bei den Distributionen mit längerer Laufzeit wie Debian Stable oder Ubuntu LTS aus. Hier werden sehr dieselben Paketversionen über sehr lange Zeit beibehalten.

Dieses Releasemodell läuft konträr zur gegenwärtigen Upstream-Releasepolitik. Nicht nur Chrome und Firefox haben die ständigen Releases zur Maxime erhoben, sondern auch die großen Desktopumgebungen releasen sehr häufig neue Versionen. Das hat zur Folge, dass eine Version upstream oftmals nur 6 Monate (bspw. GNOME und KDE) mit Updates versorgt wird. Danach sind die Distributoren in der Pflicht Bugfixes zurück zu portieren.

Doch seien wir mal ehrlich: Kaum eine Distribution tut das wirklich. KDE 3.5 war in Debian Lenny beim Release schon quasi nicht mehr gepflegt und KDE 4.4 im aktuellen Stable Release Squeeze bekommt meines Erachtens nach auch keine wirklichen Updates. Für den Benutzer bedeutet das zwangsläufig auf Bugs, die upstream bereits behoben sind, in der aktuellen Distribution sitzen zu bleiben. Ein gutes Beispiel dafür sind die Nepomuk-Fixes, die es nicht mehr in openSUSE 12.1 und Kubuntu 11.10 geschafft haben. Dem Benutzer bleibt hier nur auf den nächsten Distributionsrelease zu warten und so lange keine vernünftige Suchfunktion (im Nepomuk-Beispiel) zu haben.

Das ist ärgerlich und entspricht meiner Auffassung nach nicht dem Sinn einer stabilen Distribution. Die Kernelentwickler und jüngst auch die Firefox-Entwickler haben auf diese Umstände reagiert und veröffentlichen LTS bzw. bei Firefox ESR Versionen mit verlängerter Supportlaufzeit. Meiner Meinung nach bräuchten mehr große Projekte solche Versionen um den realen Anwendungsszenarien gerecht zu werden. Natürlich hat man es als bloggender Benutzer leicht mit solchen Vorschlägen, während die Entwickler alles freiwillig machen aber letztlich muss doch Software auch für die Anwender programmiert werden?

Was meint ihr dazu?

Mr.Gerard.Cruiz schrieb:

Was meint ihr dazu?

Das es für jeden Einsatzzweck bereits das passende gibt im riesigen Linux-Universum.

Du willst aktuelle Software und nimmst dafür auch instabilitäten in Kauf? Aptosid und Siduction stehen bereit.

Du willst immer aktuelle Software quasi direkt aus dem Upstream? Kein Problem, ArchLinux und Gentoo warten auf dich.

Du willst ein stabiles System für einen längeren Einsatzzweck? Kein Problem, Debian ist das Mittel der Wahl für Server, Arbeits-PCs etc. pp.

Du willst ein äußerst stabiles System, das über viele Jahre hinweg eingesetzt werden kann? Auch kein Problem, hier warten CentOS und Scientific Linux schon auf dich.

Einzig LTS-Versionen sind wirklich zu empfehlen, denn gern vergeht mal ein Jahr, bis die einigermassen fehlerarm laufen.

Erst nach dem der Support der letzten LTS ausgelaufen ist, sollte man einen Wechsel auf die nächste in Betracht ziehen.

Derzeit ist die Gefahr ziemlich gross, danach trotzdem mit einem unbrauchbaren Rechner dazustehen - eingehende Tests im Vorfeld empfehlen sich also.

Die Zwischenvarianten haben zur "Reifung" überhaupt nicht die Zeit.

Bei den Programmen mit Internetzugang ist es ohnehin sinnvoll, direkt vom Hersteller zu installieren und zu aktualisieren, die Aktualisierungen über die Distribution hängen oft viel zu lange nach - eigentlich sind wir damit zwar beim Windows-Konzept, aber Sicherheit geht vor.

Dieses Dilemma läßt sich in der Tat mit einem Wort umschreiben: Stabilität! Ein Problem, an dem Linux schon immer krankt.

Im Server-Bereich sieht das übrigens anders aus. Da wird nicht alle Nase lang eine Mode gegen eine andere gerade gültige Mode ausgetauscht, jedes halbe Jahr zum -schlußverkauf. 😉

Ich muss wohl präzisieren: Ich meinte LTS Versionen bei den Upstream Projekten wie Firefox oder dem Kernel.

LTS Versionen unter den Distributionen haben wir schon lange aber - überspitzt gesagt - bedeutet das bisher nur, dass man 3-5 Jahre auf seinem Bug sitzen bleiben darf.

Mr.Gerard.Cruiz schrieb:

LTS Versionen unter den Distributionen haben wir schon lange aber - überspitzt gesagt - bedeutet das bisher nur, dass man 3-5 Jahre auf seinem Bug sitzen bleiben darf.

Du solltest hier Ubuntu nicht mit Linux gleichsetzen. Es gibt durchaus auch Linux-Distributionen, die sich um die Bugs in ihren stabilen Version kümmern...

Ja ich sagte auch nicht, dass überhaupt nichts gefixt wird aber es ist schon so, dass nicht alles was upstream behoben wird auch wirklich zurückportiert wird. Und das bei allen mir bekannten Distributionen. Kubuntu und Debian liefern beide gerade in den LTS bzw. Stable Varianten KDE 4.4 aus. Mir kann niemand erzählen, dass das ohne jede Mitwirkung der KDE-Entwickler effektiv gepflegt wird.

Das war früher weniger ein Problem. Bei GNOME änderte sich kaum was zwischen den Releases und KDE 3.5 wurde von 2005 bis 2008 upstream gepflegt. Davor kamen die Releases auch nicht halbjährlich, sondern jährlich. Meiner Erfahrung nach haben die Distributionen mit den stark verkürzten Upstream Supportzeiten schon ihre Probleme. Debian bekam Iceweasel ja zeitweilig kaum noch sicher und das ist ein Programm und nicht eine ganze Programmsammlung wie KDE.

Mr.Gerard.Cruiz schrieb:

Mir kann niemand erzählen, dass das ohne jede Mitwirkung der KDE-Entwickler effektiv gepflegt wird.

Wer behauptet das denn? Schau dir z.B. bei Debian die changelogs der aktuell verwendeten KDE-Pakete an. Da findest du öfter Patches, die aus Upstream-Paketen kamen.

Debian bekam Iceweasel ja zeitweilig kaum noch sicher

Mehr Details bitte. Ich verwende Debian seit Sarge, muss wohl an mir vorbei gegangen sein...

Ich habe nicht gesagt, dass sie es nicht geschafft haben aber es war ein enormer Aufwand um Iceweasel sicher zu halten und das wurde so auch innerhalb der Community kommuniziert. Muss wohl an dir vorbei gegangen sein...

Betreffend KDE. Nur ein kleiner Auszug: kdebase hat sein letztes Update Januar 2011 erhalten, andere Pakete noch früher. Mal selbst schauen? http://packages.debian.org/search?suite=squeeze-updates&section=all&arch=any&searchon=names&keywords=kde

Ich sage nicht, dass nichts gefixt wird aber Upstream werden deutlich mehr Bugs behoben, als zur Distribution durchsickern und die Bugs sind bei KDE nicht erst alle nach 4.4 eingezogen.

Beim Kernel klappt die Zusammenarbeit zwischen den Kernelentwicklern und den einzelnen Distributionen erstaunlicherweise sehr gut. Die LTS-Kernel entstanden ja aus einer gewissen Tradition. Wieso nicht auch bei anderen Projekten?

Mr.Gerard.Cruiz schrieb:

Betreffend KDE. Nur ein kleiner Auszug: kdebase hat sein letztes Update Januar 2011 erhalten, andere Pakete noch früher.

Schau dir bitte mal die ausstehenden Bugs an. Da ist nicht ein sicherheitsrelevanter dabei, und darum ging es dir ja wohl.

Mal selbst schauen? http://packages.debian.org/search?suite=squeeze-updates&section=all&arch=any&searchon=names&keywords=kde

Habe ich vorher schon getan, aber nicht mit unbrauchbaren Links.

Ich sage nicht, dass nichts gefixt wird aber Upstream werden deutlich mehr Bugs behoben, als zur Distribution durchsickern und die Bugs sind bei KDE nicht erst alle nach 4.4 eingezogen.

Es geht darum, Sicherheitsupdates zu liefern. Nicht darum, jeden erdenklichen no so kleinen Darstellungsbug etc. zu fixen.

Okay wir reden vollständig aneinander vorbei. Es ging mir immer um Bugs und nicht um Securityfixes. Unter Linux haben wir die paradoxe Situation, dass man für Bugfixes immer die neueste Version braucht bzw. eigentlich ein Rolling Release, was aber immer neue Instabilitäten zur Folge hat. Stable bedeutet bei den meisten Distributionen momentan nur, dass der Bug-Stand stabil ist (und bleibt). Deshalb meine Frage ob es mehr LTS Releases upstream geben müsste, die sich auch mit Bugs auseinander setzen.

@Mr.Gerard.Cruiz

wie tomtomtom hier schon geschreiben hat, gibts durchaus Distries, die ein anderes Release-Modell haben, als Debian und Ubuntu.

Zwischen den vier Abstufungen findet man noch ein paar Distries, die von Haus aus "mischen". Also bei Sicherheitsrelevanten Bugs nicht patchen, sondern die neueren Versionen via Repo verteilen (zumindest bei den Paketen, die nicht aus dem Kernsystem sind und wo das möglich ist).

Bei den großen Distries (aber nicht nur da) gibts so gut wie immer Quellen, die inofizielle Backports für den neuesten Upstream anbieten. Bei Ubuntu z.B. via Launchpad-PPAs.

Und die Möglichkeit, sich seine Pakete selber zu bauen (oder an der Paketverwaltung vorbei zu installieren) gibts immer. Das ist natürlich aufwändiger, als zu sagen "Hey, ihr Distrie-Typen, macht mal bitte so, wie ich das will, mir doch egal, ob das andere auch so wollen." (Das soll jetzt kein Angriff auf dich sein).

Ab einer gewissen Abhängzeit des Basissystems funktionierts dann aber oft auch nicht mehr, weil z.B. Upstream schon auf neuere Bibliotheken setzt, die das Basissystem aber nicht hat. Bei dem Anspruch landet man früher oder später aber sowieso bei einer Rolling-Release-Distrie.

Und das Problem, warum es so wenig Software-Projekte gibt, die sich eine lange gepflegte Stable-Version leisten ist schlicht fehlende Man-Power.

Ich bin mir über die Alternativen schon im klaren.

Ich frage mich halt, weshalb die Distributionen es nicht hinkriegen sich mit den wichtigsten Upstream-Projekten zu koordinieren. Letztlich ist es ja schon das Ziel der Distributionen eine möglichst fehlerfreie Version auszuliefern. Beim Kernel klappt das ja auch. Hier setzen viele Distributionen (ja nicht durch Zufall) dieselbe Version ein und arbeiten an der Rückportierung der Patches. Im "Nachruf" für 2.6.32 wurde das ausdrücklich gewürdigt.

Letztlich werden von den Benutzern oft Probleme bemängelt, die upstream behoben wurde (dazu muss man ja nur hier im Forum lesen). Wie oft muss man lesen, Nepomuk / Strigi einfach abschalten, funktioniert eh nicht. In KDE 4.8 funktioniert das aber dank diverser Bugfixes im letzten halben Jahr sehr gut, nur liefert das quasi keine Distribution offiziell aus und die Patches wurden auch nicht zurückportiert.

Naja ist wohl die leidige Frage für wen entwickelt wird, für die Benutzer oder die Entwickler.

Mr.Gerard.Cruiz schrieb:

Ich bin mir über die Alternativen schon im klaren.

Das war in der Deutlichkeit (für mich) nicht zu erkennen.

Ich frage mich halt, weshalb die Distributionen es nicht hinkriegen sich mit den wichtigsten Upstream-Projekten zu koordinieren. Letztlich ist es ja schon das Ziel der Distributionen eine möglichst fehlerfreie Version auszuliefern. Beim Kernel klappt das ja auch. Hier setzen viele Distributionen (ja nicht durch Zufall) dieselbe Version ein und arbeiten an der Rückportierung der Patches. Im "Nachruf" für 2.6.32 wurde das ausdrücklich gewürdigt.

Der Kernel ist ja auch `die Komponente. Bei anderen Programmen siehts schon anders aus, selbst bei so Sachen wie z.B. den core-utils oder ähnlich wichtigen Programmen. Da wird nicht nur nicht die gleiche Version benutzt, sondern gerne auch mal ein Klon/konkurierende Version. Siehe mawk/gawk oder vim/vi/elvis, cron/anacron, usw. Wenn man dann noch die verschiedenen init-Versionen hinzuzieht, wirds uferlos :) Alleine zu sagen, was die wichtigsten Upstream-Projekte sind, ist schwierig. Die großen Desktops, ok. Aber die sind auch nur wichtig, wenn man sie dabei hat. Was interessiert eine Distrie, die Xfce als Haupt-DE hat, wann KDE einen Milestone raushaut? Dann haben die auch noch alle abweichende Releasezyklen (wenn sie nicht "it´s done, when it´s done" haben, was ich für das vernünftigeste halte btw.). Das wäre also der Quadratur des Kreises sehr nahe, was du verlangst. Wenn dann ein Projekt kurz vor dem eigentlichen Releasetermin einen Showstopper entdeckt, was soll es machen? Den Termin einhalten oder doch erst releasen wenn der gefixt ist? Und was machen dann die "gleichgeschalteten" Distries? Auch verschieben?

Letztlich werden von den Benutzern oft Probleme bemängelt, die upstream behoben wurde (dazu muss man ja nur hier im Forum lesen). Wie oft muss man lesen, Nepomuk / Strigi einfach abschalten, funktioniert eh nicht. In KDE 4.8 funktioniert das aber dank diverser Bugfixes im letzten halben Jahr sehr gut, nur liefert das quasi keine Distribution offiziell aus und die Patches wurden auch nicht zurückportiert.

Gentoo, Arch, andere Distries mit Backports liefen es relativ kurz nach Release aus. Du hast eine zu sehr auf die Stable-Releases à la Ubuntu gerichtete Sicht.

Naja ist wohl die leidige Frage für wen entwickelt wird, für die Benutzer oder die Entwickler.

Du vergisst die Hauptkomponente, die Distributoren. Die sind für die Zusammenstellung verantwortlich, nicht die Entwickler. Und Upstream ist eben Upstream, die Software läuft eben erst nach gewisser Zeit des Testens auf Tauglichkeit bei den Distries in die Stabilen Versionen. Ich würde mich bedanken, wenn meine Distrie mir ungestestete Upstream-Shice in den Stable-Repos anbieten würde. Das wäre für mich ein Grund, mich nach einer anderen Distrie umzusehen.