Nikolai Bezroukov. Portraits of Open Source Pioneers

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

Softpanorama Linus Torvalds' Interviews Collection (1993)
(preserving Linus Torvalds interviews for humanity ;-)

The Choice of a Gnu Generation

An Interview with Linus Torvalds

Linus Torvalds, a computer science student at the University of Helsinki in his early twenties, took his first course on Unix and C in the Fall of 1990. In the Spring of 1991 Linus was running Minix (a small Unix-like operating system designed for teaching) at home on his new '386. What was to become Linux started in the Summer of 1991 as a basic protected mode system that evolved from a "Hello World" program into a terminal program.

By October 1991 Linux 0.02 was announced to the world. In two years, through the hard work of Linus and many other people, Linux, currently at version 0.99, has become an extremely useful and popular operating system. The comp.os.linux.* hierarchy is among USENET's busiest and there are several companies selling Linux and providing professional support. All this in such a short time, yet Linux is available for free, and development has almost entirely been done by volunteers. Meta interviewed Linus via E-mail to probe his mind about Linux's future and the environment it is developing in. The results follow....

Meta: Do you agree that without the net to facilitate collaboration and a base of preexisting free software (e.g., the GNU tools), Linux would not be nearly as developed as it is?

Linus: No question about it. Without net access, the project would never have even gotten off the ground; having access to gcc and the other GNU tools was very important. I was also able to get in contact with some people like Bruce Evans (author of the Minix-386 patches and the 16-bit assembler that is still used to assemble the Linux 16-bit startup code), and we had some interesting discussions by E-mail.

Aside from getting me started, net access also kept the development going and accelerating: up to about version 0.12 or so, I wrote most of the code myself, but in the current kernel, only about 50% of the code is mine or very closely related to code written by me. The SCSI drivers, the networking code and the new floating-point emulator code is completely written by others.

Even when people haven't sent in patches or new code, just the fact that I've had access to a lot of testers has meant a lot for Linux development; they've found bugs I wouldn't have noticed myself, and have suggested features that I might not have otherwise cared for, but that have turned out to be very useful indeed. One extreme example is the memory manager: I originally implemented demand-loading and swapping to disk mostly because people who used the early versions of Linux thought it might be useful.

M: Probably the most frequent complaint about Linux is the lack of certain applications. With the net, free development tools and a free Unix with source code all in place, what do you think are the prospects for free end-user applications being developed in a similar decentralized manner?

L: While Linux has a very reasonable development environment and a lot of programmers that would potentially be able to write a good word processor or spreadsheet or whatever, there are some problems which make me doubtful that it will happen soon. Right now, I think there is a better chance of getting a word processor by being binary compatible with Windows or some "real" '386 Unix (both of which are being worked on).

The programs that have "made it" through a decentralized network development have usually had a few things in common:

(a) Somebody (usually one person) wrote the basic program to the state where it was already usable. The net community then takes over and refines and fixes problems, resulting in a much better program than the original, but the important part is to get it started (and channeling the development some way). The net works a bit like a committee: you'll need a few dedicated persons who do most of the stuff or nothing will get done.

(b) You need to have a project that many programmers feel is interesting: this does not seem to be the case with a lot of the application programs. A program like a word processor has no "glamour": it may be the program that most users would want to see, and most programmers would agree that it's not a simple thing to write, but I also think they find it a bit boring.

I think it's entirely possible that the Linux community (or some other group of net.persons) will get a good word processor going, but while having net access helps some parts of development a lot, it's certainly not enough in itself.

M: Could you comment on the effort to make Linux binary compatible with "real" Unixes and speculate on the effect Linux is having on the Unix market, especially on Coherent and lower-tier System V vendors?

