It totally is. I see the appeal: it's, on the surface, easy. But this comes at a cost.
Turning Linux into Windows by replicating svchost.exe shouldn't be applauded by the Linux community.
I'm glad the BSDs are still out there and I'm glad there are still non-systemd Linux distros out there and I'm even more glad some systemd distros haven't completely shut the door on moving back away from systemd.
Do I write a systemd service once in a while? Yup, I do. Is it easy? Kinda, at first. But we shouldn't be too excited about superficial simplicity. Something has been lost in exchange.
The monster systemd squid spreads its infinite tentacles on everything it touches while being PID 1, making sure that a countless number of current and future exploits (or backdoors) are possible.
We've got Linux's PID 1 (for most distros) controlled by a MS employee, who replicated Windows' svchost.exe. And people are all excited?
I personally cannot wait for another, better, init system to come out and replace systemd.
Meanwhile I'm glad there's choice: OpenBSD, Alpine Linux, Devuan, etc.
> Turning Linux into Windows by replicating svchost.exe shouldn't be applauded by the Linux community. ... We've got Linux's PID 1 (for most distros) controlled by a MS employee, who replicated Windows' svchost.exe. And people are all excited?
systemd was pretty consciously patterned after launchd, not svchost. The goal was, and for good reasons, to make Linux behave like a more integrated Unix-like that already existed: MacOS.
Benno Rice has an excellent presentation on systemd that's worth watching through to the end; unlike most of the table-pounding (and "it's just svchost.exe!!" is exactly that), he provides what I think is a pretty fair--and, interestingly to me, a BSD-grounded--view as to where systemd is strong and is weak. https://www.youtube.com/watch?v=o_AIw9bGogo
The thing is, I own a mac, and I've never had to touch launchd.
I've hit severe systemd bugs on 100% of the linux desktop installs I've set up in the last 5-10 years. (examples: "x/wayland session management is broken", "uncached DNS takes 10 seconds to resolve", "this service is masked, and none of the force-unmask paths work", "omg lol no more logs for you", and so on).
The fact that pid 1 can even be involved in those sorts of userspace bugs shows how broken the architecture is.
> (examples: "x/wayland session management is broken", "uncached DNS takes 10 seconds to resolve", "this service is masked, and none of the force-unmask paths work", "omg lol no more logs for you", and so on).
I used to be release manager for a Linux distro. Mostly, such issues were integration problem and not a systemd problem. In some cases that I worked on, the integration wasnt well-thought, or it was done in some amateurish way which needed actually some extra hours of professional software development to make it "production ready". Unfortunately part of the process of working with open source.
This is one of the downsides of systemd from a community perspective--it's not that it doesn't work; it largely has, and has consistently, for most people and most distros who've adopted it pretty much since the jump! But the bonkers level of partisan poo-flinging by folks who will not simply go off to Devuan or whatever has inculcated an automatic assumption that a system built by some of the most talented folks working in the Linux space simply has to be broken whenever they have a problem.
By being ambitious, systemd brought it on itself, but it's frustrating because the conversations don't go anywhere and don't matter.
Take a look at S6 and dinit. They both embody what systemd was intended to be while keeping the portability, technical simplicity and loose coupling.
You might also want to consider Void and Chimera. Void has a unique combination of technical simplicity, functionality, rolling updates and low maintenance along with some beefy repos. It's close to being the perfect desktop Linux to me.
Chimera uses dinit, which is closer to systemd's features, whereas Void uses runit, with is more of a minimal viable init + rc.
They are very interesting for sure, but I'm waiting for the S6 successor that's in development before I switch from systemd. There are a number of things systemd offers that are either easier, better, or unavailable in other tools that keep me happy for now. If the successor ends up being good but still missing those features, I'll try my hand at implementing them for the greater good.
Are you referring to svchost.exe, the performance hack that allows multiple Microsoft-supplied services to share a single process, or the Service Control Manager[1], the Windows component responsible for starting and stopping Windows services?
If the former, I agree that trading off service process isolation for reduced start time and lower resource usage is an optimization that has probably outlived its usefulness and should not be emulated on systems that aren't severely resource-constrained.
While systemd arguably bundles too much functionality into its own process, AFAIK it doesn't include any mechanisms to support svchost.exe-like behavior in services it controls.
If the latter, I'd argue that the SCM is actually quite minimalistic, especially in comparison with systemd: it's responsible for starting services in the correct order per a supplied list of dependencies, restarting failed services, notifying services of important lifecycle events — service configuration changes, shutdown requests, network interface status changes, etc. — and that's about it.
It totally is. I see the appeal: it's, on the surface, easy. But this comes at a cost.
Turning Linux into Windows by replicating svchost.exe shouldn't be applauded by the Linux community.
I'm glad the BSDs are still out there and I'm glad there are still non-systemd Linux distros out there and I'm even more glad some systemd distros haven't completely shut the door on moving back away from systemd.
Do I write a systemd service once in a while? Yup, I do. Is it easy? Kinda, at first. But we shouldn't be too excited about superficial simplicity. Something has been lost in exchange.
The monster systemd squid spreads its infinite tentacles on everything it touches while being PID 1, making sure that a countless number of current and future exploits (or backdoors) are possible.
We've got Linux's PID 1 (for most distros) controlled by a MS employee, who replicated Windows' svchost.exe. And people are all excited?
I personally cannot wait for another, better, init system to come out and replace systemd.
Meanwhile I'm glad there's choice: OpenBSD, Alpine Linux, Devuan, etc.