Login
Newsletter
Werbung

Thema: Debian entscheidet über alternative Init-Systeme

51 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
5
Von Nur ein Leser am Mi, 30. Oktober 2019 um 12:14 #

Wenn Debian nun systemd only wird, kann es m.E. nicht mehr von sich behaupten ein universales Betriebssystem zu sein.
Warum nicht? Hier wäre eine tiefergehende Begründung sinnvoll.
In der Vergangenheit hat Debian auch nur ein Init unterstützt, nämlich SysVInit
The system initialization process is handled by the init daemon. In squeeze and earlier releases, that daemon is provided by the sysvinit package, and no alternatives are supported. In wheezy, the default init daemon is still sysvinit, but a "technology preview" of systemd is available. In jessie and stretch, the default init system is systemd, but switching to sysvinit is supported.
Quelle

Heißt das, nach Deiner Logik war Debian vor Wheezy auch kein "Universal Operating System" und wurde dies erst durch die Aufnahme von systemd?

Aber der Einsatz von systemd muss zum Anwendungsfall passen.
OK.
Allerdings sehe ich Distributionen von Raspbian und LibreElec (Embedded) bis hin zu SUSE und Red Hat (Server/ HPC/ Cloud etc.) und die scheinen alle mit systemd recht zufrieden zu sein für ihren Anwendungsfall.
Hier wäre also auch etwas mehr Erläuterung notwendig, welche Szenarien für systemd denn ungeeignet sind und warum.

Mit OpenRC und runit gibt es andere moderne Alternativen, die inzwischen auch erprobt sind (z.B. in Gentoo, Void, Alpine).
Das ist doch gut.
Und wenn jemand den Debian-Entwicklern überzeugend darlegen kann, warum man das als Alternative integrieren sollte in Debian, dann wird es vielleicht auch gemacht.
Debian ist demokratisch organisiert, wenn es irgendwo die Chance gibt, dann da.


