4 ms·

...but preferably using the SQLite engine, and eschewing well-known proprietary formats. https://news.ycombinator.com/item?id=32275078 https://news.ycombinator

by chasil 4y ago

...but preferably using the SQLite engine, and eschewing well-known proprietary formats. https://news.ycombinator.com/item?id=32275078 https://news.ycombinator.com/item?id=32275078

fezfight 4y ago
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 *.*
- chasil 4y ago
  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');
  - fezfight 4y ago
    Good tips, thanks! I love sqlite3.
- NavinF 4y ago
  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.
  - deleted 4y ago
    [deleted]
  - hsbauauvhabzb 4y ago
    No need to get passive aggressive, parent has a legitimate point. Grep is a huge part of my workflow.
    - NavinF 4y ago
      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.
      - fezfight 4y ago
        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!
  - fezfight 4y ago
    Snowflakes are beautiful.
  - codedokode 4y ago
    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.
- flukus 4y ago
  Better yet, put it in a .rec file for the best of both worlds: https://www.gnu.org/software/recutils/ https://www.gnu.org/software/recutils/
codedokode 4y ago
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.
- chasil 4y ago
  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
- snikolaev 4y ago
  Or Manticore Search (startup time 2 seconds) :) Manticore vs Elasticsearch startup time benchmark - https://manticoresearch.com/blog/manticore-alternative-to-elasticsearch/#startup-time https://manticoresearch.com/blog/manticore-alternative-to-el...
- NavinF 4y ago
  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.
  - codedokode 4y ago
    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.
    - NavinF 4y ago
      Like I said it makes no difference when your SSD takes 40us to respond to a read. Maybe you have an exceptionally slow CPU?
thayne 4y ago
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.

by chasil 4y ago

...but preferably using the SQLite engine, and eschewing well-known proprietary formats. https://news.ycombinator.com/item?id=32275078 https://news.ycombinator.com/item?id=32275078

fezfight 4y ago

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 *.*

chasil 4y ago
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');
- fezfight 4y ago
  Good tips, thanks! I love sqlite3.
NavinF 4y ago
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.
- deleted 4y ago
  [deleted]
- hsbauauvhabzb 4y ago
  No need to get passive aggressive, parent has a legitimate point. Grep is a huge part of my workflow.
  - NavinF 4y ago
    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.
    - fezfight 4y ago
      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!
- fezfight 4y ago
  Snowflakes are beautiful.
- codedokode 4y ago
  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.
flukus 4y ago
Better yet, put it in a .rec file for the best of both worlds: https://www.gnu.org/software/recutils/ https://www.gnu.org/software/recutils/

codedokode 4y ago

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.

chasil 4y ago
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
snikolaev 4y ago
Or Manticore Search (startup time 2 seconds) :) Manticore vs Elasticsearch startup time benchmark - https://manticoresearch.com/blog/manticore-alternative-to-elasticsearch/#startup-time https://manticoresearch.com/blog/manticore-alternative-to-el...
NavinF 4y ago
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.
- codedokode 4y ago
  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.
  - NavinF 4y ago
    Like I said it makes no difference when your SSD takes 40us to respond to a read. Maybe you have an exceptionally slow CPU?

thayne 4y ago

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.