Debian May Need To Re-Evaluate Its Interest In "Init System Diversity"

[audir8]

Apple can maintain launchd alone, they don't have distros to deal with. It's up to the distros to decide how much they want to use systemd and it makes sense for debian to be only systemd if they want.

That said, having used systemd on Ubuntu and having not used it on Gentoo: I've yet to see a feature in systemd that isn't currently well done by existing programs I use on Gentoo. I don't want the init system dealing with cronjobs, cgroups, logs, sockets, or even services I don't want to start at boot. I don't like some of the defaults systemd has, and thus also don't like giving up any control over configuration of what I might want to do. Any init script has root, so it should be the app/user which decides which cgroup config to run in and the init system should not be involved at all. Break all of this functionality up into completely separate projects, and let app developers/distros decide if they want to use it.

I wouldn't mind writing init scripts in a declarative way with better dependency management/parallelism, but that's really all I want from an init system. Fixed device naming works just fine on eudev/openrc/elogind, and I honestly don't know why I would want systemd on Gentoo.

Pulse audio for what it's worth, does enable features I use like pulse effects. The same is not true for systemd. It's bloat I don't need, and get by without just fine using plasma/kde on the newest kernel/gcc/etc..

[spstarr]

The thing is, all those whining about systemd need to understand, that the old sysvinit scripting just does *NOT* scale anymore. I need cloud-init, I need containers, I need this, I need to know if this specific SSD disk UUID is available, I need this... OpenRC might be the closest, but if it was going to be the better init system why did Debian not default to OpenRC instead? We know Fedora/RHEL was forced to use systemd given the alignment of Red Hat knowing about systemd and its goals.

Nobody has yet given a reason why OpenRC should be used over systemd and, given some the complexities I've had that systemd solved, why having to write shell scripts to implement user privileges (sudo anyone?) makes any sense?

Systemd's unit 'ini' formatting is ok, I can live with it, but what it *does* give me is a consistant front-end interface to any shell scripts/executables I need to run - while not having to manage user privileges in scripts themselves or having to probe udev or whatever to find out of a device exists. Or without me having write all those systemd units just to manage dependencies for finding resources.

Systemd wraps those up so I can expect them to be there.

I remember the horrors with sysvinit and having to manage hacky init scripts with initramfs, all the race conditions that, just that one time the init script hung the whole boot up... at least in systemd if there's going to be a hang its going to drop into an SOS state for me to look at why.

I don't want to go back to those days, and until someone takes some of the good ideas with systemd and or marries them with OpenRC that hides all the low level detection/discovery/recovery of resources/events, I don't want to hear any complaining.

[andyprough]

Unfortunately the problem is... systemd has a goal of making itself a hard dependency all over the place to drive out alternatives through brute force. Same as pulseaudio... it's super annoying to setup a non pulseaudio desktop for no valid reason. However puseaudio worms it's way into software and then later native audio support is dropped for example with Firefox.

If systemd was a launchd alike... hey that'd be great and we could use that but it isn't it's a monster be all and end all project that nobody should want.

If you want to use a Debian-based system with no systemd and with alsa instead of pulseaudio, I would recommend antiX. Only difference is in order to start Firefox with sound you need to invoke it with the apulse cli utility: $ apulse firefox

Firefox ESR works with alsa without having to use apulse, as does Waterfox. Alternatively, you can do what I do and compile firefox with alsa support.

[andyprough]

Ok at the risk of feeding the trolls... what's with this fetish of what they call "init" systems? No-one seems to whine for "choice" between 10 incompatible and broken system call ABIs, why should the event, configuration and services manager be any different? Besides, Linux has IMHO a very pressing and urgent need for de-unixifcation and systemd is probably a very good place to start.

Linux is not an OS, it's just a kernel. So, what you are describing that you want is available on some distros, not on others. There is nothing unifying about systemd, other than that it makes it that much easier to distro hop from one systemd distro to another. It certainly does nothing to unify all GNU/Linux distros into one common experience.

[andyprough]

For the most part systemd makes things work better, but as controversial as that opinion may be, I would say we would need (something like) systemd EVEN IF it was worse than the existing solutions. Why? Because the Linux community must learn the value of having ONE TRUE WAY of doing things if it ever wants to reach any noticeable relevance as a desktop OS.

