Comment by jraph | Hacker News Reader

Comment by jraph | Hacker News Reader

The argument is actually broader than what I expected from the title. It's not a matter of having to edit C code or Makefiles, it's a matter of having to edit any file (even a configuration file) that is shipped by the author of the program (or the package) and that can change. Then you are basically expected to maintain a fork.

I can't agree more with this.

Please make me edit completely empty files to override defaults.

Also related, it's painful when APT asks you what to do with an upgraded configuration file, just to notice that upstream edits are just mistake fixes in comments (hello Matrix / Synapse a while ago), or that self-closing XML tags have became totally equivalent but more verbose full, empty tags (WHY?!? Hello Collabora Online).

The moves to:

- let us expand the configuration in config.d folders

- ship default configuration files in system folders, outside /etc, config that you can overrides in /etc

are welcome. With the later, you can provide a fully documented default config file, and then I can override it, even commenting why I changed a value and these comments are not mixed with upstream documentation.

Yes. Yes yes yes. Configuration files with standardized contents tend to ossify into an appendage of the application written in what is effectively a domain-specific language. (See sendmail, for instance.)

The downside of this is that if the author changes a configuration key, you configuration will probably be invalid (thus refusing to come back online), or worse, ignored and the warning buried in systemd logs.

At least if the maintainers version and your version require review, you have a fighting chance to update the configuration with your customizations, without downtime or unexpected behavior.

You can't rely on this stuff if you want to avoid downtime.

If you want to avoid downtimes, you need to read changelogs and plan upgrades, and maybe test the upgrades before upgrading the production, in any case.

That works for an enterprise or business. When you are doing this stuff for fun and/or hobby, being halted during the upgrade is a MUCH better UX than deleting all my data or whatever undefined thing might happen.

Of course, I'm not advocating for such adversarial behaviors like the upgrade process deleting your files.

But you have a point, and maybe a solution to this issue ought to be found.

There's a nice spec for this by the UAPI group: https://uapi-group.org/specifications/specs/configuration_fi... , with the most common implementation called libeconf. The tl;dr is that an application / OS vendor can ship the default configuration in a path like /usr/etc, some dynamic runtime component can then override it in a path like /run, and a sysadmin can override that in a path like /etc. Each location is searched for a main config file or dropin patches under a `.d` directory or both (depending on the software's choice), and then considered in a defined order - later search directory roots have priority over earlier ones when the filename is the same, and dropins are considered in lexicographical order of filename regardless of which search directory they were found under.

That said, it unfortunately doesn't go on to specify local-user overridability via $XDG_CONFIG_HOME etc, which might limit its adoption.

> (hello Matrix / Synapse)

Synapse also supports using a drop-in directory for configuration

Nice. That was some time ago, it probably improved since then. I edited my post to reflect this.

I think it is matter of contract between author and users. Some authors just do not provide services like "background compatibility".

"Shipping" requires a lot of work, and some people just refuse to do that. Some of my popular programs are just repos on Github. To use them you have to run build script and execute from source code.

It elimites people who would require a lot of support, and would not give a meaningful contribution. Less work for me...

And if you desperately need my software, I always provide consulting...

I fail to see what is won by not providing clear, simple, standardised installation instructions in a README.

I make a habit of providing these for myself and they are great, both when I enter a new domain and need to remind myself of best practice, and when I return to a domain after a long time.

The lack of such instructions is a strong indicator to me that a project hasn’t reached maturity.

Reply on news.ycombinator.com