Slashdot Mirror
Linus on Linux in 1994
Vrallis writes "Ten years ago this month, Linux Journal christened their maiden issue with an interview with Linus Torvalds. It is definitely worth the read, and worth some reflection on just how far Linux has come in the last decade."
Linus (rhymes with shyness) Torvalds (author of the Linux kernel, see box) traded e-mails with us for several days in January giving us his views on the future direction of Linux (rhymes with clinics) and his ongoing role in its development.
Linux Journal: Ken Thompson was once asked, if he had the chance to do it all again, what changes would he make in Unix. He said he would add an e to the creat system call.
How about you and Linux?
Linus: Well, Considering how well it has turned out, I really can't say something went wrong: I have done a few design mistakes, and most often those have required re-writing code (sometimes only a bit, sometimes large chunks) to correct for them, but that can't be avoided when you don't really know all the problems
If it's something I have problems with, it's usually the interface between user-level programs and the kernel: kernel-kernel relations I can fix easily in one place, but when I notice that the design of a system call is bad, changing that is rather harder, and mostly involves adding a new system call which has semantics that are the superset of the old and then leaving in a compatibility-hack so that the old calls still work. Ugly, and I avoid it unless it really has to be done.
Right now I'd actually prefer to change the semantics of the and write() system calls subtly, but the gains aren't really worth the trouble.
Linux Journal: The most consistent compliment that Linux receives is its stability on Intel PC computers. This is particularly true compared to ``real Unices'' that have been ported to the Intel platform.
What do you see that was done right in Linux that is causing problems for these other PC Unices?
Linus: There are probably a couple of reasons. One is simply the design, which is rather simple, and naturally suits the PC architecture rather well. That makes many things easier. I'd suspect that the other reason is due to rather stable drivers: PC hardware is truly horrendous in that there are lots of different manufacturers, and not all of them do things the same (or even according to specs).
That results in major problems for anybody who needs to write a driver that works on different systems, but in the case of linux this is at least partially solved by reasonably direct access to a large number of different machines. The development cycle of linux helps find these hardware problems: with many small incremental releases, it's much easier to find out exactly what piece of code breaks/fixes some hardware. Other distributions (commercial or the BSD 386-project which uses a different release schedule) have more problems in finding out why something doesn't work on a few machines even though it seems to work on all the others.
Linux Journal: Have you heard of any problems running Linux on the Pentium chip? Do you expect any?
Linus: I know from a number of reports that it works, and that the boot-up detection routines even identify the chip as a Pentium ("uname -a" will give "i586" with reasonably new kls, as I ignore Intel guidelines about the name). The problems are not likely to occur due to the actual processor itself, as much as with the surrounding hardware: with a Pentium chip, manufacturers are much more likely to use more exotic hardware controllers for better performance, and the drivers for them all won't necessarily exist for linux yet. So I've had a few reports of a Pentium PCI machine working fine, but that the kernel then doesn't recognize the SCSI hard disk, for example.
From a performance viewpoint, the current gcc compiler isn't able to do Pentium-specific optimizations, so sadly linux won't be able to take full advantage of the processor right now. I don't know when gcc will have Pentium-optimization support, but I expect it will come eventually (most of the logic for it should already be there, as gcc can already handle similar optimization problems for other complex processors).
One interesting thing is that the "bogo-mips" loop I use to calibrat
It's quite amusing to consider how far Linus' operating system has come, how big it has become - to the point of challenging the multi-billion dollar corporations - when you think that at the start, Linus himself had said Linux wouldn't "be big and professional like gnu". Or to quote the original USENET post:
Heh."Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect" -- Linus Torval
Posted on Tuesday, March 01, 1994 by LJ Staff
Linus (rhymes with shyness) Torvalds (author of the Linux kernel, see box) traded e-mails with us for several days in January giving us his views on the future direction of Linux (rhymes with clinics) and his ongoing role in its development.
Linux Journal: Ken Thompson was once asked, if he had the chance to do it all again, what changes would he make in Unix. He said he would add an e to the creat system call.
How about you and Linux?
Linus: Well, Considering how well it has turned out, I really can't say something went wrong: I have done a few design mistakes, and most often those have required re-writing code (sometimes only a bit, sometimes large chunks) to correct for them, but that can't be avoided when you don't really know all the problems
If it's something I have problems with, it's usually the interface between user-level programs and the kernel: kernel-kernel relations I can fix easily in one place, but when I notice that the design of a system call is bad, changing that is rather harder, and mostly involves adding a new system call which has semantics that are the superset of the old and then leaving in a compatibility-hack so that the old calls still work. Ugly, and I avoid it unless it really has to be done.
Right now I'd actually prefer to change the semantics of the and write() system calls subtly, but the gains aren't really worth the trouble.
Linux Journal: The most consistent compliment that Linux receives is its stability on Intel PC computers. This is particularly true compared to ``real Unices'' that have been ported to the Intel platform.
What do you see that was done right in Linux that is causing problems for these other PC Unices?
Linus: There are probably a couple of reasons. One is simply the design, which is rather simple, and naturally suits the PC architecture rather well. That makes many things easier. I'd suspect that the other reason is due to rather stable drivers: PC hardware is truly horrendous in that there are lots of different manufacturers, and not all of them do things the same (or even according to specs).
That results in major problems for anybody who needs to write a driver that works on different systems, but in the case of linux this is at least partially solved by reasonably direct access to a large number of different machines. The development cycle of linux helps find these hardware problems: with many small incremental releases, it's much easier to find out exactly what piece of code breaks/fixes some hardware. Other distributions (commercial or the BSD 386-project which uses a different release schedule) have more problems in finding out why something doesn't work on a few machines even though it seems to work on all the others.
Linux Journal: Have you heard of any problems running Linux on the Pentium chip? Do you expect any?
Linus: I know from a number of reports that it works, and that the boot-up detection routines even identify the chip as a Pentium ("uname -a" will give "i586" with reasonably new kls, as I ignore Intel guidelines about the name). The problems are not likely to occur due to the actual processor itself, as much as with the surrounding hardware: with a Pentium chip, manufacturers are much more likely to use more exotic hardware controllers for better performance, and the drivers for them all won't necessarily exist for linux yet. So I've had a few reports of a Pentium PCI machine working fine, but that the kernel then doesn't recognize the SCSI hard disk, for example.
From a performance viewpoint, the current gcc compiler isn't able to do Pentium-specific optimizations, so sadly linux won't be able to take full advantage of the processor right now. I don't know when gcc will have Pentium-optimi
In times like these, it is helpful to remember that there have always been times like these. - Paul Harvey
Excuse me, linux was more unix like. I remember when I switched from slackware to redhat back in the 5.2 days. This was back when the new gnome libs were just coming out and I had no idea it would be where it is today. Many of the tools back then were direct rip-offs of common UNIX tools. It's good to see Linux making it's own path these days and I hope it continues. We need to be the leader, not following one.
www.slashrank.org
FreeBSD celebrated its 10th anniversary this past november .
Don't include NT/2K in the microkernel club. NT might have started that way, but the bloat code in Redmond made Cutler change his mind pretty quick.
None of those are really Microkernel's in the true sense though, they're pretty close to linux. The difference is that linux has a big kernel that has a lot of stuff built in and can dynamically load drivers, whereas OSX/XP have big kernels with a lot of stuff build in and can dynamically load drivers.
Wait, that's the same thing...
OSX specifically was based on mach, but it's really a mach microkernel with a bunch of stuff rolled into kernel space to make it faster, thus not a true mach microkernel.
That would be because Linux IS just the kernel. Everything that runs on top of it GNU.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
You may have already found this, but the article is also in the Linux Journal Archive, here: http://www.iar.unlp.edu.ar/~fede/revistas/lj/Magaz ines/LJ1/2736.html
philcrissman.com.
that quote isn't in there
> Since then Linux has traveled around the sun ten :P
;)
> times but its still in the same old place.
OT, but Linux (and Linus) has travelled nearly seventy billion kilometers in the last ten years, courtesy of Sol's orbit around the galaxy.
--
-JC
coder
http://www.jc-news.com/parse.cgi?coding/main
VMS and NT kernel should not be compared like this. they might be similar in design and such, but VMS is ROCK SOLID. when a production machine would very rarely go down running VMS, the DEC engineers would be onsite shortly to provide a full report. and of course, since it was one of a cluster of machines, the others would pick up the slack.
NT kernel might have evolved its stability over the years, but certainly you cannot compare the stability of VMS to that of an NT kernel.
Yeah, who would want to use an OS with source code that was laced with profanity?
you're all figments of my deranged imagination
In 1994, UnixWare was a Novell product. SCO OpenServer was the high water mark for x86 UNIX at the time.
Actually, in some 3D design niches (the really high-end) Linux is better than Windows. That's why a lot of movie studios (eg. ILM) are using it.
A deep unwavering belief is a sure sign you're missing something...