Nikolai Bezroukov. Portraits of Open Source Pioneers

For readers with high sensitivity to grammar errors access to this page is not recommended :-)

The Anatomy of Accidental Success

Linux is the clone of Unix that managed to became a successful commercial techno-cult.  Accidental success is not a new phenomenon in the PC world. And accidental geniuses are more common in software then in other fields. Again in software everything is timing, timing and timing. In his famous book Accidental Empires   Robert X. Cringely noted that Microsoft, despite mediocre technology, become a master of the PC software universe because of its prowess at establishing and maintaining industry standards. Essentially Linux repeated Microsoft success in the world of Unix and, no matter what Eric Raymond would tell you, Linux is essentially Microsoft Windows of the Unix world: inferior in some technical dimensions, but a highly successful clone of a previously know (well known in  cases like CPM->MsDos, VAX/VMS-> Windows NT, Unix-Linux )  OS. As the system was pretty small there was a chance for people to understand the code and participate in the development. This chance disappeared around version 2.4 and is no longer their. Current Linux is as hostile to volunteer development as any large proprietary system: it is just too complex.  As Bill Joy aptly put it:

BJ: No. I think that if you exclude device drivers, you'd find that there's a bit of a myth operating here; that a whole lot of people wrote the system. It was actually a small number of people.

LM: In BSD or in Linux?

BJ: Both cases. We have this myth that distributed development works, but it's a slight bit of a lie in that a small number of bright people can create an operating system. It does take a lot of people to write all of the device drivers. That's true. But that doesn't necessarily mean we can coordinate the programming of hundreds of people writing C code. I don't know if that's true or not, and I personally don't think Linux proves it. I don't think Apache proves that. That's the myth that people have propagated. Maybe it's true, but if you called me as an expert witness, I would testify that it has not been true in my experience.

LM: Is there something to the notion that the people working on BSD are more exclusive than the Linux community?

BJ: That's an us-versus-them thing. These things just get amplified. I don't think these people vary from each other by much. They just identify with some group, and that's a human-nature thing.

BSD is older. It doesn't need as much hacking. So if you're a new person learning how to hack, BSD was not as good a place to go. It didn't need as much work. Linux grew up with the Internet. By the time the Net came along, BSD didn't need the same level of work and wasn't as amenable to getting people interested in it.

When you already have several million lines of code, it's not as much fun to work on. Linux was a great thing because it allowed a lot of people to get involved in learning about operating systems by helping to finish this system. That process of creating something is the process of creating a community.

So Linux came along at the great, perfect time in a perfect, incomplete state for lots of people to participate in. It was still small enough that people could read the code. On the other hand, BSD was already mature, and the things that needed to be done to it were hard enough that it made it difficult for any person to come and participate.

So BSD wasn't as amenable to parallel innovation because the bar to participating was pretty high and the code base was too large. When I started on Unix, the source code could be listed in ten or twenty thousand lines as a 50-page or 100-page book.

If I came in today and wanted to do something with Solaris, I'd be overwhelmed. I can't have the kind of impact I had on Unix with Solaris. The second-generation people coming into the Linux community are going to have the same problem.

And in some deep sense the Linux success is  the symptom of crisis in software engineering as a discipline. As Rob Pike observed:

Linux Innovation? New? No, it’s just another copy of the same old stuff. OLD stuff. Compare program development on Linux with Microsoft Visual Studio or one of the IBM Java/web toolkits. Linux’s success may indeed be the single strongest argument for my thesis: The excitement generated by a clone of a decades-old operating system demonstrates the void that the systems software research community has failed to fill. Besides, Linux’s cleverness is not in the software, but in the development model, hardly a triumph of academic CS (especially software engineering) by any measure.

What is Systems Research these days? Web caches, web servers, file systems, network packet delays, all that stuff. Performance, peripherals, and applications, but not kernels or even user-level applications. Mostly, though, it’s just a lot of measurement; a misinterpretation and misapplication of the scientific method. Too much phenomenology: invention has been replaced by observation. Today we see papers comparing interrupt latency on Linux vs. Windows. They may be interesting, they may even be relevant, but they aren’t research. In a misguided attempt to seem scientific, there’s too much measurement: performance minutiae and bad charts. By contrast, a new language or OS can make the machine feel different, give excitement, novelty. But today that’s done by a cool web site or a higher CPU clock rate or some cute little device that should be a computer, but isn’t. The art is gone. But art is not science, and that’s part of the point. Systems research cannot be just science; there must be engineering, design, and art.

A lot of open source evangelists claim that Linux success is based on technical merits. But the truth it as Ken Thompson aptly observed "A whole bunch of random people have contributed to this source, and the quality varies drastically."  I would agree with Rob Pike  that Linux signified the deepening crisis of software engineering: it was the second major OS (after MS DOS) that succeed because of social factors and by catering to the mainstream architecture and mainstream users. Like MS DOS before, Linux happened to be just the "least common denominator" for computer enthusiasts and small business that wanted to experiment/benefit from Unix, but at the same time it has an important dimension of commercial techno-cult. The latter makes Linux success quite different from DOS. Microsoft is a software empire but in no way is a software cult, and I never saw people overexcited about even the best Microsoft's products. In no way Linux was attractive to the University computer science department gurus who always valued the technical quality and cleanness of the code most (and here OpenBSD is probably the champion of the Unix world), but like Microsoft Linux quickly found its way to the university environment, the environment that previously was dominated by various flavors of BSD. I would like to stress that still in my opinion, the best university clone of Unix is OpenBSD, as the most Spartan and close to the roots flavor. 

The main reason of Linux success was early commercialization or "Selling Bazaar to the Cathedral" if we reuse Raymond's cliché in an non-traditional way. Creation of commercial distributors chain make also possible direct infusion of money from Intel and IBM into those startups, as both companies were concerned about the level of Microsoft dominance on PC. There were other "accidental" positive factors that greatly helped Linux. None of them is connected to the quality of the Linux kernel (in 1991-1994 it was still significantly inferior to BSD kernels). If we try to enumerate the factors that contributed to Linux success we might mention the following:

