3 ms·

I'm not familiar with NixOS, so can't argue there. However: /lib/systemd and /etc/systemd make perfect sense to me -- /lib/systemd is what the package installs

I'm not familiar with NixOS, so can't argue there. However: /lib/systemd and /etc/systemd make perfect sense to me -- /lib/systemd is what the package installs. /etc/systemd is the admin overriding what's in /lib. That's a perfectly fine solution in that the admin's modifications apply cleanly on top of whatever the package installs, and works nicely with package updates. Installing files into /etc is troublesome. Stuff like PropagatesReloadTo exists because there exist things that are built from multiple cooperating units that need such measures. The vast majority of things don't need anything more than a 5 line service file. One file for the dependency graph? How would that work, and why would that be a good idea? In systemd, the service declares what it needs. Why would I want to manually go mess with a file after installing some third party service to tell the system what that service needs?

mindslight 5y ago
> Installing files into /etc is troublesome Installing default files into /etc is what every Debian service does. When the user edits them, they take over responsibility. Same as installing them in /lib and then manually dropping an override in /etc, only with all files (default and edited) in the same place. > Stuff like PropagatesReloadTo exists because there exist things that are built from multiple cooperating units that need such measures Every little feature is obviously needed for some purpose. The problem is they never did the design step to whittle down the model such that all those extra facets were subsumed by fewer more general features. > Why would I want to manually go mess with a file after installing some third party service to tell the system what that service needs? A distro would have the top-level file defining the graph of all the distro packages you could possibly install, so you would not need to edit any files.
- dale_glass 5y ago
  > Installing default files into /etc is what every Debian service does. When the user edits them, they take over responsibility. Yeah, dealt with that, it sucks. You upgrade, and then end up staring at half a dozen 3-way diffs for services you're only vaguely aware exist. Sometimes the packagers modify the comments or rearrange the file, so figuring out whether anything of importance happened can be tricky. Systemd makes this nice and easy. If I add an environment variable to a service, it stays added after an upgrade without any fuss. I can look in /etc and see exactly what was overriden, and trivially return to an unmodified state if needed. > The problem is they never did the design step to whittle down the model such that all those extra facets were subsumed by fewer more general features. I'm not sure how could that be done without going to every software maker out there and telling them to ensure such a feature wouldn't be needed. I'm not seeing that happening. > A distro would have the top-level file defining the graph of all the distro packages you could possibly install, so you would not need to edit any files. Lots of stuff doesn't come with distros, including the packages for my own project which ships systemd units. Add a third party repo, install packages, enable services, done. No need to mess around with some global dependency config.
  - mindslight 5y ago
    > You upgrade, and then end up staring at half a dozen 3-way diffs for services you're only vaguely aware exist This is a fundamental problem that you cannot escape. If you take something from upstream and modify it, then you're stuck keeping up with the changes. If you're only "vaguely aware" of something you modified, it's because you forgot. > Systemd makes this nice and easy No, it doesn't. You're describing doing the exact same thing as if you just ignore the config file diffs - keeping your own version and ignoring upstream. If the upstream changed something relevant, your forked config breaks. > I'm not sure how could that be done without going to every software maker out there and telling them to ensure such a feature wouldn't be needed. I'm talking about the design of systemd, not the complexity of services. We're not going to be able to hash out how they could simplify their own overall model in a message board thread, but suffice it to say that 11 different types of dependencies (double including their reversals) could certainly be pared down. > Lots of stuff doesn't come with distros, including the packages for my own project which ships systemd units. Add a third party repo, install packages, enable services, done Your packages would drop a unit in say /etc/sysd/units/, and augment the toplevel config by dropping something in say /etc/sysd/graph.d/
    - dale_glass 5y ago
      > This is a fundamental problem that you cannot escape. You can escape it if you design for it. You can't escape it for exim.conf, but you can escape it for systemd's own files, because it designed for that particular case, as explained below. > No, it doesn't. You're describing doing the exact same thing as if you just ignore the config file diffs - keeping your own version and ignoring upstream. If the upstream changed something relevant, your forked config breaks. No. The way it works is that stuff in /etc overrides stuff in /lib, line by line. Eg, in /etc you place something like this: [Service] Environment=FOO=bar And that's all the file contains. This file adds an extra environment variable to the unit it overrides, and nothing more. If upstream has two variables now and adds a third in the next release, then it all still adds up correctly and without any interaction. There's also a special syntax for saying "Ignore whatever this says in the packaged original, I only want my version". > I'm talking about the design of systemd, not the complexity of services. One and the same. Systemd exists to run existing services. If an existing program is composed of 3 cooperating binaries and needed hacks where signals must be sent to the other processes, there's nothing for systemd to do but to implement the required functionality to support that. > Your packages would drop a unit in say /etc/sysd/units/, and augment the toplevel config by dropping something in say /etc/sysd/graph.d I'm not seeing the benefit then. What's the difference, keeping the config in two files vs one?

