* It gets rid of a system cobbled together from init, inittab (which people rarely remember exists), monit, cron, and inetd/xinetd.
* It removes a bunch of horrible hacks in init scripts such as calls to sleep.
* It removes the need for pid files.
* It removes the need for a lot of stupid boilerplate, like the whole start-stop-daemon stuff in scripts.
* It allows precisely tracking what belongs to each service. I can easily find out what a random process belongs to.
* It captures all the log output of each process
* It drastically improves the upgrade process -- I never need to look at a 3-way diff of /etc/init.d/apache2 again
* As a developer it means I don't need to write a slightly different script for every distro
* It makes logging a whole lot pleasant
* It allows having user services without having to hack around it with cron
* It allows a whole bunch of settings to be applied to any random service, without having to edit a shell script and figure out how to stick it in there.
* It means services run identically when started by hand, without the confusion of a service inheriting my local environment.
* It makes my VM servers boot faster. And if you're going to pipe up with "I reboot my servers once a year", that doesn't cut it for me. I boot my servers on demand, when they're needed. They adapt to the load.
It is a nicely concise summary of the problems. I'd disagree with the characterizations of the previous system as "cobbled" or "horrible hacks" but there are solid things that need to be solved well by any system initialization architecture/service.
Recently, I started using pipewire, which is designed to rely on a user-level service to start and stop the pipewire process.
To bypass this requirement, the slackware guys came up with an elaborate solution that wraps the pipewire command with a daemonize tool that is supposed to cleanup after itself: https://www.linuxquestions.org/questions/slackware-14/using-...
Meanwhile, the gentoo guys just did the simplest thing possible: https://github.com/gentoo/gentoo/blob/f788f38/media-video/pi...
Of course, with both of these workarounds, the semantic changes from "start this process once the user logs in" to "start this process once the desktop environment starts", but the end results are identical for almost all users.
You mean Slackware users on some random forum. Besides, the solution they came up with uses XDG autostart which has nothing to do with systemd. Not to mention that it's not even doing the exact same thing as the Gentoo solution and running two more commands in addition to pipewire. On top of that, Gentoo also seems to be using XDG autostart for Pipewire[1] so it's basically the same approach.
[1]: https://github.com/gentoo/gentoo/blob/f788f389419678d2f2399e...
Believe it or not, that's actually the official slackware forum. And whatever solution those guys come up with, it will likely become the official solution.
> Besides, the solution they came up with uses XDG autostart which has nothing to do with systemd.
The slackware solution involves a project that nobody has heard of before, just so it can imitate the "user-level service" feature provided by systemd: https://github.com/raforg/daemon
> Not to mention that it's not even doing the exact same thing as the Gentoo solution and running two more commands in addition to pipewire.
The slackware solution requires starting those 3 processes (pipewire, pipewire-media-session, pipewire-pulse) separately from 3 different .desktop files, likely because the daemon tool above can't properly reap the pipewire-pulse process (not sure whose fault is this though).
On the other hand, the gentoo solution can start all 3 processes with just 1 .desktop files, because `pkill` takes care of it. Simple and effective.
I think the key difference, in this case, is that the slackware guys are trying their best to imitate a systemd feature, while the gentoo guys seem to focus more on finding the best way to allow users to enjoy pipewire.
My bad. TIL.
> The slackware solution involves a project that nobody has heard of before, just so it can imitate the "user-level service" feature provided by systemd
Daemonizing processes has been a thing far before systemd even existed. Solutions similar to this "daemon" project are commonly employed in SysV init scripts. If anything, systemd made those things irrelevant by offering a more simple configuration to daemonize programs.
> The slackware solution requires starting those 3 processes
> On the other hand, the gentoo solution can start all 3 processes with just 1 .desktop files
It looks to me Gentoo doesn't start the other two processes. I don't see how "daemonize" or pkill is relevant here.
> slackware guys are trying their best to imitate a systemd feature, while the gentoo guys seem to focus more on finding the best way to allow users to enjoy pipewire.
With respect, this is a unsound take. The explanation is more simple and it's that Gentoo does not currently handle pipewire cleanup.
lol. I had to trash an Arch Linux box because it failed to upgrade systemd from 208 to 211. Everytime I upgraded the system hung trying to mount filesystems so I had to roll back.
On the desktop, I feel like boot time is slightly longer than it was 20 years ago, yet hardware is faster now. I used to shut down my computer every night back then; now I leave it running, because it takes so long to get back to where I left off.
I think it takes my Linux system ~13 seconds to boot? That is definitely less time than it took 20 years ago, but I think that's mostly b/c the storage is no longer slow spinning rust running on IDE cables more than anything else…
It's Monday morning at 10:30, I've already got 29 tabs on 3 windows across 2 virtual desktops (2 monitors each) running on my main desktop. I've trimmed down to just 30 various rxvt windows with ssh or vim open, with files and notes at various stages of completion.
Some tabs may restore next time I load my browser, some won't.
My current server boots in 10 seconds, which isn't bad.
Interesting that you mention Sun. Didn't SMF precisely replace runlevels with SMF milestones[1] in much the same way systemd replaces runlevels with target units?
[1] https://docs.oracle.com/cd/E23824_01/html/821-1451/hbrunleve...
Good to see people down-voting a completely factually correct statement that they don't believe and don't want to personally investigate. Go read the systemd sources or read any article analyzing how systemd does dependency based startup and see for yourself.
I always ask ""What problem is this trying to solve?" and then "Is this a good solution for that?"
I appreciate the "startup dependency problem" and when I was in the Systems Group at Sun we worked with AT&T on their solution which was the whole "run level" thing.
And I appreciate the whole "shell scripts can do anything" problem that just using a naming scheme on shell scripts to run can lead to unexpected behaviors.
From an architectural taste perspective, I prefer systems which are more comprehensible in parts and thus don't try to abstract out semantics to the point of incomprehension.
So at the end of the day, something with a better model, better visibility into its operation and configuration, with a way to validate and debug dependencies would be good. But I haven't been impressed with systemd.