rants: Tue Dec 2 22:49:00 2014

Tue Dec 2 22:49:00 2014

C privilege

Previously I went on at length about the flaws in the language-based package manager model; coincidentally I got to see some of the background/sausage-making¹ of a Debian attempt to reconcile certain pip vs. dpkg issues. While I have a lot of respect for the people involved and the effort they're putting in to the problem, I stood (quietly) by my belief that the whole space is wrong... and then a digression about C led someone² to state that

it could be argued that distros packaging is the C package manager

which collided with a few other ideas floating around in my head:

• The extent to which a programming language is "real" rather than "scripting" matches closely with how easy it is to get at C from it - Go breaks the model, but (to be a little mean) Java doesn't
• C was there first, everything else has to play by C's rules even when they're stupid (see career_limiting_memcpy)
• People who "have" C tend to defend its difficulty (discussions of programmer interviewing techniques come to mind though I don't have good references handy, the internet mostly has bad ones)
• Concrete examples of human-oriented approaches to hard-core engineering problems (the relatime story specifically, as an instance of a solution that implies a class of approaches.)

All of this clicked into shape as a pattern of privilege - not to coopt the language of the very real problems the industry faces, but just to look at the "anti-pattern" of the conflict between distro and language package management from a perspective that makes some sense of why language package managers refuse to die off - it's not just that the people who work on them are persistent and/or stubborn. Certainly it turns the question around: given all the other language-specific package managers, where is the C one? And, as with social privilege, once you start looking for it, you realize that maybe "you're soaking in it" - and that Unix has been, since the 1970's, an extended support system for the C language, so of course any "distro packaging system" is going to be heavily C-program biased.

Now is that a helpful epiphany? It has the initial smell of "reduced to a previously unsolved problem", but it does suggest that attempting to credit C with it's proper share of the packaging burden might be productive; that leads to the idea that instead of "why would a language have anything intelligent to say about where files get installed" that in fact, the language may have one set of things to say, and the distro has a different set of things to say, and while we need them to mesh, they are more likely (today) to grind. It also suggests the fun mental exercise of considering a world, perhaps not without C but one where you assume your language of choice (yes, Python) as a starting point - maybe not as deeply special as the Lisp Machine, but it could still lead to some implementable insight.