Login
Newsletter
Werbung

Thema: Debian entscheidet über alternative Init-Systeme

5 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
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?

Pro-Linux
Gewinnspiel
Neue Nachrichten
Werbung