6 ms·

> August 24, 2020 Unexpected to say the least. Good read though, mostly agree. > My main gripe is that the files under /etc/rc.d/ are immutable scripts. Are

by waheoo 6y ago

> August 24, 2020 Unexpected to say the least. Good read though, mostly agree. > My main gripe is that the files under /etc/rc.d/ are immutable scripts. Are they though? A lot of, well at least old software, lacked configuration files, their command line flags and unit scripts were for all intensive purposes, their config files. Whether this actually makes upgrade harder (the next point made), is kind of debatable no? Arch does fine with pacsave and pacnew files. Making changes or tracking changes to these files is going to be required regardless from a systems upgrade point of view - because people want control over their system units. And for what its worth, I'd rather find out about a breaking update via pacsave/new than figure it out months later when my copied but now outdated and untracked unit starts failing.

krastanov 6y ago
Just a minor grammar point that does not detract from your argument: It is "for all intents and purposes", not "intensive purposes" https://www.dictionary.com/e/for-all-intents-and-purposes-vs-for-all-intensive-purposes/ https://www.dictionary.com/e/for-all-intents-and-purposes-vs...
- adzm 6y ago
  These kinds of substitutions are called eggcorns (like acorns) https://en.wikipedia.org/wiki/Eggcorn https://en.wikipedia.org/wiki/Eggcorn
  - Zamicol 6y ago
    My household has started calling them "Bone Apple Teas". https://old.reddit.com/r/BoneAppleTea/ https://old.reddit.com/r/BoneAppleTea/ My favorite being a friend called a cul-de-sac a "culture sack". Years later we still laugh about this one.
    - jacobush 6y ago
      It’s also true
  - eindiran 6y ago
    Geoffrey Pullum, who came up with the term "eggcorn", also came up with "snowclone" [0]. He has had a lot of very interesting posts on Language Log [1]. [0] https://en.wikipedia.org/wiki/Snowclone https://en.wikipedia.org/wiki/Snowclone [1] http://www.lel.ed.ac.uk/~gpullum/langlog-posts.html http://www.lel.ed.ac.uk/~gpullum/langlog-posts.html
    - m0xte 6y ago
      Language Log is brilliant. Perfect morning reading with my coffee. “Orca emits speech-like sound; reporters go insane“ says more about our culture and media than anything I’ve read for years. Thanks for posting the link.
- waheoo 6y ago
  Til, but I don't even know if I'll change, intents and purposes sounds wrong. :|
  - krastanov 6y ago
    "Intents and purposes" has a meaning on its own word-by-word. Not so much with the eggcorn. What is "intensive" about the "purpose" in "intensive purposes"?
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.
masklinn 6y ago
> Are they though? A lot of, well at least old software, lacked configuration files, their command line flags and unit scripts were for all intensive purposes, their config files. Most of the article is dedicated to explaining how modern BSDs changed from these origin and how system owners are very much expected not to edit these scripts so… yes, they are? > Whether this actually makes upgrade harder (the next point made), is kind of debatable no? Not it’s not? The article explains exactly how: BSD upgrade process diffs and merged every config file, which includes core rc scripts which the system owner would or should not have edited. So said system owner finds themselves spammed with every upstream update to scripts they never touched, none of which would be relevant to them. If you argue that this is a good thing, then surely they should also be spammed with upstream updates to every binary, utility or script these use? > Arch does fine with pacsave and pacnew files. The article is not about arch? > Making changes or tracking changes to these files is going to be required No. > And for what its worth, I'd rather find out about a breaking update via pacsave/new than figure it out months later when my copied but now outdated and untracked unit starts failing. Does pacsave/pacnew force you to review every built-in systemd unit?
- geofft 6y ago
  The claim is that the Arch pacman mechanism (and the dpkg one, and the rpm one, and ...) only prompts you when there is an actual merge, and when it does that, it's actually fine and preferable for the package manager to leave old and new versions on disk and ask the sysadmin to resolve the merge by hand, and this works in practice. It does not ask you to review every change to /etc. This is why Arch is mentioned, as an example of a system where this situation works fine. (Debian and Fedora are also good examples.) If the BSDs' upgrade procedure cannot distinguish between changes to /etc where the local sysadmin has also modified the file and changes to /etc where the file is unmodified, and they prompt you to review every single change to /etc, that seems like an easily fixable missing feature. Do the BSDs really prompt you to accept every change to /etc on upgrade for files you didn't modify, such as sshd.conf or services?