• Microsoft ;-). It was Microsoft  that created a certain vacuum in PC-based OSes when it abandoned XENIX  -- a pretty decent Unix implementation for PC (AFAIC this was the first Unix that implemented the idea of switching consoles using Ctrl-F1, Ctrl-F2, etc).  Users of Xenix were DOS users that wanted cheap (or better free)  PC-friendly Unix and were a suitable base to lure to Linux instead of BSD-derived OSes. SCO Unix was too expensive. Dominant PC OS -- MS-DOS was technically obsolete and essentially 8086 oriented -- that mean that it was backward by two generations of hardware. Windows 3.1 just started to appear on high end PCs and as (to a certain extent) Mac clone. It was major improvement over DOS because of it introduced reasonable GUI interface for the new generation of PCs that outgrow DOS, but in no way it utilized all advantages of 386 architecture. The absence of  preemptive multitasking  was especially annoying for advanced users. Growing anti-Microsoft sentiments among considerable part of programmers became a factor that can be effectively exploited as an organizing and motivating force for Internet-based development projects and lead to conditions in which even so "raw"(technically) solutions like the first Linux kernel found wide adoption and support. 
• Widespread adoption of CD technology starting at 1992 created a possibility of mass production of Linux CDs. This technology became the cornerstone of the "commercial open source" that is often associated with Linux.  This is very important and often overlooked factor. Actually it created the wave of commercial Linux distributors that later played a critical role in Linux rise to the top.
• Availability of GCC. In 1991 GNU was already more of less full Unix-compatible environment lacking just kernel to run.  Especially important was GCC compiler -- a pretty decent C compiler that historically became a workhorse for many important free software efforts. Paradoxically, but no GPLed GNU-compatible kernel existed -- Hurd was vaporware (and architectural ideas were far ahead of its time), BSD was weakened by defection of some developers to the commercial BSDI project and its future was clouded by the lawsuit from AT&T. The latter essentially was a big red flag for any commercial BSD adopter and Linux was a natural alternative: inferior, but promising...
• Downward spiral of  PC hardware costs just reached the point when 386-based PC became a commodity. It's largely because of Microsoft and Intel that Linux has such an abundant hardware base to run on today. Microsoft became  the sole, exclusive owner of "PC" hardware platform that it licensed for free to hardware vendors and they in return ensured compatibility with Windows. In this situation "exploitation" of PC platform for running different OS was pretty obvious idea and Linux piggy-backed on the unique situation when high quality hardware were available at very reasonable costs and was pretty open for running any other non-Microsoft OS.  In early 1992 386sx motherboards had became cheaper than Minix license ($150) and widely available because of Microsoft OSes and software. Growing popularity of Windows 3.1 led to the adoption of 4MB of RAM as a standard and 120MB (or bigger) hard drives. In other words the standard configuration for 386 PCs suddenly became quite adequate for running Unix on PC. Here is an example of confguration of one of the early PCs capable of running Linux that belongs to Michael K. Johnson:

  The computer on your right, my left, as I stare out of your computer screen, is Roland. Roland was one of the first computers to run Linux; judging from the traffic on the original [email protected] mailing list, my guess is that Roland was easily one of the first 50.

  Roland got tired of sitting around at home idle, and so until June 1998 it happily slaved away as the internet gateway, www server, ftp server, and so forth for a small local software company. Roland is a 386 sx/16 with 8MB of RAM (yes, I splurged) and a 100MB hard drive. I'll have you know that when I bought that hard drive (for the express purpose of running Linux), it was on the large drives list.

   That was a  big upgrade from the 1M memory 40M harddrive world of PC 286 and 386sx was much better environment to run Unix that anything before. Historically, Intel 386 CPU was the first cheap mass produced CPU capable to run Unix. As Alan Cox recollected:

  I'd always wanted a Unix system but even Minix was out of my price range. I'd spent some time adding unixlike stuff to the Amiga I had but wasn't bold enough to write an entire new OS. When Linux 0.11 & 386BSD were announced I ordered a 386 box. I couldn't afford an FPU which 386BSD needed at the time so I installed Linux (off two floppy disks at the time). 0.95 appeared and the university computer society bought a 386 box and I fixed a couple of things.

• Several excellent books on Unix and 386 processor architecture were just published making reengineering of UNIX kernel far less complex than before. Microsoft again was the major force being this because XENIX created a new market for Unix books and this market continued to be viable aven after Microfot withdow fromthe Unix game. Among them I would like to mention Design of the Unix Operating System by Marice J. Bach that Linus used. It was published in 1986 and still can be highly recommended. Many of the names of the important functions in the Linux source came from this book, and are named after the algorithms presented in the book.  Another excellent (and widely available in the underground photocopies) book was Lions' Commentary on Unix: With Source Code. Actually the version of Unix described in the book was less than 10,000 lines of code. This legendary underground classic is really two works in one:
  • the complete source code to an early version (Edition 6) of the UNIX operating system, a masterpiece in itself!
  • a brilliant commentary on that code by John Lions.
• Cheap PC (386sx) orientation and MS Dos heritage. Simplicity (primitivism) of the early version of Linux (early versions of Linux were essentially a DOS of Unix world) and orientation of cheapest and the most mass produced PC configuration (386sx with 4M of memory) attracted a large number of skilled and relatively poor European developers that has access to such a hardware platform (at this time PC was already number one platform among all computer architectures, and high quality C compilers for MS DOS became a commodity). This orientation of the most popular part of the market was a prerequisite of forming international development community for Linux and later Linux success.
• In early 90th email became a dominant communication medium for both USA and European technical community, especially programming community. WWW explosion was just two years ahead of Linux release.

In 1991 Linus was 21 and probably had at least five years programming experience (mostly in assembler, but probably at least one year in C). I don't know whether he was accomplished DOS programmer, but he authored a terminal emulator. I suspect that both because of the mastery of assembler achieved while programming his emulator (as well as his vast Prince of Persia experience :-) he understood DOS architecture and internals well enough (especially having access to BIOS listings) to borrow ideas from it.  Ignorant Unix/Linux fanatics often discard DOS as "piece of crap". But in reality it's predecessor Dr Dos was a very solid, innovative OS for 8-bin microprocessors (Dr DOS introduced the idea of BIOS and loadable drivers-based OS portability: now a standard feature of most commercial Unixes and Linux).

The main idea of his project was simple and effective: lets take Minix codebase and the book Design of the Unix Operating System  by Marcie J. Bach and gradually modify Minix core using the book in such way that it will be able to run GNU software. It was a pretty conservative plan and as you can see from further development Linus Torvalds can be classifies as a conservative type of programmer.  He probably belongs to so called "polisher" types of programmers, programmers who are able deeply concentrate on a single task of polishing and perfecting interfaces for an existing architecture and are not interested in trying new grounds. So this is quite funny that he sometimes is called revolutionary: he was a counter revolutionary, trying to restore the status quo that existed before Microsoft entrance into operating systems market (Unix dominance),  if you like. And as we see below that spelled trouble for people who think otherwise (see Fred van Kempen story with networking support below).  Here is how Linus recollected the events:

