Free for All by Peter Wayner (great books to read .txt) 📖

computer users often notice this effect without realizing why it ated operations where one company controls all exists. Most Macintosh computers, for instance, can be sluggish at times because the OS does not do a good job juggling the workload between processes. The kernel of the OS has not been completely overhauled since the early days when the machines ran one program at a time. This sluggishness will persist for a bit longer until Macintosh releases a new version known as MacOS X. This will be based on the Mach kernel, a version developed at Carnegie-Mellon University and released as open source software. Steve Jobs adopted it when he went to NeXT, a company that was eventually folded back into Apple. This kernel does a much better job of juggling different tasks because it uses preemptive multitasking instead of cooperative multitasking. The original version of the MacOS let each program decide when and if it was going to give up control of the computer to let other programs run. This low-rent version of juggling was called cooperative multitasking, but it failed when some program in the hotel failed to cooperate. Most software developers obeyed the rules, but mistakes would still occur. Bad programs would lock up the machine. Preemptive multitasking takes this power away from the individual programs. It swaps control from program to program without asking permission. One pig of a program can't slow down the entire machine. When the new MacOS X kernel starts offering preemptive multitasking, the users should notice less sluggish behavior and more consistent performance.

Torvalds plunged in and created a monolithic kernel. This made it easier to tweak all the strange interactions between the programs. Sure, a microkernel built around a clean, message-passing architecture was an elegant way to construct the guts of an OS, but it had its problems. There was no easy way to deal with special exceptions. Let's say you want a web server to run very quickly on your machine. That means you need to treat messages coming into the computer from the Internet with exceptional speed. You need to ship them with the equivalent of special delivery or FedEx. You need to create a special exception for them. Tacking these exceptions onto a clean microkernel starts to make it look bad. The design starts to get cluttered and less elegant. After a few special exceptions are added, the microkernel can start to get confused.

Torvalds's monolithic kernel did not have the elegance or the simplicity of a microkernel OS like Minix or Mach, but it was easier to hack. New tweaks to speed up certain features were relatively easy to add. There was no need to come up with an entirely new architecture for the message-passing system. The downside was that the guts could grow remarkably byzantine, like the bureaucracy of a big company.

In the past, this complexity hurt the success of proprietary operating systems. The complexity produced bugs because no one could understand it. Torvalds's system, however, came with all the source code, making it much easier for application programmers to find out what was causing their glitch. To carry the corporate bureaucracy metaphor a bit further, the source code acted like the omniscient secretary who is able to explain everything to a harried executive. This perfect knowledge reduced the cost of complexity.

By the beginning of 1992, Linux was no longer a Finnish student's part-time hobby. Several influential programmers became interested in the code. It was free and relatively usable. It ran much of the GNU code, and that made it a neat, inexpensive way to experiment with some excellent tools. More and more people downloaded the system, and a significant fraction started reporting bugs and suggestions to Torvalds. He rolled them back in and the project snowballed.

8.1 A HOBBY BEGETS A PROJECT THAT BEGETS A MOVEMENT

...................................................

On the face of it, Torvalds's decision to create an OS wasn't extraordinary. Millions of college-age students decide that they can do anything if they just put in a bit more elbow grease. The college theater departments, newspapers, and humor magazines all started with this impulse, and the notion isn't limited to college students. Millions of adults run Little League teams, build model railroads, lobby the local government to create parks, and take on thousands of projects big and small in their spare time.

Every great idea has a leader who can produce a system to sustain it. Every small-town lot had kids playing baseball, but a few guys organized a Little League program that standardized the rules and the competition. Every small town had people campaigning for parks, but one small group created the Sierra Club, which fights for parks throughout the world.

This talent for organizing the work of others is a rare commodity, and Torvalds had a knack for it. He was gracious about sharing his system with the world and he never lorded it over anyone. His messages were filled with jokes and self-deprecating humor, most of which were carefully marked with smiley faces (:-)) to make sure that the message was clear. If he wrote something pointed, he would apologize for being a "hothead." He was always gracious in giving credit to others and noted that much of Linux was just a clone of UNIX. All of this made him easy to read and thus influential.

His greatest trick, though, was his decision to avoid the mantle of power. He wrote in 1992, "Here's my standing on 'keeping control,' in 2 words (three?): I won't. The only control I've effectively been keeping on Linux is that I know it better than anybody else."

