GLN016 - Linuxnews, Rolling Releases, Legacy Systeme, Haftung bei Datenverlust

  Ralf Hersel   Lesezeit: 11 Minuten  🗪 6 Kommentare

Shownotes der Folge 16 des GnuLinuxNews-Podcasts

Folge 16 des GnuLinuxNews-Podcasts, aufgenommen am 28. Oktober 2021.

In dieser Folge sprechen Ferdinand, Ralf und Lioh über 4 Jahre Linuxnews, das Für und Wider von Rolling Releases, über den Umgang mit Altsystemen und führen ein Interview mit Christian Laux über die Haftung bei Datenverlust in Behörden.

Für ein optimales Hörerlebnis, empfehlen wir eine Podcatcher-App zu verwenden. Zum Beispiel AntennaPod (Android) oder gPodder (Desktop) oder GNOME-Podcast (GNOME-Desktop).

Shownotes

Feedback

4 Jahre LinuxNews

  • erste Idee 2016

  • Nach 4 Jahren Schreibens für Pro Linux hatte ich das Bedürfnis nach einem weiteren Linux-Blog, das optisch einen anderen Weg einschlägt.

  • Zudem hatte ich zunehmend das Gefühl, dass die Betreiber Hans Joachim Baader und Mirko Lindner nach rund 20 Jahren verständlicherweise müde waren.

  • Grundlage war schnell klar: WordPress: nicht allzu viel Aufwand beim Administrieren, viele Erweiterungsmöglichkeiten über Plugins. Pro Linux basierte auf einem selbstgeschriebenen CMS, dass sich als recht aufwändig in der Unterhaltung erwies und in Zeiten zunehmender Smartphone-Formfaktoren nie responsiv gestaltet wurde.

  • Der Name war auch schnell klar, mein Blog sollte LinuxNews heißen. Ich war in der glücklichen Lage, für 230 Euro die Domain linuxnews.de erwerben zu können.

  • Los ging es am 1.9.2017. Ich schrieb News, wenn ich Lust und Zeit dazu hatte, mal 2 am Tag, mal 2 Tage keine.

  • Das ging so bis Ende Mai 2020, als Pro Linux seine Pforten nach 7643 Tagen und fast 30.000 Artikeln schloss. Ich wusste einige Wochen vorher Bescheid und konnte mich vorbereiten, einige der Leser von PL aufzunehmen. Das hieß für mich täglich mehrere News schreiben. Im September 2020 gab es einen Relaunch, der das Blog unter anderem auf mobilen Plattformen besser lesbar machte.

  • Zu der Zeit lief das Blog bei einem kleinen, auf WordPress spezialisierten Hoster, mit dem ich eigentlich zufrieden war und der dem Blog für 80 EUR im Jahr eine Heimat bot. Doch zunehmend wurde es schwieriger, das Blog dort zu betreiben, vor allem störte das PHP-Memory Limit, das auch beim nächstgrößeren Plan nicht entsprechend mitgewachsen wäre.

  • Also stand ein Umzug an. Angestrebt war ein Server unter meiner Kontrolle. Im Endeffekt fand sich mit Stefan ein netter Sys-Admin, der Platz für LinuxNews hatte und genügend Ressourcen auf Jahre hinaus bietet. Der Umzug fand im April 21 statt und ich bin mit der Lösung sehr zufrieden. Ich kann mich aufs Schreiben konzentrieren, Stefan kümmert sich bei Bedarf zeitnah um Serverprobleme.

  • Derzeit sind nach etwas über 4 Jahren 1.750 Beiträge veröffentlicht worden, wobei rund 50 von anderen Autoren stammen. Zudem sind über 11.000 Kommentare erstellt worden.

