11–20 of 69 posts
About 20 or so years ago, I have come across a configuration pattern that could be arguably called "Level 0". It was configuration by file existence. The file itself would be typically empty. So no parsing, syntax, or schema involved. For example, if the file /opt/foo/foo.txt exists, the software does one thing but if it is missing the software does another thing. So effectively, the existence of the file serves as a…
> Don't waste time on discussions within a level. For example, JSON and YAML both have their problems and pitfalls but both are probably good enough. Disagree. YAML is considerably easier to work with than JSON, and it’s worth dying on that hill.
But if you do require a complex configuration, I think it is beneficial to both yourself and your users to invest in a openbsd style parse.y like solution rather than just shovel the usual json or yaml slop.
https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr...
By which I mean it does not have to be yacc, but taking the time to think about the language of your configurations improves the ui dramaticly.
> Don't waste time on discussions within a level. For example, JSON and YAML both have their problems and pitfalls but both are probably good enough. Disagree. YAML is considerably easier to work with than JSON, and it’s worth dying on that hill.
I love that there is one comment saying JSON is better, and then yours saying YAML is better.
About 20 or so years ago, I have come across a configuration pattern that could be arguably called "Level 0". It was configuration by file existence. The file itself would be typically empty. So no parsing, syntax, or schema involved. For example, if the file /opt/foo/foo.txt exists, the software does one thing but if it is missing the software does another thing. So effectively, the existence of the file serves as a…
> Don't waste time on discussions within a level. For example, JSON and YAML both have their problems and pitfalls but both are probably good enough. Disagree. YAML is considerably easier to work with than JSON, and it’s worth dying on that hill.
About 20 or so years ago, I have come across a configuration pattern that could be arguably called "Level 0". It was configuration by file existence. The file itself would be typically empty. So no parsing, syntax, or schema involved. For example, if the file /opt/foo/foo.txt exists, the software does one thing but if it is missing the software does another thing. So effectively, the existence of the file serves as a…
eject mt
[ test
chgrp chmod
cksum md5 sha1 sha256 sha512
cpio pax tar
ksh rksh sh
And I am guilty of abusing symbolic links as a simple single value key value store. It turns out the link does not need to point to anything and using readlink(1) was easier than parsing a file.
I'm not convinced by reducing this to a single dimension. There are differences in both 'what can be expressed' and 'what validation can be done' which are somewhat independent of each other
Debugging a configuration becomes tedious once computation is involved. You think some value should be "foo" but it is "bar". Why is it "bar"? If someone wrote it there, the fix is simply to change. If "bar" is the result of some computation, you have to understand the algorithm and its inputs, which is significantly harder.
Given a "reversible" programming language that might be easier. Such languages are weird though and I don't know much about them. For example: https://en.wikipedia.org/wiki/Janus_(time-reversible_computi...