Ohne Systemd: Devuan 3.0 »Beowulf« veröffentlicht

Verfasst von

Devuan 3.0 »Beowulf« mit Xfce | Screenshot: ft

Zehn Jahre nach der Ankündigung von Systemd und rund ein Jahr nach Debian 10 »Buster« erscheint der Debian-Fork Devuan 3.0 »Beowulf«. Die Debian-Variante ohne Systemd setzt in der neuen Ausgabe auf Debian 10.4.

Init Freedom

Devuan (ausgesprochen als DevOne) wird seit 2014 von den »Veteran Unix Admins« (VUA) entwickelt. Das sind in der Hauptsache Franco »nextime« Lanza, der dyne:bolic-Entwickler Denis »jaromil« Roio und Daniel »Centurion« Reurich. Das Motto von Devuan lautet »Init Freedom« der nach Meinung der Entwickler bei Debian nicht gegeben ist. Damit haben sie nicht völlig unrecht, denn vor einem halben Jahr diskutierte Debian erneut über Systemd, da die Unterstützung für SysVinit und andere Init-Systeme immer mehr abnahm. Andererseits gibt es viele Distributionen und Projekte, die ohne Systemd auskommen.

Desktop-Auswahl

Erst 2017 konnte eine erste Version von Devuan freigegeben werden, die aber immer noch nicht alle Brücken zu Systemd kappen konnte. Vor zwei Jahren erschien Devuan 2.0 »ASCII« mit Xfce als Standard-Desktop und Plasma, Cinnamon, LXQt oder MATE als weitere Optionen.

Freie Wahl des Inits

Wie bei Debian 10 kommt auch bei Devuan 3.0 Kernel 4.19 zum Einsatz. Bei der Wahl des Init-Systems soll der Anwender bei Devuan nicht eingeschränkt werden. Neben SysVinit kann zwischen runit, sinit, OpenRC, s6 und shepherd gewählt werden. Anstelle von udev kommt eudev zum Einsatz, systemd-logind wird durch elogind ersetzt. Bootprozess, Display-Manager und Desktop erhielten neue Themes.

Breites Angebot

Devuan bedient neben i386 und amd64 auch die Architekturen armel, armhf, arm64 und ppc64el. Abbilder für die Installation als Live-Medium mit 1,2 GByte, als Netinstall mit rund 300 MByte, als Server- oder Desktop mit 670 MByte, respektive 4 GByte oder Minimal-Live mit 460 MByte stehen in 32- und 64-Bit auf den Spiegelservern bereit.

Abbilder für weitere Architekturen stehen auf dem FTP-Server des Projekts bereit. Anwender von Debian, die umsteigen möchten, finden eine Anleitung in der Dokumentation. Alle Änderungen zu Devuan 3.0 sind den Release Notes zu entnehmen.

Devuan

Kommentare

11 Antworten zu „Ohne Systemd: Devuan 3.0 »Beowulf« veröffentlicht“

2020-06-03

Andi

Heute habe ich mir Devuan Beowulf mit XFCE installiert – ich bin begeistert. Das neue Theme gefällt mir so gut, dass ich es nicht mal anpassen musste. Auch meinem T420 fällt das schnaufen nun leichter, free -m zeigt mir 280 an. Das Fedora XFCE wo vorher drauf war 630.

Antworten
2020-06-04

Jochen Geyer

> free -m zeigt mir 280 an. Das Fedora XFCE wo vorher drauf war 630.

Wenn du nun noch angibst, wie die Werte genau aussehen, können wir deine Aussage auch einordnen.

Antworten
2020-06-04

Andi

Was willst du denn noch für Werte? Der kurze Ramfresser Vergleich von einem frisch installierten Devuan xfce zu einem frisch installierten Fedora xfce – auf einem T420 – sollte genug aussagekräftig sein.

Antworten
2020-06-05

Nick

Immer noch eine massive Verschwendung von Zeit. Denn wenn man es auf die Basis herunter bricht, dann ist SysV (egal ob nun mit oder ohne OpenRC) nichts anderes als ein stupider Programmstarter, der auf rudimentären Abhängigkeiten zwischen den Diensten aufbaut, und nahezu vollständig von qualitativ sehr variablen Shellscripten abhängt. Sprich, ist letzteres nicht sauber programmiert (was nahezu immer so praktiziert wird/wurde), oder hat irgendeine andere Komponente der genutzten Toolchain in Wechselwirkung ein Problem, dann ist hier absolut alles an desaströsen Szenarien vorstellbar. Und nichts davon kann effektiv zur Laufzeit kontrolliert, analysiert oder auch nur irgendwie nachverfolgt oder gar gestoppt werden. Faktisch hat SysV nach dem Start eines Prozesses nicht den Hauch einer Ahnung was ab dann geschieht. War der Start erfolgreich? Wenn nicht warum nicht? Was macht ein Prozess im Detail zur gesamten Laufzeit? Welche Rechte hat ein Prozess und was für Ressourcen werden beansprucht? Verhält sich ein Prozess destruktiv und muss isoliert werden? Versucht der Prozess seine Privilegien auszuweiten, und wenn ja wie? Das ist nur ein kleiner Bruchteil dessen, was SysV nicht mal ansatzweise beantworten kann.