Again, Linux is not an OS. There are a huge number of projects using the Linux kernel for which systemd is not an option, and would make no sense whatsoever.

[spstarr]

Again, Linux is not an OS. There are a huge number of projects using the Linux kernel for which systemd is not an option, and would make no sense whatsoever.

Yep, Linux is the kernel only. We're not a BSD where the kernel and userspace are together the 'OS'. I sometimes wonder if that was a mistake when GNU/Linux was starting to be pulled together early on, if Linux had the core set of userspace libraries/utilities under one common project with the kernel.

Though, even today, GNU libc can be compiled to match a subset of kernels to support new syscalls etc, its still not uniform though.

[audir8]

...Because the Linux community must learn the value of having ONE TRUE WAY of doing things if it ever wants to reach any noticeable relevance as a desktop OS.

This can be cgroup-utils, syslog, cron, etc.. in many cases the user/developer api for these services is same even with different implementations. The average user doesn't care about any of this, they care about what udev/networkmanager/pulseaudio/xrandr can do for them. Make that functionality consistent with decent fallbacks over rolling or monolithic upgrades and there would be less distro hopping and more Linux adoption in general. You can have a same-looking networkmanager almost anywhere and it works! More of that please.

The user/dev experience with systemd is worse in some cases (wtf does masking a service need to exist?), and marginally better in others (logging). If you want to make an improvement, you can do it with better APIs all around. There is no need for a user or developer to use most of the functionality in the systemd repo if they just want to deploy a service. Interfacing with the Linux system in general is a much bigger problem, and cgroups is about the last place I would start. Do you know what would be the first? f*&^ing temperatures and cooling!

[jacob]

This can be cgroup-utils, syslog, cron, etc.. in many cases the user/developer api for these services is same even with different implementations. The average user doesn't care about any of this, they care about what udev/networkmanager/pulseaudio/xrandr can do for them. Make that functionality consistent with decent fallbacks over rolling or monolithic upgrades and there would be less distro hopping and more Linux adoption in general. You can have a same-looking networkmanager almost anywhere and it works! More of that please.

The user/dev experience with systemd is worse in some cases (wtf does masking a service need to exist?), and marginally better in others (logging). If you want to make an improvement, you can do it with better APIs all around. There is no need for a user or developer to use most of the functionality in the systemd repo if they just want to deploy a service. Interfacing with the Linux system in general is a much bigger problem, and cgroups is about the last place I would start. Do you know what would be the first? f*&^ing temperatures and cooling!

I think a more fundamental problem is that the systems you mention (cron etc...) follow the "everything is a text file" concept which was perfectly fine... in the 1970s where computers were static, centralised, had a full time sysadmin and the concept of third-party user applications didn't exist. But today we need a clean break from that and move to an era where everything is an API instead. Cron for example has no API at all. With cron there is no way whatsoever the developer of an application (I'm specifically saying DEVELOPER, not the admin!) can say "I need this function to run every 6 hours" for example to update F/X rates and be sure that it's indeed going to happen as required. Note also the deliberate use of the word function as opposed to shell script. Plus the sacrosanct "choice" means that whatever clunky and inadequate ersatz the developer will implement to work around this stupid limitation, it may not (and probably will not) work anyway for totally arbitrary and unpredictable reasons.

Put another way, Linux was born out of Unix which was a sysadmin's OS. It's imperative that it becomes a developer's OS instead.

[Templar82]

No-one seems to whine for "choice" between 10 system call ABIs,

If we were forced to replace our current working ones with a fragile bloated one you would probably see that.

[cb88]

If you want to use a Debian-based system with no systemd and with alsa instead of pulseaudio, I would recommend antiX. Only difference is in order to start Firefox with sound you need to invoke it with the apulse cli utility: $ apulse firefox

Firefox ESR works with alsa without having to use apulse, as does Waterfox. Alternatively, you can do what I do and compile firefox with alsa support.

I do this on Gentoo... but yeah, I may give MX Linux a try... I have downloaded antiX in the past... many moons ago.