(Anachronistic) Dispatches from the Kingdom of Makuria.

When Linux came out, the World was excited about, not the fact that it was a “free Unix”—for there were many of those, already—but because it was an “open source” Unix. It is important, also, to understand that the World was not excited about the fact that it was “free software”, because the licence it uses (the GNU Public Licence—GPL) is not free; rather, the World was excited about its being “open source.”

As a propaganda (“marketing”) term, “open source” was a brilliant coup and a roaring success. It was finely managed by men like Eric S. Raymond (esr), even to the chagrin of other supporters like Richard Stallman (rms), the architect of the licence, the GPL, which he considered “free” (even though it is not), and who preferred that it be called “free software.” Alas, among anglophones, it required the constant qualification of “free as in free speech”, which “open source” didn’t need. Journalists prefer not to qualify sentences, leave alone phrases or—Heaven forfend—buzzwords.

All that said, the main attraction was the development model of Linux, which, at the time, the journalists found to be intriguing, novel, exciting, and a serious challenge to the model of the then-dominant players in the kernel/operating systems World, both within the Unix tradition and without. Here were underdogs taking a different strategy, a collaborative method, full of the “hacker” spirit, and posing a serious challenge to the big players. So the journalists shouted from the rooftops about how revolutionary the Linux systems were; the kernel and the operating systems (distributions) built on top of it. Because the GPL was not free, requiring perpetuation of the GPL’s very terms in all derivative works, the revolution was to be locked in permanently, in the event of the success of Linux.

The people who marketed Linux, in particular esr, sold the worst features of it, because these were the most-exciting both to media and to the wide-eyed kids who found in the revolutionary hacker spirit a calling and a cause. So esr had a main mantra, that “given enough eyeballs, all bugs are shallow.” The unthinking newbie thinks this is a good thing; the journalists can see nothing wrong with it; so it caught on. The problem with that, of course, is that it encourages focus on more eyeballs, which is unsustainable and stupid, rather than focus on less bugs which is right. Who cares if you have a million shallow bugs? I want no bugs there! And Linux bears sickening witness to the shallowness of that particular orientation of the open source movement. Moreover, the multiplicity of eyeballs was not exactly subtractive of bugs—after all, how do bugs get there in the first place? As Edgar Djikstra said, if debugging is the process of removing bugs, then programming must be the process of putting them there. And the Mythical Man Month should have warned against so blindly increasing eyeballs, because that is guaranteed to merely increase on the bugs, even as it makes them shallow—which it doesn’t. This, in fact, is the biggest problem with open source: all those programmers do not reduce on the fundamental challenges of software development. It is not as though we had no sound software, or that there were no well-established ways of dealing with bugs, before open source. —And of all the methods that have ever been actually tried, “more eyeballs” has never distinguished itself.

Consider the horrible difficulty of changing what programming language is used in a Linux operating system.
This is no idle experiment: the first successful Linux operating system (“distribution”)—successful, because Microsoft panicked enough about it to buy it outright—achieved such success by, first of all, committing to building the operating system tools in a different language from the shit the rest of them are built with. I am talking of Linspire, also called “Lindows” at some point. The reason I can give the trophy, unqualified, is because it declared by that horrid name, Lindows, that it was going to be the Linux that unseats Windows. This is something Linux had got famous for attempting from the beginning, and Linus Torvalds once featured in a CNN special that spun the thing as Microsoft Windows’ nightmare stepped out into all four dimensions; and every year since then, stupid Linux fanboys have been declaring the year of Linux on the Desktop. They have been wrong every time, because they line up behind stupid marketing games like Ubuntu, or whatever else the fuck is copying Windows this time (rather than, for once, actually challenging Windows). —But Linspire! How inspiring! And how common-sense. They actually saw that Windows could be only passed by not copying it, for crying out loud. So they moved to functional programming, first OCaml, then—an inspired decision—Haskell. But one scheming Microsoft is smarter than all the emotive open source fanboys put together, so it paid for Linspire and smothered it; they knew they could not pull ahead by copying, either; better by killing. And if Microsoft could not shift over to Haskell (in spite of being the main sponsor of its development, for decades), what chance does any Linux distro, with its scattered contributors who are not even being paid to learn the new approach? After all, they contribute because they already know the languages and approaches; nobody can require of them more than they already have.