Rolling Releases

  • Bei einem Betriebssystem, das das Rolling-Release-Prinzip anwendet, gibt es keine Betriebssystem-Versionen, bei denen bei einem Versions-Upgrade eine grosse Menge an Software auf einmal aktualisiert wird. Die einzelnen Software-Pakete werden vielmehr kontinuierlich aktualisiert. Dies schliesst sogenannte Releases, also Veröffentlichungen des Betriebssystems, aber nicht aus; im Gegensatz zu einem Betriebssystem ohne Rolling Releases sind die Veröffentlichungen jedoch keine Versionen, sondern sogenannte Snapshots, das heisst eine Kopie aller im Moment im Repository liegenden Software-Versionen.

  • Diese Distributionen verwenden Rolling Releases:

    • Arch, Manjaro, Void LInux, Gentoo, Paldo, PCLinuxOS, Sabayon, Ubuntu Touch, openSUSE Tumbleweed, Siduction, Aptosid (ex Sidux), Xebian

  • Diese Distributionen verwenden getaktete Releases und liefern nur Sicherheits-Updates im Rolling Modus:

    • Ubuntu, Fedora, Mint, Pop!OS, Elementary, Zorin, Solus, ...

  • Eine Sonderrolle stellen die Freeze-Distributionen dar, bei denen es sich meist um den Entwicklungszeig handelt:

    • Debian testing, Fedora rawhide, Mandriva coocker, Slackware current

    • Im Laufe der Entwicklung des Betriebssystems wird der Entwicklerzweig „eingefroren“. Danach werden keine Software-Pakete mehr aktualisiert, sondern nur noch Fehler an diesen beseitigt. Sobald der Entwicklerzweig keine Fehler mehr enthält, die eine Veröffentlichung des Betriebssystems verhindern würden, wird der Entwicklerzweig als stabile Version veröffentlicht. Dabei verliert der Entwicklerzweig das Freeze-Stadium und die einzelnen Software-Pakete werden wieder wie vorher kontinuierlich aktualisiert.

  • Bei den Rolling Releases kann noch zwischen Semi-Rolling (oder curated rolling) und Continuous-Rolling unterschieden werden:

    • Arch Linux ist ein Beispiel für continuous rolling

    • Manjaro ist curated rolling. Es werden eigene Tests durchführt, bevor die Pakete ausgerollt werden. Das schafft eine grössere Sicherheit und höhere Stabilität.

  • LTS Releases (long term support):

    • Klassisches Beispiel dafür ist Ubuntu. Alle zwei Jahre erscheint ein LTS; alle sechs Monate ein Zwischenrelease.

  • Vor- und Nachteile

    • Rolling: aktuellere Software, grösseres Risiko für Probleme

    • Semi: aktuelle Software, ein wenig getestet, geringeres Risiko für Probleme

    • LTS: zwei Jahre lang Ruhe; Software nicht aktuell; Sicherheits-Updates kommen kontinuierlich.

  • Das Versprechen der Rolling Releases ist es, nie neu installieren zu müssen (was ich bezweifle).

  • Bei LTS ist zwar ein dist-upgrade grundsätzlich möglich, aber eher nicht zu empfehlen; besser frisch installieren.

  • Bei Distrowatch wird unterschieden zwischen: Fixed, Fixed (LTS), Semi-Rolling, Rolling:
    https://distrowatch.com/search.php#advanced

  • Empfehlung

    • Vorsichtige nehmen eine LTS-Distro und installieren alle paar Jahre neu.

    • Allen anderen empfehle ich ein curated-rolling Modell, wie z.B. Manjaro.

  • Debian Paketmanagement

And now the legacy begins

  • Sind Legacy Systeme ein Fluch, mit dem man leben muss? Bei Legacy Software handelt es sich um Systeme, die man eigentlich loswerden möchte, aber aus irgendwelchen Gründen weiter betreiben muss. Sei es, weil kein adäquater Ersatz vorhanden ist, oder weil der darauf betriebene Dienst auslaufen soll. Oftmals ist diese Software fehlerbehaftet und der Maintainer muss aufwändig Backports von Bugfixes erstellen.

  • Einige Distributionen wie Debian stable sind grundsätzlich Legacy Software. Falls funktionale Fehler nach dem Release gefunden werden, bleiben diese meist ungelöst. Nur Backports können eine Abhilfe schaffen. Was bedeutet das für den Maintainer? Zum Beispiel hat der Entwickler von xscreensaver sich zu einem Zeitpunkt geweigert, Fehler in alten Versionen der Software zu beheben.

  • Wie läuft ein Fehlermeldungsprozess bei solcher Software ab? Upstream Entwickler kümmern sich in der Regel nur um den neuen Scheiss. Wer ist dann für die Instandhaltung der alten Software verantwortlich? Der Distributionsbetreiber? Oder niemand?