L: This one is hard for me to really say much about: I haven't been in contact with any real i386-Unix users, and have only once seen a Xenix system being run on a friend's machine (that one was converted to Linux, but that doesn't really count when I know him personally). I have gotten various mails and seen some newsgroup messages about persons who have switched over already or would like to switch over once Linux is able to run commercial binaries, but at least so far, I doubt Linux has dented the "real unix" market very much.

Coherent might have a bit more problems competing with Linux. While Coherent is commercial, it doesn't carry the same "real Unix" stamp as SCO and the other major PC Unix providers, so a potential Coherent user is also likely to chose Linux, if he has access to it. And the superior performance and features of Linux may well be (and has been in many cases) reason enough to chose Linux despite the reportedly good documentation and support of Coherent.

Being binary-compatible with SVR3 and SVR4 might change the picture a lot: it would make it possible to reasonably easily mix Linux machines into an existing machine park, and would make Linux much more viable in some situations. The current kernel can load ELF binaries, and COFF support is available as patches. The actual binary code emulation is still being worked on, but there seems to be no major obstacles. If the Wine project (running Windows binaries under Linux and X11) also works out, the picture changes again.

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.

M: Some people, particularly Peter MacDonald of SLS, have been criticized for trying to make money on free software. What is your opinion of this?

L: The people who criticize Peter are usually persons who have written none of the kernel, or even user-level code, and I hope Peter (and others) just ignore the monetary issues raised by some. Peter not only has written code for Linux (he worked on the original pty and VC code, which was adapted by me, and he is still making suggestions and patches to the kernel), but the SLS release has been of immense value for the Linux community. SLS has its share of problems (which also get criticized), but there is no question about the fact that it was one of the things that made Linux really available for "Joe User."

The fact that others make money by selling Linux is something that I find mostly amusing, and something which does my ego no end of good. Frankly, I wouldn't want to bother personally, so if somebody else does it, it doesn't hurt me. It's also quite legal by the copyright, and so far I haven't seen any major developer stand up and say he doesn't like his code being sold, so I don't see the problem.

M: There seems to be a perception that Linux is very tied to the '386 architecture and would be very hard to port to others, yet there are apparently projects underway to port Linux to the Amiga and MIPS. What's the real story?

L: The early releases of Linux were indeed very tightly coupled to the '386, both with memory management and process handling. This is still somewhat true, but it has gotten a lot better in later versions. It's still the case that porting is very much non-trivial, but the 68k port is getting along (reportedly running some binaries already), and the first port to a new architecture is always the hardest one. I hope that I'll be able to correct the worst portability issues once I see what the biggest problems for the 68k port were. Currently I'm ignoring all but the grossest portability problems; I don't want to really work on it before I have something to go by.

Of course, porting Linux is never going to be easy as just doing a "make" on the new architecture: the drivers in particular usually have to be re-written mostly from scratch anyway, and memory management is another area that tends to need lots of work when moving from one processor to another. But I no longer think it's doomed to fail_back in the time of Linux 0.12 or so, I felt that porting Linux was essentially impossible.

M: What are your short- and long-term goals for Linux?

L: This is one of those questions I don't have an answer to. I hate to admit it, but Linux development has never had any real well-defined goals. Problems have been solved as they come up, and features have been added when somebody has been interested enough to write the code (and I've felt the result was "worthy").

There are naturally some short-term goals: things people have started on or things I'm not really happy with in the current kernel. The Windows emulator is one of these: it needed additional code to let the kernel handle multiple segment signal handlers etc., but I hope the kernel issues are resolved now. iBCS2 is still being worked on, and the memory management will need a few updates still in the near future. Getting the networking stable is a short-term goal as well _ and has been for a long time.

The long-term goals are just general platitudes like "stability," "POSIX conformance" (which is pretty good already as far as POSIX.1 and POSIX.2 is concerned, but POSIX.4 might be interesting) and "portability"_the kind of words that would make any marketing division proud.

In fact, the main goal of Linux might be called "usability." I want the kernel to remain clean as far as the implementation is concerned, but when it really matters, a kind of pragmatic approach has generally been the main design issue: the most important thing is that it works well and people (which most emphatically includes me) want to use it. As an example, I've always wanted Linux to be POSIX, but that wasn't really as much a goal as a way to make porting user-level software easy. POSIX is just a small part of that_the POSIX standards don't really cover a lot of details that people expect from a Unix system.

M: When can we expect version 1.0 to be released, and what needs to be done to get to that point?

L: You don't expect a serious answer to this one, I hope? Frankly, I've wanted to make a 1.0 for a long time. Every now and then I get mail from Linux "old-timers" that reminisce about the times when Linux was at version 0.12. I said that it's so close to 1.0 that I'll rename it 0.95 (which I did: there never was anything between 0.12 and 0.95).

The main stumbling block right now is the networking. The rest of the kernel is in my opinion stable enough for a 1.0 release (and has been for some time_the rest of the kernel has also gotten better lately, but it's been "good enough" for several months). I still hope to get it out in a few months, but judging by past performance....

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