Better yet, a flat file structure that you can grep with standard utilities. We can put it somewhere convenient, like in dot files in the users home directory. We can even add them to git with something simple like git add *.*

As tempting as that may be, the ability to enforce ANSI SQL constraints (not null, unique, check, foreign key, etc.) could prevent many types of configuration errors.

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');

Good tips, thanks! I love sqlite3.

Yes! Let's also make every config file is its own special snowflake with its own syntax, keywords, and escape characters. That way, it's much harder for software to interact with these files and humans will have to write config templates for each deployment.

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.

You are suggesting good ideas, but we should go further. Let us write configuration files in Turing-complete exotic programming languages that almost nobody knows! This way malicious programs won't be able to parse them or perform automated edits, and many malicious humans too.

No need to get passive aggressive, parent has a legitimate point. Grep is a huge part of my workflow.

Ah I left out a few sentences. My passive aggressiveness is directed at the state of Linux distros today, not at the parent. I agree that his scheme is a lot better than the mess we deal with today.

> Grep is a huge part of my workflow.

You can flatten and grep structured binary formats too.

I honestly feel like you were just matching the tone of my comment so no harm done really. Mine was smarmy, yours passive aggressive. Its like a 90s sitcom in here!

Snowflakes are beautiful.

Better yet, put it in a .rec file for the best of both worlds: https://www.gnu.org/software/recutils/

Then you couldn't really use git (or any other kind of VCS) to version your config.

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.

Why add just a monstrous database engine that will spend time reading and parsing database schema, parsing SQL queries, building execution plans to read several settings? Let's go further and use Elasticsearch (startup time about 1 minute) for this.

By these rules, we probably shouldn't link to the C library either.

  # 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.6

Or Manticore Search (startup time 2 seconds) :)

Manticore vs Elasticsearch startup time benchmark - https://manticoresearch.com/blog/manticore-alternative-to-el...

SQLite has identical performance vs parsing ad hoc text files assuming you're reading from flash not RAM. It's also a lot faster if you're loading a few settings from a larger file.

SQLite is inefficient. For example: it parses table definitions and SQL queries, builds execution plans at runtime, although this could be done at compile time.

Like I said it makes no difference when your SSD takes 40us to respond to a read. Maybe you have an exceptionally slow CPU?