Wäre ein Ansatz wie bei Kali-Linux was für Debian?

[sys_op]

Nun, Kali ist zwar nicht meine Wahl, aber ein Ansatz in Kali 2.0 gefällt mir sehr!

Und zwar der, dass es angeblich in Zukunft keine neue Version von Kali mehr geben soll, sondern das System permanent auf einem neuen Stand gehalten werden soll. Wie das genau aussehen soll, keine Ahnung, aber wäre das nicht auch ein Ansatz für Debian, insbesondere Server?

Was spicht dagegen?

[uname]

Es wird wohl eine Art Rolling-Release sein. Mit etwas Glück braucht man dann wirklich nie wieder neu installieren, da das System fortlaufend aktualisiert wird ähnlich wie Debian Testing. Trotzdem wird Kali neue Versionen rausbringen müssen, da niemand nach 6 Monaten oder ein Jahr ein veraltetes Live-System haben will. Auch wird der Installer dann auf die aktuellsten Pakete zurückgreifen müssen. Wenn ich Kali entwickeln würde, würde ich Snapshot-Versionen rausbringen und sie nach dem Tag der Veröffentlichung benennen. Man kann an Ubuntu alles schlecht finden. Die Versionsnummern sind aber mit Jahr und Monat sehr sprechend.
Wobei für ein Live-System ist es nicht ganz so wichtig ob ungepachte Sicherheitslücken enthalten sind bzw. ob das System veraltet ist. Auf einem Server kannst du sowas natürlich vergessen, da ein Rolling-Release meist höchst unsicher und evtl. instabil ist. Und wenn doch dann installiere bitte Debian Testing auf deinen Server und nicht Kali mit Hunderten Anwendungen, die dein Server sowieso nicht braucht.

[rendegast]

Eine echte rolling-release sollte bzgl. Konfig-Transfer "stabil" arbeiten,
soweit sollte unbeaufsichtigtes automatisches Update wohl vorgesehen und gewährleistet sein.
(ala windows)

(debian) testing macht da schonmal Probleme, heißt schließlich "testing",
und die Upgrade-Flut nach Beendigung eines Freeze ist wohl nicht ohne.

[sys_op]

Dass man mich richtig versteht, meine Frage war eher allgemeiner Natur und rein theoretisch.

Auf Servern könnte man das ja Diensteweise abfragen, ob man updaten möchte oder nicht. Dann hätte man keinen Server, der bei einem Upgrade von jetzt auf gleich Probleme macht.

Ich stelle mir da zB vor, dass man bei einem Web und Fileserver zuerst den Apache upgraded und die anderen Dienste erst mal in Ruhe lässt. Läuft der Indianer wieder, kommt der nächste Dienst drann usw.

[uname]

Auf Servern könnte man das ja Diensteweise abfragen ...

Das wird nicht funktionieren, da die verschiedenen Dienste Abhängigkeiten zu den selben Basispaketen (z.B. libc6) haben werden, die evtl. für die Aktualisierung des Dienstes auch in der Version angehoben werden müssen. Der Betrieb der Basispakete gleichzeitig in beiden Versionen ist schon aufgrund der sehr wahrscheinlichen Namensgleichheit der Pakete technisch nicht möglich.

[Radfahrer]

...aber wäre das nicht auch ein Ansatz für Debian...

Gibt es doch. Nennt sich Testing und Unstable. OK, gibt zwar ab und zu einen Freeze aber kommt einem rolling release schon sehr nahe, besonders Unstable.

Gerade auf Servern möchte man aber doch gut getestete und bewährte Software haben. Und nicht ständig neue Versionen.
Ich denke, hier wäre ein rolling release keine so gute Idee. Ich würde so etwas jedenfalls nicht auf einem Server installieren.

Auf dem Desktop ist das was anderes. Da habe ich lange Zeit Debian Testing benutzt und jetzt seit kurzem Unstable.

[marfla]

Hm, an und für sich ist eine Rolling Release Distribution für den Endanwender prima. Das Problem ist halt nur, dass viele Rolling Release Distros auch wenn sie von einer großen und engagierten Gemeinschaft gehegt und gepflegt werden trotzdem für einen Systemcrash sorgen können.

