Should we plan on systemd ?

[richb]

@CharlesV
And that definitely makes a big difference too. I have had a few oddities, but I push my machines pretty hard and while I tend to stay off problem software, I do bend things around a bit sometimes :()

It is *always* interesting to me what a 'standard users' machine is. Many people stay within a set of guidelines... but quite a few are just over that line and not really 'power users' ... just working it more.

Very true. We see it on the Forum. New users need guidance even when staying with standard stuff. But many wander off the reservation and cause serious problems for themselves.

[Adrian]

The problem with systemd is that we still have some stuff with the Live system that doesn't work well with systemd. If everything would work then there would be a good case that we'd have better support and compatibility if we were defaulting on systemd, I would still like to be able to offer an alternative for ideological people who would not touch systemd with a 10 foot pole.

[CharlesV]

The problem with systemd is that we still have some stuff with the Live system that doesn't work well with systemd. If everything would work then there would be a good case that we'd have better support and compatibility if we were defaulting on systemd, I would still like to be able to offer an alternative for ideological people who would not touch systemd with a 10 foot pole.

But if the shim's are basically coming from Debian... will they continue ? I would think at some point they would just say enough and move to 100% systemD . .. and then what?

[asqwerth]

While I have systemd distros (Fedora, Manjaro, Solus) in my distro collection, I am all for choice and am very happy using sysV in MX (also in PCLinuxOS). Choice is why my collection has different desktop environments, package management systems and inits.

Since I am a normal user with no unusual usage requirements needed of my computer systems, using systemd if it's baked into a distro is not a problem. But I also like to look at the big picture.

I just don't want systemd to squeeze other inits out. Because if they do and we are left with only systemd, who knows what else will be made a hard dependency/requirement of systemd. Will we have to use their homed /home directory? their systemd bootloader?. Right now these are only optional functionality parts of systemd.

Just how safe is systemd to attacks when it is such a big program, and it wants to take over more and more tasks?

But if the shim's are basically coming from Debian... will they continue ? I would think at some point they would just say enough and move to 100% systemD . .. and then what?

They haven't come from Debian for a long time. MX appointed a programmer to keep it patched and up-to-date with the latest systemd in Debian Stable. So we won't know what needs to be done for the shim in Debian Trixie until we know what version of systemd will land in the next Debian Stable.

[CharlesV]

@asqwerth AH.. thank you for all that excellent info!

[asqwerth]

....... and as I recall there are plans for restoring multiple inits in Debian as first-class citizens.

I think that any steps taken by Debian in that direction [if at all] might be focused on how one might replace systemd with another init, rather than allowing many inits to co-exist on the same installation and accessible from the boot menu.

[AVLinux]

One certain thing is need for systemd will not become less.. Right now for MX, all three of their supported DE's still work well with both inits (not without some intervention). I would be extremely (and pleasantly) surprised if KDE didn't tilt further toward requiring systemd like Gnome and some others now have...

[asinoro]

The systemd will be more and more unavoidable, which also means that in the future AI by itself will run it, a small example which still needs humans: https://medium.com/@david.franko1998/au ... 0a143c31e5

[MikeR]

One more data point:
As a fairly new convert to MX, I used Ubuntu since the Warty version (circa 1995, IIRC), still not a Linux maven I found that the switch to systemD left me in "a maze of twisty passages..."
The smallest problem in point A led to point B ,... C ... etc. There seems no way for a non-expert user to sufficiently master systemD.
I feel sure that if it is forced on us we (you) will see an exodus of all those satisfied to stay with their "noob" status.

Meanwhile, thanks for all the effort put into MX Linux, and for the excellent support provided in this forum.

Mike

[DukeComposed]

I think that any steps taken by Debian in that direction [if at all] might be focused on how one might replace systemd with another init, rather than allowing many inits to co-exist on the same installation and accessible from the boot menu.

I don't think Debian has ever been big on managing a plurality of init systems. The vote I was thinking of occurred in 2019 and concluded with the decision "B: systemd but we support exploring alternatives".

And that in itself is a victory, since it means that Debian will not take such a hostile stance towards existing userbases as, say, Fedora. Personally I don't see a point in supporting several different concurrent init systems, as the feature sets always vary. Just make it so that a user isn't obligated to depend only on systemd. (Nothing ticks me off quite like the fanboys who insist that systemd isn't that bad and if you don't like something you can "just disable it". OK, bro. Now, if I just want my init system to just be an init system I need to go in and (a) turn off hardware device naming as a kernel argument in the bootloader, (b) switch off the DNS resolver, (c) fix the broken time synchronization issue, (d) move other core services over to a real process management utiilty because systemd also handles local and network daemons, et cetera, et cetera. Cool, bro. Now half of my new-PC-setup activities I run every time I build a new machine are turning off things I don't want and never asked for, and now my box is hamstringed because they pulled out all the perfectly functional tools that ran things normally before 2014. Cool. That is a cool and normal way to distribute a serious operating system.) The advantage to Debian taking this Option B path is that at a minimum they will acknowledge that other init systems exist and their OS should still be able to boot with what it's been given.

This means that Debian, in some small way, can still function outside of the narrow purview of how Lennart Poettering thinks you should run your box, even if you have to mix the malt and the yeast yourself at home. It's becoming increasingly common, expected even, that a distro will switch to systemd and watch everything start breaking, and as we've seen, the only way to keep systemd working on your distro is to keep adding more systemd. Not even Linus trusts it and that was back in 2017.