4 ms·
The problem with a Turing-complete configuration format is that pretty much the only thing you can do with it is preserve it verbatim, or execute it to see what
by thristian 12y ago
The problem with a Turing-complete configuration format is that pretty much the only thing you can do with it is preserve it verbatim, or execute it to see what config it produces. You can't, for example, write a tool to safely update a config file to work with a new version of the software, or to apply some specific update across a bunch of machines, or to catalogue the configurations each machine has.
- andrewflnr 12y agoYeah, but that's more of problem with shell than Turing-completeness in general. You just need to design a language with a usable T-incomplete subset, like maybe name assignments and conditionals. The only problem is that it's tricky to enforce that sort of sunsetting on sh. But I don't see why your migration script couldn't just say, "sorry, your config is too weird to automatically migrate" when it sees a loop or external callout.
- contingencies 12y agoYou can't, for example, write a tool to safely update a config file to work with a new version of the software You never can tell the future. This is a straw man. apply some specific update across a bunch of machines This is a bad idea anyway: the immutable server model seems to have been recognized as the way forward. See https://news.ycombinator.com/item?id=6705269 https://news.ycombinator.com/item?id=6705269 for reasoning. or to catalogue the configurations each machine has Again, immutable servers make this pointless. I think, overall, given your examples you are clearly looking at the wrong tool (ssh or whatever plus systemd; a host-centric combined init system, process manager, log manager, and whatever else) for the job (managing multiple machines in disparate states).