Ein Beispiel: Ich hatte mal 6 Monate lang Arch Linux LXDE auf meinem alten HP Laptop am Laufen. Monatelang absolut ein Traum, tägliche Updates einzuspielen war nie auch nur annähernd problematisch, zumal pacman saumäßig schnell arbeitet.

Bis zu jenem verhängnisvollen Tag als durch ein Kernelupgrade mein System unbrauchbar wurde, da Booten absolut unmöglich bzw. "Kernel panic" ohne Ende. Nicht mal ein Live-System zu booten, dann zu mounten und den Kernel downzugraden war da noch möglich, ich kam gar nicht mal soweit.

Zusätzlich kam hinzu, dass wer den Schaden hat, sich um den Spott nicht zu sorgen braucht, - es hieß lapidar seitens der Community "Selber Schuld, hättest du Esel mal lieber die Veröffentlichungshinweise gelesen" etc.

Bei Debian Testing, welches eigentlich ein Semi-Rolling-Release ist, da ja ein Freeze vor Veröffentlichung der neuen Version des OS erfolgt passierte mir das nie, da es ja "apt-listbugs" gibt bzw. falls es mal passiert, schätze ich die Debian-Gemeinschaft reifer ein punkto Hilfe.

[DeletedUserReAsG]

[…] wäre das nicht auch ein Ansatz für Debian, insbesondere Server?

Insbesondere auf Servern will ich explizit kein rolling release. Upstream baut neue Features samt Bugs ein, entfernt Features, ändert mal fix die Syntax der Config oder gestaltet Schnittstellen so um, dass andere, davon abhängende, Software gegen die Wand fährt, etc. – nein, sowas möchte ich nicht. Ich möchte, dass die Software auf einem Versionsstand bleibt, bis ich nach zwei Jahren oder so einen Tag dafür einplane, es auf das nächste Release hochzuziehen und alle Configs in einem Abwasch anzupassen, um dann wieder zwei Jahre oder so einen fixen Versionsstand zu haben. Deswegen habe ich auf Servern und Co. schließlich auch Stable.

Würde man tatsächlich beschließen, Stable fortan auch rollend zu machen, würde ich mir wohl einfach Arch auf die Server ziehen. Dann fiele nämlich der große Vorteil der Stabilität weg, und es gäbe keinen Grund mehr, die Nachteile (persönliche Ansicht) von Debian inkaufzunehmen.

[rendegast]

Nachtrag(?)
debian testing darf auch nicht als rolling-release gesehen werden,
da ein solches aktive Maintainer haben sollte.

Ein böses Beispiel dazu ist das in testing/stretch/sid derzeit liegende und scheinbar nicht aktiv gewartete roundcube 1.1.1+dfsg.1-2, welches 2 kritische Sicherheitslücken beinhaltet.
(Unter jessie bekomme ich bei Installation Fehler bzgl. Erstellung der sqlite-Datenbank,
aber keine Nachricht von (letzte Hoffnung) debian-security-support wegen der Sicherheitslücken
(welches zBsp. bei webkitgtk oder xulrunner anschlägt).)

[schwedenmann]

Hallo

@marfla

Ein Beispiel: Ich hatte mal 6 Monate lang Arch Linux LXDE auf meinem alten HP Laptop am Laufen. Monatelang absolut ein Traum, tägliche Updates einzuspielen war nie auch nur annähernd problematisch, zumal pacman saumäßig schnell arbeitet.

Bis zu jenem verhängnisvollen Tag als durch ein Kernelupgrade mein System unbrauchbar wurde, da Booten absolut unmöglich bzw. "Kernel panic" ohne Ende. Nicht mal ein Live-System zu booten, dann zu mounten und den Kernel downzugraden war da noch möglich, ich kam gar nicht mal soweit.

Naja, egal ob stable, oder unstable ein backup ist Pflicht, also selber Schuld, hat nichts mit der community zu tun. Außerdem kannst du bei arch ein bak des images einstellen, ist nämlich nicht , wie bei debian, standardmäßig aktiviert, dann könntest du nämlich mit dem alten vmlinuz booten


mfg
schwedenmann