P.S.: Oh je - es geht wieder los ;)

  • 0
    Von schmidicom am Mi, 30. Oktober 2019 um 12:31 #

    P.S.: Oh je - es geht wieder los ;)
    "Ohe je" trifft es, vor allem wenn man bedenkt das der Inhalt der in diesem Artikel erwähnten Diskussion mit keinem einzigen Wort erläutert wird. Und mehr als diesen Artikel werden die meisten Nörgler hier vermutlich nicht gelesen haben...

    • 1
      Von Henry am Mi, 30. Oktober 2019 um 12:48 #

      Es geht darum, ob Debian alternative Init-Systeme unterstützen solle. Das ist der Ihalt der Diskussion, und darum dreht sich auch mein Kommentar.

      • 0
        Von schmidicom am Mi, 30. Oktober 2019 um 13:11 #

        Ich habe es jetzt mal ein bisschen nachgelesen und da steckt schon etwas mehr dahinter. Unterm Strich wurde wohl auch verlangt die Abhängigkeiten anderer Pakete so anzupassen das diese alternativ zu systemd auch elogind als gültige Abhängigkeit akzeptieren. Oberflächlich betrachtet eine banale Sache, aber bei einer Distribution die fertig kompilierte Software ausrollt ist das leider nicht immer so einfach.

        Ich nehme jetzt einfach mal an das viele Paket-Betreuer schlicht keinen Bock haben die von ihnen betreute Software erstens mal so zu bauen das sie (sofern überhaupt möglich) beides akzeptiert und zweitens auf beidem testen zu müssen.

        • 1
          Von Pfister2 am Fr, 1. November 2019 um 16:22 #

          Das ist nicht das Problem. Problematisch ist vielmehr, dass Pakete derart an etwas angepasst werden müssen, dass sie nur noch damit laufen bzw. alternativ gar nicht mehr einsetzbar sind.

          Ich liefere Dir gerne einen aktuellen Fall, der mich zimelich "wütend" machte. Ich nutze aktuell Mate, dieses bautin auf Gnome auf. Gnome wiederum baut auf GTK auf. Nun wird in GTK eine Änderung eingespielt, die dafür verantworltich ist, dass alle Menüs mit Touchscreen-Bildschirmen (nicht nur in Mate, in so ziemlich allen Windows-Managern) nicht mehr laufen, siehe dazu:

          https://gitlab.gnome.org/GNOME/gtk/issues/945

          Antwort: GTK is a volunteer-driven project; this means: everybody is responsible for bugs

          Sorry, ich hab den Code nicht geschrieben, nach einem halben Tag, den ich verbraten habe, um nur schon die Abhänigkeiten in GTK aufzulösen (es blieb beim Versuch), hab ich dann die Menütechnologie (brisk) geändert, damit die Menüs in AVMultimedia mit TouchScreens laufen.

          Ich hab ferner einige Tage verbraten, damit AVMultimedia hochfährt, weil irgendjemand auf die gloriose Idee kam, alles nur noch in /usr/bin zu peppen, und weil das irgendwie nicht klappte, wurde dann ein symlink auf /bin angelegt, was beim Hochfahren des Systems unerbärmlich zum Crash führte, weil der Wechsel mit switch_root sich selber über den symlink "abschmierte".

          Also, schreibst dann mal die Software so, dass sie von Anfang an und für immer so läuft, dass es (möglichst) keine Abhänigkeiten gibt und dess es (möglichst) viele Alternativen gibt. Die Aussage "Kein Bock" bzw. "volunteer-driven project" ist da etwas gar einfach. Macht bzw. haltet die Dinge einfach, dann schau ich mir das gerne auch, wenn es Probleme gibt. Es aber bis über jeglichen sinnvollen Horizont (aus welchen Gründen auch) zu überladen und danach zu sagen, "Kein Bock" bzw "volunteer-driven project", das reicht nicht.

          Manchmal beschleicht mich fast schon das Gefühl, ich unterhielte mich mit "Trollen" von Konzernen (oder wem auch immer), die genau das wollen, ein an sich stabiles System so komplex zu machen, dass die Sourcen am Ende nicht mehr les- bzw. wartbar sind.

          • 1
            Von Purism5 am Fr, 1. November 2019 um 16:54 #

            Nun wird in GTK eine Änderung eingespielt, die dafür verantworltich ist, dass alle Menüs mit Touchscreen-Bildschirmen (nicht nur in Mate, in so ziemlich allen Windows-Managern) nicht mehr laufen

            Wenn das bei dem international am weitest verbreiteten Enterprise-Desktop bisher nicht aufgefallen ist, dann ist das ein Sonderfall und die Antwort war richtig.

            • 1
              Von Pfister2 am Fr, 1. November 2019 um 17:01 #

              Zwei Fragen

              a) Was meinst Du mit dem "international am weitest verbreitenden Enterprise-Desktop"?

              b) Wenn Dinge,c) Das Problem trifft aktuell praktisch alle Linux-Desktops die zuvor (in früheren GTK-Versionen) anstandslos liefen, in späteren Versionen nicht mehr laufen, dann ist der neue Code nicht ok. Oder was sehe ich jeztzt falsch bzw. warum sollte die Antwort richtig sein? Ist 'won't fix' richtig? (Gut, das waren jetzt drei Fragen).

    2
    Von Henry am Mi, 30. Oktober 2019 um 13:11 #

    Vor einigen Jahren gab es halt nur SysVInit als getestetes und verbreitetes Init-System. Inzwischen gibt es mehrere.

    systemd ist m.E. ungeeignet

    1. in allen Szenarien, in denen es auf Zuverlässigkeit (Server) ankommt. Ich habe ständig mit nicht startenden Diensten unter systemd zu tun. "systemctl status $DIENST" gibt dann auch nur "failed" aus und die Fehlersuche ist ein Graus. Hinzu kommt die berühmte "A start/stop job is running..." Meldung. Gerade gestern hatte ich wieder ein Ubuntu, welches nicht mehr bootet, weil systemd "infinite" lang starten will. Solche Dinge sind mir in 20 Jahren unter SysVInit noch nie untergekommen.

    2. für Systeme in denen man mit wenig Ressourcen auskommen muss oder will. Z.B. Container. Nicht ohne Grund wird für Docker und LXC ganz oft Alpine (OpenRC) genutzt. Aber auch auf Low-Spec Routern (z.B.ältere ALIX Boards) ist ein einfaches Init besser.

    3. wenn Sicherheit an erster Stelle steht oder stehen muss. systemd ist komplex (1,2 Mio. LoC, Stand Mai 2019. OpenRC hat ca. 10k, runit ca. 1k) ) und Komplexität ist der Feind der Sicherheit.

    • 1
      Von Nur ein Leser am Mi, 30. Oktober 2019 um 20:44 #

      or einigen Jahren gab es halt nur SysVInit als getestetes und verbreitetes Init-System. Inzwischen gibt es mehrere
      Das stimmt so pauschal nicht.

      Upstart war seit 2006 produktiv bei Ubuntu (einem Debian-Derivat!) im Einsatz, wurde aber nie als Alternative zu SysVInit in Debian angeboten.
      OpenRC und runit gibt es auch nicht erst seit letztem Jahr, auch die wurden nie in Debian angeboten.

      Das hat auch nie jemanden gestört, aber jetzt bei systemd ist das angeblich der Normalzustand, das ein "Universal Operating System" mehrere Inits anbieten muss.

      1. in allen Szenarien, in denen es auf Zuverlässigkeit (Server) ankommt
      Ich werde Dir nicht Deine Erfahrungen streitig machen, aber WENN systemd für Serveraufgaben nicht tauglich WÄRE, warum setzen SUSE und Red Hat voll darauf, seit Ewigkeiten? Bei Distros, die für viel Geld angeboten werden?

      • 2
        Von glasen am Mi, 30. Oktober 2019 um 21:48 #

        Ich werde Dir nicht Deine Erfahrungen streitig machen, aber WENN systemd für Serveraufgaben nicht tauglich WÄRE, warum setzen SUSE und Red Hat voll darauf, seit Ewigkeiten? Bei Distros, die für viel Geld angeboten werden?
        Komm ihm doch nicht mit Fakten.

        • 0
          Von 1ras am Mi, 6. November 2019 um 17:07 #

          Er hat schon recht, mit Systemd wurde Mitnichten alles besser. Ungefähr bei jedem 10. Booten kann hier Systemd die über /dev/urandom verschlüsselte Swap-Partition nicht einhängen und wartet dann unendlich darauf, bis Swap verfügbar wird. D.h. das System hängt auf Dauer beim Booten fest. Worst case. Jetzt ist es ja nicht so, dass Verschlüsselung über /dev/urandom nicht die empfohlene Methode für Swap-Partitionen wäre oder gar, dass /dev/urandom blockieren könnte.

          Wenn Systemd nun brauchbares Troubleshooting unterstützen würde, dann könnte man das als Vorteil von Systemd werten, nur dem ist ja leider nicht so. Da ist ein Workaround wie eine Swap-Verschlüsselung per statischem Keyfile bedeutend schneller umgesetzt (und damit der Fehler auch nicht mehr aufgetreten), so dass dies ebenfalls nicht für Systemd spricht.

          Systemd mag vieles können, aber zuverlässiger ist der Bootvorgang durch Systemd nicht geworden und Systemd gibt es langsam lange genug, um es noch als Kinderkrankheit abtun zu können. Daran ändert leider auch das Prinzip "fresst Scheiße, Millionen von Fliegen können nicht irren" nichts.

          Edit:
          Auch im negativen Sinne bemerkenswert sind die immer wieder mal auftauchenden "A stop job is running"-Meldungen bei denen Systemd zwar weiß, dass sich offenbar ein Job nicht beenden lässt aber unfähig ist diesen zu benennen oder gar dem Nutzer ein Mitspracherecht einräumt, den Wartevorgang einfach (z.B. mit CTRL+C) abzubrechen. Ich habe mich auf Clientsystemen schon mehrmals dabei ertappt ein solches System dann einfach hart durch Stromentzug abzuwürgen und auf das Journaling des Dateisystems zu vertrauen, anstatt minutenlang für Nichts zu warten.

          Auf Serversystemen habe ich mittlerweile die Reservezeit der USV großzügig erhöht, da die Meldungen auch noch verschachtelt auftreten können und sich die Zeitspanne immer weiter erhöht und es zu einem unkalkulierbaren Risiko wird, dass dadurch noch während des Herunterfahrens der Strom ausgeht.

          Systemd hat den Bootvorgang sicher schneller gemacht und hat auch sicher die Konfiguration vereinheitlicht, aber zuverlässiger ist dadurch nichts geworden.

          Dieser Beitrag wurde 2 mal editiert. Zuletzt am 06. Nov 2019 um 17:32.
        1
        Von wer verfolgt welche interessen am Mi, 30. Oktober 2019 um 21:52 #

        SUSE und Red Hat, also Novell und IBM, verfolgen ihre eigenen Interessen. Debian sollte sich nicht so vereinnahmen lassen. Wer braucht denn wirklich 1,2 Mil. LoC für ein Startsystem??? Bitte besinnt euch der Entwurfsgrundsätzen von UNIX-Systemen. Ein Werkzeug für eine Aufgabe und nicht die eierlegenden Wollmilchsau, die keiner außer den Erstellern mehr überblickt.

        • 1
          Von Nur ein Leser am Mi, 30. Oktober 2019 um 23:02 #

          Wer braucht denn wirklich 1,2 Mil. LoC für ein Startsystem???
          Also ich weiß nicht, ob diese 1,2 Mio Zeilen stimmen, aber ich weiß, das systemd nicht nur ein Startsystem ist. systemd ist eine ganze Sammlung von Services/demons, die diverse Aufgaben übernehmen können (und optimal mit dem init zusammenarbeiten).

          • 1
            Von Major Nese am Fr, 1. November 2019 um 11:20 #

            Anhand von diesem Fall, elogin und logind, merkt man allerdings recht eindeutig das alles Systemd eine grosse Lennartd-Spaghetti ist.

            • 1
              Von klopskind am Fr, 1. November 2019 um 12:33 #

              ... was immer das auch heißen mag. Bitte zeigen Sie mir den Lennarts Spaghetti-Code in logind (Dateiname und Zeilen oder entsprechender Link). Danke!

              • 1
                Von Major Nese am Fr, 1. November 2019 um 17:54 #

                Das heißt das es nicht möglich ist logind ohne systemd zu betreiben. elogin zeigt dass das nicht notwendig ist und ein lennart-free logind zudem n8ch um einiges schlanker und schneller ist.

                • 1
                  Von klopskind am Fr, 1. November 2019 um 18:29 #

                  1. Sie haben meine Frage nach Belegen Ihrer Aussage nicht beantwortet, womit letztere weiterhin unbelegt sind.

                  2. logind ist im Wesentlichen die Referenzimplementierung einer Schnittstelle, und kann somit im Kern als halbwegs stabile Spezifikation angesehen werden. elogind ist ein Fork, der eine echten Teilmenge dieser Schnittstellen unter Inkaufnahme von Hacks und dem Risiko von Race-Conditions reimplementiert. Einige Schnittstellen sind nicht implementiert. Demnach fehlt elogind gewisse Funktionalität, sowie andere erstrebenswerte Eigenschaften. Quelle:

                  Libelogind just implements login-related functionality. It also provides the sd-bus API.

                  Unlike systemd, whose logind arranges to manage resources for user sessions via RPC calls to systemd, in elogind there is no systemd so there is no global cgroup-based resource management. This has a few implications:

                  • Elogind does not create "slices" for users. Elogind will not record that users are associated with slices.

                  • The /run/systemd/slices directory will always be empty.

                  • Elogind does not have the concept of a "scope", internally, as it's the same as a session. Any API that refers to scopes will always return an error code.

                  On the other hand, elogind does use a similar strategy to systemd in that it places processes in a private cgroup for organizational purposes, without installing any controllers (see http://0pointer.de/blog/projects/cgroups-vs-cgroups.html). This allows elogind to map arbitrary processes to sessions, even if the process does the usual double-fork to be reparented to PID 1.

                  Elogind does not manage virtual terminals.

                  Elogind does monitor power button and the lid switch, like systemd, but instead of doing RPC to systemd to suspend, poweroff, or restart the machine, elogind just does this directly. For suspend, hibernate, and hybrid-sleep, elogind uses the same code as systemd-sleep. Instead of using a separate sleep.conf file to configure the sleep behavior, this is included in the [Sleep] section of /etc/elogind/login.conf. See the example login.conf for more.
                  For shutdown, reboot, and kexec, elogind shells out to halt, reboot and kexec binaries.

                  The loginctl command has the poweroff, reboot, suspend, hibernate, hybrid-sleep and suspend-then-hibernate commands from systemd, as well as the --ignore-inhibitors flag.
                  [...]
                  Basically all symbols are included. But any API calls that require to call systemd, or need internal knowledge of systemd, are simple stubs. They are there to provide ABI compatibility, but will not work.

                  One exception is sd_is_mq() that is found in sd-daemon.h. This is the only place using POSIX message queues, which would add further dependencies. As those would be completely unused in the rest of elogind, this function is also a stub, always returning 0.

                  Außerdem braucht gewisse Software, die unter systemd läuft spezielle Anpassungen für elogind. Wird das nachhaltig funktionieren?

          1
          Von klopskind am Do, 31. Oktober 2019 um 10:44 #

          1. SUSE gehört schon lange nicht mehr zu Novell. Nach der Übernahme Novells durch die Attachmate Group (2011) wurden Novell und SUSE wieder zu eigenständigen Unternehmen entflechtet. Das blieb auch nach der Übernahme Attachmates von Micro Focus International (2014) so bestehen. Seit Mitte 2018 gehört SUSE dem Investor EQT Partners AB. Quelle

          2. Woher stammt die Zahl von 1,2M LoC? Laut OpenHub handelt es sich eher um circa 660k Zeilen Quelltext, davon sind etwa knapp 500k Zeilen Quelltext (davon ~385k C-Code und ~65k XML z.B. für hwdb(7)), der Rest sind Kommentare (~44k Zeilen) und Leerzeilen (~130k).
          Andere Zahlen finden sich auch hier. Ich verweise auch auf meine eigens durchgeführte Zählung von Ende Mai.

          3. SLOC ist eine Metrik mit geringer Aussagekraft. Was genau wollen Sie damit messen?

          4. Die Anzahl der Zeilen Quelltext im Quellverzeichnis von systemd bewältigen weitaus mehr Aufgaben als init (oder SysV). Da ist bspw. udev enthalten, sowie viele rein optionale Komponenten (systemd-boot, journald, journalctl, networkd, networkctl, resolved, resolvectl, timesyncd, ...).
          Ja, der Teil für init ist bei systemd fetter als bei SysV zuvor, insbesondere der init-Prozess. Er kann aber auch sehr viel mehr. Die Fähigkeiten mögen zwar nicht immer notwendig oder gewünscht sein, aber das ist der Preis "universeller" Systeme. Zudem hat man die Option der reichhaltigen Alternativen.

          5. Was genau sind Ihrer Meinung nach die "Entwurfsgrundsätze von UNIX-Systemen"? Entspricht der Linux-Kernel und das Entwicklungsmodell der BSDs (alle entwickeln ihren eigenen monolithischen Kernel samt Basissystem ohne Ansprüche auf absolute Minimalität, Orthogonalität, Portabilität oder Unabhängigkeit projektspezifischer Features) auch diesen Grundsätzen?

          6. Warum sollen sich die anderen auf Ihre Maximen "besinnen"? Mit welchem Recht machen Sie Ihre Forderungen zum Anspruch geltend? Statt zu nörgeln, habe Sie die Möglichkeit, es besser zu machen. Tragen Sie systemd bei und verbessern es, forken Sie es nach Ihrem gusto und beglücken ggf. den Rest der Welt damit, falls es Ihnen recht ist, oder aber finanzieren, unterstützen, entwickeln, nutzen und/oder verbreiten Sie eine Alternative zu systemd. Sie haben die Wahl.

          7. zu "Ein Werkzeug für eine Aufgabe und nicht die eierlegenden Wollmilchsau, [...]": Genau die wollen die wichtigsten Kunden Red Hats aber scheinbar haben. Und was nun?
          Und welche Teile von systemd sollen Ihrer Meinung nach technisch strikter separiert werden? Oder geht es Ihnen eher um das Entwicklungsmodell (Monorepo) oder die politische Komponente?

          8. "[...], die keiner außer den Erstellern mehr überblickt.": Sie suggerieren hier implizit etwas, dass Sie nicht belegen können. Es scheinen viele talentierte und gut bezahlte Administratoren zu existieren, die sich mit ihren Werkzeugen auskennen, sonst würden ständig mittlere digitale Infrastrukturkatastrophen entstehen, die sich allein auf systemd zurückführen ließen und von denen der Otto Normalverbraucher etwas mitkriegen würde. Zudem würde niemand diese Administratoren oder die Software-Lizenzen bezahlen wollen.
          Haben Sie quantitative Belege für Ihre Aussage?


          Ergo: Bitte reden Sie Klartext, streuen Sie keine falschen Fakten ein, belegen Sie Ihre Fakten und Argumente, und ziehen Sie bitte logische Schlüsse und Vergleiche bevor Sie voreilig urteilen. Nur das kann als solide Grundlage für eine erstrebenswert fruchtbare Diskussion gewertet werden. Andernfalls kann man Sie nicht ernst nehmen.

          • 1
            Von klopskind am Do, 31. Oktober 2019 um 11:53 #

            Eine Punkt hatte ich vergessen. Also:

            9. Viele Zeilen Quelltext in systemd sind auch mit Absicht geschrieben worden, das Entwickeln und Warten von traditionell unixoiden daemons zu vereinfachen. Daher auch die services aus der Begriffswelt von systemd. Die Verwaltung mehrerer Prozesses eines Dienstes, das traditionelle double-forking, die Abhängigkeiten, die Race-Conditions, das Neustarten, die Init-Skripte, das Isolieren und der dafür in jedem daemon notwendige zusätzliche Code wurden mit systemd angegangen und zu großen Teilen abgedeckt.
            Vielen Quelltextzeilen systemds stehen also ein Vielfaches an obsoleten Quelltextzeilen in systemd-Diensten gegenüber.

            1
            Von Henry am Do, 31. Oktober 2019 um 12:14 #

            Zu 2:
            Systemd Now Has More Than 1.2 Million Lines of Code

            Ja, systemd kann mehr als ein minimales Init. Und genau das ist das Problem in sicherheitsrelevanten use cases.

            Zu 5: zumindest OpenBSD befolgt die Grundsätze der Minimalität. Im übrigen sind die Grundsätze von Unix recht gut definiert: https://en.wikipedia.org/wiki/Unix_philosophy

            Zu 6: Seit wann ist es eigentlich Mode dass, sobald jemand etwas fordert, unterstellt wird man wolle etwas bestimmen, eine (Meinungs-)Diktatur errichten o.ä. Im Rahmen der Meinungsfreiheit hat jeder das Recht alles mögliche zu fordern.

            Mit diesen Unterstellungen und dem ad hominem Angriff am Ende ("man kann Sie nicht ernst nehmen") disqualifiziert sich der Beitrag eigentlich selbst.

            • 1
              Von klopskind am Do, 31. Oktober 2019 um 14:31 #

              zu 2:
              Die von Ihnen genannte Sekundärquelle ist wie auch der Pro-Linux Artikel, zu welchem ich bereits indirekt mit dem Verweis auf meinen Kommentar mit eigener Zählung verwies, mehr oder minder reißerischer Clickbait. Die Primärquelle ist Phoronix, welches mit git-stats zählte. Leider halte ich diesen Ansatz für mangelhaft, wie Sie auch in dem bereits oben verlinkten Kommentar nachlesen können.

              Haben Sie meinen referenzierten Kommentar und meine darin enthaltene Zählung überhaupt nachvollzogen? Glauben Sie reißerischem Clickbait mehr als OpenHub, Coverity und meinen Ausführungen zusammen? Haben Sie selbst gezählt?

              zu 5:
              Es gibt wesentlich minimalistischere Betriebssysteme als OpenBSD. Und warum eigentlich hat OpenBSD konsequenterweise keinen Microkernel wie etwa QNX? OpenBSD setzt auch im Jahr 2019 immer noch auf einem monolithischen Kernel auf. Welchen "Entwurfsgrundsätzen von UNIX-Systemen" entspricht das? Warum kritisieren Sie OpenBSD nicht für Software aus dem Basissystem, die nicht unter Linux läuft (alles, was BSD-spezifische Features wie strl*, explicit_bzero, BSDAuth, unveil, pledge, pf etc. nutzt)? LibreSSL und OpenSSH mussten auch auf portiert werden. Siehe auch getentropy/getrandom, was effektiv erst mit Verzögerung und Detailunterschieden unter Linux implementiert worden ist.

              Diese Grundsätze sind zwar historisch gerechtfertigt, aber stoßen inzwischen seit Jahrzenten an ihre Grenzen des Möglichen. Grund dafür ist bspw. die zweite Regel Doug McIlroys, bzw. die dritte Peter H. Salus.

              Und an welchen Punkten genau verstößt systemd diese Regeln grundlos? Was wären funktionell oder abstrakt gleichmächtige Alternativen?

              zu 6: Mode interessiert mich nicht. Den Begriff der Diktatur habe ich nicht verwendet. Sie formulierten den Appell "Bitte besinnt euch der Entwurfsgrundsätzen von UNIX-Systemen.", was einerseits einer Forderung und andererseits einer Kritik gleichkommt. Ob Sie gerne etwas bestimmen wollen würden, weiß ich nicht, aber es liest sich für mich so.

              Wenn Sie etwas kritisieren und Änderung fordern, aber nicht einmal Skizzen eines Alternativvorschlags vorweisen können, wie kann man sich davon überzeugen, dass Ihre Forderungen überhaupt realistisch sind? Ist ein zu systemd gleichmächtiges Pendant, welches sich stringent an die "Entwurfsgrundsätze von UNIX-Systemen" hält und gleichzeitig mehrere Systeme unterstützt, real umsetzbar? Wie groß wäre der Aufwand? Und wird der seinem Nutzen gerecht? Sind nicht schon viele Versuch dieser Art gescheitert? (Siehe uselessd; Ziel war es systemd aufs init zu reduzieren und auf andere libc-Implementierungen und Systeme wie die BSDs zu portieren. Es gab auch weitere ähnliche Versuche deren Namen mir allerdings entfallen sind, aber heute alle gescheitert sein dürften.) Andere Projekte wie eudev und elogind (Forks von Teilen von systemd) kommen an ihre Grenzen und erfüllen respektiv nur eine Teilmenge an Features. Da sind diese Fragen und Einwände wohl gerechtfertigt, oder?

              Im Rahmen der Meinungsfreiheit hat jeder das Recht alles mögliche zu fordern.
              Ja, natürlich. Nur was wollen Sie mir damit sagen? Dass ich Ihre falschen Fakten, oberflächlichen Argumente, Schlussfolgerungen und Darstellungen einfach so stehen lassen soll?

              Sie müssen Ihre Aussagen auch belastbar stützen können. Da müssen Sie sich schon "fiese" Einwände und Fragen gefallen lassen. Mit Meinungsfreiheit hat das nichts zu tun. Eher mit eingeschnappter Leberwurst, die nur wenige stichhaltige Gegenargumente auffahren kann und deshalb in einem Streit der Ansichten unterliegt.

              Mit diesen Unterstellungen und dem ad hominem Angriff am Ende ("man kann Sie nicht ernst nehmen") disqualifiziert sich der Beitrag eigentlich selbst.
              Nett, dass Sie das "Andernfalls" aus "Andernfalls man kann Sie nicht ernst nehmen" gekonnt ausgelassen haben. Demnach hatte ich es allein Ihren Reaktionen auf meinen Kommentar überlassen, ob man Sie tatsächlich nicht ernst nehmen könnte. Nicht einmal für ein "[...] man kann Sie nicht ernst nehmen." hat es gereicht... ein Schelm, wer dabei Böses denkt.
              Um ein "ad hominem" handelt es sich in jedem Fall nicht, da er sich auf den Inhalt Ihrer Kommentare bezieht.

              Meine "Unterstellung" sind jedenfalls nicht haltlos. Sie haben ihre Berechtigung, welche ich bereits angeführt habe.


              ---
              Ich gehe davon aus, dass Sie mit meinen Darstellungen in den Punkten übereinstimmen, auf die Sie nicht näher eingegangen sind.

              1
              Von pointer am Fr, 1. November 2019 um 20:24 #

              Ja, systemd kann mehr als ein minimales Init. Und genau das ist das Problem in sicherheitsrelevanten use cases.

              Nicht nur da. Dieses Zeugs scheint in jede Ritze des Systems auszubreiten - wie ein Pilzmyzel. Mir wird das immer suspekter.

              Zu 6: Seit wann ist es eigentlich Mode dass, sobald jemand etwas fordert, unterstellt wird man wolle etwas bestimmen, eine (Meinungs-)Diktatur errichten o.ä. Im Rahmen der Meinungsfreiheit hat jeder das Recht alles mögliche zu fordern.

              Nicht aufregen, das ist zum Glück noch keine Mode, sondern nur die *Masche* bestimmter Leute hier. Der eine oder andere kommt mir dabei vor wie eine Art Chimäre aus Korinthenspalter und Aal. ;)

              • 1
                Von klopskind am Fr, 1. November 2019 um 22:13 #

                Nicht aufregen, das ist zum Glück noch keine Mode, sondern nur die *Masche* bestimmter Leute hier. Der eine oder andere kommt mir dabei vor wie eine Art Chimäre aus Korinthenspalter und Aal. ;)
                Na aber, das geht in großen Schritten in Richtung ad hominem - merken Sie selber, nicht?

                An welcher Stelle habe ich unterstellt, jemand würde eine (Meinungs-)Diktatur errichten wollen, oder suggeriert, jemandem das Recht auf Meinungsfreiheit einzuschränken oder zu versagen?

              1
              Von Verfluchtnochmal_5987108 am So, 3. November 2019 um 23:42 #

              Mit Verlaub aber wer 2019 meint initscripts wären so toll was security betrifft ist ziemlich ahnungslos!

              Dank systemd laufen meine httpd seit Jahren mit cgroups, seccomp, namespaces und vor allem eingeschränkten capabilities

              Bedeutet: Auch der Master Prozess läuft nicht als root, die capability um auf 80/443 lauschen zu können ist mit einer Zeile im systemd unit erledigt und voila der exploit aus einem worker per scoreboard root Rechte zu erlangen hat hier auch vor dem Update nicht funktioniert

              Ähnliches galt vor Jahren als sich mysql/mariadb über ein dämliches config snippet im datadir austricksen ließ, genauer gesagt mysqld_safe was ich hier 2011 durch systemd ersetzt habe weil das Tool nicht mehr gebraucht wird

              Geh weg mit deinen Märchen von wegen sysvinit und security, ich könnte dir Bücher schreiben von ganzen Angriffsklassen die ich über die Jahre durch das Lesen von systemd Manuals und konsequentem Einsatz der Möglichkeiten einfach ausgeschlossen habe

              Vieles davon ist mit einem initscript schlichtweg nicht machbar oder ein extrem fragiles Konstrukt

              • 0
                Von SecurityGuy am Fr, 8. November 2019 um 11:23 #

                Klassisches Beispiel einer Strohmann-Argumentation. Mit keinem Wort wird zuvor erwähnt, dass sysvinit besonders sicher wäre. Erwähnt werden "minimale Inits" - namentlich OpenRC und das BSD-Init von OpenBSD.

            1
            Von GNU dmd am Do, 31. Oktober 2019 um 13:37 #

            systemd ist von der Fre Software Foundation nicht zertifiziert. Man sollte immer auf freie Software zurückgreifen, in diesem Fall also auf GNU Shepherd.

            • 1
              Von klopskind am Do, 31. Oktober 2019 um 14:39 #

              Ich weiß nicht, was genau "zertifiziert" in diesem Zusammenhang bedeuten soll, und welchen Bezug Ihr Argument in dieser Diskussion hätte. Könnten Sie das bitte konkretisieren?

              systemd steht unter der LGPL v2.1+, siehe hier und hier. Damit ist es "frei" im Sinne der Definition der FSF.

              • 1
                Von GNU dmd am Do, 31. Oktober 2019 um 15:30 #

                Im Zweifelsfall soll man immer original GNU software verwenden, dann steht man auf der sicheren Seite.

                • 1
                  Von klopskind am Do, 31. Oktober 2019 um 15:46 #

                  Ja, aber das erklärt erstens nicht den Zusammenhang zur vorangehenden Diskussion, und zweitens was man tun soll, wenn die GNU-Software Feature X nicht unterstützt? Konkreter: Was tun wenn GNU dmd Feature X von systemd nicht unterstützt? Als Hausaufgaben Sie dürfen sich selbst ein solches X aussuchen :P

              1
              Von Verfluchtnochmal_5987108 am So, 3. November 2019 um 23:44 #

              Von der FSF zertifiziert?
              Hast du getrunken?

        1
        Von Henry am Do, 31. Oktober 2019 um 00:19 #

        OpenRC und runit gibt es auch nicht erst seit letztem Jahr, auch die wurden nie in Debian angeboten.
        Stimmt so nicht:

        http://archive.debian.org/debian/pool/main/o/openrc/
        http://archive.debian.org/debian/pool/main/r/runit/
        http://archive.debian.org/debian/pool/main/u/upstart/

        WENN systemd für Serveraufgaben nicht tauglich WÄRE, warum setzen SUSE und Red Hat voll darauf, seit Ewigkeiten?

        Ich hab ein paar CentOS-Boxen und auch eine SLES-Box. Und bei beiden habe ich immer wieder mal Probleme mit systemd. Ich sag nicht, dass es garnix taugt, aber der Idealzustand ist es nicht.

        • 1
          Von OiNoi am Do, 31. Oktober 2019 um 08:25 #

          Ich sag nicht, dass es garnix taugt, aber der Idealzustand ist es nicht.

          Richtig, ideal ist es nicht! Bei mir kommt systemd gleich nach dem Network-Manager. Beide machen Probleme, wo es nicht sein müßte. Nur den NM kann ich wenigstens vom System kicken,...

          1
          Von Nur ein Leser am Do, 31. Oktober 2019 um 09:09 #

          OK, können wir uns darauf einigen, das ich mit "wurde nie angeboten" sprachlich zu ungenau war (ich meinte: "wurde nicht offiziell unterstützt"), das Du aber mit Deiner obigen Aussage von wegen "es gab nur SysVInit" trotzdem unrecht hast?

          Wir müssen hier schon die gleichen Maßstäbe anlegen:
          Es wird ja gefordert, das SysVInit auch in Zukunft offiziell als zweites Init in Debian vollumfänglich unterstützt wird, und nicht nur "irgendwie" in den Paketquellen liegt.
          Und diese Situation gab es bei Debian vor systemd eben nicht. Damals wurde offiziell nur SysVInit unterstützt, alles andere war auf eigenes Risiko und - viel wichtiger - kein Paketbetreuer musste Rücksicht darauf nehmen, ob sein Paket denn mit dem inoffiziellen Upstart oder dem inoffiziellen runit funktionierte.

          Falls das jetzt gleich als Argument kommt "Die sind ja aber auch zu den SysVInit-Skripten kompatibel" - das ist systemd auch.

          • 1
            Von Henry am Do, 31. Oktober 2019 um 09:46 #

            OK, können wir uns darauf einigen, das ich mit "wurde nie angeboten" sprachlich zu ungenau war (ich meinte: "wurde nicht offiziell unterstützt"), das Du aber mit Deiner obigen Aussage von wegen "es gab nur SysVInit" trotzdem unrecht hast?

            Ich schrieb

            Vor einigen Jahren gab es halt nur SysVInit als getestetes und verbreitetes Init-System.
            Evtl. definierst Du "vor einigen Jahren" anders als ich - ich meine damit die Zeit vor der Verbreitung alternativer Init-Systeme, also vor Upstart, also vor 15 - 20 Jahren (bin halt schon so alt, da rechne ich in anderen Zeitmaßstäben :))

        3
        Von pointer am Do, 31. Oktober 2019 um 08:52 #

        Ich werde Dir nicht Deine Erfahrungen streitig machen, aber WENN systemd für Serveraufgaben nicht tauglich WÄRE, warum setzen SUSE und Red Hat voll darauf, seit Ewigkeiten? Bei Distros, die für viel Geld angeboten werden?

        Komplexität und Intransparenz sind beste Freunde derer, die mit "Services" ihr Geld verdienen. ;)

        • 2
          Von Nur ein Leser am Do, 31. Oktober 2019 um 09:16 #

          Ja genau und Reputation für gut und zuverlässig laufende Systeme zählt in dem Business natürlich gar nichts :o

          Das ist ein Blödsinns-Argument, denn die Support-Gebühr bezahlst Du beim Einsatz einer kommerziellen Linux-Distro als Abo-Gebühr so oder so. Egal, ob Du jemals den Support in Anspruch nimmst, oder ob das System 10 Jahre problemfrei durchläuft.
          Es ist also ganz im Gegenteil zu Deiner Behauptung so, das man als Anbieter einer kommerziellen Distro mit Abo-Modell ein Interesse daran hat, das möglichst wenig Support-Anfragen auflaufen.
          Einzig Zusatz-Services, wie z.B. Einrichtung der Software, Schulung, Customizing etc. wird extra abgerechnet.

          • 1
            Von Henry am Do, 31. Oktober 2019 um 09:51 #

            Es ist halt oft so, dass sich nicht das technisch beste System durchsetzt und die meisten Marktanteile gewinnt, sondern das System mit dem besten Marketing und der größten Marktmacht (hier systemd mit RedHat im Rücken). Ansonsten würde sich nicht Windows bis heute halten.

            1
            Von Unerkannt am Fr, 1. November 2019 um 05:44 #

            Microsoft und Windows im speziellen haben eine schlechte Reputation und das stört die Verbreitung nicht im geringsten.

            1
            Von pointer am Fr, 1. November 2019 um 08:19 #

            Das ist ein Blödsinns-Argument, denn die Support-Gebühr bezahlst Du beim Einsatz einer kommerziellen Linux-Distro als Abo-Gebühr so oder so. Egal, ob Du jemals den Support in Anspruch nimmst, oder ob das System 10 Jahre problemfrei durchläuft.

            Daran ist überhaupt nichts "blödsinnig", grundsätzlich stimmt meine Aussage. Und wenn bei RH/S alles so problemlos läuft, wozu dann ein Abo? Da wäre es doch sinnvoller und wohl auch günstiger, Service gezielt und fallweise anzufordern.

            • 1
              Von tomkater68 am Fr, 1. November 2019 um 09:24 #

              Da wäre es doch sinnvoller und wohl auch günstiger, Service gezielt und fallweise anzufordern.

              Hier geht es um Systeme, die in kritischen Unternehmensbereichen eingesetzt werden. Wenn es da zu einem Servicefall kommt, wird sofort - auch am Wochenende und in der Nacht - Hilfe benötigt. Da will und kann keiner bis zum nächsten Morgen oder gar bis zum nächsten Montag warten. Die Vorhaltung einer solchen Infrastruktur kostet viel Geld - unabhängig davon, ob sie benutzt wird oder nicht. Anders als über regelmäßige Wartungsgebühren, kann das gar nicht finanziert werden.

              1
              Von Nur ein Leser am Fr, 1. November 2019 um 13:14 #

              Da wäre es doch sinnvoller und wohl auch günstiger, Service gezielt und fallweise anzufordern
              Ok, offenbar hast Du noch nicht (Service-)Leistungen mal selbst kalkulieren müssen.
              Ich gebe Dir da gerne etwas Einblick:

              - Du bietest einem Kunden eine Leistung an, für diese Leistung musst Du intern Ressourcen vorhalten. Sprich, neben Rechnern und Infrastruktur insbesondere Menschen, die jeden Monat bezahlt werden wollen. Und nicht nur das, es reicht halt nicht irgendwelche Menschen da sitzen zu haben, die müssen nämlich auch Know-How haben. Also musst Du die einmalig sehr viel und dann noch wiederkehrend qualifizieren.
              - Das bedeutet, Du hast laufend Kosten in erheblicher Höhe, unabhängig davon, ob Dein Kunde auch nur eine einzige Stunde Service in Anspruch nimmt
              - Dein Kunde möchte jetzt nur "fallweise" für Service bezahlen. Was machst Du? Wenn Du keine andere Möglichkeit hast, gehst Du darauf ein.Aber dann musst Du natürlich schauen, das Du nur exakt so wenig Personal hast, das dies auch dauerhaft mit Aufträgen ausgelastet ist - ansonsten würdest Du nämlich Minus machen, was Du Dir nicht leisten kannst.-
              - Es kommt jetzt noch die Schwierigkeit hinzu, das Du den Aufwand nur schwer kalkulieren kannst, denn Du weißt ja nicht, wann Deine Kunden wirklich mal ein Problem haben, manchmal ist nichts los, manchmal extrem viel.
              - Heißt für Deinen Kunden: Wenn er dann mal "fallweise" ein Problem hat, muss er sich hinten anstellen - er bekommt dann Service, wenn jemand gerade frei ist. Das kann auch mal ein paar Tage dauern. Wie Tomkater unter mir geschrieben hat, ist das für die meisten Kunden keine Option, denn WENN sie Service brauchen, dann auch SOFORT
              - Ach ja, nicht zu vergessen: Dein fallweises Service-Geschäft muss übrigens auch noch die komplette Entwicklung mitbezahlen, denn Du bietest ja freie Software an - da ist es wirklich schwierig, mit der Software selbst Geld zu verdienen

              Die Alternative, und genau das machen SUSE und Red Hat:
              - Du bietest Deine Software nur gebündelt mit einem Service-Abo an
              - Das generiert regelmäßige Einnahmen, was schon mal eins Deiner Probleme löst und auch die Entwicklung finanziert
              - Du kannst besser kalkulieren, wie viele Leute Du für Service vorhalten musst, weil Du nämlich verschieden Service-Klassen in den Abos anbietest und davon ausgehen kannst, das die Kunden diese im Zweifel auch voll nutzen werden
              - Nichtsdestotrotz ist es in dieser Situation für Dich vorteilhaft, wenn Dein Kunde KEINE Service-Anfrage stellt - dann können Deine Service-Leute in der Zeit nämlich andere Sachen machen (das Know How haben sie, da gut qualifiziert, für viele Sachen), werden aber trotzdem für Service bezahlt

              • 1
                Von pointer am Fr, 1. November 2019 um 19:47 #

                Ok, offenbar hast Du noch nicht (Service-)Leistungen mal selbst kalkulieren müssen.
                Ich gebe Dir da gerne etwas Einblick:

                Doch. Anderes Geschäft. Aber trotzdem danke für Deine Ausführungen.

                - Nichtsdestotrotz ist es in dieser Situation für Dich vorteilhaft, wenn Dein Kunde KEINE Service-Anfrage stellt - dann können Deine Service-Leute in der Zeit nämlich andere Sachen machen (das Know How haben sie, da gut qualifiziert, für viele Sachen), werden aber trotzdem für Service bezahlt

                Ja, da ist was dran. Und von daher ist das Abo-Modell schon auch geschickt.

      1
      Von pointer am Do, 31. Oktober 2019 um 09:00 #

      Hinzu kommt die berühmte "A start/stop job is running..." Meldung.

      Irgendwann hatte ich dann die Faxen dicke: Als wieder mal "A stop job is running" kam, dachte ich "Genau - und zwar *für Dich*, systemd!". Danach schritt ich zur Tat. ;)

    1
    Von qbert am Mi, 30. Oktober 2019 um 14:01 #

    Debian hatte früher mal den Anspruch, nicht nur Linux, sondern auch noch andere Kernel (z.B. FreeBSD oder Hurd) zu unterstützten. Da systemd allerdings nur unter Linux läuft, ist es kein universelles Betriebssystem mehr.

    • 1
      Von Nur ein Leser am Mi, 30. Oktober 2019 um 23:10 #

      Debian hatte früher mal den Anspruch, nicht nur Linux, sondern auch noch andere Kernel (z.B. FreeBSD oder Hurd) zu unterstützten.
      Hat das jemals wirklich funktioniert? Meines Wissens nach ist das nie über einen Technikvorschau/Demo-Modus hinausgekommen, eben weil es sehr aufwändig ist, ohne einen echten Mehrwert zu bieten.

      Wenn man ehrlich ist, war Debian schon immer "nur" eine Linux-Distribution, wenn auch eine mit Besonderheiten.

      • 1
        Von Oiler der Borg am Do, 31. Oktober 2019 um 10:02 #

        Ist zwar noch keine Produktivversion und auch noch 32Bit-only.... aber schon mehr als ein MockUp
        https://www.youtube.com/watch?v=AuBNKwlPw4A
        https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/

        eben weil es sehr aufwändig ist, ohne einen echten Mehrwert zu bieten.
        .... das ist nun mal die Sache mit dem Papiertiger "Microkernel" in freier Wildbahn trifft man nur den Effekt der Entschleunigung an :cry:

        1
        Von klopskind am Do, 31. Oktober 2019 um 11:41 #

        Ich denke, dass es sich um ein Teilprojekt im Rahmen der Infrastruktur Debians gehandelt hatte, einfach weil jemand es kann und Lust dazu hatte, die Grenzen des Möglichen zu testen/sprengen. Meinem Eindruck nach war das von Beginn an Hobbyspielerei ohne große Erfolgsaussichten und -ambitionen.

Pro-Linux
Unterstützer werden
Neue Nachrichten
Werbung