It really is a mess and it would be helpful if we had some sort of database for configuration that was reasonably standardized. Some sort of "registry" if you will :D
If you want to grep everything in a sqlite database, then ".dump" it.
$ echo "create table myconfig(param text, value text);
insert into myconfig values('scrollbar', 'wide');
insert into myconfig values('verbose', 'no');" | sqlite3 myconfig.db
$ sqlite3 myconfig.db '.dump myconfig' | grep verbose
INSERT INTO "myconfig" VALUES('verbose','no');Oh and we might as well store these config file in a different place on each distro and move them around once in a while just to keep things interesting. Users can ignore upstream documentation and just strace the process if they wanna know where the files are this year.
> Grep is a huge part of my workflow.
You can flatten and grep structured binary formats too.
# ll /lib64/libc-2.17.so /lib64/libsqlite3.so.0.8.6
-rwxr-xr-x. 1 root root 2156664 May 18 20:27 /lib64/libc-2.17.so
-rwxr-xr-x. 1 root root 753272 Jan 27 2020 /lib64/libsqlite3.so.0.8.6Manticore vs Elasticsearch startup time benchmark - https://manticoresearch.com/blog/manticore-alternative-to-el...
Also, not all config really lends itself to rows in a database (or some other binary registry). For example, commands to run on login. Or really anything where order matters, would be a pain to edit.
Things like dconf and about:config exists in no man's land, where neither generic GUI skills nor generic unixy skills are applicable.
How is this a problem with dconf? GNOME Settings for example is typical GUI preferences and works as a front-end to the dconf database.
Edit: Although I agree that some situations may require a readable text format, like a dotfiles repo. I personally use the `dconf-editor` program to find the right keys and the `dconf load` command to sync them from a regedit-like file format
Neither of these is a complete answer, but
1. Distros like NixOS and GuixSD address this successfully by emitting the config files themselves. They don't statefully edit your configs but instead store them in their own language and then translate them as wholes.
2. You can mitigate much of the pain of this with something like etckeeper, which essentially gives you version control for /etc.
I don't care. They can use OSes designed for their needs, like macOS and Windows.
Not sure why there is such a persistent idea that "everyone using Linux, including entirely non-technical users who just want an appliance" is actually a desirable or realistic goal.
And the funny thing is that everyone does use Unix. Everyone with a smartphone does as both iOS and Android are derivatives of Unix-OSes (Darwin and Linux). Only Fuchsia will be truly non Unix. If it ever makes it out the door.
However those mobile OSes (or ChromeOS) are of course not what we're talking about when we say we love Unix. The same will happen if Linux ever makes it mainstream. Consumers might love it but we won't. I'm happy for it to stay a niche thing. My niche.
You're responding to complaints that settings done this way are user-hostile, opaque, and require a ton of insider knowledge to even find. So if the only goal is user-friendliness, we're moving away from it, not towards it.
(The answer is not to type "sound" into the search bar. That takes you to the "new" sound control panel, which doesn't have all the old features, including disabling sound devices. So you have to open the control panel, go to Devices & Sound, and then you can search around to disable a device.)
The fundamental difference between Windows and Linux here is that if you write an instructional blog post to fix this problem for Windows, you can put some drive-by malware installer on it and make some money. You could obviously malware up similar Linux documentation, but by the time you get discovered you will have only infected 1 person, simply because it's much less widely used. Unfortunate!
I had to check literally more than a dozen locations in the registry (some in different hives) just to see where the thing was actually set to autoload. I then had to create new keys in still another location whose type was simply arbitrary binary data, and the only way to determine what actual value was needed there was to examine the registry before and after disabling and then reenabling the startup profile in the GUI.
The Windows registry is an absolute fucking shitshow, and it's a big part of the reason that the OS is inherently hostile to automation. The inherent invisibility of the registry and the systematic underdocumentation of registry schemas for applications and OS components makes figuring out how to do anything in a repeatable way a fucking quest.
> I personally use the `dconf-editor` program to find the right keys
For GUI applications, config files are often undocumented anyway. But to me having to run an application and see how it messes with its configuration in some database when you click buttons is an insane way to figure out how settings are declared or stored. I would so much rather the configuration format be plaintext and documented than be expected to reverse engineer my apps' friggin' config files!
The thing we want to optimize for is "how easy is to change a setting". Firefox's "about:" seems like a reasonable approach for expert users.
You wouldn't even need that many basic types to cover about 90%+ of the state space. Of course, there would be bonus points if applications could define their own types in a UI-meaningful way.
These issues neither disappear nor improve when you hide the settings in a mystery binary.
It would be nice to have a base level of types that all programs could agree on.
Same problem with Firefox; hamburger->settings will take you to a GUI that contains maybe 0.01% of all the settings Firefox actually has. You have to be "in the know" to know that about:config exists. I think the first time most firefox users find out about about:config is when they're angrily searching the web for a solution to their problems, which is basically how I discovered dconf-editor too. You don't find either of these by searching through the GUIs like a normal computer user, nor will you find them by poking around in your dotfiles like a seasoned console jockey.
Any setting in about:config can be set in user.js and your user.js file can be diffed, grepped, version controlled, edited with your favorite editor, and copied between profiles/machines.
Sadly, Mozilla is moving a lot of config out of about:config/user.js and into multiple random sqlite files, so sane config management is getting harder with each new release.