Comment by anonsivalley652 | Hacker News Reader

Comment by anonsivalley652 | Hacker News Reader

Parent Full thread

anonsivalley652

Yes, text configuration files are dumb because they require N parser/script editors times M configurable programs. Furthermore, what people really want is universal progmatic and CLI access to configuration.

Microsoft Microsoft'ed configuration management with the way they implemented the registry. The Apple PList way sort-of goes there but doesn't quite master it.

A better way would've been is configuration via code and command-line that's easy to interface for all purposes. It's important to:

- be able to transactionally backup and restore all settings

- have multiple instances of the same program with different settings

- wipe out settings to default

- enumerate all settings within a program or within the whole system

- subscribe and be notified of setting changes

- ACLs or privileges to separate users and processes from each other (similar to the Windows Registry)

- audit and undo setting changes

- hide secrets that are provided from dynamic providers

- allow dynamic providers for values of settings

Switch and router OSes have a unique CLI configuration system that is both simple and quite powerful. Compared to Linux I especially like the ability to enumerate the entire configuration with one command ("show running-config" in Cisco's IOS, for example).

I would love to be able to see and manage a Linux system's configuration in an analogous way. Obviously there's a lot more to a modern general purpose OS than a simple network device, so I'm not sure, maybe it wouldn't work very well?

> Yes, text configuration files are dumb because they require N parser/script editors times M configurable programs.

No, they don't. It's N editors + M parsers (where M=programs) I suppose if you want really smart editors that are also developed completely independently, such that each require it's own parser, its N+M parsers plus N editors.

> Furthermore, what people really want is universal progmatic and CLI access to configuration

I'm fairly certain most people don't want anything CLI anything.

> I'm fairly certain most people don't want anything CLI anything.

I'm fairly certain they all want CLI everything, it's just they don't know it yet.

It's more convenient to call and export needed function directly via C API than force everybody to make and use another "universal" layer.

I want better CLIs. The author's criticism is spot on when it comes to those. The CLI flag format should be specific to the shell not specific to the program.

The low hanging fruit is a common parser/serializer, which is usually handled in library code in Unix - handwritten parsers are usually the enemy.

The other bits describe a whole configuration management system, which gets into the realm of questions like "For version X of software Y, value Z can be between A and B, but this changes when using version X+1", which is extremely difficult logic to encode into an external data store. Even worse are relational consistency issues that come up across structures.

Having a "fail if invalid" results in people setting values and then being frustrated at the system.

BTW, this all existed in a language neutral way in the early 2000's with XML parsing and validation leveraging RelaxNG and Schematron. Unfortunately those were deemed ugly and hard to use, and thrown out in exchange for the half baked JSON/YAML solutions.

I know it’s a bit hacky, but you can satisfy most of your requirements with environment variables; and most of your other requirements with a mini daemon that sits on top of `env`.

When I think about it, this is basically what the various “keychain” daemons provide, which IMO are underused despite their terrible ergonomics.

This sounds like your basic configuration management tool plus a service discovery tool.

Reply on news.ycombinator.com