Inital Conditions are Structured Data
Posted in Programming and Technical, Ubuntu on May 21st, 2009 by doctormoI was looking at etckeeper recently, it looks like a fascinating program that will store configurations in any one of half a dozen repository types. Thus allowing the experienced administrator to easily version control and distribute their system’s configurations.
When I think of configuration files, weather it be in etc or in the users home directory1, I think about them as initial conditions: You have a logical program your going to run and setting the initial conditions will make it go this way or that way in the logic. The fact that these conditions are saved over from the last execution is irrelevant for this thought exercise.
Now all initial conditions follow the very fixed mathematical rules of all structured data. If I were to put this in Perl parlance, everything’s a hash, array or string. Even seemingly complex things like crontabs will fit this rule once you make take order and format out the back and shoot it.
Following this logic it should be possible to convert any one configuration format into any other2, given enough information about the file’s intended format. Once you can describe what the file should look like you can get on with working on explaining what the structure should be.
Then your but a stones throw away from being able to systematically test any initial condition data (configuration files) against known structure validators (say an xsd or dtd) using a clever format parser definition (see what vim does for lots of examples) and confirm that this version of the package’s config will work with the next version.
And then… now here’s where you can get some really fancy happenings: you can use translation languages like xslt to upgrade or downgrade from one version to the next of any given configurations. Making systematic config regressions disappear and allowing programmers to offload configuration management onto a standard system.
I’ll be at UDS and I’ll be happy to discuss or argue with anyone there about the merits of such a system.
1 All of which should be moving to ~/.config/ XDG directories anyway.
2 Except those where form and function are bound, e.g. crontab

Then, I think towards all of the people in the modern world who no longer consider themselves parts of their cultures, communities, countries. They consider themselves classes by it, but not a part of it. It means they can be lazy and lay easy claim to other people’s successes, but to feel no responsibility to do anything for anyone else inside of it.

So to take advantage of these ideas for Ubuntu LoCos and communities it would mean focusing very hard on a very small community or sector and focus all resources on getting that community up to 66% usage in order to get ignition, this is where the ideas will shift and everyone will believe that it’s normal to use Ubuntu (see 


