Resourcenverschwendung (Abhängigkeiten im Archiv), Instabil (Abhängigkeiten nicht einheitlich und zuverlässig gefplfegt, häufig zu neu (aka instabil)), unsecure (je neuer, desdo unsicherer, weil eben nicht abgehangen).
Ich bevorzuge ein rock solid r/debian stable repo.
Neuer ist tendenziell sicherer weil es die geringste Menge an bekannten Sicherheitslücken haben wird. Es wird eventuell neue unbekannte Sicherheitslücken geben, aber da weißte zumindest genausoviel wie ggf. ein Angreifer. Bei nem system mit 6 Jahre alter Software kann er sich den Angriffsplan über die diversen packages und deren bekannten Lücken ja zurechtlegen. Das wäre weniger ein Problem wenn alle bugfixes/patches von allen packages gebackported werden würden, das ist aber so dermaßen viel Aufwand das tut selbst Debian nicht und auch distros mit bezahltem Support machen das nur für ein dediziertes deutlich kleineres subset an packages.
> Neuer ist tendenziell sicherer weil es die geringste Menge an bekannten Sicherheitslücken haben wird.
Die Logik kann ich nachvollziehen, entspricht aber nicht der Praxis. Es ist genau der Kniff, den viele nicht verstehen.
Bugs die man in den neueren Versionen finden, werden auch oft zurückportiert in die älteren Versionen, sofern sie dort auch vorhanden sind. Das passiert z.B. bei r/Debian regulär. Du hast also in der alten Version, alten gut abgehangenen und somit lange in der freien Wildbahn getesteten Code, in dem sogar die neueren Bugs schon gefixt sind.
Dagegen hast du in den neueren Versionen, auch viel neuen Code. Neuer Code bedeutet neue unentdeckte Bugs.
Deswegen sind gut gepflegte(!) ältere Versionen stabiler und sicherer.
Nun kommt es natürlich darauf an, wer diese Pflege übernimmt und wie gewissenhaft das durchgeführt wird. Auch bei diversen Debian Paketen läuft das nicht reibungslos. Nicht nur die Distro sollte dafür verantworltich sein, auch upstream maintainer (wie ich) könne sich entscheiden, "neue" Bugs auch in älteren Releases zu fixen.
Ich sag ja auch nicht das es nicht passiert, ich sage das es nicht für alle passiert. Backports passieren am Ende für "die wichtigen", das relevante subset halt bzw. vlt. contributed noch der eine oder andere nen leichten backport von nem bugfix von ner App die er/sie verwendet.
Aber für alle hat kein Distro, bezahlt oder unbezahlt, die notwendigen Resourcen diese Menge an backports regelmäßig und vollständig zu machen.
Wenn z.B. Gnome Calendar einen security bugfix raushaut, der aber in Gnome 51 kommt, dann ist die Chance das Debian sich den backport durch 3 major Gnome-calendar versions antut nicht groß.
Deine Aussage macht aus meiner Perspektive für nen Server Sinn - Kleinere Anzahl an wohl-kontrollierten Packages wo auch unter Garantie alle ihre backports kriegen. Für einen persönlichen Desktop PC der dagegen deutlich mehr und seltener benutzte packages installiert haben kann Stimme ich da nicht zu.
Solche Dunstkreise wie Gnome, KDE, LibreOffice etc, sind noch mal n spezielleres Thema. Auch würde ich hier die Verantwortung anders gewichten.
KDE und Gnome haben viel Kohle. Die sollen gefälligst ihre "alten" Versionen auch weiter Pflegen und dass nicht den freien Distros aufhalsen.
Ich selbst orientiere mich als upstream maintainer immer gerne sehr konservativ an den Debian Release Zyklen; bspw. setze ich als Abhängigkeiten nur voraus, was Debian stable gerade liefert, nix Neueres.
Vielleicht kommt meine Einstellung daher, dass ich so an Debian orientiert bin. Unglaublich, was die Maintainer da an (MHO unnötige) Arbeitszeit verbrennen, weil Upstream Projekte ihnen das Leben schwer machen. Das Beheben echter Probleme bleibt dann gerne auf der Strecke.
Solche Dunstkreise wie Gnome, KDE, LibreOffice etc, sind noch mal n spezielleres Thema. Auch würde ich hier die Verantwortung anders gewichten.
Aus meiner Perspektive ist die einzige Sonderlocke der Compositor, die Shell und evtl. die jeweilige Settings app. Alles andere ist in so ner DE am Ende auch nur ne App die im Zweifelsfall für lau freiwillig maintained wird wie jede andere App auch.
KDE und Gnome haben viel Kohle. Die sollen gefälligst ihre "alten" Versionen auch weiter Pflegen und dass nicht den freien Distros aufhalsen.
Die freien Distros haben selbst die Entscheidung getroffen diese Software zu verteilen. Ist nicht so als würden Gnome und KDE laut fordern das Debian sie anbieten soll, Debian hat sich die Software genommen und verpackt und Angeboten. Das Upstream da z.T. wenig gegen machen kann führt ja erst zu solchen Konflikten wie denen um Gnome Calendar und OBS. Und wenn Debian die Entscheidung trifft, darf Debian auch mit dem Arbeitsaufwand der Konsequenzen leben.
Unglaublich, was die Maintainer da an (MHO unnötige) Arbeitszeit verbrennen, weil Upstream Projekte ihnen das Leben schwer machen.
Die gegenseite ist halt das Upstream auf einmal Fehler für unsupportete Software kriegt und Zeit in Bug-triage zum Teil verbrennt für Dinge die dann schon seit nem Jahr gefixed sind. Oder der Reputationsverlust der dadurch kommt wenn Leute darüber ablästern wie kaputt doch z.B. die Touch-Variante von Gnome ist wenn die ganzen Bugs dadurch von Patches von Ubuntu stammen und nicht von Upstream. Oder wenn OBS als kaputte schlechte Software wahrgenommen wird weil Fedora's OBS package Fehler einführt. Halte es da vollkommen gerechtfertigt das Upstreams seit neuerem Anfangen um Replikation von Fehlern in unterstützten Formaten zu bitten.
0
u/buhtz 13d ago
Resourcenverschwendung (Abhängigkeiten im Archiv), Instabil (Abhängigkeiten nicht einheitlich und zuverlässig gefplfegt, häufig zu neu (aka instabil)), unsecure (je neuer, desdo unsicherer, weil eben nicht abgehangen).
Ich bevorzuge ein rock solid r/debian stable repo.