Ich denke der Ansatz von Debian ist heute einfach nicht mehr zeitgemäß.
Ich denke Stabilität kommt bei Systembetreuern nie aus der Mode. Neue Versionen bedeuten oft auch Konfigurationsänderungen oder das irgendwelche Abhängigkeiten kaputt gehen. Wenn einem das System mit jedem Update um die Ohren fliegt dann macht man irgendwann keine Updates mehr.
Die Software ist schon bei der Veröffentlichung steinalt und dementsprechend ist auch die Sicherheit nicht mehr gewährleistet.
So alt ist sie nun auch wieder nicht. Bis kurz vor dem Freeze werden noch neue Versionen eingepflegt. Danach werden aber sicherheitsrelevante Patches zurück portiert. Entsprechend ist diese "alte" Software genau so sicher wie aktuelle Software. Teilweise sogar sicherer. Ich denke da an sowas wie Heartbleed. Die OpenSSL Version die in Debian 6 vorhanden ist war überhaupt nicht anfällig für das Problem. Nur die neuere OpenSSL von Debian 7 musste dann mit einem Sicherheitpatch gefixt werden. Es ist überhaupt nicht selten das neue Funktionen auch neue Fehler enthalten.
Zumindest für Desktopanwendungen sollte es ein Umdenken geben und hier die jeweils aktuelle Version ausgeliefert werden, damit man sicher über die Releaselebensdauer kommt.
Wenn du die Debconf 17 verfolgt hast dürfte dir das Thema Flatpak aufgefallen sein. Das wäre ein Ansatz um eine Mischung aus stabiler Basis und neuem Desktop zu bekommen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 14. Aug 2017 um 12:13.
Ich denke Stabilität kommt bei Systembetreuern nie aus der Mode. Neue Versionen bedeuten oft auch Konfigurationsänderungen oder das irgendwelche Abhängigkeiten kaputt gehen. Wenn einem das System mit jedem Update um die Ohren fliegt dann macht man irgendwann keine Updates mehr.
Hier ist schon der erste Trugschluss. Mit Stabilität hat das ganze nicht zu tun, denn dann müsste man auch Bugfixes einspielen, was nicht passiert. Zudem sprach ich explizit vom Desktop, denn den liefert Debian ja auch mit aus.
So alt ist sie nun auch wieder nicht. Bis kurz vor dem Freeze werden noch neue Versionen eingepflegt. Danach werden aber sicherheitsrelevante Patches zurück portiert. Entsprechend ist diese "alte" Software genau so sicher wie aktuelle Software. Teilweise sogar sicherer. Ich denke da an sowas wie Heartbleed. Die OpenSSL Version die in Debian 6 vorhanden ist war überhaupt nicht anfällig für das Problem. Nur die neuere OpenSSL von Debian 7 musste dann mit einem Sicherheitpatch gefixt werden. Es ist überhaupt nicht selten das neue Funktionen auch neue Fehler enthalten.
Doch sie ist alt, teilweise sogar sehr alt um nicht zu sagen antik. Vom Freeze bis zur finalen Veröffentlichung vergeht bei Debian aber viel Zeit, da erscheint schon noch die ein oder andere neue Browserversion. Ich halte die alte gepatchte Software zudem nicht für sicherer aus den im ersten Post von mir genannten Gründen. Firefox ist hier das Paradebeispiel wie man es nicht machen sollte.
Meiner Meinung nach sollte man soweit wie möglich auf ESR-Versionen setzen und dann die Fixes auch aus dem Hauptzweig einspielen. Genauso wie man bei anderen Desktopanwendungen zumindest die Minorversionen als Updates bereitstellen sollte. Dort ändern sich auch keine Configs, was im Desktopbereich ohnehin keine große Rolle spielt.
Diese ganzen Containerformate halte ich ebenfalls für kritisch, da sie an der Idee der geteilten Bibliotheken vorbei geht und dann überhaupt niemand mehr weiß in welchem Paket nun anfällige Versionen irgendwelcher Bibliotheken verpackt sind. Dann lieber an zentraler Stelle für alle Anwendungen patchen.
Hier ist schon der erste Trugschluss. Mit Stabilität hat das ganze nicht zu tun, denn dann müsste man auch Bugfixes einspielen, was nicht passiert.
Wir reden hier von zwei verschiedene Arten von Stabilität. Du meinst das die Software keine Abstürze hat oder sonstige nervige Bugs die aber nicht Sicherheitsrelevant sind. Ich meine damit das die Distribution als solches über einen längeren Zeitraum im großen und ganzen unverändert ist und das Updates keine inkompatiblen Änderungen rein bringen.
Zudem sprach ich explizit vom Desktop, denn den liefert Debian ja auch mit aus.
Auch auf dem Desktop kann Versionsstabilität in bestimmten Umgebungen von Vorteil sein. In Unternehmen willst du z.B. das die Desktops in der Regel alle identisch sind und das auch hier keine großen Überraschungen warten. Hunderte oder tausende von Arbeitsrechnern zu administrieren ist was anderes als beim privaten PC. Es hat durchaus seinen Grund warum Unternehmen meistens 2 Versionen hinter dem aktuellen Windows her hängen.
Zudem gibt es mit Debian Testing auch die Möglichkeit von etwas das man mit einem Rolling Release vergleichen kann. Sofern kein Freeze vorhanden ist fließen ständig Updates mit neuen Versionen in den Testing Zweig.
Wir reden hier von zwei verschiedene Arten von Stabilität. Du meinst das die Software keine Abstürze hat oder sonstige nervige Bugs die aber nicht Sicherheitsrelevant sind. Ich meine damit das die Distribution als solches über einen längeren Zeitraum im großen und ganzen unverändert ist und das Updates keine inkompatiblen Änderungen rein bringen.
Es sit aber extrem nervig, wenn die mitgelieferte Version Bugs hat und die nicht behoben werden. Es wird zudem bei den meisten Programmen zwischen Bugfixversionen und denen die neue Funktionen bringen unterschieden. man kann sich ja mal die Versionsstände von Debian 8 anschauen kurz bevor 9 erschien. Da ist schon sehr altes Zeug dabei.
Auch auf dem Desktop kann Versionsstabilität in bestimmten Umgebungen von Vorteil sein. In Unternehmen willst du z.B. das die Desktops in der Regel alle identisch sind und das auch hier keine großen Überraschungen warten. Hunderte oder tausende von Arbeitsrechnern zu administrieren ist was anderes als beim privaten PC. Es hat durchaus seinen Grund warum Unternehmen meistens 2 Versionen hinter dem aktuellen Windows her hängen.
Sicher hat das seine Vorteil aber auch sehr viele Nachteile. Letztlich musst du darauf vertrauen, dass der Maintainer alle kritischen Lücken akribisch nachpflegt und selbst, wenn er das täte, ist er immer noch davon abhängig, dass auch der Entwickler alle geschlossenen Lücken sauber dokumentiert. Gerade letzteres passiert aber nicht immer. Zum einen, weil vielleicht gar nicht direkt klar ist, dass der behobene Bug auch als Sicherheitslücke missbraucht werden kann (siehe Debian und die längst gefixte Imagemagick-Lücke) oder weil der Entwickler Angreifer nicht zusätzlich darauf Aufmerksam machen will oder was weiß ich. Bisher konnte mir zumindest noch niemand plausibel erklären, warum Minorbugfix-Releases der Entwickler nicht direkt bereitgestellt werden.
Bisher konnte mir zumindest noch niemand plausibel erklären, warum Minorbugfix-Releases der Entwickler nicht direkt bereitgestellt werden.
Könnte daran liegen, dass Bugfix-Releases idR ohnehin 1:1 durchgereicht werden. Du glaubst doch nicht ernsthaft, dass sich ein Maintainer diese heiden Arbeit mit Backports macht wenn es nicht zwingend erforderlich ist. Backports werden nur dann gemacht wenn der Entwickler mal wieder seine 5 Minuten hatte und eine eindeutige Verhaltensänderung als Bugfix umdeklarieren wollte oder ein Versionsstrang sein EOL durch den Entwickler erreicht.
Bisher konnte mir zumindest noch niemand plausibel erklären, warum Minorbugfix-Releases der Entwickler nicht direkt bereitgestellt werden.
Sehr einfach. Man kann sich bei tausenden Paketen nicht darauf verlassen das nicht doch irgendwo in dem Minor Bugfix nicht doch irgendwas verändert wurde über das man dann stolpert.
Das klassische Versionsschema war immer Major.Minor.Patchlevel. Dabei sollten sowohl bei Patchlevel als auch Minor keine Inkompatiblen Änderungen enthalten.
Aber wie ich aus Erfahrung mit PHP Versionen weiß stimmt das nicht immer. Der Sprung von PHP 5.3 auf 5.4 war einer der extremsten die ich je gesehen habe, obwohl es nur ein "Minor" Sprung lt. Versionnummer war. Eine Menge Skript mussten angepasst werden da nichts mehr funktionierte. Bei PHP gab es auch Änderungen die nur als Bugfix Releases veröffentlicht wurden aber trotzdem dafür gesorgt haben das bestimmte Skript nicht mehr funktioniert haben.
Allerdings scheinen die Paketmaintainer von PHP auch schon langsam die Nase voll zu haben davon das die Entwickler Sicherheitspatches und andere Bugfixes nicht sauber trennen können. Daher werden die Patchlevel Releases bei PHP direkt durchgereicht.
Und auch bei einiger anderer Software werden Versionsänderungen durchgereicht da der Aufwand zu groß ist alles nach Sicherheitspatches zu durchleuchten.
Ich denke Stabilität kommt bei Systembetreuern nie aus der Mode. Neue Versionen bedeuten oft auch Konfigurationsänderungen oder das irgendwelche Abhängigkeiten kaputt gehen. Wenn einem das System mit jedem Update um die Ohren fliegt dann macht man irgendwann keine Updates mehr.
So alt ist sie nun auch wieder nicht. Bis kurz vor dem Freeze werden noch neue Versionen eingepflegt. Danach werden aber sicherheitsrelevante Patches zurück portiert. Entsprechend ist diese "alte" Software genau so sicher wie aktuelle Software.
Teilweise sogar sicherer. Ich denke da an sowas wie Heartbleed. Die OpenSSL Version die in Debian 6 vorhanden ist war überhaupt nicht anfällig für das Problem. Nur die neuere OpenSSL von Debian 7 musste dann mit einem Sicherheitpatch gefixt werden. Es ist überhaupt nicht selten das neue Funktionen auch neue Fehler enthalten.
Wenn du die Debconf 17 verfolgt hast dürfte dir das Thema Flatpak aufgefallen sein. Das wäre ein Ansatz um eine Mischung aus stabiler Basis und neuem Desktop zu bekommen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 14. Aug 2017 um 12:13.Zudem sprach ich explizit vom Desktop, denn den liefert Debian ja auch mit aus.Doch sie ist alt, teilweise sogar sehr alt um nicht zu sagen antik. Vom Freeze bis zur finalen Veröffentlichung vergeht bei Debian aber viel Zeit, da erscheint schon noch die ein oder andere neue Browserversion. Ich halte die alte gepatchte Software zudem nicht für sicherer aus den im ersten Post von mir genannten Gründen. Firefox ist hier das Paradebeispiel wie man es nicht machen sollte.
Meiner Meinung nach sollte man soweit wie möglich auf ESR-Versionen setzen und dann die Fixes auch aus dem Hauptzweig einspielen. Genauso wie man bei anderen Desktopanwendungen zumindest die Minorversionen als Updates bereitstellen sollte. Dort ändern sich auch keine Configs, was im Desktopbereich ohnehin keine große Rolle spielt.
Diese ganzen Containerformate halte ich ebenfalls für kritisch, da sie an der Idee der geteilten Bibliotheken vorbei geht und dann überhaupt niemand mehr weiß in welchem Paket nun anfällige Versionen irgendwelcher Bibliotheken verpackt sind. Dann lieber an zentraler Stelle für alle Anwendungen patchen.
Browser und weitere Webanwendungen werden bei Debian aus Sicherheitserwägungen öfter aktualisiert als der Rest (zumindest bei den Point Releases).
Wir reden hier von zwei verschiedene Arten von Stabilität. Du meinst das die Software keine Abstürze hat oder sonstige nervige Bugs die aber nicht Sicherheitsrelevant sind. Ich meine damit das die Distribution als solches über einen längeren Zeitraum im großen und ganzen unverändert ist und das Updates keine inkompatiblen Änderungen rein bringen.
Auch auf dem Desktop kann Versionsstabilität in bestimmten Umgebungen von Vorteil sein. In Unternehmen willst du z.B. das die Desktops in der Regel alle identisch sind und das auch hier keine großen Überraschungen warten. Hunderte oder tausende von Arbeitsrechnern zu administrieren ist was anderes als beim privaten PC. Es hat durchaus seinen Grund warum Unternehmen meistens 2 Versionen hinter dem aktuellen Windows her hängen.
Zudem gibt es mit Debian Testing auch die Möglichkeit von etwas das man mit einem Rolling Release vergleichen kann. Sofern kein Freeze vorhanden ist fließen ständig Updates mit neuen Versionen in den Testing Zweig.
Bisher konnte mir zumindest noch niemand plausibel erklären, warum Minorbugfix-Releases der Entwickler nicht direkt bereitgestellt werden.
Könnte daran liegen, dass Bugfix-Releases idR ohnehin 1:1 durchgereicht werden. Du glaubst doch nicht ernsthaft, dass sich ein Maintainer diese heiden Arbeit mit Backports macht wenn es nicht zwingend erforderlich ist. Backports werden nur dann gemacht wenn der Entwickler mal wieder seine 5 Minuten hatte und eine eindeutige Verhaltensänderung als Bugfix umdeklarieren wollte oder ein Versionsstrang sein EOL durch den Entwickler erreicht.
Sehr einfach. Man kann sich bei tausenden Paketen nicht darauf verlassen das nicht doch irgendwo in dem Minor Bugfix nicht doch irgendwas verändert wurde über das man dann stolpert.
Das klassische Versionsschema war immer Major.Minor.Patchlevel. Dabei sollten sowohl bei Patchlevel als auch Minor keine Inkompatiblen Änderungen enthalten.
Aber wie ich aus Erfahrung mit PHP Versionen weiß stimmt das nicht immer. Der Sprung von PHP 5.3 auf 5.4 war einer der extremsten die ich je gesehen habe, obwohl es nur ein "Minor" Sprung lt. Versionnummer war. Eine Menge Skript mussten angepasst werden da nichts mehr funktionierte. Bei PHP gab es auch Änderungen die nur als Bugfix Releases veröffentlicht wurden aber trotzdem dafür gesorgt haben das bestimmte Skript nicht mehr funktioniert haben.
Allerdings scheinen die Paketmaintainer von PHP auch schon langsam die Nase voll zu haben davon das die Entwickler Sicherheitspatches und andere Bugfixes nicht sauber trennen können. Daher werden die Patchlevel Releases bei PHP direkt durchgereicht.
Und auch bei einiger anderer Software werden Versionsänderungen durchgereicht da der Aufwand zu groß ist alles nach Sicherheitspatches zu durchleuchten.