Debian General Resolution: Init systems and systemd on 12/7 – 12/27

Posted on by Sven

Debian General Resolution: Init systems and systemd

Just in case they vote on Choice 1: F: Focus on systemd,
i.e. completely disabling another init script, I have to pick up a new distribution.

Today, I mostly run Debian on desktop and server.
Most server use a non-systemd init system for sanity.

Easing systemd dependencies via systemd-shim, libsystemd0
and using sysvinit.

Documentations of not using systemd are

 

IMHO the only good Debian proposals are

Devuan’s take on the vote in a post, as Debian is essential for Devuan and all other distributions based on it willing to provide a non-systemd system.

Problem is, the more lenient a policy is towards init abuse,
i.e. only supporting systemd and creating hard dependencies on it,
the less likely it is most packages will work w/o systemd
running nor installed.

Risk: Who controls systemd will control the Linux desktop.

An init system originally only handles process
initialization and management,
which was usually done in a few lines of code
and was always considered very security critical.

It is a long debate, but I get goose bumps when
an init system and its environment takes over
more than half of a Unix like system’s services,
especially when the user land applications
start to make it a hard requirement.

I didn’t keep too much track of systemd,
but after keyboard and console control,
networking, harddisk partitions and what not
– now they want full user identity control,
naming it ‘Home Directories’ or ‘systemd-homed‘

This not only includes home partition setup
but also control of key management for encryption etc.

Is all the systemd work still coming solely from Red Hat giving us a single service provider concentration risk, which other distributions intended to avoid? Now being reintroduced and enforced via systemd?

Good evening and let’s hope init choice
can be still be made in the future.

Cheers,

~Sven

PS: I will post an edited version later on my blog

Published by Sven

7 thoughts on “Debian General Resolution: Init systems and systemd on 12/7 – 12/27”

  3. Gentoo and Alpine Linux comes to mind as a complete replacement, hmm.
    Alpine Linux supports:
    – ZFS root filesystem
    – ZFS native encryption
    – musl libc http://www.etalabs.net/compare_libcs.html
    – OpenRC init system
    – Read-only image into ram, working from ram plus partition for ‘data’ or ‘changes’
    – x86_64, arm32 and arm64
    hmm .. need to compare Gentoo with the list above.

    Raspberry Pi is also somewhat supported 😉

  4. Problem with Alpine Linux seems to be the almost dead community (forum etc)?
    Wiki does exist to the point, but surely can’t beat Arch Linux’s wiki (probably the best when it comes to to the point user base setup).
    It is a journey ..

  5. Guillem Jover [guillem@debian.org] who initiated the ‘G’ proposal
    put a very nice post in the mailinglist: https://lists.debian.org/debian-vote/2019/12/msg00051.html

    When reading hist initial proposal, I liked his spirit right away,
    as he generalizes the problem – it is not just about ‘init’.
    It is about any building block of the whole cathedral being debated on the bazaar 😉

    Ian’s reply is very useful here: https://lists.debian.org/debian-vote/2019/12/msg00063.html
    Shows that the only portable proposals would be E and D.
    Better a combo or G+E or G+D that is, spirit and strong guidance for the systemd special case.

    When I roll back time, the most impressive notion of Debian was that you could replace the kernel,
    i.e. run the userspace packages on Linux, FreeBSD or whatnot.
    And this is exactly what I didn’t like with systemd’s author standing, he dismissed the standards
    which took years to form to allow interoperability.

    It would be feasible to have systemd operate like today’s OpenRC with process monitoring,
    i.e. tracking the actual state of the process to reanimate or notify w/o ‘funny polling’.
    OpenRC can be used as a replacement to sysvinit w/o compatibility issues IMHO.
    But for some reason, systemd want to solve problems which simply do not exist
    and then heavily relying on the Linux kernel it sort of extends.
    The real innovation for a better world would have been to specify an init process
    capable to be implemented by any willing party while keeping requirements low.
    But the ever growing systemd submodules (or whatever they are called) give me the feeling
    that they call for world domination 😉

    The Master Control Program (MCP) comes to mind from Tron (1984)
    https://en.wikipedia.org/wiki/Tron
    https://en.wikipedia.org/wiki/List_of_Tron_characters#Master_Control_Program

    😉

  7. OpenRC, initng, runit, monit, s6, daemontools, and Shepherd.

    Most can handle process supervision and most comply with the good ole standards I would think?
    Well, none of them is trying to handle user identities, encryption keys or whatever curious expansion systemd has in mind 😉

Comments are closed.