For me it was the scope creep. Systemd is turning "init" into a framework of all the vulnerable and bad ideas that Microsoft moved away from after Win95/XP. binfmt mount, intercepting and changing the behavior of DNS, polkit implementation, changing user authentication, so much more than I could put here. There are many desktop concepts being shimmed into servers that are simply not appropriate for a lean mean web machine.

The good bits that systemd brought into the mainstream such as cgroups and lxc do not require systemd. They can be implemented independently. The watchdog timers and unit files were not a new concept either and did not require systemd.

> Systemd is turning "init" into a framework of ...

This is conflating the systemd project and they systemd init system. Most of the things you mention are seperate systems (systemd-resolved,logind, polkit, etc.) that are part of the systemd project and interoperate with the systemd init system, but are not part of the init system itself.

Agreed and the conflation is somewhat intentional. When you install a system, you get all of that. Custom kickstart files can strip away some of it. For the longest time, you would get polkit regardless. The rpm spec file was changed about a year or two ago so that it can be removed if someone did not exclude it specifically. To be fair, each OS maintainer is including or excluding bits of systemd in the default configurations, so that is not entirely systemd's responsibility. Every year systemd appears to be subsuming more and more system functionality.

Is it correct to even say that systemd "brought" cgroups and lxc? They seem like fairly independent projects.

systemd did bring them mainstream, but yea cgroups were around for years before systemd was a thing. But they were mostly independently managed by some small daemons that did things based off rules and other things like that mostly. Systemd changed how they got used, primarily because multiple management systems working with them tends to cause issues, but using them for low impact isolation and tracking of daemons automatically really turned them from something you'd independently setup to something that brings a lot of utility for just about every use-case everywhere.

You can still use cgroups independently with systemd, but it's recommended that you use a service and the delegate option to have systemd create a cgroup hierarchy and also know that it shouldn't mess with it after creating it. This lets you have your cake and eat it too if you have a case that systemd doesn't handle (I'm working on a setup with this myself for a coding sandbox setup).

I think Docker had a bigger influence on cgroup use than systemd.

I disagree because everybody who uses Ubuntu is using systemd, but only a fraction of them use docker.

Ubuntu uses snaps heavily bringing cgroups to play.

I agree with you and edited my wording.

Sigh, this argument just has to come up in every discussion on Systemd. Anyone who dare to be critical about Systemd is apparently just a Luddite afraid of change. You know what, I have no problems with change at all, only when the change is to something worse.

There doesn't seem to be any single, general, perfect answer.

I use systemd across distros, and am now confused when I run into an old SysV system.

When I'm sufficiently advanced to bump into one of these corner cases, it will be a Good Problem To Have.

The market penetration of systemd is about as good an empirical validation as can be had. How soon until it's codified in Posix?

Do you have concrete evidence that systemd is in fact worse from a technical perspective?

I'll readily admit that systemd isn't perfect, but my overall experience is that it is better in many ways to its predecessors, and did solve real problems.

And when I referred to "systemd hate" I was not referring to healthy criticism, but to those who take very chance to claim that systemd never should have been invented and their init system of choice is clearly superior. Rather than, say trying to make systemd better, or make their init system fix the problems that systemd was designed to remedy.

Something bothers me when they talk about fear of change. Some changes are consensual, some are mostly agreed upon organically and then you have cases like systemd who fueled lengthy debates. I don't like to ignore this as "fear of change".

If we're not afraid of change, Let's change away from systemd.

There was a switch away from SysV init for particular reasons, not change for the sake of change.

You know, everyone says this but every server I worked on (several thousands) which used sysvinit I cant remember any issues with startups that couldn't easily be scripted around.

I still dont understand what issues are fixed with systemd and I am aware of many it has created.

I am not convinced every sysadmin could ‘easily’ script around init issues on the servers they manage, but I’ll give you that.

The real issue isn’t with servers, it’s with desktop systems and laptops. When users plug in a USB sound card or plug their laptop into a dock, they don’t want to (and likely couldn’t) “easily script around” that; they expect an audio device, network connection, video card to be created without any user intervention, and go away when devices get unplugged.

Making a set of init scripts (and surrounding unload and reload scripts) robust against insertion and removal of any of many different devices isn’t easy even for init script gurus, and would lead to duplicated code for detecting and handling the various load/unload conditions.

That, I think is the primary reason Apple went with launchd. Systemd took that idea. There’s nothing wrong with that.

The main issues with systemd, IMO are a) initially it was buggy, and b) tremendous scope creep.

>The real issue isn’t with servers, it’s with desktop systems and laptops. When users plug in a USB sound card or plug their laptop into a dock, they don’t want to (and likely couldn’t) “easily script around” that; they expect an audio device, network connection, video card to be created without any user intervention, and go away when devices get unplugged.

Bingo !

Folks who know, and I mean really understand how to run servers know how to script init.

Folks who use Linux on the laptop / Admin Ubuntu do not and systemd makes them able to do stuff "most of the time"

There is no reason to force systemd as the default for servers. You dont plug things into servers and in fact you dont want some service monitoring servers so someone can stick something in a server and start rooting around it.

Unfortunately linux often STILL doesn't handle plugging and unplugging devices very well and it kind of seems like this has gotten worse not better with systemd.

Also you seem to be conflating dealing with devices with initialization of the system. Dealing with such devices has insofar as I'm aware always been handled by c code in and out of the kernel whereas at one time initialization of services and orchestration of components was handled by a scripting language.

This is to say that a bash script may have brought up different components and services but that c code that makes up the component is in charge of actually managing said device.

Its obviously feasible for both c (or any other language) code and orchestration of start up and shut down of services to be buggy but its not equally easy for end users to fix their own problems in all cases.

Ideally bugs get reported to those who are most capable and the underlying code is corrected however if said labor isn't paid to work on their project hours to do so may be in short supply and it may frequently fall on users to lend a hand.

This is a numbers game. If you have 10000 users and 10 of them are qualified to solve such problems you may be lucky to get the help of 1 to submit patches or post a solution to a problem on a forums for others to use before the upstream problem is fixed.

If 100 are qualified you are 10x as likely to find help to solve a problem. I have on many occasions come across a solution months or years before an official upstream solution came into being. You are suggesting that most sysadmins might find it challenging to solve their own problems. They don't always have to. Merely having comprehensible user friendly systems make it more likely that one of their fellows can help them do so and more likely that such solutions travel both laterally between users and hopefully upstream solving the problem for all.

Desktops and laptops are a tiny and insignificant minority of Linux installations, and almost completely related to why Linux is popular and important.

To what?

RunIt, say.

I suspect the OP is referencing Void Linux[1] which makes use of runit as its init system. If not, it's the first thing that came to mind.

I'm not sure it's necessarily a better solution as it requires more manual interaction out of the box (namely creating symlinks by hand among other duties), but that might be argued as a feature. There appears to be a wrapper or two out there to automate away some of the tedium.

[1] https://voidlinux.org/

s9

What should someone google in order to find out more about this? (i tried, i got lots of information about the samsung phone, even with -samsung and various incantations of 'init', 'processes', 'linux', etc)

I think the OP meant s6 and not s9.

runit, s6 and also nosh are all daemontool-style init systems, which have a somewhat different idea how to do things than systemd all, but all are inspired by the original daemontools package.

s6 and nosh have decent overviews:

https://skarnet.org/software/s6/ https://jdebp.eu/Softwares/nosh/guide/introduction.html

The original daemontools: https://cr.yp.to/daemontools/faq/create.html#why

I'll let others decide whether these are better or worse than systemd. I go with whatever my distro would give me, since picking a different init system is too much work...