Interview - Wer haftet bei Datenverlust in Behörden?

Tags

Rolling, Software, LTS, Releases, Linux, Podcast, Datenverlust, Behörde

👓
Geschrieben von 👓 am 3. November 2021 um 11:58

Ich habe hier eine Frage an die Linux Betriebsystem-Experten @Ferdinand und @Lioh:

(Ich möchte aber noch erwähnt haben, dass das unten von mir häufig genannte Overlayfs zu wenig kenne und nur ein Beispiel sein soll.)

Warum werden eigentlich moderne Techniken nicht auch bei Desktops angewendet? Bsp: Ein Stateless Basic Root System als eine Art Bootbars Image, dann mit Overlayfs wahlweise die Desktop Installation in minimal oder normal Ausführung und ebenfalls als Overlayfs die Konfigurationen die durch Root vorgenommen wurden. Dann könnte man bei Systemupdates einfach immer das Delta zu den jeweiligen Images aktualisieren und hätte nebenbei noch ein Image was alle von Root geänderten Einstellungen (nicht nur /etc aber auch da nur die geänderten daten) abbildet.

Für Applikationen die, nachdem Setup installiert werden, könnten apt und GUI ebenfalls ein eigenes Overlayfs nutzen und alle Software Modifikationen da wie gehabt hineinschreiben. Bei Rolling-Releases könnte man alle 4 Wochen ein neues Rootdelta erstellen und einfach zwischendurch die Updates in ein Rolling-Overlay speichern.

Für das Homeverzeichnis freue ich mich auf die Entwicklung von Homed. Alternativ könnte man auch da mit Overlayfs arbeiten.

Ich persönlich finde es im Home Verzeichnis zu chaotisch. Ich weiss aber nicht, ob man da viele Möglichkeiten hat, schliesslich entscheiden Apps selber wo sie was speichern. Bei Verwandten arbeite ich daher recht stark mit dem .hidden File im home Verzeichnis. Nur schon um das dofe snap Verzeichnis in Ubuntu für normale User auszublenden.

Lioh
Geschrieben von Lioh am 3. November 2021 um 18:01

Das Thema ist für eine der nächsten Podcast Folgen geplant.

👓
Geschrieben von 👓 am 3. November 2021 um 17:58

Kann es sein, dass ihr meinen Kommentar gelöscht habt?

Lioh
Geschrieben von Lioh am 3. November 2021 um 18:00

Nicht bewusst. Möglicherweise wurde er noch nicht freigeschaltet.

👓
Geschrieben von 👓 am 6. November 2021 um 09:50

Man sieht ja immer eine vorschau des Kommentars, plötzlich war der weg hatte mich irritiert.Sorry!

👓
Geschrieben von 👓 am 7. November 2021 um 17:50

Ich habe zu Arch eine Frage.

Müsste Arch nicht auch das kleinste System ergeben? Ich habe mal gelesen, das Debian alle kompilierten Programme in kleine Einzeldateien zerteilen, damit man diese im System möglichst flexibel nutzen und wiederverwerten kann. Während Debian über seine Quelltextdatenbank vermutlich für jede mehrfach verwendeten Quelltextblock eine eigene Datei schreiben muss, damit die User im System die Programme flexibel installieren und deinstallieren können, kann Arch sich das dann sparen und das auf den PCs der User erledigen und damit besser auf die Datenlage auf dem jeweiligen System anpassen. Wäre doch sicher auch für Programmierer einfacher, wenn sie Quelltexte aus dem Internet laden oder selber Programme schreiben, dann wird arch ja anhand der Quelltextdatenbank auch genau sagen können welche Quelltexte vielleicht schon wegen anderen Programmen mal kompiliert wurden und kann sich dann Kompilierarbeit und Dateigrösse sparen.