Comment Re:What is systemd exactly? (Score 1) 765
The problem is that a lot of the behind-the-scenes tinkering and established-over-decades code in scripts is going out of the window and one huge set of binaries are trying to replace it WHILE also stepping in to replace an awful lot of other pseudo-related systems.
There is no such "established-over-decades code in scripts" in the real world, which is why sysadmins around the world constantly had to tinker with these scripts. This is also the exact reason why if no one cares about them, these init scripts will wither and die.
The most important plumbing init scripts are flawed by design, init is flawed in a dynamic environment like the one created by the Linux kernel, which is why everyone wanted to flee it since a long time. But sysadmins and distro makers couldn't agree on anything until systemd.
Systemd is tying into everything from initial boot to how to configure your soundcard.
Actually, systemd doesn't tie into how to configure your soundcard, but if you don't understand what people are talking about, especially systemd opponents, I see why you would think that. You must believe pulseaudio is part of systemd I gather.
On the one hand, you have Windows etc. who've always done it this way - you can't play with the boot process there at all and the closest you can get is playing with Automatic / Delayed Start / Manual on a service, or RunOnce lists. On the other hand you have generations of UNIX admins who are recoiling in horror at the idea of having lots of unaccountable, undebuggable binaries doing these jobs where scripts have always played their part.
I don't understand why you're talking about Windows here as a party, you're not making any sense.
systemd is free software, so I assure you that you don't have to deal with undebuggable binaries, as the code to these binaries is readily available. Exactly like the source code of sysvinit or the numerous daemons launched by the scripts you're talking about.
Perhaps you believe the init scripts themselves were serving as daemons, but that's rarely the case : these scripts were just there to try (badly) to understand the context to then launch "undebuggable binaries".
It's against the "one tool does one job, and does it well" philosophy, and quite scary that so much of your system working is reliant on systemd behaving as expected.
I don't understand what is scary about that. Your system depends on lots of binaries working as expected, starting with your bootloader, your kernel, your daemons,
That's the job of a sysadmin, I can assure you they're not scared at all providing they know what they are doing.
I can't be the only person who's been glad when a kernel has completely failed to do anything useful because of a broken system and just dropped you to a root bash shell to let you fix it.
Actually you can still do that with systemd, but even better than before, especially when your keyboard is not qwerty or your character encoding not ASCII.
On the "I want my desktop to just work" side, they're generally cheering for systemd. On the "I want my desktop to do what I say and let me choose what happens at all stages" side, they're generally against it.
Why? I'm on the second side and I do exactly as advertised, even better than with sysvinit.
More importantly, in my opinion, is quite how much critical code is now under the control of one project that always seems to want to do things "differently", and how much that's going to tie our systems into a future "do it the systemd way or don't do it at all" scenario.
This was always the case in Linux, like most of the Linux plumbing ecosystem, which is not a bad thing imho, as long as the projects are active.