MX Linux Forum

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?

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.

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).

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...

The elogind package conflicts with systemd: 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/

Head_on_a_Stick wrote: Mon May 06, 2019 10:00 am [...]

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?

manyroads wrote: Mon May 06, 2019 10:04 am which non-systemd init script 'might' be sensible?

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

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.

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.

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.

not sure how much more work that would entail

a whole lot...

rasat wrote: Mon May 06, 2019 11:18 am 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 wrote: Mon May 06, 2019 11:38 am 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.

It IS impossible (at the moment)

Sometimes in life -- and in Linux -- you just don't have a choice. systemd is what is being adopted going forward throughout Linuxdom. Sure, niche distros will stick to their never-systemd guns, but they will remain niche distros. Unless a solution can be found that can be maintained for the long term, now may be the time to relent and move on.

Is it worth it for MX to sponsor or take over systemd-shim maintenance ? How many debian subsystems/services will ship with properly tested (sysV)init scripts going forward ?

What are the implications of switching to systemd for antiX and MX (i seem to recall this may break the live features ?) Would it be more work to port the antiX live system to systemd ?

Sorry, i only have questions, probably like most users. Either way i am afraid there is going to be extra work for the developers to support buster.

systemD is definitely not something I want to see between me and the kernel...

And really wish MX Linux would stop supporting it... not to debate, just delivering my opinion.

Jerry3904 wrote: Mon May 06, 2019 11:56 am

not sure how much more work that would entail

a whole lot...

That's what I figured, so didn't mention it as a first option.

baldyeti wrote: Mon May 06, 2019 12:49 pm Is it worth it for MX to sponsor or take over systemd-shim maintenance ? How many debian subsystems/services will ship with properly tested (sysV)init scripts going forward ?

The systemd devs have already broken systemd-shim, are likely to break it again if development is resumed (since they really want systemd at PID 1) and we don't have the developers familiar enough with the internals of systemd to do that development ourselves.

Using systemd-shim doesn't help with init scripts. We would still have to deal with that issue either way.

Apart from a few active forum users (including devs), I doubt many of the 1000s of MX Linux users even know what systemd is, let alone have the knowledge to argue for it's inclusion/exclusion etc. So, I'll trust the Antix/MX team to do whatever they need to do to maintain the level of stability/reliability (and a few more ***ity's, security/simplicity/usability... etc ), that keeps many, including myself, using both Distros (bearing in mind any restrictions forced upon Antix/MX by decisions made by Debian).

So, as The Four Tops once sang; "Do what you gotta do..." (Yes, I'm that old that I remember The Four Tops )

Fork Debian Stretch and become independent, smaller (number of packages) and rolling (you already are sort of). If PCLOS can do it...

PS I don't know what is right for MX Linux so I just throw suggestions at the wall...

In one of my more unpopular posts/ questions here I asked if it wouldn't make sense to build future releases off of Devuan, rather than Debian, if staying systemd-free was essential. I'll repeat the question, put on my helmet & flak jacket and duck for cover.

Edit: Or perhaps offer two flavors of MX (Devuan and Debian) thus leaving the systemd non-systemd efforts to the respective root OS team(s).

There seems to be some misconceptions about Devuan.
For those that do not know, Devuan uses the Debian repos as its MAIN repo (but they hide it), just like MX and antiX do.

anticapitalista wrote: Mon May 06, 2019 7:02 pm There seems to be some misconceptions about Devuan.
For those that do not know, Devuan uses the Debian repos as its MAIN repo (but they hide it), just like MX and antiX do.

So much for my misconceptions...

manyroads, you are getting confused.

antiX live system - needs sysV init to work properly.
And antiX has been running on Debian repos all this while, and yet filtering out the systemd packages so they are systemd-free.
There's no need to discuss turning to Devuan just to be systemd-free. And Devuan doesn't not have the antiX live system.


If MX wants the benefit of the live system, it has to be based on antiX and use sysV. So that is issue 1.

Debian Buster - systemd-shim no longer maintained nor working. Means systemd and sysV cannot CO-EXIST on same installed system.

From my basic understanding of what anti and dolphin have said previously, antiX and MX CAN just run SOLELY on sysV in Debian Buster (without any systemd packages), except that:

1) certain applications that don't come with sysvinit scripts may need to be sorted out so their services can be started or stopped using sysV [for the majority of users who have just been happily running default MX without knowing anything about init managers, this doesn't appear to be a problem. It looks like a few of the VPN apps may require work, but fehlix appears to have cracked it]

2) snaps won't work since systemd is absolutely required for that (who knows why Canonical made it that way). [that's why flatpak support and UI is provided in MXPI]

So issue 2 is due to the current inability of init managers to co-exist on Debian Buster:
- any possibility of getting systemd-shim maintained and working again?
- if not, does MX come out with separate isos for sysV and systemd versions? Time, manpower, knowledge and willingness of the devs are major considerations.


The main question here is co-existence of init managers on the same MX iso/installed system. Again, Devuan is irrelevant to the question of co-existence since they don't do systemd at all.

asqwerth wrote: Tue May 07, 2019 12:49 amIf MX wants the benefit of the live system, it has to be based on antiX and use sysV. So that is issue 1.