He pointed out that his control was only an illusion that was caused by the fact that he did a good job maintaining the system. "I've made my changes available to ftp-sites etc. Those have become effectively official releases, and I don't expect this to change for some time: not because I feel I have some moral right to it, but because I haven't heard too many complaints."

As he added new features to his OS, he shipped new copies frequently. The Internet made this easy to do. He would just pop a new version up on a server and post a notice for all to read: come download the latest version.

He made it clear that people could vote to depose him at any time. "If people feel I do a bad job, they can do it themselves." They could just take all of his Linux code and start their own version using Torvalds's work as a foundation.

Anyone could break off from Torvalds's project because Torvalds decided to ship the source code to his project under Richard Stallman's GNU General Public License, or GPL. In the beginning, he issued it with a more restrictive license that prohibited any "commercial" use, but eventually moved to the GNU license. This was a crucial decision because it cemented a promise with anyone who spent a few minutes playing with his toy operating system for the 386. It stated that all of the source code that Torvalds or anyone else wrote would be freely accessible and shared with everyone. This decision was a double-edged sword for the community. Everyone could take the software for free,

but if they started circulating some new software built with the code, they would have to donate their changes back to the project. It was like flypaper. Anyone who started working with the project grew attached to it. They couldn't run off into their own corner. Some programmers joke that this flypaper license is like sex. If you make one mistake by hooking up with a project protected by GPL, you pay for it forever. If you ever ship a version of the project, you must include all of the source code. It can be distributed freely forever.

While some people complained about the sticky nature of the GPL, enough saw it as a virtue. They liked Torvalds's source code, and they liked the fact that the GPL made them full partners in the project. Anyone could donate their time and be sure it wasn't going to disappear. The source code became a body of work held in common trust for everyone. No one could rope it off, fence it in, or take control.

In time, Torvalds's pet science project and hacking hobby grew as more people got interested in playing with the guts of machines. The price was right, and idle curiosity could be powerful. Some wondered what a guy in Finland could do with a 386 machine. Others wondered if it was really as usable as the big machines from commercial companies. Others wondered if it was powerful enough to solve some problems in the lab. Still others just wanted to tinker. All of these folks gave it a try, and some even began to contribute to the project.

Torvalds's burgeoning kernel dovetailed nicely with the tools that the GNU project created. All of the work by Stallman and his disciples could be easily ported to work with the operating system core that Torvalds was now calling Linux. This was the power of freely distributable source code. Anyone could make a connection, and someone invariably did. Soon, much of the GNU code began running on Linux. These tools made it easier to create more new programs, and the snowball began to roll.

Many people feel that Linus Torvalds's true act of genius was in coming up with a flexible and responsive system for letting his toy OS grow and change. He released new versions often, and he encouraged everyone to test them with him. In the past, many open source developers using the GNU GPL had only shipped new versions at major landmarks in development, acting a bit like the commercial developers. After they released version 1.0, they would hole up in their basements until they had added enough new features to justify version 2.0.

Torvalds avoided this perfectionism and shared frequently. If he fixed a bug on Monday, then he would roll out a new version that afternoon. It's not strange to have two or three new versions hit the Internet each week. This was a bit more work for Torvalds, but it also made it much easier for others to become involved. They could watch what he was doing and make their own suggestions.

This freedom also attracted others to the party. They knew that Linux would always be theirs, too. They could write neat features and plug them into the Linux kernel without worrying that Torvalds would yank the rug out from under them. The GPL was a contract that lasted long into the future. It was a promise that bound them together.

The Linux kernel also succeeded because it was written from the ground up for the PC platform. When the Berkeley UNIX hackers were porting BSD to the PC platform, they weren't able to make it fit perfectly. They were taking a piece of software crafted for older computers like the VAX, and shaving off corners and rewriting sections until it ran on the PC.

Alan Cox pointed out to me, "The early BSD stuff was by UNIX people for UNIX people. You needed a calculator and familiarity with BSD UNIX on big machines (or a lot of reading) to install it. You also couldn't share a disk between DOS/Windows and 386BSD or the early branches off it.

"Nowadays FreeBSD understands DOS partitions and can share a disk, but at the time BSD was scary to install," he continued.

The BSD also took certain pieces of hardware for granted. Early versions of BSD required a 387, a numerical coprocessor that would speed up the execution of floating point numbers. Cox remembers that the price (about $100) was just too much for his budget. At that time, the free software world was a very lean organization.

Torvalds's operating system plugged a crucial hole in the world of free source software