by waheoo 6y ago

krastanov 6y ago

Just a minor grammar point that does not detract from your argument: It is "for all intents and purposes", not "intensive purposes" https://www.dictionary.com/e/for-all-intents-and-purposes-vs-for-all-intensive-purposes/ https://www.dictionary.com/e/for-all-intents-and-purposes-vs...

adzm 6y ago
These kinds of substitutions are called eggcorns (like acorns) https://en.wikipedia.org/wiki/Eggcorn https://en.wikipedia.org/wiki/Eggcorn
- Zamicol 6y ago
  My household has started calling them "Bone Apple Teas". https://old.reddit.com/r/BoneAppleTea/ https://old.reddit.com/r/BoneAppleTea/ My favorite being a friend called a cul-de-sac a "culture sack". Years later we still laugh about this one.
  - jacobush 6y ago
    It’s also true
- eindiran 6y ago
  Geoffrey Pullum, who came up with the term "eggcorn", also came up with "snowclone" [0]. He has had a lot of very interesting posts on Language Log [1]. [0] https://en.wikipedia.org/wiki/Snowclone https://en.wikipedia.org/wiki/Snowclone [1] http://www.lel.ed.ac.uk/~gpullum/langlog-posts.html http://www.lel.ed.ac.uk/~gpullum/langlog-posts.html
  - m0xte 6y ago
    Language Log is brilliant. Perfect morning reading with my coffee. “Orca emits speech-like sound; reporters go insane“ says more about our culture and media than anything I’ve read for years. Thanks for posting the link.
waheoo 6y ago
Til, but I don't even know if I'll change, intents and purposes sounds wrong. :|
- krastanov 6y ago
  "Intents and purposes" has a meaning on its own word-by-word. Not so much with the eggcorn. What is "intensive" about the "purpose" in "intensive purposes"?

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.

masklinn 6y ago

> Are they though? A lot of, well at least old software, lacked configuration files, their command line flags and unit scripts were for all intensive purposes, their config files. Most of the article is dedicated to explaining how modern BSDs changed from these origin and how system owners are very much expected not to edit these scripts so… yes, they are? > Whether this actually makes upgrade harder (the next point made), is kind of debatable no? Not it’s not? The article explains exactly how: BSD upgrade process diffs and merged every config file, which includes core rc scripts which the system owner would or should not have edited. So said system owner finds themselves spammed with every upstream update to scripts they never touched, none of which would be relevant to them. If you argue that this is a good thing, then surely they should also be spammed with upstream updates to every binary, utility or script these use? > Arch does fine with pacsave and pacnew files. The article is not about arch? > Making changes or tracking changes to these files is going to be required No. > And for what its worth, I'd rather find out about a breaking update via pacsave/new than figure it out months later when my copied but now outdated and untracked unit starts failing. Does pacsave/pacnew force you to review every built-in systemd unit?

geofft 6y ago
The claim is that the Arch pacman mechanism (and the dpkg one, and the rpm one, and ...) only prompts you when there is an actual merge, and when it does that, it's actually fine and preferable for the package manager to leave old and new versions on disk and ask the sysadmin to resolve the merge by hand, and this works in practice. It does not ask you to review every change to /etc. This is why Arch is mentioned, as an example of a system where this situation works fine. (Debian and Fedora are also good examples.) If the BSDs' upgrade procedure cannot distinguish between changes to /etc where the local sysadmin has also modified the file and changes to /etc where the file is unmodified, and they prompt you to review every single change to /etc, that seems like an easily fixable missing feature. Do the BSDs really prompt you to accept every change to /etc on upgrade for files you didn't modify, such as sshd.conf or services?