From: [email protected] (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: To Linus, Lions book?
Message-ID: <[email protected]>
Date: 3 Jul 92 11:35:06 GMT
References: <[email protected]>
Organization: University of Helsinki
Lines: 96


In article <[email protected]> [email protected] writes:
>
>How did you get all your now how to create Linux?
>Was hands on learning, which books/mags/articles/code
>did you read? Go on Linus, give us a potted life history :-)

Heh. I can't let these ego-building posts go by, so I'll have to answer
it.

Linux started for several different reasons: originally just to learn the 386, and for this the book "Programming the 80386" by Crawford and Gelsinger is a must. At least I haven't found anything better (although admittedly bookstores in Finland probably don't have the plethora of books available over in the US etc).

The 386 book info has been used for all the 386 details: the lowest level of the task-switching code, memory manager, floating point emulations etc. It doesn't even mention the AT hardware, so for device drivers you'll need more info, but it does contain everything on the 386/387 chips (even if it's a bit hard to read: read it through several times before starting to look into details).

The device drivers have been written mostly by trial and error: I haven't found a single good source of info on the standard AT hardware. Helpful sources have been (a) the AT Technical Reference Manual (notably the BIOS listing) (b) actual data-sheets for the 8250 etc chips used in the AT hardware (c) other sources (mach drivers and to a lesser extent minix drivers) (d) various books like "IBM Microcomputers: a programmers manual", "The PC Sourcebook" etc.

Even though there are a lot of books on the AT hardware, none of them seem to approach the information content of the 80386 books. I can't recommend any of the sources I've used, and the best bet is probably to have a lot of books and hope they together cover most of it.

Then there is naturally the hardware-independent parts of the kernel: general filesystem/process/memory management. The two books I originally used were "The Design of the Unix Operating System" by Bach, and "OS Design and Implementation" by Tanenbaum. Tanenbaum's book should be read a couple of times: ignore the details (especially about minix), but get the general picture clear. The Bach book has a few nice algorithms in it, and I'd suggest reading them too: many of the actual ideas on how something could be implemented came from that.

Still, OS design is mostly common sense: it doesn't need complicated algorithms like a compiler does or similar. A lot of thought, careful programming and some good decisions. And unix is a very simple OS really: I first came in contact with it 2 years ago when I did the "C-kieli ja unix ohjelmointiymp{rist|" course in the fall of -90. By early -91 I had bought a PC, and linux v0.01 was ready in August -91. That wouldn't have been possible with some other systems I could mention (VMS.. arghh).

The most difficult parts are:

- device drivers: you can go crazy trying to find why something doesn't work on some machines (especially if you can't even test it out).

- filesystem: trying to make it clean and well designed, as well as getting rid of all race conditions. The current linux vfs layer seems to work well enough, but my original design wasn't too good. Rewriting big parts isn't fun when something works.

The kernel proper is pretty simple in fact, although you have to keep track of a lot of things. The memory manager has also survived pretty well all the changes, and although I'll have to change it to use different page directories for different processes some day it will probably look pretty similar even after that.

>Also could you mail me a few lines, grouping the source code
>files into chunks. I.e., which files make up the lowest most
>basic layer of the OS 'onion', which ones make up the next layer?
>This would make it lot easirt to peruse the code in an orderly fashion
>so I can try to understand it.

Hmm. To get a good general idea of the different pieces, I'd suggest reading linux/*/*.c - all the memory management sources, the normal kernel sources and the vfs routines. They are pretty modular: you can generally understant linux/fs/*.c without having to understand the kernel and vice versa (for a general picture, that is. For the details you usually have to read it all).

The linux device drivers (linux/kernel/chr_drv and linux/kernel/blk_drv) are a pain to read: they don't actually give you any more info on the kernel itself, so reading them is only needed if you really want to know how a block is loaded into memory etc. Similarly for the math-emulator (linux/kernel/math).

The special filesystems (linux/fs/minix and now linux/fs/ext) can be read if you are interested in the actual lay-out of the disk, or if you want to see how some of the fs races are handled. Note that most race-conditions are handled directly by the buffer-cache routines or the vfs layer, but some races are inherent to the actual fs implementation (renaming a file etc).

But pure "polishing" abilities  definitely were not enough. You need great social skills and communication skills as well.   Linus inherited (and he had grown in the environment were it was easy to learn) an excellent communication skills that were amplified by his personality ("overachiever arrogance" is very useful for communication). He proved to be a very skilled PR person, keeping project going year after year without major PR blunders.  Here I highly recommend the reader to compare him with RMS to see the real difference. RMS is also a polisher, but with inferior social skills ("overcontroller"). That led to several crisis situation when people working for him just work out. 

Actually his project was not even the first attempt to modify Minix kernel to make it more POSIX compatible. The first successful attempt was an earlier series of Minix patches by Fred van Kempen, a talented programmer who later contributed the first version of the Linux networking code.  The other indirect inspiration might have been BSD Net/2
tepw (June 1991) and later 386BSD  ( see Salon Technology The unknown hackers ) developed by Bill and Lynne Jolitz. Version 0.1 of 386BSD was out on St. Patrick's Day 1992. What is also important that this version was documented in articles in Dr Dobbs journal starting from 1992 -- the magazine available in most universities. Linus himself acknowledged that he read those articles in one of his interviews and he might adopted his famous short release cycle after reading discussions about BSD development problems:

... In a 1993 interview with Meta magazine, Linus Torvalds himself name-checked their O.S. "If 386BSD had been available when I started on Linux," he said, "Linux would probably never have happened."

...In 1989 or 1990, Lynne remembers, the Berkeley distribution had gone from being available on the most relevant machines to being limited to what the Jolitzes saw as the most irrelevant. "There was an HP [Hewlett-Packard] port in progress and nothing else," she says. "Since we were looking for recreation, we offered to do one for the 386." "Completely as a lark," Bill adds.

...The Jolitzes released Version 0.0 of 386BSD on St. Patrick's Day 1991. It was barely functional, but available to anyone with 30 floppy disks to spare. The system shipped under a BSD-style software license, permitting it to be freely distributed and modified as long as copyright attribution remained intact. But the Jolitzes knew even as they announced it that this release was not enough.

