I have the feeling systemd is meant exactly for what you call hobby or novice users.
I actually enjoy some of it on my laptop to be honest ;-)
But in the datacenter it has caused me hours and hours of 'fixing problems that did not exist before systemd came along'.
Most of it's 'improvements' target the desktop user.
Many of it's 'improvements' actually get in the way in the server room.
I mean, why would I want to optimize my boot time on a server with all this parallel startup crap?
The server spends 10 times more time in BIOS and POST then it takes to boot the OS.
It has always been like this. And it still is like this.
From a config management point of view I like systemd. I gives me a consistent API to enable/disable start/stop services. That's awesome. I also like that I can 'override/patch' upstream units without having to maintain a fork. Perfect.
But many other things that came from the systemd ecosystem are questionable.
E.g. systemd-resolved, timesyncd and that kind of stuff.
Maybe these are nice for desktop users who want a click and play experience on their laptop.
No problem with that. But why do they have to break my server's for this?
I mean seriously: Linux on the desktop is irrelevant. Why optimize the whole OS/init for a irrelevant use case?
Boot time is a big deal for us. Not sure if it matters, but I don't get paid enough to decide what matters. All I know is we paid extra for some Dell software that lets you fine tune the BIOS and we streamline for boot speed. We're currently in the process of moving anything that can be run on a VM to a VM so this will be even less of a concern in the future and pid 1 will be more of a bottle neck. That said, except for the db servers, we don't run mem checks on boot so our servers are very fast to boot (I believe Dell cites that each Gb of RAM is equal to 1 sec. of boot time when you are running with the mem checker on).
The only time I ever do a "deep dive" and manual setup a server is when I have to provision a server for a new department/service. Generally speaking ansible does the work for me and I just hit go on my console and then go get a coffee. So I don't see much of a headache in server provisioning. I also am on the automation side of Ops so I do a lot more work with a already setup server, and in that case, like you said, systemd API is a godsend.
I have the feeling systemd is meant exactly for what you call hobby or novice users. I actually enjoy some of it on my laptop to be honest ;-)
But in the datacenter it has caused me hours and hours of 'fixing problems that did not exist before systemd came along'.
Most of it's 'improvements' target the desktop user. Many of it's 'improvements' actually get in the way in the server room.
I mean, why would I want to optimize my boot time on a server with all this parallel startup crap? The server spends 10 times more time in BIOS and POST then it takes to boot the OS. It has always been like this. And it still is like this.
From a config management point of view I like systemd. I gives me a consistent API to enable/disable start/stop services. That's awesome. I also like that I can 'override/patch' upstream units without having to maintain a fork. Perfect.
But many other things that came from the systemd ecosystem are questionable. E.g. systemd-resolved, timesyncd and that kind of stuff. Maybe these are nice for desktop users who want a click and play experience on their laptop. No problem with that. But why do they have to break my server's for this?
I mean seriously: Linux on the desktop is irrelevant. Why optimize the whole OS/init for a irrelevant use case?