Die unendliche Geschichte: Debian und Systemd

Verfasst von

Debian Systemd — Bild: Debian | Quelle Mohd Sohail | Lizenz: CC BY-SA-2.0

Es vergeht kein Jahr, in dem es bei Debian nicht mindestens eine Diskussion über Systemd gibt, das bei der Distribution seit 2014 das Standard-Init-System ist. Die Entscheidung für Systemd traf damals nach langen und hitzigen Diskussionen Debians Technisches Komitee (CTTE).

Seitdem gab es viele Diskussionen über die Unterstützung alternativer Init-Systeme, die letztes Jahr in einer Grundsatzentscheidung (General Resolution, GR) gipfelten. Gewonnen hat die Abstimmung damals Option 2 „B: Systemd but we support exploring alternatives“ des damaligen Debian-Projektleiters Sam Hartman:

Das Debian-Projekt erkennt an, dass Systemd Service-Einheiten die bevorzugte Konfiguration sind, um zu beschreiben, wie man einen Daemon/Dienst startet. Dennoch bleibt Debian eine Umgebung, in der Entwickler und Benutzer alternative Init-Systeme und Alternativen zu Systemd erforschen und entwickeln können. Diejenigen, die daran interessiert sind, solche Alternativen zu erforschen, müssen die notwendigen Entwicklungs- und Paketierungs-Ressourcen zur Verfügung stellen, um diese Arbeit zu erledigen.

General Resolution missachtet?

Das scheinen nicht alle Entwickler so zu sehen, denn nun kommt ein Fall vor das CTTE, bei dem der Maintainer des Pakets NetworkManager nach Meinung anderer Entwickler diese Grundsatzentscheidung missachtet und damit den Zugang zu anderen Init-Systemen erschwert oder gar verhindert.

Init-Script entfernt

Es begann mit einem Bugreport aus dem Sommer, der moniert, dass Michael Biebl, der maßgeblich die Integration von Systemd in Debian vorangetrieben hat und immer noch betreut, ein Init-Script aus dem von ihm betreuten Paket NetworkManager entfernt hatte, dass die Nutzung alternativer Init-Systeme ermöglichte. Da NetworkManager ein essenzielles Paket für viele Anwender ist, versucht der Bugreport, die Entfernung rückgängig zu machen.

network-manager (1.25.91-1) unstable; urgency=medium

  * New upstream version 1.25.91 (1.26 rc2)
  * Remove SysV init script

 -- Michael Biebl <[…]>  Thu, 02 Jul 2020 01:17:08 +0200

Das Technische Komitee entscheidet

Da Biebl aber über Monate nicht im Sinne der Befürworter des Init-Scripts reagierte, versuchte es ein Entwickler über das in dem Fall ungeeignete Mittel eines NonMaintainerUpload (NMU), die Änderung rückgängig zu machen. Dem widersprach Biebl. In letzter Konsequenz wendet sich Entwickler Matthew Vernon jetzt an das CTTE, Debians höchste technische Instanz, um den Fall klären zu lassen. Die Frage im entsprechenden Bugreport an das Komitee lautet: »Sollten Maintainer in der Lage sein, Änderungen der Init-Kompatibilität zu blockieren?«

Vernon möchte damit nicht nur das Init-Script in NetworkManager zurück an seinen Platz, sondern generell eine Entscheidung, die verhindert, dass Maintainer Debians Init-Freiheit behindern, es sei denn, der Grund ist ein kaputtes Paket. Vernon wünscht sich eine Entscheidung, die sich bereits auf Debian 11 »Bullseye« auswirkt.

Debian GNU/Linux Systemd

Kommentare

24 Antworten zu „Die unendliche Geschichte: Debian und Systemd“

2020-11-20

rantanplan

Wie war denn die Argumentation von Michael Biebl hierzu?

Antworten
1. 2020-11-20
  
  Ferdinand
  
  Öffentlich hat er sein Vorgehen meines Wissens gar nicht erklärt. Er sagte lediglich, es geben keinen Grund, die Änderung zurückzunehmen, denn das sei kein Versehen, sondern absichtlich geschehen. Das ist natürlich etwas schroff, aber andererseits hat Michael Biebl so viele Diskussionen durch, das er bestimmt nicht noch eine braucht.
  
  Antworten
  1. 2020-11-20
    
    kamome
    
    so viele Diskussionen durch, das er bestimmt nicht noch eine braucht.
    
    Naja, wenn er kommentarlos, bewusst und anscheinend unnötig andere Init-Systeme behindert, braucht er wohl doch eine weitere Diskussion 😉
    
    Antworten
    1. 2020-11-20
      
      Ferdinand
      
      Das »anscheinend unnötig« hätte er ausräumen können. Aber das hätte halt wieder einen Flamewar zur Folge gehabt (den es jetzt vermutlich eh geben wird).
      
      Antworten
