Just saw dolphin's blog post on systemd-shim

[anticapitalista]

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.

[manyroads]

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

[asqwerth]

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.

[BitJam]

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

[manyroads]

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.

[KBD]

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.

[manyroads]

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:

[Jan K.]

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

[manyroads]

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

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

[Head_on_a_Stick]

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?