(This started out as a comment on https://lobste.rs/s/vwhaig/configuration_files_suck .)
I’ve been thinking for the past week about @tedu’s “Features are Faults, Redux”, and it occurs to me that perhaps not all features are faults. Features related to runtime configuration are particularly prone to being faults, because they are a sign of a seam between zones of ownership. When I bring up Vim today it runs code straddling at least three distinct zones of ownership: the code in Vim itself, the system-wide
vimrc bundled with my OS, and my own personal
.vimrc. Vim’s configuration language mediates these transitions.
Runtime configuration is a symptom that the person doing the configuration is different from the person building the software. All of @tedu’s examples arose because the connection between the two grew gradually baroque over time (“could you just give me this one teensy little feature so I don’t have to look at your yucky code?”), eventually metastasizing into security issues like Shellshock.
This line of reasoning gives me a desire for a system shipped as a single zone of ownership. Ship with just two languages, one compiled and one interpreted. Users who wanted to change how a program behaves would have to edit its sources. The sources would be close at hand, though, shipped with each system. A single command would recompile the entire system. Programs would be organized to put configuration data in one place that’s easy to find.
OpenBSD is already pretty close to this ideal. You can tell from @tedu’s posts that OpenBSD maintainers are often treating it as a single zone of ownership and making pervasive changes. But what if we go further, just as a thought experiment? Rip out
/etc. Stop parsing configuration entirely in the base system. Assume that it’s intended for a desktop or server used by a single user who has some programming knowledge. Get rid of
I’ve been poking at
httpd a bit lately, and I notice that you can turn on TLS on a per-server basis. But the most common use case is a single user on a system who wants to run a handful of sites, all with TLS. The extra flexibility of per-server TLS configuration is obsolete, a holdover from the days when people shared common servers.
We still need some runtime configuration, say for text editors. I want to use tabs in my Go projects and spaces for everything else. And people may still end up building in runtime configuration on top of the base system, either for themselves or for non-programmers. But as a community we need to be querying all cases of runtime configuration much more antagonistically. “System-wide runtime configuration” should be an oxymoron.