Linus Torvalds - Just for Fun

Ari Lemke must have been quite an optimist. He created the subdirectory (ftp.funet.fi) long before I had something I wanted to release. I had the password, and everything was set up for me to just log in and upload stuff to it. But it took about four months for me to feel I had anything I was willing to share with the world, or at least with Ari and the few other operating system freaks with whom I had been exchanging email.

My original goal was to create an operating system that I could eventually use as a replacement for Minix. It didn't have to do more than Minix, but it had to do the things in Minix that I cared about, and some other things I cared about, too. For example, not only was the Minix terminal emulation bad, but there was no way of performing the job-control function -- putting a program in the background while you're not using it. And memory management was done very simplistically, as it still is in the Mac OS, incidentally.

The way you create an operating system is to find out what the system calls are supposed to do, and then write your own program to implement those system calls in your own way. Generally speaking, there are a couple of hundred system calls. Some of them can represent multiple functions. Others are quite simple. Some of the more fundamental system calls are really complicated and depend on a great deal of infrastructure being there. Take the system calls of "Write" and "Read." You need to create a disk driver in order to write something to disk or read something from disk. Take "Open." You have to create the entire file system layer that parses the names and figures out where on the disk everything is. It took months just to write the "Open" system call. But once it was in place, the same code could be used for other functions.

That's how the early development was done. I was reading the standards from either the Sun OS manual or various books, just picking off system calls one by one and trying to make something that worked. It was really frustrating. The reason: Because nothing is happening, you can't really see any progress. You can make small test programs that test whatever it is you just added. But that doesn't really accomplish anything. After awhile you get to the point where, instead of just reading through a list of system calls, you give up on that approach. It's getting complete enough that you want to run a real program. The first program you have to run is a shell because, without a shell, it's pretty hard to run anything else. And besides, the shell itself contains many of the system calls you will need. Get it running and you will be able to print out a running list of the system calls you haven't implemented.

In Unix, the shell is kind of the mother of all programs. It's there to start up other binaries. (A binary is a program in the 1's and 0's that a machine reads. Whenever you write a program in a computer language, you then compile the source code and it becomes a binary.) The shell allows you to log on in the first place.

Okay, traditionally in a real Unix system the first program you run is called init, but initreally needs a lot of infrastructure in order to work. It's kind of a controller for what goes on. But when you don't really have anything that works, there isn't any point to having init.

So instead of starting init, the first thing my kernel did was to start the shell. I had implemented about twenty-five system calls and, as I mentioned, this was the first real program I was trying to run. The shell wasn't something I had written myself. I had downloaded onto a disk a clone of the Bourne Shell, which was one of the original Unix shells. It was available over the Internet as free software, and its name was derived from a bad pun. The guy who wrote the original was named Bourne, so was the clone Bourne-Again Shell -- commonly referred to as bash.

When you try and load a real program from disk, invariably there's a bug in the disk driver or in the loader because it doesn't understand what it's reading in. So it prints out a running commentary on what it's doing. It's important because that's how you can find out what is going wrong.

I got to the point where my program was loading the shell and generating a printout of every system call that the shell contained that I hadn't yet implemented. I booted, ran the shell, and it would spit back something like: "system call 512 is not done." Day and night I was looking at printouts of system calls, trying to determine which ones I was doing wrong. But this was much more fun than taking a list of calls and just implementing them. You got to see progress being made.

It was late August or early September when I finally got the shell working. From that point, things got a lot easier.

This was a big deal.

When I got the shell working, I was pretty much immediately able to compile a few other programs. The shell was more complicated than the cp (copy) program, for example, or the 1's (for getting a directory listing) program. Everything you needed had to be there for the shell already, so once the shell was working it went from close to zero to 100 in nothing flat, because all these pieces had been in place. At some point there was enough in place that I experienced a Let There Be Light moment, because until then, nothing had really worked.

Yes, I felt a great sense of satisfaction. I think that was particularly important because I hadn't been doing anything that summer except working on the computer. This is not an exaggeration. The April through August period is pretty much the best time of the year in Finland. Folks are sailing in the archipelago, sunning themselves on beaches, sitting in their summer-cottage saunas. But I rarely even knew if it was day or night, weekend or weekday. Those thick black curtains blocked out the near round-the-clock sunshine, and the world. Some days -- nights? -- I'd roll out of bed directly into the chair at my computer, less than two feet away. Apparently my dad was bugging my mom to make me get a summer job. But she didn't mind: I wasn't bothering her. Sara was a bit annoyed that the phone lines were always tied up when I went online. She could probably write that sentence with a little less diplomacy. It's not an exaggeration to say that I had virtually no contact with the world outside my computer. Okay, maybe once a week a friend would knock on my window and if I wasn't scrolling through important code I would invite him in. (It was always a him-remember, this was before geeks were considered cool.) We would drink tea and maybe watch an hour of MTV in the tiny kitchen. Now that I think of it, yes, I do recall going out for an occasional beer or for some snooker after having my window pounded by someone like Juoko (I call him "Avuton," which means "he who slays dragons," but that's another story). But, in all honesty, nothing else was going on in my life at the time.

And I didn't feel the least bit like some pathetic, pale-skinned, propeller-head loser. The shell was operational, which meant that I had actually built the foundation of a working operating system. And I was having fun.

With the shell working, I started testing its built-in programs. Then I compiled enough new programs to actually do something. I was compiling everything in Minix, but I moved the shell over to a special partition that I had created for the new operating system. Privately I called it Linux.

Honest: I didn't want to ever release it under the name Linux because it was too egotistical. What was the name I reserved for any eventual release? Freax. (Get it? Freaks with the requisite X.) In fact, some of the early make files-the files that describe how to compile the sources-included the word "Freax" for about half a year. But it really didn't matter. At that point I didn't need a name for it because I wasn't releasing it to anybody.