Neben Linux Mint veröffentlicht das Team um Chefentwickler Clement »Clem« Lefebvre sporadisch auch die »Linux Mint Debian Edition« (LMDE). Deren dritte Ausgabe wurde, nach einer Beta-Version im Juni als LMDE 3 »Cindy« gerade in stabiler Version freigegeben. Die aktuelle Ausgabe baut auf dem derzeit stabilen Debian 9 »Stretch« auf und verwendet in der derzeit einzigen Variante das aktuelle Cinnamon 3.8.8 als Desktop-Umgebung.
Debian-Alternative
LMDE ist ein Nebenprojekt, das längst nicht so viele Anwender hat wie Linux Mint selbst. Aber für die Mint-Macher dient LMDE einem Zweck, wie Clem in der Ankündigung der Veröffentlichung erklärt. Für das gesamte Projekt ist es wichtig, neben dem auf Ubuntu LTS basierenden Mint eine Alternative zu pflegen, die auf Debian direkt basiert. Das könnte wichtig werden, sollte Ubuntu einmal nicht mehr als Basis verfügbar sein oder den Ansprüchen nicht mehr genügen.
Direkte Updates
Linux Mint Debian Edition erhält während seiner Laufzeit keine Punkt-Releases. Abgesehen von Bugfixes und Sicherheitskorrekturen bleiben die Debian-Basispakete unverändert, aber Mint-Tools und Desktop-Komponenten werden kontinuierlich aktualisiert. Neu entwickelte Funktionen werden direkt in LMDE integriert, während sie für die nächste kommende Linux-Mint-Version bereitgestellt werden.
Doppelt hält besser
Bei LMDE 3 experimentiert das Team ein wenig und liefert zwei Installer aus. Neben dem von Mint bekannten Live-Installer ist auch ein Installer auf der Basis des Calamares Installer Framework im Menü zu finden. Dabei bietet Calamares mehr Funktionen als der hauseigene Installer. Dazu gehören erweiterte Partitionierungsoptionen sowie die Möglichkeit, die Installation vollständig zu verschlüsseln.
Auch als 32-Bit
LMDE 3 steht in 32- und 64-Bit zur Verfügung. Um die Kompatibilität mit Nicht-PAE-Prozessoren zu gewährleisten, werden die 32-Bit-Versionen von Linux Mint Debian standardmäßig mit einem 686er Nicht-PAE-Kernel ausgeliefert. Für PAE-Unterstützung kann ein 686-PAE-Kernel installiert werden. Das gelingt als Root mit dem Befehl apt update && apt install linux-headers-686-pae linux-image-686-pae. Anschließend muss der Rechner neu gestartet werden. Weitere Änderungen können dem Changelog entnommen werden.
SUSE feierte vor rund einem Jahr den 25. Geburtstag, Slackware blickte vor wenigen Wochen auf ein Vierteljahrhundert Entwicklung zurück. Heute nun vor 25 Jahren kündigte Ian Murdock im Usenet auf comp.os.linux.development die bevorstehende Fertigstellung einer neuen Linux-Veröffentlichung an, der er den Namen Debian gab. Der Name setze sich aus seinem und dem Vornamen seiner Freundin Debra zusammen. Murdock hatte die damals erste Linux-Distribution Softlanding Linux System benutzt und war mit einigem unzufrieden. Nach einer Zeit der Erweiterung des Vorhandenen entschloss er sich, ein System »from scratch«, als von vorne zu erstellen. Debian 0.01 wurde dann am 15. September 1998 veröffentlicht.
Oldtimer ohne Chef
Heute ist Debian die älteste der großen Linux-Distributionen, hinter der kein Unternehmen steht. Die rund 1.000 freiwilligen Entwickler leiten die Distribution nach dem Prinzip der Do-okratie. Das bedeutet in etwa: »Wer macht, bestimmt«. Das verlängert zwar Entscheidungen oft über Gebühr durch nicht enden wollende Diskussionen. Aber bisher hält Debian an diesem Prinzip trotzt einiger heftiger Krisen, deren letzte die Entscheidung für Systemd brachte, fest.
Gut geregelt
Den Rahmenbedingungen dieses oft chaotisch wirkenden Haufens bieten einige Richtlinien. Der Debian-Sozialvertrag, der eine Vision der Verbesserung der Gesellschaft bietet, beinhaltet auch die Debian-Richtlinien für Freie Software (DFSG), die Anhaltspunkte dazu geben, welche Software als brauchbar angesehen wird. Ergänzt werden sie durch die Projektverfassung, die die Projektstruktur festlegt, und den Verhaltenskodex, der den Ton für die Interaktionen innerhalb des Projekts vorgibt.
Stable, Testing und Unstable
Debians aktuelle Veröffentlichung hört auf den Namen Debian 9 »Strech«. Alle Veröffentlichungen tragen Namen von Figuren des Films Toy Story, so auch das für nächstes Jahr erwartete Debian 10 »Buster«-. Viele Anwender nutzen aber auch einen der anderen Zweige Testung oder Unstable aka Sid, was nach dem Jungen benennt ist, dessen Lieblingsbeschäftigung das Zerstören von Spielzeug ist. Früher stimmte diese Analogie durchaus, heute ist das nach dem Rolling-Release-Prinzip operierende Unstable aber relativ zahm und mit ein wenig Linux-Kenntnissen gut zu benutzen.
Dementsprechend gibt es seit Jahren einige Distributionen wie etwa Siduction, Xanadu oder das auf Router und Firewalls spezialisierte VyOS, die Debian Unstable erfolgreich als Basis nutzen. Insgesamt gibt es über 300 Distributionen, die Debian als ihre stabile Basis benutzen. Darunter sind auch Knoppix, dass das Prinzip von Live-CDs populär machte und Ubuntu, das eine Zeitlang die vermutlich am häufigsten genutzte Distribution war.
Debian GNU Linux wird 25 50!
Bisher konnte sich Debian immer an die Gegebenheiten und Erfordernisse des Marktes anpassen. So wurde vor drei Jahren Langzeitunterstützung realisiert, wodurch Debian-Veröffentlichungen nun insgesamt fünf Jahre Support erhalten und damit für Unternehmen interessant bleiben. Es besteht deshalb kein Grund anzunehmen, dass Debian nicht auch die 50 vollmachen kann.
Linux-Mint-Projektleiter Clement Lefebvre gab heute die Verfügbarkeit der Beta-Version des kommenden »Linux Mint Debian Edition 3« mit dem Codenamen »Cindy« bekannt. Die kurz auch als LMDE bekannte Distribution will der Hauptausgabe Linux Mint so ähnlich wie möglich sein, beruht jedoch direkt auf Debian anstatt auf Ubuntu.
Solide Grundlage
Nachdem vor wenigen Wochen Linux Mint 19 »Tara« veröffentlicht wurde, konzentrierte sich das Team auf die noch für den Juli versprochene Herausgabe einer Beta-Version für LMDE 3 »Cindy«. LMDE 3 basiert auf Debian 9 »Stretch« anstatt auf Canonicals letzter Langzeitversion Ubuntu 18.04 LTS »Bionic Beaver«. LMDE 3 wird mit einem aktuellen Cinnamon 3.8 als Desktop-Oberfläche ausgeliefert.
Linux Mint Debian Edition erhält während seiner Laufzeit keine Punkt-Releases. Abgesehen von Bugfixes und Sicherheitskorrekturen bleiben die Debian-Basispakete unverändert, aber Mint-Tools und Desktop-Komponenten werden kontinuierlich aktualisiert. Neu entwickelte Funktionen werden direkt in LMDE integriert, während sie für die nächste kommende Linux-Mint-Version bereitgestellt werden. Das erklärte Lefebvre heute in der Ankündigung der Beta-Version.
Zwei Installer
Bei LMDE 3 experimentiert das Team ein wenig und liefert zwei Installer aus. Neben dem von Mint bekannten Live-Installer ist auch ein Installer auf der Basis des Calamares Installer Framework im Menü zu finden. Dabei bietet Calamares mehr Funktionen wie der hauseigene Installer. Dazu gehören erweiterte Partitionierungsoptionen sowie die Möglichkeit, die Installation vollständig zu verschlüsseln.
Experimentierstube LMDE
LMDE 3 hat wesentlich weniger Nutzer als Linux Mint, die aber wiederum weitaus enthusiastischer sind. LMDE dient Lefebvre und dem Team ein wenig als Experimentierstube und pflegt eine Alternative, falls Ubuntu als Unterbau einmal nicht mehr verfügbar sein sollte. Auf GitHub kann die weitere Entwicklung von Linux Mint Debian Edition 3 bis zur Veröffentlichung der fertigen Version verfolgt werden.
Debian 9.0 »Stretch« erschien am 16.6. 2017 und erhielt jetzt mit Debian 9.5 sein fünftes Punkt-Update. Debian 9.4 erschien Mitte März. Wie üblich bei Debian werden mit den Punkt-Releases über die Laufzeit einer Veröffentlichung Sicherheitsupdates verteilt und Fehler in Paketen behoben, wenn dies möglich ist, ohne Regressionen hervorzurufen.
Neuer Intel-Microcode
Debian 9.5 ist vergleichsweise groß ausgefallen und bringt 100 Sicherheits-Updates und 91 behobene Fehler in Paketen. Unter anderem erhält Debian 9.5 »Stretch« damit einen neuen Intel-Microcode mit der Versionsnummer 3.20180425.1~deb9u1, der auch Code zum Schutz gegen die Prozessor-Lücke Spectre v2 enthält. Neben der Auslieferung des neuen Kernel 4.9.110 und einem Update für den Debian-Installer wurden auch Pakete wie apache2, base-files, clamav, dpkg, reportbug und systemd von Fehlern befreit.
Sicherheit verbessert
Bei der Verbesserung der Sicherheit erhielt Firefox-ESR insgesamt sechs Security-Updates, unter anderem gefolgt von Xen mit vier und Thunderbird mit zwei Vorfällen. Weiterhin betroffen war auch hier der Webserver Apache2 ebenso wie WordPress Drupal7, Gnupg1 und 2. Alle Sicherheits-Updates wurden bereits in einem »Debian Security Advisory« (DSA) beschrieben.
Bitte aktualisieren
Insgesamt fassen die Debian-Punkt-Releases die Sicherheitsupdates und Fehlerkorrekturen seit dem jeweils letzten Punkt-Release zusammen. Anwender, die ihr System regelmäßig aktualisieren, haben die meisten Sicherheits-Aktualisierungen bereits erhalten. Ein Debian-Punkt-Release erfordert keine Neuinstallation des Systems. Die neuen Pakete können über die Paketverwaltung aktualisiert werden.
Frische Images
Erste aktualisierte Images für Anwender, die trotzdem eine neue Installation vornehmen möchten stehen auf den Download-Servern zur Verfügung, weitere werden in den nächsten Tagen folgen. Bis im nächsten Jahr die nächste Debian-Veröffentlichung Debian 10 »Buster« erscheint, werden vermutlich eine weitere Handvoll Punkt-Releases folgen.
RISC-V ist eine offene Befehlssatzarchitektur, die im Gegensatz zu den meisten anderen ISAs (Instruction Set Architecture) nicht patentiert ist und dank der BSD-Lizenz jedermann erlaubt, Mikroprozessoren damit zu entwerfen und zu vermarkten. Das US-amerikanische Unternehmen SiFive brachte im Oktober vergangenen Jahres mit dem U54-MC Coreplex eine erste RISC-V CPU auf den Markt, die mit einem 64-Bit Quadcore-Design erstmals auch Linux und BSD unterstützte. Im Februar 2018 gelang SiFive mit dem HiFive Unleashed die Schwarmfinanzierung des ersten Linux-tauglichen Entwicklerboards. Etwa zur gleichen Zeit wurde der Code von RISC-V in den Kernel 4.15 aufgenommen. Kernel 4.16 brachte Korrekturen, für den nächsten Kernel 4.17 wurden bereits weitere Patches eingereicht.
Debians RISC-V Port
Damit ist die Bahn für Distributionen frei, RISC-V als Architektur zu unterstützen, ohne einen eigenen Kernel-Zweig pflegen zu müssen. Debian kündigte nun offiziell einen solchen Port an, der unter dem Namen riscv64 läuft. In der Ankündigung erklärt Entwickler Manuel Fernandez Montecelo, dass bisher bereits mehr als 4.000 Pakete in der neuen Architektur verfügbar sind. Auf seiner Debian-Webseite veröffentlicht Montecelo den jeweiligen Stand des Projekts.
Hoffnungsträger RISC-V
Damit erhält Debian neben den derzeit unterstützten zehn Architekturen amd64, i386, arm64, armhf, armel, mips, mipsel, mips64el, ppc64el und s390x mit riscv64 eine weitere hinzu. Mit der anhaltenden Entwicklung von RISC-V bei Hardware und Software verbinden viele die Hoffnung, dass eine offene Architektur künftig ARM und anderen Architekturen ernsthaft Konkurrenz bieten kann.
Weiter Weg
Dafür sprechen der Wegfall von Lizenzgebühren und komplizierte Verträge, die hauptsächlich Anwälte reich machen. Die RISC-V-Foundation hat inzwischen über 130 Mitglieder, zu denen Google, HPE, IBM, Microsoft, Oracle, Nvidia, Qualcomm und viele andere gehören. Die Anfänge sind also gemacht, es ist jedoch noch ein weiter Weg.
Einige große Distributionen befinden sich seit geraumer Zeit im Umbau, um auf veränderte Herausforderungen in der IT zu reagieren. Sowohl Fedora als auch openSUSE haben sich in den letzten Jahren von Grund auf neu aufgestellt. Fedora teilte die Distribution in drei Teile für Desktop, Server und Cloud auf und arbeitet weiter an der Modularisierung. openSUSE verankerte Tumbleweed sehr erfolgreich als offizielle Rolling-Release-Variante und setzte obendrauf mit openSUSE Leap einen Hybriden, der sein Basissystem aus der Mutter-Distribution SUSE bezieht und den Rest aus Tumbleweed hinzufügt.
Debian unzufrieden
Jetzt scheint auch Debian an einem Punkt angelangt, an dem eine Kurskorrektur ansteht. Schon seit Jahren sieht sich Debian, eine der ältesten Distributionen am Markt, zunehmend in der Situation, hauptsächlich als Basis für einige Hundert Derivate zu dienen und seine ursprüngliche Ausrichtung zu verlieren. Auch die Einführung von länger unterstützten Veröffentlichungen, die für die Distribution ein Kraftakt war, konnte an der Situation nichts ändern. Während ein Teil der Entwickler die Positionierung als Basis für andere Distributionen als akzeptabel empfinden, scheint nun eine andere Fraktion die Oberhand zu gewinnen, die diesen Zustand nicht hinnehmen will.
Rolling Release als Lösung
Aus gut unterrichteter Quelle ist zu erfahren, dass Debian plant, die für Desktop-Nutzer oft etwas angestaubte Variante Stable, die bisher als einzige veröffentlicht wird, um eine weitere Veröffentlichung auf der Basis von Debian Unstable aka Sid zu bereichern. Das würde dann in etwa dem Entwicklungsmodell von openSUSE mit Tumbleweed oder Red Hat mit Fedora entsprechen. Zudem ist eine schmale Variante für Cloud und Container unter dem Begriff Debtainer angedacht.
Chance für Entwicklungsimpulse
das inoffizielleDebian Unstable wird zwar von vielen Entwicklern genutzt, dient auch etwa dem Derivat Siduction als Basis, hat aber insgesamt nicht die Verbreitung wie die eben genannten Beispiele der Mitbewerber. Debian erhofft sich von dem geplanten Schritt eine breitere Basis an Benutzern für die Rolling-Release-Variante und verbindet damit die Hoffnung auf neue Impulse für die Entwicklung. Wie die neue Ausrichtung technisch umgesetzt wird und wie die zusätzliche Arbeitslast geschultert werden soll ist noch nicht ausgearbeitet.Auch ein genauer Termin ist noch nicht festgelegt.
Kernel haben gemeinhin eine recht kurze Lebensspanne, die kaum über das nächste Release hinausreicht. Ein oder zweimal im Jahr greift sich Greg Kroah-Hartman einen Kernel heraus und lässt ihm eine Langzeitpflege von rund zwei Jahren angedeihen. In dieser Zeit erhält dieser Kernel Sicherheits-Updates und Fehlerbereinigung.
Kernel 3.2 noch gepflegt
Einige Maintainer pflegen Kernel auch über längere Zeiträume, ohne dass dazu feste Regeln bestehen. Der derzeit älteste noch offiziell gepflegte Kernel ist der von Debian-Entwickler Ben Hutchins gepflegte Kernel 3.2, der im Januar 2012 veröffentlicht wurde. Vor nicht allzulanger Zeit erst wurde die Pflege des Kernels 2.6.32 von 2009 eingestellt.
20 Jahre Support geplant
Das alles erscheint kurz gegenüber den Plänen einer Initiative, die Kernel über 20 Jahre pflegen möchte, über die Jonathan Corbet jetzt auf LWN berichtet. Dabei handelt es sich um die Civil Infrastructure Platform (CIP). Entwickler Yoshitake Kobayashi stellte das Konzept auf der kürzlich abgehaltenen Embedded Linux Conference 2018 in Portland, Oregon vor. Dabei geht es darum, eine stabile Tragschicht für zivile Infrastruktursysteme zu schaffen.
Andere Zeitskala
Die Infrastrukturen, auf die wir uns alle verlassen, einschließlich derjenigen für Transport, Energieerzeugung und vieles mehr, basieren auf Linux. Wenn diese Systeme ausfallen, entstehen sofort ernsthafte Probleme. Diese Art von Infrastruktur läuft auf einer anderen Zeitskala als eine typische Linux-Distribution. Die Entwicklungszeit, die allein für die Inbetriebnahme eines solchen Systems benötigt wird, kann bis zu zwei Jahrzehnte betragen, und das System selbst kann dann üblicherweise 25-60 Jahre in Betrieb bleiben.
Our civilization’s infrastructure runs on Linux
<em>Yoshitake Kobayashi</em>
Zuverlässigkeit, Robustheit und Sicherheit
Die Rechnersysteme, die diese Infrastrukturen unterstützen, müssen über lange Zeiträume funktionieren. Sie müssen auf industrietauglicher Software basieren, die in der Lage ist, das erforderliche Maß an Zuverlässigkeit, Robustheit und Sicherheit zu bieten. Aber auch in dieser konservativen Umgebung müssen diese Systeme stets auf dem aktuellen Stand der Technik sein. Bislang wurde die langfristige Unterstützung, die notwendig ist, um sie am Laufen zu halten, von einzelnen Unternehmen geleistet, ohne dass es zu gemeinsamen Anstrengungen kam, wie Kobayashi berichtet. Das hat diese Systeme zwar funktionsfähig gehalten, ist aber ein teurer Ansatz, der tendenziell hinter dem aktuellen Stand der Technik zurückbleibt.
Gemeinsam stärker
Der Weg zu einer Zusammenarbeit besteht darin, ein kollaboratives Framework zu schaffen, das industrietaugliche Software unterstützt und dabei so weit wie möglich mit den Entwickler-Communities zusammenarbeitet. Das ist die Rolle, für die das CIP geschaffen wurde. Derzeit unterstützen sieben Mitgliedsunternehmen die Initiative. Sie supporten das Projekt, indem sie direkt zu den Upstream-Projekten beitragen und Arbeiten finanzieren, die die Ziele des CIP vorantreiben.
SLTS-Kernel
CIP konzentriert sich derzeit auf die Erstellung einer Open-Source-Basisschicht, die aus einer kleinen Anzahl von Komponenten besteht, darunter der Kernel, die GNU C-Bibliothek und BusyBox. Die Distributoren sollen auf dieser Basis aufbauen können. Das Hauptprojekt im Moment ist die Erstellung des Super-Langzeit-Support-Kernels (SLTS), der hoffentlich mindestens zehn Jahre lang unterstützt werden kann. Wenn damit die Erfahrung mit extra langfristigem Support wächst, werden künftige Kernel auch längere Supportzeiten haben können. Der erste SLTS-Kernel basiert auf der 4.4 LTS-Version und wird von Ben Hutchings gewartet; die entsprechende 4.4.120-cip20-Version erschien am 9. März 2018.
Im Allgemeinen sehen die Richtlinien des Projekts vor, den stabilen Upstream-Versionen zu folgen, solange sie unterstützt werden. Backports von neueren Kerneln sind explizit erlaubt, aber sie müssen in der Hauptlinie liegen, bevor sie für einen SLTS-Kernel infrage kommen. Neue Kernel-Versionen werden alle vier bis sechs Wochen veröffentlicht. Es gibt eine explizite Richtlinie, die die Unterstützung für Out-of-Tree-Treiber aus dem Staging-Bereich des Mainline-Kernel-Trees ausschließt.
Anpassung an LTS-Auswahl
Alle zwei bis drei Jahre wird ein neues Major-Kernel-Release für den Super-Langzeit-Support ausgewählt. Das Projekt denkt derzeit darüber nach, welches Release die Basis für den nächsten SLTS-Kernel sein wird. Die Anpassung an die LTS-Auswahl von Greg Kroah-Hartman ergibt dabei den meisten Sinn. Bei einem Treffen auf dem Japan Open Source Summit im Juni wird diese Entscheidung getroffen werden.
Das Jahr-2038-Problem von EDV-Systemen könnte zu Ausfällen von Software im Jahr 2038 führen.« -<em> Wikipedia</em>
Zusammenarbeit mit Debian
Das Hauptaugenmerk von CIP-Core liegt bei der Erstellung von installierbaren Images, die aus einer kleinen Untermenge von Debian-Paketen und dem CIP-SLTS-Kernel bestehen. Der Code hierzu wird auf GitLab gepflegt. CIP arbeitet mit Debian zusammen, um eine Untermenge von Paketen längerfristig zu unterstützen, die Cross-Compilation zu verbessern und den Austausch von DEP-5-Lizenzinformationen zu verbessern.
Sicherheitszertifizierung angestrebt
Längerfristig strebt CIP eine Sicherheitszertifizierung nach IEC-62443 an. Das ist ein ehrgeiziges Ziel, das CIP nicht alleine erreichen kann. Das Projekt arbeitet an Dokumentationen, Testfällen und Tools, die hoffentlich bei einem Zertifizierungsantrag helfen werden. Ein weiteres Problem, das bei einem solchen Projekt auf dem Radar sein muss, ist das Jahr-2038-Problem, das derzeit eine harte Grenze setzt, wie lange ein Linux-System unterstützt werden kann. CIP arbeitet mit Kernel- und Libc-Entwicklern zusammen, um Lösungen in diesem Bereich voranzutreiben.
Am Wochenende hat die aktuelle, im Juni 2017 freigegebene Veröffentlichung des Debian-Projekts, Debian GNU/Linux 9 |»Stretch«, das vierte Punkt-Release erhalten. Zuletzt war Debian im Dezember 2017 auf Version 9.3 angehoben worden.
Wie üblich enthält auch das neue Punkt-Release hauptsächlich Sicherheits-Updates und Fehlerbereinigungen. Dabei liegt das Hauptaugenmerk darauf, mit der Beseitigung von Fehlern keine neuen Regressionen einzuschleppen.
Korrekturen von wichtigen Fehlern gab es unter anderem bei Clamav; bei Cups und beim Debian-Installer sowie bei Base-Files, Flatpak und Systemd. Der Kernel wurde auf 4.9.82-1+deb9u3 aktualisiert.
Sicherheitsupdates wurden unter anderem für Firefox, Thunderbird, Tor, Wireshark, OpenSSL und Transmission herausgegeben. Aus Sicherheitsgründen entfernt wurde beispielsweise die Bitcoin-Geldbörse Electrum, die nun von der Electrum-Website bezogen werden muss.
Insgesamt wurden in 88 Paketen Fehler behoben oder die Version angehoben. Sicherheitsaktualisierungen gab es bei 71 Paketen, die jeweils in einem »Debian Security Advisory« (DSA) beschrieben sind. Insgesamt fassen die Debian-Punkt-Releases die Sicherheitsupdates und Fehlerkorrekturen seit dem jeweils letzten Punkt-Release zusammen. Anwender, die ihr System regelmäßig aktualisieren, haben die meisten Änderungen bereits erhalten. Erste aktualisierte Images für neue Installationen stehen auf den Download-Servern zur Verfügung, weitere werden in den nächsten Tagen folgen.
Drei Monate nach 2018.1 erschien nun die zweite Veröffentlichung der auf Debian basierenden Rolling-Release-Distribution siduction für dieses Jahr. Wie den Release Notes zu entnehmen ist, wird siduction für die Desktop-Umgebungen KDE, LXQt, GNOME, Cinnamon, MATE, Xfce und Lxde herausgegeben. Dazu kommen zwei Varianten für Anwender, die sich ihr System nach den eigenen Vorstellungen einrichten möchten. Bringt die »Xorg« benannte Variante einen X.org-Stack und Fluxbox als Fenstermanager mit, so kommt »noX« ganz ohne X auf den Rechner und ermöglicht so größtmögliche Freiheit bei der Einrichtung des Systems.
Desktops satt
Siduction 2018.2 ist ein Schnappschuss von Debian Unstable vom 4. März, der mit einem Distributionskernel 4.15.7, X-Server 1.19.5 und systemd 237.4 ausgestattet ist. Der grafische Installer basiert auf dem Calamares Installer Framework. Zudem ist mit dem CLI-Installer ein zweiter Installer auf der Basis von Ncurses an Bord, der in den Varianten Xorg und noX auch die einzige Installationsmöglichkeit darstellt. Bei den veröffentlichten Desktop-Umgebungen steht KDE Plasma bei Version 5.12.2 und GNOME bei 3.26. LXQt wird als 0.12.0, Xfce als 4.12.4, Cinnamon mit 3.4.6 und MATE mit 1.20.0 ausgeliefert.
Meltdown und Spectre
Siduction hat von Anfang an sehr zeitnah die Patches zur Abschwächung der CPU-Sicherheitslücken Meltdown und Spectre in seine Kernel integriert. Auch der mit 2018.2 ausgelieferte Kernel 4.15.7 ist hierbei auf dem neuesten Stand. Um dem Anwender zu ermöglichen, den jeweiligen Schutz gegen die Lücken nachzuvollziehen wurde das Paket spectre-meltdown-checker integriert. Mit Root-Rechten aufgerufen, vermittelt es grafisch einen Überblick der implementierten Schutzmaßnahmen.
Weitere Neuerungen von siduction 2018.2 vermitteln die Release Notes. Die als Live-Medium ausgelegten Images der verschiedenen Desktops bieten die Spiegelserver des Projekts zum Download an. Am kommenden Wochenende kann man die Entwickler auf einem Stand bei den Chemnitzer Linux-Tagen antreffen.
Auf der Debian-Entwickler-Mailing-Liste wird seit einigen Tagen in dem Thread What can Debian do to provide complex applications to its users? ausgiebig über ein Problem diskutiert, das im Kern die saubere Paketierung von komplexen Anwendungen in Debian betrifft, die meist aus dem Bereich Web-Applikationen stammen. Dabei geht es beispielsweise um Applikationen. die auf die Plattform Node.js und deren Repository NPM setzen. Es ist nicht das erste Mal, dass Debian diese Probleme diskutiert, die im Endeffekt auch die eigene Relevanz in der Zukunft der Linux-Distributionen betreffen.
Debian diskutiert neue Entwicklungsmodelle
Die Welt der Software-Entwicklung verändert sich seit Jahren rapide außerhalb des Debian-Ökosystems. Ein aktueller Trend in der Software-Entwicklung ist die Verwendung von Programmiersprachen, oft interpretierte Hochsprachen, kombiniert mit der intensiven Nutzung von Drittanbieter-Bibliotheken und einem sprachspezifischen Paketmanager für die Installation von Bibliotheken durch Entwickler und den Systemadministrator, der die Software für die Produktion installiert. Dadurch werden Linux-Distributionen zunehmend umgangen.
Nicht kompatibel
Debians Richtlinien kollidieren hier häufig mit der gebotenen Aktualität bei dieser Art von Anwendung. Sicherheit ist dabei ein wichtiges Thema. Es wird in dem Thread unter anderem zu Recht bemängelt, dass Quelltext und Copyright-Informationen der in Web-Applikationen häufig verwendeten unzähligen JavaScript-Bibliotheken von Upstream oft nicht angegeben oder gar unbekannt sind, was in Debian prinzipiell unakzeptabel ist. Darüber hinaus werden JavaScript-Bibliotheken als Abhängigkeiten in solchen Anwendungen häufig aktualisiert, während in Debian noch eine ältere Version der Bibliothek Standard ist und somit die Anwendung bricht.
Viele Upstream-Entwickler solch komplexer Anwendungen ziehen es zunehmend vor, wegen der als restriktiv angesehenen Richtlinien nicht mit Debian zusammenzuarbeiten. Dabei geht es oft um Anwendungen, die neben JavaScript auf PHP, Python, Ruby oder Golang setzen. Die kurzen Supportzeiträume dieser Frameworks und Sprachen passen nicht mit Debians Philosophie zusammen. Ein weiteres Problem ist die Minifizierung, die neben CSS besonders bei JavaScript angewendet wird, um eine beschleunigte Ausführung des Codes zu erreichen. Dies ist aber nicht konform mit Debians Social Contract und ergibt im Ergebnis unwartbaren Quellcode. Deshalb sehen auch Debians FTP-Master und das Technical Comitee minifizierten Code als für Debian unbrauchbar an.
Weiterhin spielt das Thema Vendoring eine Rolle. Vendoring ist die Erstellung einer eigenen Kopie von Bibliotheken, die ein Upstream- Projekt verwendet. Diese Kopien werden traditionell in jedem Projekt platziert und dann im Projekt-Repository gespeichert. Gibt es in einer der Original-Bibliotheken ein Sicherheitsproblem, so wird die »vendored version« oft nicht oder viel zu spät aktualisiert. Auch das entspricht nicht Debians Richtlinien.
Debian-Paket oder externe Anwendung?
Das Dilemma, vor dem die Entwickler und Anwender hier stehen ist nicht leicht zu lösen. Fällt die Wahl auf das Debian-Paket einer Anwendung (sofern eins existiert), so kann meist die gebotene Aktualität, die bei Web-Anwendungen besonders wichtig ist, nicht gewährleistet werden oder die Anwendung bricht bei der Aktualisierung.
Als Alternative kann der Anwender auf die Upstream-Version zurückgreifen, bei der es gleich mehrere Unbekannte gibt. Sie wird meist mit einem eigenen Installer wie Pip im Fall von Python oder NPM für das allgegenwärtige Node.js. Diese Installer schaufeln Code auf die Rechner, der in keiner Weise einer Verifizierung unterliegt, wie das für Debian-Repositories der Fall ist. Andererseits handhaben diese Installer oft Hunderte von Abhängigkeiten, die ein Debian-Maintainer zeitlich gar nicht bewältigen kann.
Container oder Flatpaks
Welche Lösungen gibt es für diese Problematik? Und ist Debian flexibel genug, um mögliche Lösungen umzusetzen? Das sind Fragen, die nicht nur im Thread selbst, sondern auch in den Blogs der beiden Debian-Urgesteine Lars Wirzenius und Joey Hess aufgegriffen werden. Ein diskutierter Lösungsansatz ist die Verwendung von Containern oder Flatpaks innerhalb der Debian-Infrastruktur für solche Anwendungen. Denkbar wäre auch ein Repository für solche Pakete, ähnlich denen für contrib und non-free. Hier müsste klar vermittelt werden, dass für solch ein Repository keine Sicherheitsunterstützung gewährleistet wird.
Vision für die Zukunft?
Eine andere Möglichkeit wäre, Pakete in mehreren Versionen zuzulassen wie das beispielweise für C-Bibliotheken, GCC, Python und andere schon länger der Fall ist. Der Blick richtet sich zudem auf Distributionen wie NixOS, die nicht der traditionellen Verzeichnisstruktur des Filesystem Hierarchy Standard folgen. NixOS erlaubt mehrere Versionen einer Anwendung gleichzeitig, wobei jede Version der Anwendung ihre Dateien in einem eigenen Verzeichnis ablegt. Alle vorgebrachten Ideen drohen aber an der fehlenden Entwickler- und Betreuerzeit in Debian zu scheitern.
Das vorliegende Problem betrifft aber auch die Relevanz von Debian. So formuliert denn auch ein Entwickler:
[su_quote style=“flat-light“ cite=“Vincent Bernat“ url=“https://lists.debian.org/debian-devel/2018/02/msg00343.html“] I have the […] feeling Arch is taking away our desktop users, Ubuntu is taking away our cloud users, Alpine is taking away our container users and CoreOS/Atomic Host are taking away users interested by container orchestration solutions.[/su_quote]
Freie Software weiter tragfähig?
Tritt man etwas weiter zurück, so sieht es auf längere Sicht für Linux-Distributionen in ihrer jetzigen Form insgesamt nicht rosig aus. Viele junge Entwickler scheren sich nicht mehr um Werte wie Lizenzen, lesbaren und dokumentierten Quellcode oder nachvollziehbare Copyright-Angaben. Wenn allerdings das Modell der Distributionen nicht mehr tragfähig ist, worauf wollen Entwickler freier Software dann ihre Anwendungen laufen lassen?