2020-11-20

Mike

Debian Kindergarten. Maintainer reagiert auf Gutsherrenart.

Erinnert mich an die ffmpeg – libav Auseinandersetzung wo ffmpeg in Debian nebst Derivaten jahrelang als deprecated raus war, weil das ein Maintainer so entschied.

Antworten
1. 2020-11-21
  
  Willi
  
  So wie der Maintainer von openSSL, welcher den einzigartigen „Debian openSSL Bug“ verursachte. Ist halt eine Eigenart von Debian.
  
  Antworten
  1. 2020-11-23
    
    Nick
    
    Falsch. Wenn ein Maintainer routinemäßig besonders sicherheitsrelevante Pakete mittels automatisierter Code-Analyse prüft, und eklatante Sicherheitslücken findet und dementsprechend korrekt fixt, dann hat dieser Maintainer alles richtig gemacht. Was jedoch ungeheuerlich gewesen ist, war dieses Code-Konstrukt seitens OpenSSL, welches dermaßen fahrlässig designt war, dass die Sicherheitslücke die seitens Debian ausgeräumt wurde ein absolut unsicherer aber elementar wichtiger Bestandteil einer Funktion gewesen ist, wodurch wiederum eine katastrophale Problematik entstand. Das war ein massiver Designfehler in OpenSSL.
    
    Antworten
    1. 2020-11-24
      
      Florian
      
      Genau, er hat alles richtig gemacht, deshalb war Debian auch die einzige Distribution mit diesem eklatanten Sicherheitsfehler. Alle anderen Distris haben etwas falsch gemacht, die hatten diesen eklatanten Sicherheitsfehler nämlich nicht.
      Die „Argumentation“ mancher Debian-Fans ist teilweise schon recht abenteuerlich… 😉
      
      Antworten
2020-11-20

Uwe

Dieser Hick-Hack! Meine Güte.
Warum gehen die Unzufriedenen nicht einfach zu Devuan? Und fertich…

https://www.devuan.org/

