Debian and init system diversity

Just been reading Debian’s about to vote regarding explicit official support for init diversity. Some years back they opted for systemd as their init system. I’ve not had single problem with systemd myself personally, though can see why it could become a problem if it’s relied on exclusively.

Also some years ago, the Devuan fork of Debian started, basically to be a version of Debian that remained independent of systemd. As far as I know, the very popular MX Linux which is based on Debian officially supports init systems other than systemd and they seem to be doing well…

I’d really like to see some unity here, with Debian officially supporting init diversity and other distros which have already progressed with that contributing!

I know vanilla Debian doesn’t seem to have a strong following on DLN but Ubuntu and its flavours seem to, and this will probably affect them too.

Do you think Debian should officially support init diversity (with all the extra work that goes into managing packages) or keep their workload lower (in theory) by going exclusively with systemd?

2 Likes

I’m not a zealot in either the systemd or anti-systemd camps, I can see arguments in favour of both, but lack the in-depth knowledge to make a logical, objective, choice based on factual information.

My distro of choice is MX Linux (non-systemd init, but available for those things that use it via some “magic” shim). I had Devuan on a machine for 6 or more months and had no problems (except it was based on Stretch so older versions of a lot of thing - but hey, they worked just fine for me).

Other distro I currently have on machines are Debian Testing, ArcoLinux, Manjaro, EndeavourOS, Peppermint 9 and Sparky Linux 6 (based on Debian Testing). All those use systemd and all work just fine I’ve never had (as far as I know) a problem caused by the init system.

Systemd seems against what I “grew up” computer wise and Unix/Solaris wise through the 80s and 90s, listening to the mantra of “do one thing, do it well, make things talk to each other so they can be strung together to do complex tasks”… computer Lego, more of less anyway. BUT, I ask myself, how much of that approach was forced on them at the time by the hardware limitations they were working with. They didn’t have gigabytes of RAM, terabytes of mass storage, gigahertz processor speeds, they had kilobytes of RAM, megabytes of mass storage (tape or disc or paper tape) and kilohertz speed processors. If they had had the machines we have, well, the Unix way may not have developed and systemd or not systemd wouldn’t be a question, but I’m sure there would have been a different question because there’s always a question to argue over.

My view, I don’t care, use what works for you. If you do have a philosophicalbias one way or the other fine, pick from what’s distros are available to your camp.
.

2 Likes

I’m with you on this one. I can see arguments on both sides.

I do like that systemd can starts services in parallel, though. Although, I have not put two systems running the same services side-by-side to see how much faster systemd is. I’m not really sure it would matter in the end anyway.

1 Like

Let’s change that then! :wink:

Personally I do not care about my init. If it boots I am fine with it. I see benefits and disadvantages on both sides but I use the ‘default’ systemd with no apparent problems, only some minor hiccups as usual like when systemd wants to stop a service on reboot or shutdown and you are in a loop. Sysv never had this but other than that I also prefer the syntax of systemd to enable and disable services. Yeah, it is huge and I loved to read the log files in text form.

But as I said I do not really care. Of course Debian being the universal operating system it would likely be unfortunate to lose other init systems. But it could also be for the better, I am not sure.

1 Like

I have recently came into the scene just December of last year and I dont really understand what the issue here is. I have used MX and it seemed fine. I know it uses SysVinit and had the capability to run systemd. I have also used Ubuntus and Manjaros based systems and I really cannot tell the difference.

Is there a good analogy for this? Is systemd like a spork? Do everything and centralize everything?

Should I legitimately care as a desktop end-user? Is the server/enterprise any different? Are these philosophical differences at best?

2 Likes

My 2 sheckles: I wouldn’t worry about it. At the very least, I haven’t. The issue is partly philosophical, some initial bugs/technical disagreements and partly (mostly?) a communication problem.

While looking up articles to help you research the issue provided little to nothing of substance now that we’re 5 years on from the original controversy. Here’s a couple of quickly googled posts in order that I read them, not in effectiveness:




(Though, for the impatient, or if you like a nice tidy list, like I do, then check out the last one.)

3 Likes

In my opinion, no. :slight_smile:

5 Likes

I have no preference. However, I do like having choices. I have used OpenRC, runit and SystemD. I say let the user have the option to choose.

2 Likes

Yeah init diversity please :slight_smile:

I think systemd is a good alternative to the duplication and prone-to-error approach of writing a shell script for every service and implementing start/stop/restart/reload n times. Yes, you’d work with it if you had to write scripts, having a skeleton service file to start with etc, but it’s still not ideal.

