I don't get why people are so against systemd. I'm very happy using since it became available on debian. It's simply a clone of Apple's launchd.
If it's about 'choice', go swap out your kernel for hurd or sth.
If it's about 'choice', go swap out your kernel for hurd or sth.
- systemd supporters are mainly desktop users, so their opinions are irrelevant because as a desktop user the only thing you might do is restart a service, is important to listen to server admins that know what they are talking about
- GNOME (other Red Hat tech) depends on a systemd component and refuses patches to make it independent, so basically GNOME is forcing systemd adoption and is trying to block alternatives by refusing patches
- systemd projects and fans will ask you to create a better alternative to systemd if you don't like it, but if you try to promote an alternative they will try to block the alternatives by refusing to accept patches to keep projects systemd independent.
Monoclultures are bad, when systemd will o longer be popular and we want to implement a better succesor we will discover that many things are hard coded to depend on some it's many components.
About what is the best init system, I don't know , I am desktop user, and as I said all desktop users opinions are probably "it works for me so you are wrong"
If your trying to hastely safe shutdown “Waiting for process to stop - 3/8minutes”
Sure, you can alter the timer but that’s then just another task I shouldn’t need to do.
Dependencies within unit files
It’s own log formatting in a binary format
It’s icky, it feels clunky and while it works it doesn’t feel smooth.
systemd is really good at doing what it's told, if it's told something bad it will do something bad.
> is important to listen to server admins that know what they are talking about
Huh?
I got on the systemd train when race conditions with pidfiles caused essential services not to restart correctly for the umpteenth time on a small subset of the thousands of bare metal servers I managed.
Not a single sysadmin I worked with liked anything about sysvinit. Nearly every distro-provided init script for the services we cared about had some sort of subtle bug which we had to manually fix with our configuration management.
Or maybe somebody had been diagnosing an issue and manually run “sudo /etc/init.d/someservice start” and now congratulations, the service inherited the cwd of the person who ran the init script.
Or you have to deal with inconsistent log rotation behavior, or the service coming up before the network was ready on boot (better rename the symlink to 99_myservice!)
I don’t know where people get the idea that sysadmins prefer sysvinit. Maybe ones that only run one or two servers? After having managed tens of thousands of them across many datacenters, systemd is a clear and obvious win.
I personally had no issue with systemd or upstart or any other I used so I would wish desktop user like me would read more and comment less about what is better.
But yeah you are right(this always happens on the internet), I was also guilty of this, I remember back when C# appeared and I was sure is the best thing ever and it will soon replace all the other languages. I think at my past enthusiasm for C# when I see Rust/Go/CoolLang evangelizing why X is better and in 3 years it will dominate.
I don't see the difference between creating a systemd config file, which is super clear and managed properly and to create a bunch of init scripts that depend on pid-files which might be stale and where those directories are abitrary.
If a package you develop relies on only systemd's init capabilities, it'd probably be pretty straightforward for someone to port it to an OS with a different init system (like BSD). If your package relies on other systemd capabilities, though, the task of porting gets much harder.
Such as? Which other "systemd capability" besides the init system part exposes an API to general user-space applications? The only one I can think of is logind, for which an alternative implementation (elogind) exists.
It depends on a systemd API and there is an independent implementation, elogind. GNOME runs just fine in the BSDs, so its dependency on systemd is a strawman.
Scenario: a user is playing an audio stream that comes over the network. They put their computer to sleep. They restore it later, at another site.
Consider the dependency calculation to restore that mixing pipeline, without sending clicking noises to the user.
sysvinit scripts are horrible to create and operate. It's easy to set tup dependencies for network or other services. I haven't used it to run cron-like tasks, or inetd-type servers, but I don't have a need for that.
- init
- dependency management
- inetd-type spawning
- timed / cron launching
- managing processes depending on network state or filesystem mounting
- logging (replacing syslog)
- login (replacing login managers such as ConsoleKit)
- network configuration
- tmpfiles
- timedated (replacing ntpd)
- udev (userspace /dev manager)
- boot (replacing boot managers like grub)
As you can see, systemd has taken over a great many things that are totally unrelated to its core mission of replacing sysvinit. The fact that it continues to grow and take over all these other facilities and the fact that the systemd team actively fights people trying to develop alternatives is why people hate the project so much.
- systemd-resolved (DNS resolver)
- systemd-cryptsetup
etc etc
[0] https://groups.google.com/groups?&selm=Pine.LNX.3.91.9610161...
(I also think that those who use mailing lists should just use NNTP instead, possibly having NNTP as an alternative interface to the same data.)
This is my pet peeve: systemd-as-init is / may be fine. systemd-as-NTPd or systemd-with-udevd seems like overly tight coupling.
Never had this kinds of problems with any other init systems.