Just saw dolphin's blog post on systemd-shim

[asqwerth]

It's been publicized on Distrowatch.

From what I can see, using sysV alone (like antiX or pclinuxOS) is not that much an issue; the main issue MX faces is trying to continue giving users the freedom to choose between sysV and systemd on the same installed system.

And the shim package is needed for that.

Are there no other users/distros that use the shim?

[Adrian]

the main issue MX faces is trying to continue giving users the freedom to choose between sysV and systemd on the same installed system.

Just a small note about this, according to the poll I started viewtopic.php?f=94&t=49723 (not sure how statistically significant) 9% of our users use systemd in one way or another, we don't want to abandon them.

Not sure what other distros do, it's a very good question, unfortunately some distros were very quick to take decisions that abandon the smaller section of users -- without a very good reason I would say, like for example giving up 32bit support, so I suspect that many distros either went with one or the other init system.

[dolphin_oracle]

No one else uses systemd-shim as far as I can tell. And I think we were the only ones to ship with both systemd and sysvinit on the same iso.

systemd-shim was originally a canonical project I do believe. It hadn't been updated really since 2016 and that's only really affecting debian now.

The shim mostly affected session management with logind, but all that is largely replaced with elogind now (antix uses elogind).

[manyroads]

Without any specific knowledge basis, the following thought comes to mind...

Would it not be possible, if all else fails, to offer both a systemd & non-systemd variant of the MX distro. If it is, then neither population would be abandoned... Although I assume switching between the two in the same install would be precluded.

I'll stop thinking now...

[Head_on_a_Stick]

The elogind package conflicts with systemd:

Code: Select all

root@shinken:~# aptitude why-not systemd
i   elogind Conflicts systemd
root@shinken:~#

And at the moment in buster the user needs to be added to the input group to gain access to the keyboard and mouse/touchpad etc under sysvinit — this would not be advisable for a multi-user system because input device snooping then becomes a trivial matter.

FWIW, I don't think sysvinit is a sensible choice anyway because the init scripts supplied with the packages aren't really being tested any more:

https://lwn.net/ml/debian-devel/2018101 ... piware.de/

https://lwn.net/ml/debian-devel/b027c97 ... 7@bzed.de/

https://lwn.net/ml/debian-devel/874ldlc ... eyrie.org/

[manyroads]

[...]

FWIW, I don't think sysvinit is a sensible choice anyway because the init scripts supplied with the packages aren't really being tested any more:

https://lwn.net/ml/debian-devel/2018101 ... piware.de/

https://lwn.net/ml/debian-devel/b027c97 ... 7@bzed.de/

https://lwn.net/ml/debian-devel/874ldlc ... eyrie.org/

@Head_on_a_Stick so this begs the question "which non-systemd init script 'might' be sensible?" I see a couple of OpenRC based distros (like Artix) out there. Is that, in your opinion, a better init script?

[Head_on_a_Stick]

which non-systemd init script 'might' be sensible?

OpenRC can use sysvinit scripts but the reverse is not possible (AFAIK).

[KBD]

I've made clear that I'm not a fan of systemd, but I like having the option. Indeed, I'm booting into systemd on one of my computers right now because of an issue with wifi. I noticed randomly at boot sometimes my wifi wasn't connecting, so just out of curiosity I booted into systemd and no more wifi issues. In the past I had a problem with brightness, and systend boot fixed that.
I'm concerned that issues may crop up in the future where having that shim for systemd might fix problems that would otherwise be difficult to correct. Like I said, systemd philosophy causes me great concern, but we may run into big issues down the road as systemd will increasingly cause more work for devs just to keep MX running well without using systemd, and perhaps cause users to have to use other distros that have systemd because of unforeseen problems.

[rasat]

Same as KBD. I hope MX can keep both sysvinit and systemd in same iso. Not only for user choice, but also as security option. There are/were cases when either one fails during booting. In my case with earlier kernel version running in Dell inspiron 5567.

[KBD]

If it turns out to be impossible to use the shim in Buster, I'd suggest either detailed instructions in the wiki for installing systemd on the next MX based on Buster, or, if possible, an option in MX Tools to run a script that installs systemd for users that need it.
Edit: I'd suggest two ISO options for the next Buster-based MX, one for sysVinit, one for systemd, but not sure how much more work that would entail.