"As we were doing and documenting the port, we realized we'd eventually have to do a complete release," Lynne says. "This was a very arduous process. We had to throw away all the licensed portions. We started to do novel work. We realized that a lot of what we had thrown away were first cuts. It's ironic that people have spent so much time and money on stuff developers just threw in."

..."The Unix systems then offered eight or 10 different competing mechanisms to do basically the same thing," Bill says. "The question in 386BSD was, How many of those could we get rid of? We increased the capabilities and reduced the size by a factor of 35."

This slash-and-burn approach to the work on the new release spawned a series of articles in the respected journal Dr Dobbs. Those articles may have been even more influential than the code. A generation of O.S. developers -- including Torvalds, then a student in Finland -- studied and learned from them. On Aug. 25, 1991, Torvalds posted a fateful note to a Usenet news group devoted to the experimental operating system Minix: "Hello everybody out there using Minix," he wrote. "I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since April, and is starting to get ready."

If this blithe note represented a serious threat to their work, it didn't register with the Jolitzes. The articles in Dr Dobbs primed their audience for the release of 386BSD 0.1 on Bastille Day 1992. The tone of their announcement forms an illustrative contrast with that of Torvalds:

"We are pleased to announce the official release of 386BSD Release 0.1, the second edition of the 386BSD operating system created and developed by William and Lynne Jolitz and enhanced further with novel work and contributions from the dedicated 386BSD User Community. Like its predecessor, 386BSD Release 0.0, Release 0.1 comprises an entire and complete UNIX-like operating system for the 80386/80486-based AT Personal Computer."

There were 250,000 downloads of 386BSD 0.1, Lynne remembers. "We had people showing up on our doorstep," Bill says. "It was a fun time," Lynne agrees. "We thought there would be maybe a few hundred downloads. So much for the power of the press!" Work continued apace. The Jolitzes aimed high. "When you do a release, it takes months and months to shape it up to make it usable," says Lynne, demonstrating a distinctly different approach from the Linux mantra: Release early, release often.

Instead, in December 1993, there came 386BSD 1.0, a revised version with new internal interfaces, allowing the individual components of the operating system to talk to each other more cleanly and efficiently. But somehow, in the 18 months between 0.1 and 1.0, the project lost its momentum. Version 1.0 was widely criticized for being too little, too late.

"The idea behind what we were after was a system that always had network access, that could detect faults and repair itself on the fly," explains Bill, heaving a sigh. "Sometimes you get too far into the future," he remarks. "You have to stop and wait to see the future catch up."

By the time 1.0 was released, the x86BSD user community had fragmented. Some developers had moved to the more active and open NetBSD and FreeBSD teams. Others had jumped the fence to Linux. A lawsuit between Unix copyright holder AT&T and University of California at Berkeley was also partly to blame. But the Jolitzes, too, were criticized for their autocratic style. The strength of their convictions did not endear them to people who wanted to do things differently.

Here is the relevant part of Linus Torvalds 1993 interview (you should not believe any words about not seeing the code, poker players do not tell the truth ;-):

M: What is your opinion of 386BSD?

L: Actually, I have never even checked 386BSD out; when I started on Linux it wasn't available (although Bill Jolitz' series on it in Dr. Dobbs' Journal had started and were interesting), and when 386BSD finally came out, Linux was already in a state where it was so usable that I never really thought about switching. If 386BSD had been available when I started on Linux, Linux would probably never had happened.

I also have very limited computer resources (right now I have 160MB of disk space, the original Linux development was done in 40MB), so I haven't tried to set up 386BSD just to "see what the competition does." This means that I have only followed the 386BSD discussion and development from the side. As far as I can tell, it's a good port of BSD that is plagued by some problems (mostly non-technical).

One of the major problems with 386BSD seems to be the lack of co-ordination: that may sound weird coming from the Linux background, but in fact the 386BSD project seems to suffer from a lot of people working on the same thing due to the long release cycle (I think there are three different and incompatible keyboard/console drivers for 386BSD). A long release cycle is the way to go in a controlled environment (i.e., commercial development), but I think it hurts the "free" development that results from a lot of unconnected persons having access to sources and doing lots of modification. The NetBSD project may be a step in the right direction, but I think 386BSD has been hurt by the way it has been developed.

Note that others that know more about the actual 386BSD development may disagree and think the Linux releases have been very chaotic (which is also true, but differently). Also, 386BSD has had different starting points and different goals, so any real comparison may not really be valid. In any case, I usually ignore Linux/386BSD comparisons: I've not let any 386BSD considerations change the way I work, but just done things the way I want them done and hoping it works out. I have gotten a few mails like "we're considering changing over to 386BSD, as Linux doesn't do..." but I refuse to be blackmailed by things like that. I've also gotten mails from people who have changed the other way, so it's obviously a matter of taste.

It looks like the reasons for the success of Linux were more subjective than objective and contrary to Linus own claims the major factor were right timing and marketing.  Linus Torvalds did have an edge in speed of development and user friendliness that helped him survive the arrival of 386BSD one year after initial version of Linux kernel was released. But 386bsd was much more solid kernel from the technical point of view. Again due to pure luck (AT&T lawsuit tainted BSD) and an almost two year pause between the release of v. 0.1 and v.1.0 allow Linux to obtain a critical mass.  In his May 2000 Interview Jordan Hubbard recollected:

When 386 BSD came out, I gave out a "Hallelujah!" Finally, the PC is getting the attention it really needs. I hate to say deserves. I still think the PC platform is pretty evil in a lot of ways. Nonetheless we were seeing the writing on the wall. PCs are everywhere, and I was seeing a lot more PC stuff coming in to Lotus with SCO running on it. I was seeing how powerful it was compared to PA-RISC boxes and whatnot, which were still the benchmark against which we measured performance. But I could see the PCs getting better and better. The 486 DX 2 came out, with the 50Mhz/66MHz clock-doubled 486, I was starting to say, "That's kinda not bad for what these things cost."

So 386BSD was when lightning struck for the Unix community. Finally, we can have these technologies that we can afford.

I was one of the patch-kit maintainers for 386 BSD, because Bill Jolitz wasn't very responsive to requests. He was a Lone Ranger all the way. We tried like heck to work with him. I was working in Ireland for Lotus at the time, and I spent more money on Transatlantic phone calls from Ireland than I care to admit, talking with Bill, just trying to get him to release another increment of the technology, to do something after 0.1.

