3 ms·

I've (purposely) ignored the config files and systemd wars. But that means I am truly ignorant - what, in fact, is the big problem with plain old unix-style co

• digi_owl 12y ago
  Best i can tell, they don't play well with GUI config tools...
• vertex-four 12y ago
  > plain old unix-style config files Like what? /etc/X11/xorg.conf is a different format from /etc/openldap/ldap.conf is a different format from /etc/crontab is a different format from /etc/nsswitch.conf. Unifying configuration files under a single common format would allow for less complexity in configuration management tools - you could just create a data structure and serialise it to a file, rather than dealing with text-based templates with countless edge cases.
  • thwarted 12y ago
    And yet elsewhere, domain specific languages are preferred. I'd love to see the One Config File Format To End Config File Formats that supports xorg, ldap, crontab, nsswitch, apache, and anything else. Sure, use something like JSON, XML, INI, or YAML for this, for which the format is regular and parsable with an off-the-shelf parser, but then the domain specific stuff just moves into, for example, the key names. You've gained nothing in terms of maintenance or automatic editablity, but you have gained consistent use of whitespace and punctuation characters. "Creating a data structure and serializing it to a file" is doable text-based formats. Admittedly, templates are troublesome, but that's because you shouldn't be using templates anyway. Templates are an attempt to avoid understanding the domain specific language but still maintain the power of the domain specific language. I've never had good luck with this, which is why I mainly use configuration management tools, like puppet, to keep a fleet of machines in a consistent state by putting fully formed files in place. Templating takes significant care.
    • vertex-four 12y ago
      > And yet elsewhere, domain specific languages are preferred. Yes, but that's because the DSLs actually provide something of value. Having umpteen different ways to store a list of values under a key, for example, doesn't solve anything. > the domain specific stuff just moves into, for example, the key names Anything that wants to manage the system already needs to know the key names, etc - implementing a single config file format is significantly reducing complexity because they no longer have to implement config file parsers/serialisers. > I mainly use configuration management tools, like puppet, to keep a fleet of machines in a consistent state by putting fully formed files in place These tools are currently primarily based on templating. If you ever have reason to write your own resources for them (if you have to edit a config file for something obscure or in-house), you're going to have to write a text-based template to convert from your nice Puppet data structure to the config file format - and probably get it wrong on edge cases.
• acdha 12y ago
  There are two things which I've heard a lot: 1. Every program rolls their own format, so you end up with a bunch of custom rules for configuring each application on the system. This makes life tedious for anyone automating system management and, on a practical level, increases the chance of human error when someone forgets the precise ways in which their experience with something else isn't quite portable. 2. There are a wide range of supported features – e.g. interaction with environmental variables or external defines / defaults, ability to reference other config values, ability to either include a file or merge config parsed from a different location – and this leads to more tooling to paper over the gaps. 3. Hierarchy and discovery: in Windows or OS X, the preference system has the concept of user, system and domain config so you can set sane defaults at the domain level but a user can still override one of them just for their account. (There's another interesting tangent here where it's useful to have config supplied with a package which can be selectively overridden by a sysadmin without forking the entire file) This works, at least for certain values of "works", because there's a single standardized API for working with the registry or plist files. I generally dislike the details of plists but the fact that I can e.g. run "defaults read [scope] key value" and get the same effective config value which an application will use without knowing at which level it was last set or even whether the file was the older XML plist format or the newer binary one is really handy. The fact that a config tool can simply run "defaults write [scope] key value" and not have to worry about those same mechanics is even nicer for sparing me time worrying about e.g. editing a text file safely, knowing whether I can just dump a new value at the end or must purge old values first (oops, FooD stops at first value while BarD uses the last and BazD does either depending on quirky rules you'll just have to learn…), etc. Similarly, launchd has a regrettable config syntax but I've forgiven it at lot because it's a relief to use the same tool everywhere rather than needing the accumulation of different hacks and kludges which sysv init/cron or, absurdly, upstart still require in practice. What would be really nice would be someone building a library with plenty of language which supported configuration based on the classic Unix config files but with a defined syntax and well-documented strategies for error handling and hierarchy and started working to help popular programs migrate over on the next backwards-incompatible release. There's certainly no technical reason why any of the good parts should require Apple's XML cruft or the accumulated bad culture around the Windows registry.
  • 12y ago