If your idea of a good configuration file format is JSON, you are not a daemon I will ever run voluntarily.
-
If your idea of a good configuration file format is JSON, you are not a daemon I will ever run voluntarily.
This is not very much of a subtoot of ISC Kea. If we ever have to replace the traditional ISC DHCP server with anything, it will not be with Kea.
@cks I was about to "upgrade" isc dhcpd wtih kea until I saw that. New deployments will probably be dnsmasq instead. Which has its own problems. I have a hard time trusting a dev team that thinks json is a suitable format for a human edited config file. What other anti-pattern have they used?
-
If your idea of a good configuration file format is JSON, you are not a daemon I will ever run voluntarily.
This is not very much of a subtoot of ISC Kea. If we ever have to replace the traditional ISC DHCP server with anything, it will not be with Kea.
@cks I usually convert to yaml, edit and then convert to json back in my editor. If the goal is to keep dependency free, json is usually the only option as it is available in stdlib in most languages.
-
@cks I was about to "upgrade" isc dhcpd wtih kea until I saw that. New deployments will probably be dnsmasq instead. Which has its own problems. I have a hard time trusting a dev team that thinks json is a suitable format for a human edited config file. What other anti-pattern have they used?
Interestingly, they opted to make many of the v2 plug-ins open source with v3. I wonder why
The closed "enterprise-only" plug-in ecosystem was one of the reasons next to the idiosyncrasy of using JSON for human readable config files, why we opted against kea, just fearing we may need a plug-in down the line and would need to lock into a support contract.
dnsmasq does have its fair number of quirks, but so far, definitely usable.
-
If your idea of a good configuration file format is JSON, you are not a daemon I will ever run voluntarily.
This is not very much of a subtoot of ISC Kea. If we ever have to replace the traditional ISC DHCP server with anything, it will not be with Kea.
If your program's configuration file format is JSON, you're openly advertising that you care far more about programming convenience in reading and loading your configuration file than you do about the people operating your software. "You can generate our JSON with software from something else", yeah, no. You've told me what your priorities are and I'm going to believe you. I would rather run software that actually cares about the people running it.
-
If your program's configuration file format is JSON, you're openly advertising that you care far more about programming convenience in reading and loading your configuration file than you do about the people operating your software. "You can generate our JSON with software from something else", yeah, no. You've told me what your priorities are and I'm going to believe you. I would rather run software that actually cares about the people running it.
@cks json5 is fine in your book, right?
-
@cks json5 is fine in your book, right?
@untitaker JSON5 is moderately less hostile than JSON but for most programs it's still advertising that you care a lot more about programming convenience than having a good experience of writing configuration files.
(For both simple and complex configuration files there are much better syntaxes that are easier for people to deal with.)
-
@untitaker JSON5 is moderately less hostile than JSON but for most programs it's still advertising that you care a lot more about programming convenience than having a good experience of writing configuration files.
(For both simple and complex configuration files there are much better syntaxes that are easier for people to deal with.)
@cks @untitaker My most recent project uses tab-separated values that a script turns into XML. I assume you hate everything about this.
-
If your program's configuration file format is JSON, you're openly advertising that you care far more about programming convenience in reading and loading your configuration file than you do about the people operating your software. "You can generate our JSON with software from something else", yeah, no. You've told me what your priorities are and I'm going to believe you. I would rather run software that actually cares about the people running it.
@cks I'm inclined to think the same about yaml.
It gets used for configuration in the sense that any extension language can be used as a configuration language.
The syntax is so <expletive deleted/> that it reminds me of the time some idiot added if-then-else to xml itself.<p:if xmlns:p="http://www.w3.org/ns/xproc" test="/person/age >= 18">
<p:then>
<status>adult</status>
</p:then>
<p:else>
<status>minor</status>
</p:else>
</p:if> -
@cks @untitaker My most recent project uses tab-separated values that a script turns into XML. I assume you hate everything about this.
@jef @untitaker I think tab separated values (with comments, I hope) are a perfectly good format; I have a lot of configuration file formats in my own tools that are basically lines of 'a b'. What you turn them into internally is not my (sysadmin) problem.
-
@cks I'm inclined to think the same about yaml.
It gets used for configuration in the sense that any extension language can be used as a configuration language.
The syntax is so <expletive deleted/> that it reminds me of the time some idiot added if-then-else to xml itself.<p:if xmlns:p="http://www.w3.org/ns/xproc" test="/person/age >= 18">
<p:then>
<status>adult</status>
</p:then>
<p:else>
<status>minor</status>
</p:else>
</p:if>@davecb I don't like YAML all that much but at least it has comments and forces people to write multi-line things and so on. It's more or less a tolerable universal solvent at this point, although it's not actively good the way a configuration file format could be.
(If you don't need nesting there are simpler general formats like TOML.)
-
If your program's configuration file format is JSON, you're openly advertising that you care far more about programming convenience in reading and loading your configuration file than you do about the people operating your software. "You can generate our JSON with software from something else", yeah, no. You've told me what your priorities are and I'm going to believe you. I would rather run software that actually cares about the people running it.
It's one of the things I love about UCL-style syntax…pretty much every time I've encountered it, the syntax feels like it was targeted more at users rather than devs.
GitHub - vstakhov/libucl: Universal configuration library parser
Universal configuration library parser. Contribute to vstakhov/libucl development by creating an account on GitHub.
GitHub (github.com)
-
@davecb I don't like YAML all that much but at least it has comments and forces people to write multi-line things and so on. It's more or less a tolerable universal solvent at this point, although it's not actively good the way a configuration file format could be.
(If you don't need nesting there are simpler general formats like TOML.)
@cks I vaguely remember doing nesting in toml.
[servers]
[servers.alpha] ip = "10.0.0.1" dc = "eqdc10"
[servers.beta] ip = "10.0.0.2" dc = "eqdc20"Are we talking about the same thing?
-
If your idea of a good configuration file format is JSON, you are not a daemon I will ever run voluntarily.
This is not very much of a subtoot of ISC Kea. If we ever have to replace the traditional ISC DHCP server with anything, it will not be with Kea.
@cks I used to use a sandwich combination of = separated kv pairs in a global config, followed by libpopt ( https://manpages.debian.org/testing/libpopt-dev/popt.3.en.html ) to handle runtime overrides with an additional override of a per user override kv config file.
It was very user friendly but a huge PITA from a developer perspective.
Now all software I wrote (for work) uses straight up JSON for inputs. But that json is generated from thrift schemas which are managed by a python DSL, so it all kinda works.
-
R relay@relay.infosec.exchange shared this topicR relay@relay.mycrowd.ca shared this topic
