> /etc/ is per-system configuration overrides. There is a goal to move to "empty /etc/", meaning you should be able to remove all files in /etc/ and still have a functioning system.

I find this goal to be rather frustrating.

It means that software will hardcode it's default configuration when it cannot find a file in `/etc`, and it makes it very hard to deduce what exactly can be configured.

I strongly dislike software that will simply apply a default state when it cannot encounter a certain configuration in it's configuration file for this reason.

I favor that software simply refuse to start with a clear warning as to why, when it cannot find a configuration option in it's configuration file.

Applying a default on a missing key is another case of weak typing; I would hope that lessons were learned by now that guessing what the user wants in case of error is a bad idea.

What is even worse is software that simply ignores malformed keys, and applies a default value anyway, giving rise to not only innocent mistakes by typoes, but some malicious exploits that were found by putting zero-width spaces into keys to trick administrators viā social engineering.

I partially agree, but I think a good middleground is for default configuration to be in a place like /usr/share/, and allow for admin configuration to happen in /etc/. This way, if you upgrade, you don't need a complicated merge to merge new defaults + old configuration. I've seen a lot of configuration migrations gone wrong in my life.

That would mitigate the problem of easily finding out what options there are, but it would still be a form of weak typing where a best guess is substituted for a mistake.

If the system administrator truly intend for a value to be default, he should explicitly declare it so in the configuration file.

Interpreting the system administrator's act of forgetting something as his intention for it to be a default value, seems like a bad idea to me.

As for merge, I find it as annoying if software not support configuration directories. `foo.conf` should exist alongside `foo.conf.d`, and if the latter exist, it's contents should be parsed as well.

On an update, the system can simply install a file in `foo.conf.d` which contains the default of any new keys added from the last version.

> I strongly dislike software that will simply apply a default state when it cannot encounter a certain configuration in it's configuration file for this reason.

Isn't sensible default what make certain software a lot easier to use then others? Apple seems to be good at this. Ten years ago Ubunutu brought this to the Linux world to an extent. Personally I like the configurability of Linux, but I am past the days of spending hours tweaking it and I am quite happy if someone supplies me with sensible defaults.

Having said that, as a developer I agree with what you said, it's often easier if a library call gives an error than tries to do something smart / just carries on (JavaScript comes to mind), so there is a balance depending on what the user wants to do with the software.

Default configuration exists for multiple reasons: 1) to provide minimally working software so that the user isn't burdened by unnecessary configuration, 2) to facilitate easier testing of minimal functionality, 3) to keep configuration DRY, and 4) to stop-gap missing configuration.

Of those, only 4) relates to typing. But even then it often bears no relation to real typing, because often there's no schema or typing at all, and usually application has no idea what version a given configuration relates to.

In addition to achieving the above 4 points, we also need to be able to differentiate between default and modified configuration, so the application can override defaults successfully. You can keep default and modified configs separate a number of ways. You can hard-code it in the application, which is fine for the application. But it's a pain in the ass for the user. And as a packager, you cannot expect files in /etc/ to always be "defaults", as the user/administrator expects these to be configured by themselves at any time. And if you want to upgrade software, there needs to be a way to differentiate the versions of default configuration to compare the modified configuration to.

The best way to do this is to package default configuration in /usr/share/. The user then has the job of upgrading their modified configuration in /etc/, and they can use /usr/share/ as a reference, in combination with some UPGRADING guide.

Distros have long had a convention to package a default distro-specific configuration in /etc/, so that when the app first starts, it can work out of the box. But then when you'd upgrade a package, the distro would have to figure out what to do with the once-default-but-now-modified files in /etc/. This just adds unnecessary burden on the distro. Instead, the user needs to look at their own manual configuration and update it if necessary. But the default configuration for the system should remain virgin and independent, in /usr/share/.

And of course, none of this applies to configuration that can't be default. The application should always die if it doesn't find required configuration.

Yes. But generally many software allow configuration in home directory. That's least of my problems with Linux.

/usr/local/etc is a common pattern, though.

So maybe I would add that /usr/local is a special case of /usr for locally built* stuff, with sub-nodes imitating the corresponding nodes in /.

* Not always locally built, though. *BSDs put binary packages there too.

Except more often than not packages do their own thing and don't follow the convention. this is even worse if you compile from source.