What I take exception to personally with systemd is that it’s trying to do all of the OS outside of the kernel and userland software, and it doesn’t follow the UNIX philosophy.

Control of my own computer is the reason I use Linux, if I didn’t mind asking Master Control Program every time I wanted to do something I’d be using a Mac.

I’m keen to try runit, I’m even keener to see each part of systemd be it’s own thing that you can use or not use, and for files in /etc to be the source of truth and not just a view of systemd’s config that I can’t completely control.

2 Likes

Longtime Debian user here, for 20 years.

I, for one, feel that it would be most sensible for Debian to just stick with systemd, for the sake of saving enormous amounts of highly-precious volunteer labour to accommodate and support interchangeable init systems.

Then, should the systemd-pocalyse ever actually arrive, then systemd can be forked at that time, if necessary and some relatively minor changes can put it back on course (should the mainline systemd project not want to do anything differently). Please don’t forget that forking always remains an option for addressing systemd woes, which actually might materialize.

I was apprehensive of systemd myself, at first (and many Debian users are characteristically the conservative type), when Debian first switched to it, many moons ago. But systemd has earned my trust as being super stable, and I haven’t had any problems with it. I’m content with things the way they are now, and would prefer not to be subjected to yet another change.

I say, if it ain’t broke, then don’t fix it. Debian has plenty of other larger fish to fry, such as revamping their bug tracking system. They have plenty of other, more pressing, outdated project infrastructure that they could be modernizing instead.

I acknowledge that there are many long-standing, passionate Linux users who really, really treasure the Unix philosophy. I too believe in that phosophy, but I feel there is also a time, a pragmatic time, to chill out a bit (such as, for the sake of moving forward in popularity). Of course, these fellow, esteemed Linux users have several other great choices available to them, for distros who offer init system alternatives to systemd. But I don’t think Debian needs to be the king distro of that group of “alt-init-system” distros.

2 Likes

Thanks everyone, so far, for your views :slight_smile:

@TerryL, very interesting reflections. I agree from user perspective, systemd works just fine. My discussion is more about where we might hope Debian’s decision might go, as it could have knock-on effects on more popular distros and fundamentally, on what might become an eventual assumption or expectation of dependence on systemd (and possible wider implications of this for other applications), and systemd, as you say, goes against the Unix philosophy, whose validity today can also be debated.

@Mr_McBride, I think the speed advantage in start-up due to concurrency, might be a significant reason for adopting systemd in many distros that now use it.

@vinylninja, I’m with you all the way in supporting vanilla Debian Stable, though the wealthier members of our community enthusiastically able to invest in the latest hardware may differ due to Debian taking a long time between releases, and basically freezing the kernel and most applications during that time except for security updates. I think sysadmin experts do cite some of the advantages you mention for systemd configuration - more uniform and therefore manageable, probably. I’m also with you in the hope that Debian retains official support for init diversity though.

@astronautsupplier, definitely there’s a philosophical issue here, though my primary concern is the practical consequence either way. If Debian official supports init diversity, more work could be necessary to ensure applications can be built without being dependent on systemd, for example. If Debian does not support init diversity, there are longer-term issues that I think some people don’t like, such as over-dependence on a complex system, which if it starts to go wrong, could then become a big problem.

@TRST, thanks for your reflections and references. I haven’t followed-up those particular ones, though I will when able :slight_smile: For me it’s not just a matter of systemd. It’s already been adopted by most distros. It’s Debian’s position on systemd and crucially on alternatives, that I think matters a lot because of Debian’s position amongst other distros.

@Leviticus, I agree with having choice. I’m thinking about maintainers at Debian and their choices - which will eventually affect end users too.

@david.smyth, good - I agree on keeping the diverse option :slight_smile: I definitely agree with the idea of possibly modularising systemd, though I don’t know enough about it to know if that’s actually possible or not. After I’ve built the two versions of LFS (systemd and non-systemd) I’ll know more though!

@esbeeb, my hat off to you - fantastic to hear from such a long-term Debian user! It’s my favourite operating system, though when I started using Linux back in about 1995, it was Slackware, then RedHat, then Fedora I used, before not using Linux for some years when I changed profession, then returning to it and having used Debian mostly since approx 2013. Some very practical reflections you offer, on possibly forking systemd if ever necessary, and redirection of resources into areas that the Debian project absolutely needs them for, I agree, such bug-tracking system. Devuan seems to be pioneering in trying to establish an alternative to Debian over the systemd issue, though I’d be happier if somehow the communities could come together and work at it, as a part of me still favours the diversity option :slight_smile:

2 Likes