Mittels systemd läuft nichts ausserhalb eines kontrollierten Rahmens, da jede noch so unbedeutende Kleinigkeit geloggt wird, um auf Basis verfügbarer Informationen saubere Entscheidungen zu treffen. Darüber hinaus verzahnt systemd etliche lose Enden im System miteinander, um einerseits Kontrolle zu forcieren als auch die Kommunikation zwischen Komponenten zu verbessern/ermöglichen. Diverse Shellscripte die stupide seitens SysV abgefeuert werden, kommunizieren überhaupt nicht miteinander, noch wird auch nur ansatzweise darauf geachtet ob diese sich gegenseitig negativ beeinflussen. Auf Basis von systemd wäre dem anders.

Über systemd lassen sich auch unzählige Ressourcen für Programme einschränken, angefangen bei der Beschränkung verfügbarer CPU/RAM Ressourcen, bis hin zu fein definierbarem Sandboxing auf Basis des Linux-Kernel, welches besonders komfortabel via systemd nutzbar ist. Nicht zuletzt kann jeder Entwickler auch eigene Units dahingehend härten, um die eigene Software schon ab Installation isoliert auszuführen. Und gerade diese Units sind bezüglich des Potenzials für Fehler, und der vielfältigen Möglichkeiten, jedem Shellscript überlegen.

Alles in allem sind diese alten Init-Systeme angesichts heutiger Anforderungen, hoffnungslos unterlegen oder gar überfordert, und wurden zu Zeiten definiert die heutige Belange überhaupt nicht auf dem Schirm hatten. Das ist heute nicht mehr zeitgemäß, auch wenn es den oberflächlichen Anschein hat, dass vieles auch mit SysV, OpenRC und Co. „funktioniert“. Aber im Detail offenbaren sich dann doch unzählige konzeptionelle Mängel, die gerade das herstellen von wirklich sicheren Systemen samt Verifizierung der Abläufe, mehr als nur enorm erschweren. Es mag zwar stimmen das systemd nicht perfekt ist, aber indem nur dagegen geschossen wird anstatt sich sinnvoll einzubringen, wird definitiv nichts besser für jeweilige Kritiker. Auch wenn ich im produktiven Einsatz überwiegend positive Resonanz darüber lese, besonders seit einigen Jahren.

Antworten
2020-06-05

Henry

@Nick:
Manche möchten eben systemd nicht benutzen, aus unterschiedlichsten Gründen. Was Du „stupide“ nennst nennen andere „simpel“. In bestimmten use cases ist dieser simple Weg dem komplexen vorzuziehen. systemd besteht inzwischen aus 1,3 Millionen und ist ungeheuer komplex. Komplexität ist der Feind der Sicherheit. CVE-2020-13776 ist da nur das letze Beispiel. Solche Bugs in einem einfachen Init mit wenigen hundert Codezeilen sind dagegen fast unmöglich. Hat sicher seinen Grund, warum einfache, auf Sicherheit getrimmte Systeme wie z.B. Alpine Linux und OpenBSD solche Komplexitätsmonster wie systemd nicht verwenden.

Antworten
2020-06-06

Jochen Geyer

@Andi

> Was willst du denn noch für Werte?
> Der kurze Ramfresser Vergleich von einem frisch installierten Devuan xfce zu einem frisch installierten Fedora
> xfce – auf einem T420 – sollte genug aussagekräftig sein.

Nein, ist es nicht, weil du nicht einmal erklärst, was du zu suggerieren versuchst!

Antworten
2020-06-10

Andi

@Jochen
Vergiss was ich geschrieben habe und merke dir einfach, dass Devuan sehr sparsam mit deinem Ram umgeht.

Antworten
1. 2020-06-10
  
  Ferdinand
  
  Die Aussage wäre interessant im Vergleich mit Debian 10.
  
  Antworten
2. 2020-06-10
  
  Ferdinand
  
  Naja, RAM-Verbrauch hängt von vielen Dingen ab und sollte nie als objektives Kriterium gelten. Ansonsten ist gegen Vergleiche nichts zu sagen.
  
  Antworten
2020-06-10

Andi

@Ferdinand

Bei mir braucht auch Debian mehr als Devuan, allerdings nicht sehr viel.
Ich werde mich aber davor hüten nochmals RAM Werte zu posten. 🙂

Antworten
2020-09-28

Stefan

Ich habe mir Devuan Ceres mit dem i3 Window Manager und OpenRC init installiert und meine Progamme/Pakete. Alles soweit gut.

Antworten