He kept pushing back and pushing back, kept giving us promises about what would be in there, though. We got more and more impatient. There was no IDE support. Really crucial things were lacking that the mainstream PC people wanted. BSD already was getting a black eye for being elitist. "You guys don't support IDE drives. You only support SCSI. You guys must be elitist." No, it's just that we don't have an IDE driver yet. We were pushing Bill harder and harder to try to release more technology, so we didn't spend so much time fixing the tools and doing mundane gruntwork. We should be thinking about an IDE driver. He finally just kissed us off. I don't want to add any more technology this close to release. Why don't you go off and do it yourself?

From this point of view Linus reengineering effort looks like an interesting postgraduate project that semi accidentally (in view of  better positioned and higher quality 386BSD and Hurd projects failures) was transformed by events beyond the author control into a real production kernel.  As Bill Joy aptly put it Salon Free Software Project BSD Unix Power to the people, from the code rewriting Unix kernel was not a big deal for anybody with his level of programming talent:

"If I had to rewrite Unix from scratch, I could do it in a summer, easily," says Joy. "And it would be much better. A much, much better job. The ideas are old."

Actually rewriting of the kernel requires not only talent and not so much talent, but extremely high level of determination and  persistence (as well as some luck).  The level of talent required for rewriting was definitely of an order of magnitude less than for the initial creation: ships that going after the icebreaker have a much easier path. And in view of the volume of the code (and C is in essence a structured assembler) the project was not that too open: in no way Linus wanted to share his ideas with the world. Code yes, internal architecture, no (as of May, 2000 Linus Torvalds never published any technical article on Linux kernel.  Actually 386BSD  internals were much better documented...

I think that it's slightly funny when Linus Torvalds call this process of rewriting existing kernel "inventing Linux". I would partially agree that Unix was invented (C language was a pretty original blend of BCPL and PL/1; several key ideas like hierarchical filesystem, pipes and regular expressions were not present in Multix and CTSS which were two prototypes for Unix). But Linux was and still is a plain vanilla reengineering project.  And if Linus Torvalds can be called a revolutionary, he is a political not technical revolutionary similar to Newt Gingrich, the author of the "Contract with America" thing (fight corruption, waste in government spending, tax reform and a balanced budget, etc.). In no way Linux can be called a technological advance: classic monolithic kernel+C as implementation language means that Linux is based upon CS orthodoxy and as such is less innovative than, say, Plan 9 or Be OS, or Amiga.  This neo-conservative orthodoxy of Linux zealots -- the fundamental resistance to anything non-traditional (unless it was developed by Microsoft, in this case a reimplementation is a good thing ;-)  makes Linux success really a neo-conservative type of success.  Although it serves as an alternative to Microsoft OSes, Linux probably inhibited growth of alternative OSes like Be OS, and thus contributed to the lack of diversity, and ultimately lack of innovation in operating system market. As I mentioned before, some researchers like  Rob Pike considered the success of Linux as a sigh that innovation is dead in operating systems research.

But politically Linux was very attractive and that compensated the problem that he essentially was a yet another reimplementation of Unix, Johnny-come-lately, if you wish. I would like to reiterate that it has the following advantages:

• A strong anti-Microsoft sentiments
• A political attractiveness of the GNU license for operating system and other system programming projects along with the emergence of "commercial open source". Paradoxically Stallman's "free software" GPL became the cornerstone of "commercial open source" and huge perversions and financial machinations that occupied Linux IPO rush...
• CD technology provided the media to distribute it on a very cost-effective basis.
• An AT&T law suit that inhibited all alternative Unixes that were directly based on BSD codebase for at least four years (1991-1994)
• The wide availability of Usenet and Linus initial affiliation with Minix user group
• Extremely strongly motivated, a technically competent and politically savvy leader with a realistic goal that is in the most crude form was achievable in several months, not years; Linus really has both strong motivation and abilities to reach the goal;
• Right environment (University of Helsinki), time and equipment to do the job (he owned his 386-based PC -- the situation that, for example, was not so common in the former USSR region that also has a lot of extremely talented and motivated programmers)

BTW early versions of Linux kernel were only about 12,000 lines of code, I think. It's actually pretty close to the volume of the kernel in the famous Lion's book, a copy of which I think Linus also has (but he denied that he read it; that happens with computer science books ;-).  Actually Lion's book is such an  important achievement in itself that I completely, categorically reject attempts to undermine importance in May 2004 paper by Alexis de Tocqueville foundation president Ken Brown. As Technology News  mentioned:

In the report, Brown alleges that a course reader developed by John Lions -- then a professor at the University of New South Wales in Australia -- was an illegal copy that was so widely disseminated that many of the free-source luminaries must have seen it and used its code and techniques, thereby forever tainting the current open-source and free-source communities.

This is categorically untrue from the historical point of view accusation. Leon's book was perfectly legal and actually supported by AT&T effort.  Leon's book actually might helped Unix to survive and became a successful OS (Unix was an upstart operating system and its future was far from certain; AT&T bureaucracy never understood what a jewel it has). Moreover Leon's book can be considered as one of the classic computer books because it documented the real software masterpiece: the last version of Unix written mainly by Thompson, before the subsequent source code explosion due to the Unix success.  See also professor Andy Tannenbaum reaction to the paper.

So if we compare oranges to apples the kernel was only one tenth of the size of the GCC compiler (version 1.0, released in 1987 supported two Unix machines -- the VAX and the Sun 3 -- and comprised about 110,000 lines of code). From this point of view I would not compare Richard Stallman and Linus Torvalds as for productivity -- it looks like  RMS have wrote much more code ;-). Still Linus job was very impressive (12K of code in six months means ~ 2K a month). Please note that this is kernel code:  a lot of  top level programmers can probably write and debug similar amount of code in a half a year (writing 2,000 lines of code for a good weekend is not that uncommon for a top programmer), but programming kernel is more difficult hten say to write an editor. Anyway his project "Building a POSIX compatible kernel using old Minix codebase and Bach's book"  became a hit and nothing succeed like success.  The fact that it took him only six months (from March to September) to finish the first crude version attests the level of  his programming abilities,  the level of concentration on the task in hand as well as abilities to learn new things (and he learned a lot). In addition it is a demonstration of his ability to distill a realistic and attainable goal -- the quality that not that often comes along with the excellent programming abilities ;-). Still few people are able to work day and night on the same project for six long months and live the life of a computer screen prisoner. 