Programming languages are the only interface a programmer has to the bits he claims to be shuffling about. It is not a trivial matter. It is such a crucial point, in fact, that any claim to be dealing with the multiplicity of bugs, which doesn’t deal with the programming language, is like trying to fix the thermal properties of a room without considering the windows and ventilators, but only the wall insulation.
So, for instance, rather than esr’s nonsense, here is something you can take home and set on the table: with enough type-checking, all bugs are shallow. If there were an operating system that used Standard ML, for instance, every bug would be a matter of breaking down the offending data type into the buggy case and the other cases—even with a naïve application of the option data type—and then the compiler would scream out from the rooftop every bug written in behind closed doors, and bring into broad day light, for eyeballs to see, every last bug heretofore hidden in the darkness. This is the Curry-Howard isomorphism (and one university programmer, his PhD assistant, and Microsoft Research funding) doing the work; not more programmers, not more eyeballs. The bullshit esr sold to the World, though sounding nice, was not only the wrong solution, it was also unproven. And better one PhD working on the compiler, than one thousand sloppy script kiddies “debugging Linux.”

And the programming approach is the only thing that actually affects the rate of bugs released. For this reason, the rightful heir to Linspire, in the Linux world, is NixOS. Of course, it is an illegitimate child, first, and then an heir by convoluted tracing of the family tree, because Nix, the most-core tool and approach in the distribution, though it is itself declarative and functional and civilised, unlike all the other nonsense that other Linux programmers are ageing in pursuit of, such that they would still be failures even if they actually achieved their goal, it is still not written in a declarative functional programming language.
Haskell is older than Java. It is from 1987. Since that time, it has not been in question how to program properly. But idiots today pretend that they are inventing the future, when they are coding in what was no longer cutting edge by the time an operating system had to placed on top of the Linux kernel. You have a language that pretends that requiring programmers to remember to pass in the length of the data—and to remember to get it right—is easier and cleaner and smaller and less-wasteful than appending a count on every pointer. After all, “We are doing low-level programming!”— This is a design bug, and now we know that the cost is not in RAM, but in server break-ins. Yet even the RAM is not spared, because the programmer will allocate stack space for the length value, anyway, and pass it around. It may have been thought smart to let the programmer deal with his counts himself, back then, but why would anybody still support this trade-off now? And why would anybody use such a bug-encouraging system? And it’s not even 1987 anymore! “Speed! Speed!” Does anybody still buy that? Even after OCaml and MLton and GHC?
Yet if C had just delimited pointers (for lack of a better name), it would be even safer to program in than PHP will ever be; for then every single buffer over-flow—every last security breach you have heard of—would have been resolved in the 1970s with an iterating library. You see, all reliable PHP-built CMS apps are more-complex than half of the Linux kernel. All reliable web frameworks are more-complex than the other half. But all that effort is a waste, because it is seated above a bug. The price we pay for relying on the mal-educated inertia that open source encourages and that all the other Linux distributions epitomise is much higher—huger, bigger, far, far more-vast—than we would if we built up four functional-declarative operating systems from scratch every year.

And the Linux kernel itself is shit, because it is neither an improvement on Plan 9, nor aware that it is not an improvement on Plan 9. (Plan 9 is shit; but so is Linux. An improvement on Plan 9 would not be, but Linux is not one such, either.) Unix operating systems, in this decade, are sheer inertia and artefacts of system-level economic collapse; Linux is the best example. Unix is a work-around; Linux acts like it is a platonic ideal. Unix is, by the confession of those who should know, desperately in need of an improvement; Linux is a faithful rendition of the bug. “Oh,” reacts one in the crowd, “Linux is trying to implement Unix; it is not Linux’ fault that Unix sucks!” Fine; but Linux, when properly-done, will be a crappy and stupid failure from the early nineties. The Linus-Tanenbaum debates should have ended with someone saying “But who cares how you design your bug?”
Since no Unix operating system—built in C, as a basic identifying principle—will ever be secure, why are you wasting time pretending you are getting there? And that is just security.
There are all these work-arounds, from the file system to the terminals, that achieve little more than spending on archaic mistakes good, serious effort that should be spent on doing different things differently, one of which may work, rather than the one thing that has already failed in the one way that has already failed. And, no, kernels are not hard (if you can understand a PHP-written CMS, you are over-qualified); popular kernels are hard, though, because successful marketing is hard.

