Comment by dijit
7 years ago
False dichotomy. There are more options than those. SystemD won because it had been adopted already and was supported by a major company in FOSS
7 years ago
False dichotomy. There are more options than those. SystemD won because it had been adopted already and was supported by a major company in FOSS
I would disagree that systemd got adopted because it had been already adopted, this is a circular reasoning.
From a distance it looks like politics and influence pushed for adoption of systemd, motivation behind this uncanny move and spread has been questioned making some wonder if this could be intended with a nefarious purpose in mind.
You just cannot call it "politics and influence" when systemd was discussed thoroughly and adopted by Debian.
In the end it was a tie in the Debian technical committee. The chairman’s vote was counted twice so systemd won. Then the people who had voted for systemd resigned rather than actually implement their choice.
1 reply →
False dichotomy indeed. Right now I'm testing runit (on void linux) for my production machines. My experience since more than a year: Once it runs it runs, literally zero surprises so far.
The general volatility of systemd introduces so many unstable elements in your system, that it really makes you think if the added risk it is really worth the value it offers (even though I'm still not quiet sure what the value of systemd actually is).
I'm not exactly surprised that someone who isn't using systemd for anything is getting little value from it. If you really want to give it a fair chance go all in on 'the systemd way' and you'll wonder how you ever got by without it.
- Services can depend on mounts, sockets, paths, or other servives. Don't start the NFS server until your backend storage is online and mounted and stop it if it goes offline.
- Are you annoyed when Symantec is chewing through your CPU? Use systemctl --edit and cap it at 20% with one CPUQuota option.
- Have a NodeJS service you want to bind to port 80 but not run as root? AmbientCapabilities=CAP_NET_BIND_SERVICE and you're done.
- Want to automount a directory? Drop in an .automount file or add an option to fstab and you're done.
- Replace GRUB with systemd-boot and enjoy configuring boot options with simple INI files.
- Want to do offline updates? Have any service you want be part of system-update.target, touch /system-update and reboot.
- Annoyed that you can't have more than 3 dns servers or can't run DNSoTLS or DNSoHTTPS? systemd-resolved has your back.
- Forget about ntpd or chrony and use systemd-timesyncd is a lightweight standards complaint ntp client.
- Run all your userspace daemons like offlineimap, tmux, emacs, your dev server, etc. as systemd user services.
- Manage the permissions, resource usage, and monitor long running jobs with systemd-run.
- Replace cron with systemd timers that not only have more powerful timespecs, are hooked into the dependency solver, and can be monitored like any other service.
- Isolate troublesome 3rd party applications with systemd-portable which are a bit like privileged containers but easier to use.
- Run apps as unprivileged users without having to fill passwd with users and groups just for services with dynamic users.
These are just the ones off the top of my head. It boggles my mind how people say that systemd doesn't provide value.
The things you listed exist outside of systemd.
You’re arguing the same tired points against sysvinit except also attributing valour to systemd where it doesn’t belong.
- Services can depend on mounts, sockets, paths, or other servives. Don't start the NFS server until your backend storage is online and mounted and stop it if it goes offline.
This is what the next generation of init systems brought. Not just systemd, but runit and others. Nobody was fighting for sysvinit, which is what people seem to argue.
- Are you annoyed when Symantec is chewing through your CPU? Use systemctl --edit and cap it at 20% with one CPUQuota option.
This is just cgroups, a function of the kernel, not systemd
- Have a NodeJS service you want to bind to port 80 but not run as root? AmbientCapabilities=CAP_NET_BIND_SERVICE and you're done.
Polkit
- Want to automount a directory? Drop in an .automount file or add an option to fstab and you're done.
Automount, existed for 15 years at this point.
- Replace GRUB with systemd-boot and enjoy configuring boot options with simple INI files.
You know they adopted a boot loader for this right? It existed before systemd. Regardless an “ease of use bootloader” that comes with a lot of opinions on other things like logging and opaque non-deterministic behaviour? Nah.
- Want to do offline updates? Have any service you want be part of system-update.target, touch /system-update and reboot.
What does this mean?
- Annoyed that you can't have more than 3 dns servers or can't run DNSoTLS or DNSoHTTPS? systemd-resolved has your back.
This has been the horror of many, since the code to do this is so shitty and makes so many assumptions. (Like that it silently fails and makes your application pause, or the more subtle default of using Google’s dns server- which they didn’t pay for and is a weird default in the context of servers- hammering home to me that systemd was for the desktop.
Explains a lot of the design if you frame it that way, looks a lot like the windows subsystem)
- Forget about ntpd or chrony and use systemd-timesyncd is a lightweight standards complaint ntp client.
Why forget about things that work? I don’t understand your reasoning here. Because you like INI files?
- Run all your userspace daemons like offlineimap, tmux, emacs, your dev server, etc. as systemd user services.
This one is fair enough, I used to use supervisord, but that’s very meh- Or there’s the old tmux session that lives forever.
- Manage the permissions, resource usage, and monitor long running jobs with systemd-run.
Same as cgroups again.
- Replace cron with systemd timers that not only have more powerful timespecs, are hooked into the dependency solver, and can be monitored like any other service.
Your argument here boils down to “service integration with corn” because high resolution timers were a thing before systemd. This is solved with other inits (like runit) by making resources available as you request them. Much like xinetd.
- Isolate troublesome 3rd party applications with systemd-portable which are a bit like privileged containers but easier to use.
LXC or in a real pinch, cgroups + chroot.
- Run apps as unprivileged users without having to fill passwd with users and groups just for services with dynamic users.
Polkit. This is what polkit was designed for.
1 reply →