Of course the foundation of Linux development and the main attraction of Linux were the GCC compiler and utilities. But due to its central role, the Linux kernel almost immediately attained an independent status and downgraded everything created by GNU project to the supplementary status. With no competition from FSF, Linux kernel automatically became the most attractive platform for many other open source development projects. For example starting from version 0.12 Linux tremendously benefited from XFree86 effort. Orest Zborovski (who BTW was also one of early Minix users and experimented with Minix in 1990) decided to use Linux for his XFree86 development -- an extremely important project that tremendously helped Linux to obtain a critical mass. XFree86 was released in 1993. This gave Linux GUI and in 1994 Linux in certain aspects was able to compete with Windows GUI. ELF (Executable and Linking Format) support was added to Linux in 1995.

But DOS heritage was also important. Linux used fewer resources than FreeBSD and until Intel microprocessors reached Pentium level (1995) it was the most PC friendly Unix implementation in existence. The initial distribution was packed on just two floppies, so it was really easy to try this OS for advanced DOS users. As even the early version of FreeBSD FAQ stated:

One feature of Linux is the ability to make a filesystem on top of a DOS-FAT, so you don't need to repartition your Disk. This Filesystem is of course not so fast as a native Filesystem, but for trial it should be O.K.

Another prominent developer who join Linux at this time was Alan Cox who later turned to be a major contributor to the Linux kernel. In his recollection of the events he pointed out another advantage of early Linux kernels -- they can run on more popular and much cheaper 386sx CPUs (1999 interview) :

I'd always wanted a Unix system but even Minix was out of my price range. I'd spent some time adding unixlike stuff to the Amiga I had but wasn't bold enough to write an entire new OS. When Linux 0.11 & 386BSD were announced I ordered a 386 box. I couldn't afford an FPU which 386BSD needed at the time so I installed Linux (off two floppy disks at the time). 0.95 appeared and the university computer society bought a 386 box and I fixed a couple of things. Linus ignored one patch and rejected the other. A while later we were one of the early users of the Linux TCP/IP code, and after Ross Biro quit as the maintainer Fred van Kempen took over, and started doing a big rewrite not fixing the old code. I started maintaining  the old code (by virtue of the fact the compsoc machine crashed every 3 hours and we needed to fix it) and Linus started using that. Fred's rewrite never made it into the kernel.

Note that the ability to run on 386sx in 4M of memory was a very important advantage and it alone fueled interest in Linux at the expense of 386BSD and then FreeBSD probably until late 1994: three the most crucial years.

In view of often dismissive attitude toward DOS in computer science community it is interesting to note that Linus attempt was the first UNIX reimplementations that was manned by people who knew well DOS operating system internals. For some period one of the most popular of Linux file systems was compatible with FAT. In this sense Linux can be called:

• The XENIX replacement -- the first time the pool of developers of Unix-like system were accomplished DOS programmers/users. The fact that Linux was a reimplementation of Unix and not a direct derivative of BSD codebase helped to make several things in the kernel more Intel386 architecture specific and contributed to PC friendliness of Linux.
• The First Usenet-based Unix (and indeed for me in this area Linux is second after GNU project story of the Internet as the model for distributed collaboration -- and Linus proved to be a very talented organizer of such collaboration of (at this time) a very elite group -- very few have Usenet access in 1991).
• The first Anti-Microsoft movement inspired Unix ;-). Hostility toward monopolistic position of Microsoft and resentment about DOS that at early nineties was two generations behind current Intel hardware (486 computers with DOS were ridiculous for anybody who took a university course in operating systems. DOS was in essence slightly modernized CP/M -- an innovative, extremely portable 8 bit microprocessors OS but it no way it was suitable for 386 CPU). Anti-Microsoft sentiments were an important force that fueled and fuels Linux development (although Linus usually downplayed this factor in interviews). And it is well known that the closer religious sects are in doctrines the more fierce struggle they can engage in -- so Linux movement and Microsoft should have a pretty strong feeling toward each other as they share the same platform. In a certain sense we can consider Linux is a Microsoft-style Unix clone -- it demonstrated that software availability wins out over technical quality every time. And Linus himself can be probably considered a Microsoft-style developer -- a developer that understand the value of being first to the market and the value of controlling the desktop. Moreover, like Microsoft developers he is oriented on "pleasing the crowd", not the elite group of server administrators and university computer science researchers. As far as I understand the situation, Linus was a real hacker -- he never has any plans for Linux development and just try to catch the wind of user wishes. But he was very pragmatic, politically savvy conservative leader. See for example historical part of NET-3 HOW TO with some information about resignation of Fred van Kempen a very talented guy -- one of the former Minix developers -- who was sacrificed in order to get stable Linux networking done.

Development of Linus TCP/IP stack

Linux did not have TCP/IP stack build-in until probably 1993. Before that it was a separate package created and maintained by multiple developers. Actually TCP/IP stack was the first major subsystem that was developed almost completely without Linus participation (Linus never was strong in networking). It also nicely illustrated the power and role of Usenet community in Linux success.  Essentially the facts are that Linux was late to the Internet, but managed to catch up just in time when WEB became widely available (1994).  Here how the history is described in Linux Networking-HOWTO (Previously the Net-3 Howto) General Information about Linux Networking.

Developing a brand new kernel implementation of the tcp/ip protocol stack that would perform as well as existing implementations was not an easy task. The decision not to port one of the existing implementations was made at a time when there was some uncertainty as to whether the existing implementations may become encumbered by restrictive copyrights because of the court case put by U.S.L. and when there was a lot of fresh enthusiasm for doing it differently and perhaps even better than had already been done.

The original volunteer to lead development of the kernel network code was Ross Biro <[email protected]>. Ross produced a simple and incomplete but mostly usable implementation set of routines that were complemented by an ethernet driver for the WD-8003 network interface card. This was enough to get many people testing and experimenting with the software and some people even managed to connect machines in this configuration to live internet connections. The pressure within the Linux community driving development for networking support was building and eventually the cost of a combination of some unfair pressure applied to Ross and his own personal commitments outweighed the benefit he was deriving and he stepped down as lead developer. Ross's efforts in getting the project started and accepting the responsibility for actually producing something useful in such controversial circumstances were what catalyzed all future work and were therefore an essential component of the success of the current product.

