You must log in or register to comment.
I’ve only read the headline and first paragraph but… I already think there’s this is flawed.
It’s treating the symptom rather than the problem. Really we need to be standardising how applications are configured. Standardise the command line arguments, add logical defaults. Pick a single configuration format and a centralised location where is defined.
This is one reason I favour docker compose for running apps. Everything is configured through a
docker-compose.ymlfile.While that sounds good in principle, it’s effectively impossible to implement in reality.
The author’s proposal is a more modest and achievable one that accomplishes nearly the same thing
- regedit.exe
- dconf
- …
I kinda get it, but I also feel this going to be yet another ‘standards’ thing.
Most config files are here:
- /etc/
- /opt/PROG/etc/
User specific tends to be in:
- /home/USER/.config/
And when it comes to Windows, take your pick of the registry hive (HKLM, HKCU, …the other ones…), Prog Files, Prog Files x86, AppData (Local, Roaming, LocalLow), etc.
If it’s not, it’s usually trvial to find the config file from the running process as part of the launch command, or indeed in a softlock from their lsof output.
But, what if the config is not in a dedicated file? What if the config is read from a database? What if the config is interactively set at launch shudder?
I get it, the person is asking for it to be explicity pointed out in the documentation/help. However, if it’s not documented, then it’s probably shitty software - so why would you expect them to follow this rule just for config files?
I think, inevitably, this actually comes down to sysadmins who don’t bother to RTFM but also don’t push back on devs/managers when asked to fix something they can’t. Also, again, see the XKCD…
