3 ms·

I would argue that /etc/rc.d should be moved to /lib/exec and then use /etc/defaults files to load command line flags from environment variables. This separates

by zaarn 6y ago

I would argue that /etc/rc.d should be moved to /lib/exec and then use /etc/defaults files to load command line flags from environment variables. This separates the core of the service file you are unlikely to touch ever from the parts you want to touch and makes upgrades easier. It would also avoid or atleast minimize pacnew/pacsave files.

waheoo 6y ago
It has the same problem of separating concerns (for what?) but losing important context making things harder to reason about. Normal form isn't always the best answer, sometimes a flat cludge is the better solution.
- zaarn 6y ago
  Why shouldn't this be separated? All files that the distributor ships as configured ought to be put into /lib or /usr. Any system specific configuration belongs to /etc, but ONLY that configuration. On a fresh install of BSD/Linux I'd love to see an empty /etc directory sans any necessary overrides to make it boot. Makes backing up that directory a lot easier too.
  - jlg23 6y ago
    > On a fresh install of BSD/Linux I'd love to see an empty /etc directory sans any necessary overrides to make it boot. And I rather have a full set of configuration files that specifies the defaults at the time of the installation so my system even boots after an update in which some program changed its hardcoded defaults. > Makes backing up that directory a lot easier too. I don't really understand what the problem with backing up 0.1 or 1.0MB is.
    - zaarn 6y ago
      Well, the specified defaults are in a folder in /lib or /usr. You can find them there and copy them to /etc or just write what you change. The issue is not how much is backed up but what. If /etc only represents changes to system defaults, then the backup represents a list of my changes and it's always easily visible from each full snapshot what changes were active in the system at that time. If /etc contains all configuration, then from a single backup snapshot, you cannot determine what changes where made to the system. This would be an issue if you're trying to recover the backup to a freshly installed system, for example, because you cannot tell what changes you have made vs what changes occured in the backup due to updates or upstream due to updates since the backup. It's a semantic difference that can make restoring backups easier and replicable across different systems.
      - jlg23 6y ago
        a) Not all programs can read multiple configuration files. It's either in the one configuration file or a hardcoded default. b) Not all settings done in defaults can be simply undone later on (e.g.: apache's httpd.conf, IIRC the same for nginx - good luck getting this default listener down again) c) If you want to infer which changes were made by you or by the system's update procedures, explicitly creating snapshots before every manual or automatic modifications would be the way to go. Preferably one after each as well, so you have something to verify the integrity of a system against in case of security issues.
        zaarn 6y ago
        a) and b) are just issues with common software being idiotic about configuration and insisting one a "one truth" central config file. c) As mentioned above, inferring changes requires two snapshots, if /etc only contains changes a single snapshot allows me to infer changes. And I can verify the integrity just as well using an "after" snapshot. Just means one less snapshot is involved, which is reduced complexity.
        waheoo 6y ago
        Sadly, I have to deal with idiotic software, so where does that leave me?
        zaarn 6y ago
        Fork it?
JdeBP 6y ago
The headlined article is not about Arch, and already pointed out the existence of /etc/rc.conf (albeit that there are actually a couple of other files) containing the variable settings that configure the scripts, as documented on the rc.conf manual page.
- zaarn 6y ago
  pacsave/pacnew is how arch deals with some of these problems, but i wasn't talking about anything arch specific
  - JdeBP 6y ago
    Yes you were. You were talking about pacsave/pacnew. There are no such things on the operating systems discussed in the headlined article.
    - zaarn 6y ago
      Okay, to elaborate, a solution like the one proposed in the article, if implemented on ArchLinux, would prevent or minimize pacnew/pacsave. That doesn't make the rest of the comment irrelevant because pacnew/pacsave are specific to arch, hence that very sentence being only specific to arch. I mentioned them mostly because the top comment in this thread also mentioned them briefly. I hope that ELI5 was sufficient for you.

by zaarn 6y ago

waheoo 6y ago

It has the same problem of separating concerns (for what?) but losing important context making things harder to reason about. Normal form isn't always the best answer, sometimes a flat cludge is the better solution.

zaarn 6y ago
Why shouldn't this be separated? All files that the distributor ships as configured ought to be put into /lib or /usr. Any system specific configuration belongs to /etc, but ONLY that configuration. On a fresh install of BSD/Linux I'd love to see an empty /etc directory sans any necessary overrides to make it boot. Makes backing up that directory a lot easier too.
- jlg23 6y ago
  > On a fresh install of BSD/Linux I'd love to see an empty /etc directory sans any necessary overrides to make it boot. And I rather have a full set of configuration files that specifies the defaults at the time of the installation so my system even boots after an update in which some program changed its hardcoded defaults. > Makes backing up that directory a lot easier too. I don't really understand what the problem with backing up 0.1 or 1.0MB is.
  - zaarn 6y ago
    Well, the specified defaults are in a folder in /lib or /usr. You can find them there and copy them to /etc or just write what you change. The issue is not how much is backed up but what. If /etc only represents changes to system defaults, then the backup represents a list of my changes and it's always easily visible from each full snapshot what changes were active in the system at that time. If /etc contains all configuration, then from a single backup snapshot, you cannot determine what changes where made to the system. This would be an issue if you're trying to recover the backup to a freshly installed system, for example, because you cannot tell what changes you have made vs what changes occured in the backup due to updates or upstream due to updates since the backup. It's a semantic difference that can make restoring backups easier and replicable across different systems.
    - jlg23 6y ago
      a) Not all programs can read multiple configuration files. It's either in the one configuration file or a hardcoded default. b) Not all settings done in defaults can be simply undone later on (e.g.: apache's httpd.conf, IIRC the same for nginx - good luck getting this default listener down again) c) If you want to infer which changes were made by you or by the system's update procedures, explicitly creating snapshots before every manual or automatic modifications would be the way to go. Preferably one after each as well, so you have something to verify the integrity of a system against in case of security issues.
      - zaarn 6y ago
        a) and b) are just issues with common software being idiotic about configuration and insisting one a "one truth" central config file. c) As mentioned above, inferring changes requires two snapshots, if /etc only contains changes a single snapshot allows me to infer changes. And I can verify the integrity just as well using an "after" snapshot. Just means one less snapshot is involved, which is reduced complexity.
        waheoo 6y ago
        Sadly, I have to deal with idiotic software, so where does that leave me?
        zaarn 6y ago
        Fork it?

JdeBP 6y ago

The headlined article is not about Arch, and already pointed out the existence of /etc/rc.conf (albeit that there are actually a couple of other files) containing the variable settings that configure the scripts, as documented on the rc.conf manual page.

zaarn 6y ago
pacsave/pacnew is how arch deals with some of these problems, but i wasn't talking about anything arch specific
- JdeBP 6y ago
  Yes you were. You were talking about pacsave/pacnew. There are no such things on the operating systems discussed in the headlined article.
  - zaarn 6y ago
    Okay, to elaborate, a solution like the one proposed in the article, if implemented on ArchLinux, would prevent or minimize pacnew/pacsave. That doesn't make the rest of the comment irrelevant because pacnew/pacsave are specific to arch, hence that very sentence being only specific to arch. I mentioned them mostly because the top comment in this thread also mentioned them briefly. I hope that ELI5 was sufficient for you.