Antworten
1. 2020-11-20
  
  Pfister2
  
  Ganz so einfach ist die Sachlage nicht. Ich habe mich mit AVMultimedia bzw. unserer ArchivistaBox irgendwann für Devuan entschieden, und an sich bereue ich den Entscheid bis heute nicht. So weit so gut.
  
  ABER, nach meiner Überzeugung sollte Open Source im Grundsatz so offen, abwärtskompatibel und flexibel wie möglich realisiert werden. Wäre dies der Fall, dann würden sich all diese Diskussionen ja auch erübrigen. Open Source bringt insbesondere etwas, wenn der Einsatz in möglichst vielen Konstellationen möglich ist.
  
  Das ist nun kein Debian oder Devuan spezifisches Problem. Ich sah und sehe das die letzten beiden Jahrzehnte (viel länger bin ich bei Linux nicht an Board) immer häufiger. Manchmal mag es technische Gründe geben, bei denen Abwärtskompatilität fast nicht mehr machbar ist. Fast immer aber werden Optionen realtiv mutwillig oder unbedacht (nicht weniger schlimm) geändert, ohne darauf zu achten, ob die bisherige Nutzung gewahrt bleibt. Übrig bleibt dabei der Frust, dass etwas, das mal lief, neu nicht mehr läuft.
  
  Konkret gemäss Beitrag hat der Maintainer ein Skript entfernt, mit dem andere Init-Systeme laufen können, und dies nicht etwa bei einem kleinen Tool, sondern der zentralen Schnittstelle für die Netzwerkverbindungen (Network-Manager). Dies ergibt nicht nur keinen Sinn (was machen die paar Bytes auf der Platte aus?), es ist für das Gedeihen von Open Source höchst schädlich.
  
  Ich könnte als Devuan-User zurücklehnen bzw. einfach andere ermutigen, zu Devuan zu wechseln. Dem ist aber nicht so, denn nochmals, all jene Debian-Systeme, die auf das Skript abstützten, laufen neu nicht mehr. Solche „Aktionen“ führen letzten Endes dazu, dass (weil es nicht läuft) die User/innen frustriert Linux bzw. Open Source den Rücken kehren.
  
  Antworten
  1. 2020-11-20
    
    kamome
    
    Da können wir wohl froh sein, dass sich andere Systeme nicht davon „abhängig“ gemacht haben (https://github.com/GhostBSD/networkmgr).
    
    Antworten
  2. 2020-11-20
    
    Uwe
    
    Als aussenstehender Endanwender, der einfach nur Dankbar für Linux an sich ist, nötigt solch ein „Stess“ mir nur Kopfschütteln ab.
    
    Antworten
    1. 2020-11-21
      
      no one
      
      Allerdings trifft es hier jetzt wohl auch nur oder zumindest ganz überwiegend Leute, die bewusst ein vom Standard abweichendes Init-System nutzen, dessen Funktion von Debian nicht mehr garantiert wird.
      Das relativiert das Ausmaß des Problems dann schon ein wenig. Auf die Begründung bin ich trotzdem gespannt.
      
      Antworten
  3. 2020-11-22
    
    wurzel99
    
    „ABER, nach meiner Überzeugung sollte Open Source im Grundsatz so offen, abwärtskompatibel und flexibel wie möglich realisiert werden. Wäre dies der Fall, dann würden sich all diese Diskussionen ja auch erübrigen. Open Source bringt insbesondere etwas, wenn der Einsatz in möglichst vielen Konstellationen möglich ist.“
    
    „Im Grundsatz offen“ ist Linux. Jeder kann damit machen was er will. Das heißt aber nicht, das dieser ‚Jeder‘ – dazu gehört auch Debian – sich nicht dazu entschießen kann (warum auch immer) eine bestimmte Richtung einzuschlagen und ist damit niemand Rechenschaft schuldig.
    Das ist die Freiheit, die OpenSource gibt.
    Wem es nicht passt, der kann was anderes machen. Eben Freiheit.
    
    Antworten
    1. 2020-11-22
      
      Pfister2
      
      Natürlich bedeutet Open Source die Freiheit alles damit machen zu wollen. Das sollte uns aber nicht daran hindern, es intelligent zu machen. Und wir sollten nur das tun, wofür es gute Argumente gibt. Und weil ich bislang für die Aktion keine Argumente sehe, finde ich es jetzt nicht so toll, auch wenn ich schon damit leben kann (da ich ja mit Devuan unterwegs bin).
      
      Trotzdem sollten solche Entschede diskutiert werden. Ich möchte in diesem Zusammenhang nur daran erinnern, dass damals, als es um den Entscheid SystemD bei Debian ja oder wie ging, klar ausgefochten wurde, SystemD ja, Alternativen bleiben. Aktuell ist davon nicht mehr viel zu spüren. Aber sicher, natürlich dürfen die das, aber ob es „gescheit“ ist, dies wäre und ist eine andere Frage.
      
      Antworten
2. 2020-11-22
  
  Jochen Geyer
  
  Warum gehen die Unzufriedenen nicht einfach zu Devuan?
  
  Verkürzt gesagt, weil Devuan bis heute nicht mit den Releasezyklen von Debian mithalten kann.
  
  Antworten
  1. 2020-11-22
    
    no one
    
    Man kann den Leuten sowieso nur raten, endlich ihren Frieden mit Systemd zu machen. Es ist doch absehbar, dass Alternativen langfristig immer schlechter unterstützt werden und man sich damit dann früher oder später nur unnötige Probleme einhandelt.
    
    Antworten
    1. 2020-11-22
      
      Pfister2
      
      Kurz- und langfristig, das sind dehnbare Begriffe. Was heute gut und langfristig aussehen mag, kann morgen schon als schlecht und unbrauchbar empfunden werden und oder es auch sein. Ich kann ein Programm auch mögen oder nicht, ich kann es einsetzen oder nicht, „Frieden“ sollte jeder zunächst mit sich selber finden. Und doch finde ich persönlich es toll, wenn Systeme einfach gestrickt sind — und hier sehe ich für mich wenig Begeisterung bei SystemD. Vorliegend geht es aber darum, dass etwas, was lief, ohne erkennbare Gründe entfernt wurde. Das ergibt einfach keinen Sinn.
      
      Antworten
      1. 2020-11-23
        
        tuxnix
        
        Sehe ich auch so. Zusätzlich muss man auch sehen, dass sich die Mehrheit der Entwickler für den Verbleib alternativer Init-Sysdteme ausgesprochen hat, solange es kompatibel ist und es keiner Extraverrenkungen bedarf. (So interpretiere ich zu mindest den Beschluß)
        Wenn der Verbleib „alter Zöpfe“ nur Schwierigkeiten hervorruft, müssen sie auch mal abgeschnitten werden. Hier allerdings schnippelt jemand ohne jegliche Not nach eigenem Gusto.
      2. 2020-11-23
        
        Nick
        
        Und ob das Sinn ergibt. Du kannst auch nur fordern und kritisieren, bist aber selbst offensichtlich kein Maintainer oder Entwickler, für die das eine erhebliche Belastung darstellt diesen veralteten Müll zusätzlich zu unterstützen, der weder einer modernen Entwicklung folgt und zudem haufenweise Ressourcen bindet. Und für was? Damit heutzutage nicht mal 1% der Nutzer problemlos irgendein krudes exotisches Initsystem nutzen kann, weil dieses marginale Volk nicht darauf klarkommt, dass sich die Welt seit ihren ersten Erfahrungen vor Jahrzehnten tatsächlich weiterentwickelt hat? Und nein, Debian muss sich nicht für derartige Entscheidungen rechtfertigen, noch die Maintainer die diesem Kindergarten zurecht überdrüssig sind. Im übrigen ist „das etwas was lief“ eine sehr dehnbare Formulierung, und kein Garant dafür das etwas im Kern wirklich gut lief.
      3. 2020-11-23
        
        no one
        
        Es mag schon sein, dass Systemd irgendwann ersetzt werden wird, aber bestimmt nicht, weil irgendwer zu SysVinit zurückkehrt. Das nutzt inzwischen keine auch nur annähern relevante Distribution mehr als Standard.
        Und ich sehe, völlig unabhängig von diesem konkreten Fall, einfach keinen Sinn darin, ein Init-System zu verwenden, dass von der Distribution nur noch nach Lust und Laune unterstützt und getestet wird.
        Vor allem nicht, wenn die ganzen Systemd-tools vergleichsweise komfotabel sind und gegen den Einsatz eigentlich nur spricht, dass es manchem nicht KISS genug ist.
    2. 2020-11-26
      
      mszet
      
      Langfristig ist Debian auch wegen systemd zum Scheitern verurteilt. Falls die Debian-Leute nicht freiwillig in end- und nutzlosen Diskussionen sterben wollen, sollten diese schon Mal prophylaktisch eine RHEL-Lizenz buchen.
      
      Im übrigen gehört Network-Manager ebenfalls entfernt. Da systemd-networkd doch alles kann, was notwendig ist.
      Network-Manager ist ein Minderheitentool das keiner braucht, nur wertvolle Ressourcen verschlingt und dem Endsieg von systemd im Weg steht.
      
      Antworten
  2. 2020-11-22
    
    Pfister2
    
    Als Maintainer von AVMultimedia kann ich das so jetzt nicht stehen lassen. Zwar läuft bei Devuan es etwas „gemächlicher“ ab, das ist aber nicht nur ein Nachteil. Dinge, die laufen, laufen bei Devuan auch dann noch, wo andere (wie vorliegend beim Netzwer-Manager) etwas aus irgendeiner Laune heraus geändert haben. Und ich meinte jetzt ehrlich, dass mein AVMultimedia schon up-to-date ist, siehe dazu: http://archivista.ch/cms/de/aktuell-blog/avmultimedia-2020-x-ryzen-4000u
    
    Nebenbei gesagt, AVMultimedia läuft darauf länger als die neuen M1 MacAirs von Apple, das Lenovo-Gerät ist bei Multithreading auch ca. 20% schneller und kostet erst noch bei gleicher Hardware die Hälfte. Ich sehe aktuell kein Debian (bitte keinen Flame, wenn ich eine Distri übersehen habe, dann her damit), wo ich das kriegen würde. Im übrigen finde ich Debian nicht schlecht, ich meinte eher, dass ich wohl AVMultimedia mit der Komplexität von Debian bzw. SystemD nicht so elegant hingekriegt hätte. Ich freue mich aber an jedem Linux, an Debian, Devuan, Alpine und und.
    
    Antworten
2020-11-20

tuxnix

Hier möchte jemand per Exempel einen anderen Status herbeiführen. Er äußert sich nicht, da er möchte, dass das CTTE darüber entscheiden muss und systemd anschließend nicht nur die bevorzugte Konfiguration, sondern dann die einzige Möglichkeit ist, einen Dienst in Debian zu starten. Die Aktion ist politisch zu werten denn das Entfernen des Scripts geschieht ohne jegliche technische Not.
Ich finde das mutwillig und sehr schade. Denn die Debian Community hat bestimmt wichtigere Themen miteinander zu diskutieren. Man muss nicht immer wieder die alten Wunden aufreißen. So etwas schafft nur Frust und ermüdet alle nur.

Antworten