2 ms·
> yet another poorly thought out, ad-hoc homegrown config file format OpenBSD style ntpd.conf: servers 0.gentoo.pool.ntp.org servers 1.gentoo.pool.ntp
by akira2501 2y ago
> yet another poorly thought out, ad-hoc homegrown config file format
OpenBSD style ntpd.conf:
servers 0.gentoo.pool.ntp.org
servers 1.gentoo.pool.ntp.org
servers 2.gentoo.pool.ntp.org
servers 3.gentoo.pool.ntp.org
constraints from "https://www.google.com"
listen on *
I mean, there's always the possibility that they used a common, well known and pretty decent config file format. In this particular case, this shouldn't be the thing that differentiates your ntpd implementation anyways.
- IshKebab 2y agoThat config file perfectly illustrates the point. There's no need for it to be custom, and require me to waste time learning its syntax when it could just be JSON or TOML. Honestly I would even take YAML over that and YAML is the worst.
- xorcist 2y agoYou still have to learn the syntax even if it is expressed in json or yaml. Perhaps stating the obvious, but not every json object is a valid ntp configuration. The configuration object will always and by definition be proprietary to ntp. Expressing it as plain text allows for a trivial parser, without any of the security implications of wrapping it in a general language language ("should this string be escaped?", "what should we do with invalid utf8?"). The more simple format has survived over thirty years, is trivial to parse by anyone, and does not bring any dependencies that needs maintaining. That should count for something.
- IshKebab 2y agoSure you have to learn how to configure things but you don't have to learn basic syntax like "how do I escape a string". The fact that it has survived tells you nothing other than it's not so completely awful that someone went through the pain of fixing it. That doesn't mean it is good. There are plenty of awful things that survive because replacing them is painful due to network effects. Bash for example.