mindslight 5y ago

> Installing files into /etc is troublesome Installing default files into /etc is what every Debian service does. When the user edits them, they take over responsibility. Same as installing them in /lib and then manually dropping an override in /etc, only with all files (default and edited) in the same place. > Stuff like PropagatesReloadTo exists because there exist things that are built from multiple cooperating units that need such measures Every little feature is obviously needed for some purpose. The problem is they never did the design step to whittle down the model such that all those extra facets were subsumed by fewer more general features. > Why would I want to manually go mess with a file after installing some third party service to tell the system what that service needs? A distro would have the top-level file defining the graph of all the distro packages you could possibly install, so you would not need to edit any files.

dale_glass 5y ago
> Installing default files into /etc is what every Debian service does. When the user edits them, they take over responsibility. Yeah, dealt with that, it sucks. You upgrade, and then end up staring at half a dozen 3-way diffs for services you're only vaguely aware exist. Sometimes the packagers modify the comments or rearrange the file, so figuring out whether anything of importance happened can be tricky. Systemd makes this nice and easy. If I add an environment variable to a service, it stays added after an upgrade without any fuss. I can look in /etc and see exactly what was overriden, and trivially return to an unmodified state if needed. > The problem is they never did the design step to whittle down the model such that all those extra facets were subsumed by fewer more general features. I'm not sure how could that be done without going to every software maker out there and telling them to ensure such a feature wouldn't be needed. I'm not seeing that happening. > A distro would have the top-level file defining the graph of all the distro packages you could possibly install, so you would not need to edit any files. Lots of stuff doesn't come with distros, including the packages for my own project which ships systemd units. Add a third party repo, install packages, enable services, done. No need to mess around with some global dependency config.
- mindslight 5y ago
  > You upgrade, and then end up staring at half a dozen 3-way diffs for services you're only vaguely aware exist This is a fundamental problem that you cannot escape. If you take something from upstream and modify it, then you're stuck keeping up with the changes. If you're only "vaguely aware" of something you modified, it's because you forgot. > Systemd makes this nice and easy No, it doesn't. You're describing doing the exact same thing as if you just ignore the config file diffs - keeping your own version and ignoring upstream. If the upstream changed something relevant, your forked config breaks. > I'm not sure how could that be done without going to every software maker out there and telling them to ensure such a feature wouldn't be needed. I'm talking about the design of systemd, not the complexity of services. We're not going to be able to hash out how they could simplify their own overall model in a message board thread, but suffice it to say that 11 different types of dependencies (double including their reversals) could certainly be pared down. > Lots of stuff doesn't come with distros, including the packages for my own project which ships systemd units. Add a third party repo, install packages, enable services, done Your packages would drop a unit in say /etc/sysd/units/, and augment the toplevel config by dropping something in say /etc/sysd/graph.d/
  - dale_glass 5y ago
    > This is a fundamental problem that you cannot escape. You can escape it if you design for it. You can't escape it for exim.conf, but you can escape it for systemd's own files, because it designed for that particular case, as explained below. > No, it doesn't. You're describing doing the exact same thing as if you just ignore the config file diffs - keeping your own version and ignoring upstream. If the upstream changed something relevant, your forked config breaks. No. The way it works is that stuff in /etc overrides stuff in /lib, line by line. Eg, in /etc you place something like this: [Service] Environment=FOO=bar And that's all the file contains. This file adds an extra environment variable to the unit it overrides, and nothing more. If upstream has two variables now and adds a third in the next release, then it all still adds up correctly and without any interaction. There's also a special syntax for saying "Ignore whatever this says in the packaged original, I only want my version". > I'm talking about the design of systemd, not the complexity of services. One and the same. Systemd exists to run existing services. If an existing program is composed of 3 cooperating binaries and needed hacks where signals must be sent to the other processes, there's nothing for systemd to do but to implement the required functionality to support that. > Your packages would drop a unit in say /etc/sysd/units/, and augment the toplevel config by dropping something in say /etc/sysd/graph.d I'm not seeing the benefit then. What's the difference, keeping the config in two files vs one?