Not a lot of people, a very loud minority. They can go use Void Linux or other niche distros which replace it with the monstrosity that were SysV init scripts. It's the type of people that never had to write one of those scripts by hand, and maybe support two or three different distros.
The UX of systemd tools (systemctl, journalctl) is a bit crap, to be honest, but systemd does what it needs to do well and it is an established component of a modern Linux system.
I'm really tired of people pretending that systemd is the only modern init system around. If you're going to compare it to the status quo, at least don't strawman it. If SysV init scripts are your comparison, it just sounds like you're regurgitating outdated talking points.
Sorry but this argument really falls flat. All of the other init systems' service files are reminiscent of SysV say OpenRC or runit.
Moreover systemd achieves what it does because it provides a unified way of doing system administration. It is not only a service manager. It is the much needed dynamic system layer for Linux.
A modern Linux engineer or a sysadmin, no longer needs to make 5 to 10 different services work together by duct taping everything or writing abstraction layers per integration. Any system that has the correct level of abstraction will be at least as complex as systemd.
I never said it was. I said it's the only relevant one. Upstart was half-decent, for example, but no one uses it any more. Yes, there are other modern init systems, none that are so brilliantly designed and perfect that are worth this kind of resistance. They're all crappy in their own way. So what if systemd has won.
I do not get why people want to die on this inconsequential hill.
> regurgitating outdated talking points
No, I'm not being paid by Poettering. I've been running Linux systems and software for 25 years, and I have formed my opinion on the matter, thank you very much.
That's serveral conjectures on your part.
Give me metrics about the minority and then back up the fact that most of those people never wrote a sysinit or rc script by hand.
Like it or not Systemd breaks the Unix way and for a certain amount of people (I am not pretending to have a measuring stick) the dogma and philosophy are much more important than perceived ease of use or features.
All the major distros, especially server distros, run systemd. That is proof enough that NOT running systemd is a niche and unsupported configuration in any half-serious setup.
A conjecture is not automatically wrong. The point of a conjecture is to challenge someone else to prove it wrong. You'd have a hard time showing proof that systemd is niche.
And honestly, it does not break UNIX, let's be serious now. A haphazard bunch of shell scripts is not much better than a monolithic binary, and UNIX does not give a damn either way.
I do not care about dogma and philosophy, I am an engineer with software to run and deadlines to meet.
> I am an engineer with software to run and deadlines to meet.
Sure, but UNIX, with its minimalist philosophy, was - luckily for us! - not created under that slogan. With respect to quality, this slogan has always been the one driving its decrease that we see all around us today.
UNIX was created by engineers to run software, not as a philosophical device.
Sorry to say, yours is a terrible excuse. I respect that you might not like systemd, no software is perfect and systemd has many flaws, but the "think of the UNIX philosophy" is righteous nonsense that I cannot take seriously.
The real world is not black-and-white, with or against us. One of the most beloved UNIX tools, Emacs, is as far removed from the minimalist philosophy that some have decided to be UNIX's crowning achievement. It is not. Linux and UNIX have not won because we're all into minimalism, or dogmatic zealotry.
I don't care about a 50 year old technology philosophy. Times have changed.
Cloud computing and the prevalence of highly distributed systems have completely changed how software is deployed, scaled, and managed. These environments often rely on complex orchestration which can stretch the boundaries of the UNIX philosophy towards systems that are more about interactions between distributed components than about simple, single-purpose tools.
I don't see how it's relevant. An orchestration tool can also follow the Unix way by not implementing too much functionality and relying on the small tools for subtasks.
I really dislike that systemctl subcommands do not respect the accepted standard of `command subcommand -h`. For example, try `git branch -h` or `systemctl start -h`. The latter won't give any useful information.
The man page does not help either. `man git branch` opens the manual of the `git-branch` binary, so only the relevant options are shown. `man systemctl start` will show the man of the entire systemctl command, which is a bit unwieldy.
`journalctl` is the same: it both does paging through the logs, but also manages rotating or vacuuming the logs. Why not have two commands?
>The UX of systemd tools (systemctl, journalctl) is a bit crap....
And this is easily 80% of why I don't like it. I _know_ it's better* but my use-cases have never clashed with the limitations of init.d.
*better: I've recently had an issue that I was trying to troubleshoot while using `journalctl -fu service-name` and it just wasn't giving me enough information/the same content that /var/log/messages was giving me on my other OS (FreeBSD). Perhaps there was a flag I was missing (increase verbosity??) but the UX did get in the way.
Side note: I do chuckle every time I end up using the -fu flag. =)
I think it depends on what you get used to first. I only started using Linux back in 2016-17 (I'm 25), and for me systemd is just so insanely good compared to anything else I've tried. Maybe it's just because I never got used to what came before it or to current alternatives.
I also don't care that much about the "Unix philosophy" or whatever, so there's that.
The UX of systemd tools (systemctl, journalctl) is a bit crap, to be honest, but systemd does what it needs to do well and it is an established component of a modern Linux system.