> 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
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.