So, these days, I'm always trying to find and follow the conf.d tradition. The rationale of this tradition looks like:

• /etc/somepackage/somepackage.conf is where the default configuration is.
• /etc/somepackage/conf.d/ is where the overrides are; this is where you put your user conf.

Normally somepackage.conf is managed by the package manager. When the package gets upgraded (shipping a new version of somepackage.conf), and there are local changes, the package manager will ask you: To overwrite with the maintainer's version or to keep yours.

This question is often difficult to answer, especially if you can't, for the life of you, remember what the heck that package is about. Even "show diff" sometimes fails to help. You have to resort to searching.

Keeping your confs under conf.d helps you avoid this altogether. It also helps you separate them, selectively include/exclude some of them to a system, and prioritize them (the 00-my.conf and 99-my.conf pattern).

But that makes me wonder: If all of my user conf will stay inside conf.d, why bother? Why have /etc/somepackage/somepackage.conf at all? Why is it under /etc anyway? Legacy. /etc/resolv.conf is the first example to come to mind. Different apps fight over the control of this file, so sometimes you encounter advice like sudo chattr +i to prevent any change. Absurd, but it works!

So today I briefly wondered if there's any ongoing effort or a new clever solution to address this. Well, there's NixOS which nullifies quite a bit of my point. I've always liked its idea since like 15 years ago. But is there anything else, anything new, for my existing (less exciting) systems?

…I asked ChatGPT 5-Thinking about this, and its answer was mostly expected. The only thing that amused me was the discovery of etckeeper. OK that looks interesting.