Then there is the problem that once a project goes open source, it is harder to control. This is nice if all you are doing is hobbyism and toys. (This is why Linux is stuck there: hobbyism and toying about. I know someone will say “But so-and-so, who/which is no joker, but a big company/industry, is using Linux crucially!” What did so-and-so use before? Is so-and-so, or the associated “procurement department”, poorer or more-stupid or lazier now? Do you know? But I know a toy when I see one.) In reality, if you want to produce a dependable product, you are going to have to go cathedral, rather than bazaar. Ideals always sound good on paper, especially when they have not been tried yet, otherwise they are not ideals, and they are not inspiring. Open source was both ideal and inspiring, because it was on paper and had not really been tried yet. Of all the successful open source projects, both the ones cited back then and the ones I know of now, the control of the project—the “gather” phase of the “scatter-gather” approach, as it were—is where the quality comes from.
In my opinion, this failure or refusal to distinguish between the phases of any project—those that can survive being open source, retaining dependability, and those that would not—is the grossest thing about all the propaganda of the open source movement. I mean, for simple instance, marketing (read: selling) the product never survives being open source; and this is, unfortunately, part of every dependable product (where dependability takes into consideration psychological factors, which, admittedly, the open source movement is almost pathologically incapable of considering).

What actually hinders the esr chant about the eyeballs from being even occasionally true is that the open source approach leaves forking as a subjective necessity. So forks are neither all-bad nor all-good, not even in any particular project. Would that, on this, they were either hot or cold! But they are lukewarm, and the results are outright emetic. There are one thousand half-implemented versions of every worthwhile piece of software in the Linux world. They are all crappy, without exception, because none of them is the one piece of software. This is not trivial: no piece of software is anything but crappy unless it is the one answer to that problem. So, for instance, GNU binutils is the one answer to the “Unix utilities on Linux” question. If anybody ever forks any GNU utilities, he is a heretic and should have his properties confiscated, and his hanged body burnt at the merkat cross as a warning to all other wicked malignants. Emacs is the one answer to the “over-zealous, over-weight, unkempt, unshaven, Karl Marx-like ‘text editor’ operating subsystem” question—an important and common-enough question, for we need where to send the heretical allophyles and say to them “out! go and implement your godlessness there, with a lisp!” Vi is the one answer to the text editor question. Vim is the one answer to the “modern vi” question. mutt is the one answer to “e-mail on the terminal” question. If you fork, you are accursed; if you create an alternative, you are evil; if you disagree, you are wrong.
Imagine the evil of forking, say, Perl or Python or Ruby. This is why these are not crappy: there is the one programming language that replaces shell; the one modern alternative to it; the one alternative to both. There is one httpd—Apache—and so it is not crappy, even when it doesn’t suffice for those times when sensible system design requires that you use an alternative (lighttpd, nginx, unicorn, whatever). But you do not fork those, otherwise you are exactly the evil sinner we have been wanting to make an ensample of.

But the open source community rebels against this standard; it has no wherewithal to condemn a fork of GNU binutils. And because it lacks this, there is no way to say that all these extra eyeballs are looking at the original bugs, rather than their own new, forked-off ones. The open source people rebel against this obsessive exclusivity, preferring obsessive multipliability (even if they then condemn multiplicity). Their problem is like that of the stupid and inconsistent moral relativists, who insist that everyone is right to himself, and yet complain when I celebrate and proclaim the rightness and goodness of trapping and quick-burning moral relativists at the stake.
This is why Linux has no good PDF reader. To create something as smooth and responsive as Apple’s Preview takes more focus and effort than all the open source people will ever be able to generate, both in theory and in practice. Remember, the problem is emphatically not in the smoothness and responsiveness; it is in the absence of exclusivity—having the PDF reader that is smooth and responsive, rather than a PDF reader (none of which, in the Linux world, are both smooth and responsive).
This is also the problem with Firefox. When it was the web browser, it was great! It was, hands-down, the best browser on a PC; it was not crappy. But now you have its re-skins and other open source competitors, and it is crappier than they are—and they themselves are crappy. This is also never going to be fixed, because Chromium/Chrome is/are not going away. Farewell, then, to good web surfing on Linux, forever. (It is not a very different situation on the Mac’s OS X, for instance, but there is a non-crappy browser on iOS, and it is not because there isn’t enough choice/diversity/firethings: it is because, there, Safari is the browser. On Android, Chrome is the browser; therefore surfing there even has a chance of not being crappy—and it achieves it.)