I think we could get the live system to work with systemd. My big mistake when I tried before (2015?) was assuming systemd broke everything by accident. Now that I know they broke it all on purpose, I think I know how to fix it. OTOH, I'm very busy now with other things. Nor am I real excited about jumping in and playing with those who run around with sharp knives and don't play well with others.** Might as well get paid to work on closed source software.


** Systemd vs. the Linux Kernel

Torvalds’ reservations about systemd came to a head in 2014, when he refused to accept further contributions from Kay Sievers, systemd’s other co-founder. On the Linux Kernel Mailing List, Torvalds told Sievers that he was “tired of the fact that you don’t fix the problems in the code *you* write, so that the kernel then has to work around the problems you cause [….] This has been going on for *years,* and doesn’t seem to be getting any better [….] I am not willing to merge something where the maintainer is known to not care about bugs and regressions and then forces people in other projects to fix their project.”

asqwerth wrote: Tue May 07, 2019 12:49 am manyroads, you are getting confused.

[...]

Pretty typical, actually.
FWIW I have spent a few hours looking at the details of the issues involved and can say it seems quite the mess. If my skills were better, I'd take on some work & offer assistance. Sadly my skills are not that good. Oh well.

I'm probably reaching above my pay grade here, but I'm wondering if there can be a script or at least instructions to install systemd after the fact on an installed MX system based on Buster? I'm guessing sysVinit might have to be removed in that case? My biggest concern is some systems not working fully or correctly under sysVinit compared to systemd. I don't mind installing systemd after the fact if necessary, but I don't know if that would break MX, or if systemd can co-exist with sysVinit, or if sysVinit has to be removed to install systemd on Buster?

Obviously systemd is going to create headaches for us in Debian Buster.

KBD wrote: Tue May 07, 2019 11:02 am I'm probably reaching above my pay grade here, but I'm wondering if there can be a script or at least instructions to install systemd after the fact on an installed MX system based on Buster? I'm guessing sysVinit might have to be removed in that case? My biggest concern is some systems not working fully or correctly under sysVinit compared to systemd. I don't mind installing systemd after the fact if necessary, but I don't know if that would break MX, or if systemd can co-exist with sysVinit, or if sysVinit has to be removed to install systemd on Buster?

Obviously systemd is going to create headaches for us in Debian Buster.

I, also, wonder if it's not possible to skinny the 'active components' of systemd such that many/ most (?) of its data center functions are disabled unless specifically requested by a user (admin/ root). Per normal, I'm probably off-base.... :lipsrsealed:

Break free and join forces with Salix OS and Slackware....

Jan K. wrote: Tue May 07, 2019 12:03 pm Break free and join forces with Salix OS and Slackware....

And no one will ever be able to install the software...

asqwerth wrote: Tue May 07, 2019 12:49 am antiX and MX CAN just run SOLELY on sysV in Debian Buster (without any systemd packages)

As I mentioned earlier, if I try to run Debian buster with either sysvinit or runit-init then the graphical desktop does not work — no keyboard or mouse/touchpad inputs are possible at all and a hard reset is needed to get out of X.

I managed to get a functional graphical desktop by adding my user to the input group but this would not be a solution that MX could use.

So even if the shim was working and systemd & sysvinit could be co-installed then the graphical desktop would only be usable under systemd.

Have the developers managed to get input devices working on a Debian buster based box with sysvinit running as PID1?

Yes. You can run antiX on the Buster repos and there have been some pretty successful early work on transferring that to MX. It's nowhere near ready for public testing yet but there is definitely a functioning desktop.

Head_on_a_Stick wrote: Tue May 07, 2019 2:35 pm

asqwerth wrote: Tue May 07, 2019 12:49 am antiX and MX CAN just run SOLELY on sysV in Debian Buster (without any systemd packages)

As I mentioned earlier, if I try to run Debian buster with either sysvinit or runit-init then the graphical desktop does not work — no keyboard or mouse/touchpad inputs are possible at all and a hard reset is needed to get out of X.

I managed to get a functional graphical desktop by adding my user to the input group but this would not be a solution that MX could use.

So even if the shim was working and systemd & sysvinit could be co-installed then the graphical desktop would only be usable under systemd.

Have the developers managed to get input devices working on a Debian buster based box with sysvinit running as PID1?

**edit** see tim's note above

Excellent news, thanks for the information

manyroads wrote: Tue May 07, 2019 12:26 pm

Jan K. wrote: Tue May 07, 2019 12:03 pm Break free and join forces with Salix OS and Slackware....

And no one will ever be able to install the software...

I have enjoyed a couple of flirtations with SalixOS ("Linux for Lazy Slackers"), and even this non-techy technophobe was able to easily install and remove software using their slapt-get interface which looks and acts very much like Synaptic Package Manager! And they have a slack-build app called "Sourcery" that even creates slackware-compatible stuff that isn't in the repos - all from a GUI for us simple folk.

I know it's probably a lot to hope for, but I would absolutely love to see MX devs and Salix devs get together and learn from each other, since both distros seem to have the same mission. If and when systemd becomes unavaoidable in MX (and maybe even antiX God forbid), a hugely improved SalixOS that can use MX's awesome tools would be awesome for those of us not-very-technical users who want to avoid systemd for as long as possible.