Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

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

Operating systems are like underwear — nobody really wants to look at them

Bill Joy

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:

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:

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:

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:

July 3, 1991 Some device drivers, and the hard drive are now working; some basic user-level features are now being considered
August 25, 1991 v0.01 is almost ready; MMU used for paging (not to disk yet) and segmentation, pseudo ttys, BSD sockets, user-mode filesystem, window size in the tty structure, systems calls are capable of supporting POSIX.1 and BSD-style filenames
September 1991 Linux v0.01: no binaries are available yet, only source code; a small filesystem exists, along with a working disk-driver
October 5, 1991 Linux v0.02: The first "official" version of Linux was announced. This version was able to run bash, GCC, gnu-make, gnu-sed, and compress. This version was not very usable.
October 26, 1991 Linux v0.03: This version of Linux was considered usable.
November, 1991 Linux v0.10
December 19, 1991 Linux v0.11: This was the first stand-alone version of Linux. There was still no SCSI support, although there were people working on it. Hardware setup for this version consisted of ISA+AT-disk. No init/login yet either, you would get bash as root upon bootup (standard in the next release as well). Partially working VM (paging to disk), but 4M was needed to be able to run the GNU binaries, especially GCC. Bootup was possible with only 2M, but you could not compile.
December (Xmas) 1991 Linux v0.11+VM: Several people were trying to compile the kernel with 2M and failing, hence this version was made available to this small group of individuals that wanted to test it out.
January 5, 1992 Linux v0.12: This was the first version of Linux to contain "non-essential" features. This was also the first version that Linus allowed any money to change hands due to Linux (the birth of commercial open source ;-) Previously Linux had been distributed free, under a very lenient copyright owned by Linus. This previous copyright had actually been much more restrictive than the GNU copyright.
March 1992 Linux v0.95
April 1992 Linux v0.96: This version of Linux was capable of running X-Windows

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 quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard 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 DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting 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-MonthHow 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


Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

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