“But,“ cries out one, “in that case you are saying that the open source approach can never do a good operating system!” Yes. If you thought it was an easy-enough thing, look at your security and bug record and remember: it is easier to invade a nation and endanger its airspace and read its government e-mails at your leisure and blast propaganda at its citizens non-stop than it is to create a sound operating system. If you approach it like it is a hobby project, a toy, or an augmentation of such, you are not even wrong. If you would do military-grade systems this way, you are not even trying. An operating system like Linux wanted to be when it grew up is a military-grade system—or, at least, is supposed to be. If the type-checking above the kernel will still let through “NullPointerException”, or if the programming style is prone to “ArrayBoundsException”, or if you are using Java … just stop and go away. If your kernel is programmed like the improvement on C89 is C99, go and die.

Now, there is the Three-Clause Berkeley Software Distribution (BSD3) licence, which, though freer than the GPL, is also not free; it does not require perpetuation of the licence terms, but only citational reference to them. There were already some Unixes under the BSD licence, by the time Linux was started. Indeed, since 2009-2010, I have operated a strict policy of having only FreeBSD on all official server systems where we need a Unix, and I banned Linux completely. It is allowed on desktop systems, and I am actually typing this on an Ubuntu Linux laptop, which means that I have a continual and constant reminder of just how bad Linux is when compared to other Unix systems. Even the thing for which I use Linux—compatibility with cheap, off-the-shelf PC hardware—it is actually a very poor performer. I cannot critique too much here, because the FreeBSD sector I have on this laptop cannot even run the Wi-Fi; then again, this is a Lenovo E531, with the worst Wi-Fi antenna that ever came under “QC Passed”, such that when I need to actually work online, I use an ethernet cable, which works under FreeBSD. But then, FreeBSD for laptops is called OS X.

Of course, the only free “licence” is the public domain—because it is literally no licence at all—of course, which is why I put all my software code in the public domain, if I want to share it, short of which I keep it private. (Private code is not necessarily secret; it is just private. If someone accesses it, he still can’t use it, because it would be a shame for him for stealing. His conscience can do more to stop him than any number of over-wrought legal clauses ever will. And if his conscience does not, nothing will—but God will judge him, and that should suffice for everybody, as it does for me.)
I also work on a project, programming embedded software, that requires that I duck into a Windows installation from time to time, which is why I cannot be using a Mac, as would be sane. Now, of course, the reason it is sane to be running the regrettably-named Darwin kernel and its OS X operating system is because Darwin is basically a renamed FreeBSD, and OS X is programmed properly (that is, aware that the 1960s are not a high point in programming language design), unlike well nigh any Linux operating system I have ever seen.

Oh, this reminds me: one fatal problem with Linux is that the lead programmer, Linus Torvalds, is a confessed idiot. I once read his long and passionate argument to a Linux e-mail list, where he justified the approach that Linux was developed under by reference to darwinian evolutionary theory. He said, if memory serves, in defence of the haphazard way in which Linux is developed—the stupidity that let in the OOMKiller, among all sorts of other systemic embarassments, many of which he defended and perhaps which survive until today—saying “But do you know what else was developed that way? The most complex system we know of: you.”
How idiotic! Remember this, because it is true whether you agree or not: if any man can justify believing the neo-darwinian evolutionary theory to be true, he is too stupid to program anything properly. Even if the theory were true, which it is not, it would still be a reliable sign of incapacity to build sound, reliable software if any man could justify believing in it. So: even if it had happened, all good software developers would be wrong about the origin of the species. No exceptions. (The last time I saw anybody try to program while mouthing the stupidity of darwinism, he was coding “METHINKS IT LOOKS LIKE A WEASEL”, and he believed that the creation and its process was anything like darwinian evolution. He also says “It’s a fact, like gravity!’ except that his grandfathers believed in the fact of gravity, but not darwinism; so, no, it is not “a fact like gravity!” Unlike gravity, it requires careful brainwashing, deep-seated biases, and a well-husbanded anti-creatorist animus.)
And, you know, we have more fossils—and evidence of evolution—for the Linux kernel than we do for anything else on the planet. —Yet if anybody can look at those fossils and believe that they evolved as neo-darwinian evolutionary theory says (undirected mutation, then selection, iterated over time), he would be incapable of properly copying an archaic kernel, leave alone designing a new one. Even if Linux had, in fact, evolved by undirected mutation and consequent selection (and, this being Linus’ project, it very well may have), anybody who believed that—in spite of its hypothetical truth and verity—would be incapable of any good work.