Hacker News new | past | comments | ask | show | jobs | submit login

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.


> This is what the next generation of init systems brought. Not just systemd

Exactly! I'm not saying that it's unique to systemd, just that it's useful. I expect many next-gen init systems will be implementing many similar features to systemd.

> This is just cgroups, a function of the kernel, not systemd

And Docker resource control is just cgroups too. Doesn't mean it's not much much easier to use. The value of systemd's resource control options is that it comes with a constraint solver and sets up the cgroups to satisfy your desires. If you have many services all with their own caps it becomes very annoying to figure out how to set up the ratios of CPU shares.

> Automount, existed for 15 years at this point.

And it's been super flaky for 15 years. Would you rather edit automount maps or just say, "hey when this path is first accessed, mount it."

> Polkit

Huh? Polkit 100% cannot do this. This is the ability to set and deny Linux capabilities to services. systemd is actually providing something very unique here which as of yet doesn't exist outside systemd.

The userspace tools for capabilities allow you to set them on files so that when you exec them they have (or are denied) the capabilities you set. But what about an interpreted program like python or node? You probably don't want to set CAP_NET_BIND_SERVICE on all node processes, just your web server.

Systemd makes this very easy by starting a service as root, dropping capabilies to match your directives then execing the service. Nothing magic but something very few tools let you do. Someone could write a tool for this but it's doesn't exist anywhere in my repos.

> You know they adopted a boot loader for this right?

Look I know it's gummyboot. Gummyboot is great. Just because it's now systemd-boot doesn't make it any less good. In fact it makes it better since the userspace tooling systemd added greatly improved the experience using it.

> What does this mean?

Downloading updates to apply, rebooting into a minimal environment to apply them, and then rebooting back into your system. It's a very slick implementation.

> Why forget about things that work?

Drastically reduced complexity and attack surface because timesyncd focuses entirely on being a client.

> Same as cgroups again.

Yes they use cgroups under the hood. Tell me how to, from a shell, run an arbitrary process capped at 30% CPU and 128M of memory that's easier than

systemd-run -t -p MemoryMax=128M -p CPUQuota=30% my-process

> LXC or in a real pinch, cgroups + chroot.

Right, but systemd is providing the tooling to make it easy package and run services like this.

> Polkit. This is what polkit was designed for.

Polkit literally cannot do this. Tell me how to make a user $service exist only while $service is running.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: