A Generation Lost in the Bazaar

He takes a little while to get going, but the rant about "configure" that starts halfway down is spot-on.

Poul-Henning Kamp:

Further down the shopping list are repeated applications of the Peter Principle, the idea that in an organization where promotion is based on achievement, success, and merit, that organization's members will eventually be promoted beyond their level of ability. The principle is commonly phrased, "Employees tend to rise to their level of incompetence." Applying the principle to software, you will find that you need three different versions of the make program, a macroprocessor, an assembler, and many other interesting packages. At the bottom of the food chain, so to speak, is libtool, which tries to hide the fact that there is no standardized way to build a shared library in Unix. Instead of standardizing how to do that across all Unixen--something that would take just a single flag to the ld(1) command--the Peter Principle was applied and made it libtool's job instead. The Peter Principle is indeed strong in this case--the source code for devel/libtool weighs in at 414,740 lines. Half that line count is test cases, which in principle is commendable, but in practice it is just the Peter Principle at work: the tests elaborately explore the functionality of the complex solution for a problem that should not exist in the first place.

Even more maddening is that 31,085 of those lines are in a single unreadably ugly shell script called configure. The idea is that the configure script performs approximately 200 automated tests, so that the user is not burdened with configuring libtool manually. This is a horribly bad idea, already much criticized back in the 1980s when it appeared, as it allows source code to pretend to be portable behind the veneer of the configure script, rather than actually having the quality of portability to begin with. It is a travesty that the configure idea survived. [...]

Today's Unix/Posix-like operating systems, even including IBM's z/OS mainframe version, as seen with 1980 eyes are identical; yet the 31,085 lines of configure for libtool still check if <sys/stat.h> and <stdlib.h> exist, even though the Unixen, which lacked them, had neither sufficient memory to execute libtool nor disks big enough for its 16-MB source code. [...]

This is probably also why libtool's configure probes no fewer than 26 different names for the Fortran compiler my system does not have, and then spends another 26 tests to find out if each of these nonexistent Fortran compilers supports the -g option.

That is the sorry reality of the bazaar Raymond praised in his book: a pile of old festering hacks, endlessly copied and pasted by a clueless generation of IT "professionals" who wouldn't recognize sound IT architecture if you hit them over the head with it. It is hard to believe today, but under this embarrassing mess lies the ruins of the beautiful cathedral of Unix, deservedly famous for its simplicity of design, its economy of features, and its elegance of execution. (Sic transit gloria mundi, etc.)

(Yeah, you may guess that he lost me at the "beautiful cathedral" line. I can forgive that for his use of "festering pile".)

Tags: ,

33 Responses:

  1. Tom Lord says:

    Garsh, who could have seen that coming.

  2. David McNett says:

    I love that his column is named The Bikeshed. That's a nice nod to another quality phk rant.

  3. I found the cathedral / bazaar dichotomy rather odd, given that both have plenty of examples of horrible results. phk's been successful in making the case for clean design by simply doing it - compare varnish to squid - so the real puzzle is why he's ranting about autotools rather than simply ripping it out and publishing a “you have nothing to lose but execrable configure scripts” manifesto.

    • Tom Lord says:

      why he's ranting about autotools rather than simply ripping it out and publishing a “you have nothing to lose but execrable configure scripts” manifesto.

      I will go out on a limb and claim that it is impossible to provide a significantly better alternative to autotools that is (in a useful way) upward compatible with the coding conventions asked of projects that use autotools.

      Thus, any "here, use this instead" proposal would require essentially every adopter to alter their code and their coding conventions. In areas such as managing inter-package dependencies, the changes could become quite involved.

      Put differently: Imagine starting with a complete source tree for a full distribution and a tasteful selection of apps. Your intent is to modify it so as to use a much better approach to packaging and configuration. How many lines of code do you think you will need to change? How many directories re-organized? How many developers do you think will need to cooperate?

      It is not a practical project at this time, given where everyone's at, so to speak.

      • First, I'm not actually sure how many projects actually need autotools. I've certainly encountered many C programs where a simple Makefile suffices for Linux, *BSD and OS X; in fair number of cases in the mid-2000s, things broke on OS X because older copies of autotools botched library detection or added unnecessary compiler options and in many cases, simply removing anything non-standard fixed it.

        Two thoughts: simply rewriting autoconf in a modern language would be a huge win in maintainability. Imagine if it were, say, Python rather than m4 - how many more people would contribute fixes and extensions or clean up obsolete hacks? If it were organized in a less monolithic fashion, how many more people would contribute without fear that their change would obscurely impact something else?

        99% of what autotools is useful for could be summed up in a couple of lines of something like YAML ("compiler: c99", "libfoo: >1.2.3, <2.0", etc.) but every project using autotools / libtool ships a bunch of gnarly boilerplate code which invariably is out of date. If the mental model changed to it being the responsibility of the distribution to provide a standard dependency resolver along with the system C compiler people would always get the benefit of current versions without each project needing to ship updates to a blob of opaque third-party code. Operators of quasi-orphaned operating systems (Solaris, AIX, etc.) might need to take on more of the distribution's responsibility but that's already a given and it seems unfair to expect everyone else to subsidize negligent vendors.

        • Tom Lord says:

          simply rewriting autoconf in a modern language would be a huge win in maintainability. Imagine if it were, say, Python rather than m4

          This is a joke, right? Where's the camera?

          how many more people would contribute fixes and extensions or clean up obsolete hacks?

          Well, a shortage of fixes or clean-ups for obsolete hacks -- this is not the problem that autotools suffers from.

          It's an interesting topic and not really a jwz.org topic. Please email me, if you like. I clicked your link and noticed you work for LoC which also interests me.

  4. nooj says:

    I dunno, I remember having to compile stuff by hand, and I was relieved when configure showed up and everyone started using it. I went from "spend several hours figuring out why stuff didn't compile" to "if './configure --prefix=~; make; make install' doesn't work, it wasn't worth downloading."

    It may be a half million lines of internal bullshit; but their internal bullshit is hidden, and it doesn't hamper the developer experience (for this developer).

  5. Kevin says:

    Side topic: How did Eric Raymond ever manage to leverage himself into being a spokesperson for the open source movement? He's not a particularly good writer, he looks like something that crawled out from under a bridge, and at the time of The Cathedral and the Bazaar, his single achievement, fetchmail, was something that anyone reasonably competent could have banged out over a weekend.

    I guess when you have a movement that embraces rms as a public figure, it's not hard, but still.

    • jwz says:

      No, you guessed it: at the time, he was the voice of reason and charming like James Fucking Bond in comparison to RMS.

      • Tom Lord says:

        My impression is that he was kind of a Monkee-type celebrity.

      • Not singing an insane folk song and actually living in a house, I think, clinched it for him, although the batshit libertairian gun nut thing must be hard for at least some people to ignore.

        • I think ESR also got worse over time as he started to believe his own PR and think of himself as a visionary as opposed to the guy whose main claim to fame was maintaining the Jargon File.

        • The gun thing, the woman-hating thing, the gay-hating thing, the Muslim-hating thing...

          He's had a bit of luck memory-holing some of that, and there are a few people that seem to spend their lives scrubbing his Wikipedia entry, but while he may be superficially more hygenic than RMS, he's waaaaaaaay nuttier.

      • Alex says:

        It's depressing that rms's weirdness (funny hair, mildly eccentric, non-TV-y mode of expression, doesn't apparently care about money or property, fundamentalist but about Unix, grumpy but who the fuck isn't) is less socially tolerated than esr's (hates: women, Muslims, gays, blacks, about half the US electorate, 70% of the EU electorate, political opponents of any kind, loves: firearms, shouting, arguments from authority, denouncing people as traitors, lower taxes for him, fundamentalism about stuff that gets people killed*).

        Similarly, depressingly large numbers of people seem to prefer Julian Assange (jas? loves: himself mostly, it seems, and that sysadmin mate of his who's a nazi, hates: the inferior mud that surrounds him) as a character to rms (grumpy hippy hacker guy - did we mention he has a beard?).

        Obviously these phenomena are real and we've got to live with them. But it doesn't mean that they're good.

        *Keynes said that it was better for a man to tyrannise over his bank balance than over his fellow man. Similarly, better to tyrannise over a Unix-like operating system, etc.

    • Paul N says:

      fetchmail wasn't his single achievement, or in my opinion even the most important. He wrote a bunch of HOWTOs back in the day, some of which I found really useful. I think that documentation did a lot to help people actually use Linux.

    • David Kendal says:

      his single achievement, fetchmail, was something that anyone reasonably competent could have banged out over a weekend.

      I disagree. Someone reasonably competent could have come up with something much better than fetchmail.

  6. I think the PHK rant is mostly uninformed drivel... except in the autoconf hate.

    However, I only know _one_ userland project that successfully achieved wide portability without autoconf: git. A makefile and modest ingenuity gets the job done there.

    In a surprising fit of Stockholm Syndrome, the git maintainers were stormed by autoconf lovers. It was a jarring surprise to me that this species even existed. So to appease the monsters that inhabit the Internets, git now has a fully fledged configure script... that you can just ignore.

    (Clueless nitpickers corner: the Linux kernel does not use autoconf either. I know. It's not a relevant example -- autoconf is for portable userland programs.)

  7. John Bloom says:

    So, I'll grant him the point that autoconf is kinda crap, but saying that this failure is somehow a specific problem of the bazaar is a bit ignorant. I mean, autoconf and friends may make for a somewhat fragile, bloated, ridiculous unattended build system, but I'm willing to bet it's 20 to 30 years ahead of the custom build systems used for most commercial software products.

    • Nick Lamb says:

      The other fun fact is that autoconf is not the fault of the Bazaar or of dotcom leftovers at all, it's a product of the Cathedral. Its original creators are GNU cathedral workers, the current maintenance is done as a GNU project and in cathedral style (although it has been dragged into the 21st century enough to have a git repo). But one should never let the facts get in the way of a good rant.

  8. The perfect configure message would be:

    checking whether 1 == 1... yes

  9. Thomas J. says:

    As someone who's had the dubious fortune to develop on NEC Super-UX, to this day based on System III, I can attest that even today there's more variance in Unix than most people can imagine. So: if you are only executing configure scripts on Linux or FreeBSD and find yourself thinking along these lines:
    1. why does it try all this stuff when the answer is always yes
    2. half of that's probably not needed
    3. I can do this better/simpler
    stop right at 1. and just count yourself lucky that for you the answer is not no. At least get your hands on something like AIX before you consider yourself to have an informed opinion on this.

    • ...to this day based on System III

      Dear god. Does the console login/getty component still automatically drop into \ALL\CAPS \MODE if you enter a username with capital letters?

  10. Richard says:

    Is there a real problem?


    Good. Stop trying to "solve" it. (If you work for me, and you persist, you're fired.)

    All the automake cruft is pretty much Good Enough. Leave it alone. Anybody who spends time getting exercised about libtool's probing of long-gone Fortran compilers isn't thinking straight, and certainly isn't using his time on earth wisely.

    • Owen says:

      Yeah I was really surprised that the critique was about dependencies and not about, you know, an actual bazaar problem like shitty web developers copying and pasting horrific javascript from other websites. I haven't gone through dependency hell in a long time because I use a popular distribution that figured that out 5 years ago.

      The last time I remember when these configure scripts were an actual problem was when the OLPC guys discovered that designing a linux distribution without perl is almost impossible. They'd hoped to get rid of perl so the system would run well on their extremely light embedded-style hardware. (Then they wrote the OS in python)