Orest Zborowski <[email protected]> produced the original BSD socket programming interface for the Linux kernel. This was a big step forward as it allowed many of the existing network applications to be ported to linux without serious modification.

Somewhere about this time Laurence Culhane <[email protected]> developed the first drivers for Linux to support the SLIP protocol. These enabled many people who did not have access to Ethernet networking to experiment with the new networking software. Again, some people took this driver and pressed it into service to connect them to the Internet. This gave many more people a taste of the possibilities that could be realized if Linux had full networking support and grew the number of users actively using and experimenting with the networking software that existed.

One of the people that had also been actively working on the task of building networking support was Fred van Kempen <[email protected]>. After a period of some uncertainty following Ross's resignation from the lead developer position Fred offered his time and effort and accepted the role essentially unopposed. Fred had some ambitious plans for the direction that he wanted to take the Linux networking software and he set about progressing in those directions. Fred produced a series of networking code called the `NET-2' kernel code (the `NET' code being Ross's) which many people were able to use pretty much usefully. Fred formally put a number of innovations on the development agenda, such as the dynamic device interface, Amateur Radio AX.25 protocol support and a more modularly designed networking implementation. Fred's NET-2 code was used by a fairly large number of enthusiasts, the number increasing all the time as word spread that the software was working. The networking software at this time was still a large number of patches to the standard release of kernel code and was not included in the normal release. The NET-FAQ and subsequent NET-2-HOWTO's described the then fairly complex procedure to get it all working. Fred's focus was on developing innovations to the standard network implementations and this was taking time. The community of users was growing impatient for something that worked reliably and satisfied the 80% of users and, as with Ross, the pressure on Fred as lead developer rose.

Alan Cox <[email protected]> proposed a solution to the problem designed to resolve the situation. He proposed that he would take Fred's NET-2 code and debug it, making it reliable and stable so that it would satisfy the impatient user base while relieving that pressure from Fred allowing him to continue his work. Alan set about doing this, with some good success and his first version of Linux networking code was called `Net-2D(ebugged)'. The code worked reliably in many typical configurations and the user base was happy. Alan clearly had ideas and skills of his own to contribute to the project and many discussions relating to the direction the NET-2 code was heading ensued. There developed two distinct schools within the Linux networking community, one that had the philosophy of `make it work first, then make it better' and the other of `make it better first'. Linus ultimately arbitrated and offered his support to Alan's development efforts and included Alan's code in the standard kernel source distribution. This placed Fred in a difficult position. Any continued development would lack the large user base actively using and testing the code and this would mean progress would be slow and difficult. Fred continued to work for a short time and eventually stood down and Alan came to be the new leader of the Linux networking kernel development effort.

Donald Becker <[email protected]> soon revealed his talents in the low level aspects of networking and produced a huge range of ethernet drivers, nearly all of those included in the current kernels were developed by Donald. There have been other people that have made significant contributions, but Donald's work is prolific and so warrants special mention.

Alan continued refining the NET-2-Debugged code for some time while working on progressing some of the matters that remained unaddressed on the `TODO' list. By the time the Linux 1.3.* kernel source had grown its teeth the kernel networking code had migrated to the NET-3 release on which current versions are based. Alan worked on many different aspects of the networking code and with the assistance of a range of other talented people from the Linux networking community grew the code in all sorts of directions. Alan produced dynamic network devices and the first standard AX.25 and IPX implementations. Alan has continued tinkering with the code, slowly restructuring and enhancing it to the state it is in today.

PPP support was added by Michael Callahan <[email protected]> and Al Longyear <[email protected]> this too was critical to increasing the number of people actively using linux for networking.

Jonathon Naylor <[email protected]> has contributed by significantly enhancing Alan's AX.25 code, adding NetRom and Rose protocol support. The AX.25/NetRom/Rose support itself is quite significant, because no other operating system can boast standard native support for these protocols beside Linux.

There have of course been hundreds of other people who have made significant contribution to the development of the Linux networking software. Some of these you will encounter later in the technology specific sections, other people have contributed modules, drivers, bug-fixes, suggestions, test reports and moral support. In all cases each can claim to have played a part and offered what they could. The Linux kernel networking code is an excellent example of the results that can be obtained from the Linux style of anarchic development, if it hasn't yet surprised you, it is bound to soon enough, the development hasn't stopped.

It's important to stress that Linus really has very good organizational abilities in addition to programming talent (his famous phrase "show me the code'' -- a very nice workaround for kernel developers wanna-be who proposed new features is a good example of his organizational abilities). That really helps to keep the group small and motivated --  the elite group of elite (mostly MINIX) developers that is needed for the kernel. He managed to politically outmaneuver both RMS and FreeBSD development group -- no small fit. From the very beginning he tried  (and succeed) to get other people working on the project keeping only vital parts to himself. Hackers are often selfish and greedy as for the software ownership (Lone Ranger type of developers, as exemplified by RMS)  -- you need to be politically savvy to understand that as long as you control the central part of the project it does not matter much who contributes to the peripheral parts of the system. In technical areas he has a pragmatic conservative approach, tries to cater to the largest user group and often stresses the importance of simplicity. Being a son of journalists he proved to be able to write really good marketing pitches. Here is one of his best early marketing pitches from comp.os.minix:

``Do you pine for the nice days of Minix-1.1, when men were men and wrote their own device drivers? Are you without a nice project and just dying to cut your teeth on an OS you can try to modify for your needs? Are you finding it frustrating when everything works on Minix? No more all-nighters to get a nifty program working? Then this post might be just for you.

...As I mentioned a month ago, I'm working on a free version of a Minix-look-alike for AT-386 computers. It has finally reached the stage where it's even usable (though may not be, depending on what you want), and I am willing to put out the sources for wider distribution. It is just version 0.02...but I've successfully run bash, GCC, gnu-make, gnu-sed, compress, etc. under it.''

Initial reimplementation efforts progressed pretty fast. Linux Time Line provides the following information:

From interviews that I read, I have an impression that politically Linus behaves like a moderate conservative (or centrist if you like); usually that means attempts to balance requirements of "Linux left" (GNU license, etc.) and "Linux right" (commercial distribution, marketing, etc.) camps in such a way as to please Linux right and not offend too much Linux left. In his technical decisions he preferred to side with commercial distributors. It looks like for him open source was a business strategy, not a philosophy. For example, until recently, unlike Linux extremists he was reluctant to claim that open source software development model is universal and even sometimes agreed that there are areas where this approach does not work as effectively as in system components and pure programmer-oriented tools. Now with recent Linux success he (predictably) became much more bold :-). But politically he is pretty flexible and can go against his own beliefs, if commercial interests dictate so.  A good example is his behavior toward SMP support in kernel. Linus like Microsoft's Bill Gates understands pretty well the importance of the desktop and the fact that SMP is generally not needed for the desktop. And that's a huge development effort that greatly complicates kernel and as such goes against the KISS principle. That's why he initially rejected the idea of adding SMP to the kernel. Later under the pressure from Linux distributors he changes his tune and in some interviews even started to claim that this is an important advantage of Linux.

Similarly, he does not consider GNU license to be a sacred cow -- for him it was a nice political move that proved to be effective in the creation of commercial distributor chain. One nice feature of GPL in this particular case is that it is one way street -- GPL project can borrow whatever developers wish from the BSD-license based project, but not vice versa.   But in no way he is fundamentalist about  "philosophy of software freedom" like for RMS who after, say, 1996 became much more of a political activist ("software freedom fighter") then a programmer. May be intuitively Linus noticed that GPL license has some "subtle greed" component in it  and nicely permits commercial distributors financially benefit from free software efforts in a way that is different from BSD license: GPL favors commercial first-comers and financial heavy-weights over competitors (natural monopoly), so it might have some implicit concentration/monopolization side effect not foreseen by RMS.  This effect was first noticed by Cygnus founder, Michael Tiemann, who called it "first mover advantage":

In fact, GNUPro has become so dominant that several of our competitors have announced their intention to sell commercial support for GNU software to compete with us! Fortunately, the Open Source model comes to the rescue again. Unless and until a competitor can match the 100+ engineers we have on staff today, most of whom are primary authors or maintainers of the software we support, they cannot displace us from our position as the "true GNU" source (we supply over 80% of all changes made to GCC, GDB, and related utilities). The best they can hope to do is add incremental features that their customers might pay them to add. But because the software is Open Source, whatever value they add comes back to Cygnus as open-source software, for us to integrate if it's good, or ignore if it's not. Unlike proprietary software in which competitors fight in a two-sided win/lose contest, with Open Source it's more like fighting on a Moebius strip, and everything flows to the side of the primary maintainer. So, while our competitors may get some tactical advantage in the "me-too" GNU space, Cygnus benefits in the long run. Founded in 1989, our first-mover advantage is ten years ahead of the competition.

This advantage is not absolute, and much depends on your level of venture capital support, but as soon as you have that, you are pretty safe. Actually this was started before Linux and it was Cygnus, which became the first supported by venture capital GPL-products based company: the model that was imitated later by Linux distributors.  Two venture capital  companies (Greylock Management and August Capital) invested $6.25M in Cygnus, the largest private placement for a software company in the first half of 1997 just before Linux IPO wave was launched.  We have to accept the fact that nobody can understand all the implications of GPL right away and its attractiveness to commercial GNU software distributors and acceptability for venture capital and large companies like IBM comes somewhat as surprise.

Still Linus would definitely change the license if it benefited him and Linux. On a couple occasions he did explicitly that declaring so called "Linus exemptions" to GPL (Linux drivers is one example).  Sometimes he was even accused of lack of principles by GPL extremists like Bruce Perens. Here is one example:

Linus Torvalds is a nice guy, and I like him. Some days, though, he really misses the point. One of those Linus-in-space moments happened recently, when Linus allowed himself to be quoted saying:

My opinion on licenses is that "he who writes the code gets to choose the license, and nobody else gets to complain." Anybody complaining about a copyright license is a whiner. The anti-KDE people are free to write their own code, but they don't have the moral right to complain about other people writing other code. I despise people who do complain, and I won't be sucked into the argument.

Linus is really missing the point here. KDE's authors indeed have a right to choose any license they want. The problem is that they are pushing KDE as a standard GUI for Linux. And that changes all of the rules. When something's promoted as a Linux standard while a critical component of it has a bad license, every free software developer who has contributed to Linux has a right to complain without being despised by Linus. Their complaints are not whining or flaming. There is a real problem and they sincerely want to see it solved...

Why KDE is Still a Bad Idea by Bruce Perens

Here it is Bruce Perens who actually missed the point:  Linux understood the value of GNU software cult for proprietary software development ; he just think that you need to be more flexible and bend the rules, if necessary. 

Starting from 1994-1995 another negative development in Linux started: Linus cult of personality. This is what actually was the reason for writing this chapter. From what I saw in interviews available from the Web starting from ~1995 Linus Torvalds was never shy about his own accomplishments. For example, in 1999 PC Week interview he went as far as to claim that he "invented" Linux -- for a plain-vanilla reimplementation of POSIX-compatible kernel; this is as close to Microsoft marketing as we can get ;-). Like a standard ceremonial gesture he often stress contribution of others, although like communist party bosses he never gives any names. He also usually do not mentions GNU although GCC was/is the cornerstone of the Linux OS. That sometimes produces an opposite overreaction -- I do not mean RMS reaction here. But even far from GNU fundamentalism people started to react on exaggerations of "fearless leader"; for example as somebody put it on the Usenix 1998  "Linux is 80% GNU, 20% kernel and 1% Linus". BTW it was 1998 when Intel invested in Red Hat, so this was a completely wrong take on the situation :-)

It's important to stress that Linus, as a really good politician, made several astute political moves during this first decade of Linux development and, at the same time, made no noticeable political blunders -- moves that can irrevocably split the community. Now he loves to stress technical quality and play on anti-Microsoft sentiments (Microsoft operating systems are technically inferior and so on and so forth),  although it's clear Linux won like a neo-conservative political moderate and mainly due to early availability on the most popular low cost platform (386sx) and, later, Linus personal blessing of commercial distributors "selling Bazaar to Cathedral" -- not quality. Also, like I mentioned before, it happened to be the first working GNU-license based Unix-like kernel for the most popular at the time 386sx CPU, no more no less -- and that definitely attracted other  developers who were struggling with the same platform and cannot afford to move to 486...

Basically, mainly due to early availability Linus managed to beat both 386BSD and Stallman with his Hurd project, getting first to the market, cannibalizing available Usenet OS-developer resources and stealing all the fame ;-). On July, 1992 Linus wrote a small article about Linux history that I strongly recommend to read.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019