Message from discussion LINUX is obsolete
From: torva...@klaava.Helsinki.FI (Linus Benedict Torvalds)
Subject: Re: LINUX is obsolete
Date: 31 Jan 92 10:33:23 GMT
References: <firstname.lastname@example.org> <1992Jan29.231426.20469@klaava.Helsinki.FI> <email@example.com>
Organization: University of Helsinki
In article <12...@star.cs.vu.nl> a...@cs.vu.nl (Andy Tanenbaum) writes:
>The limitations of MINIX relate at least partly to my being a professor:
>An explicit design goal was to make it run on cheap hardware so students
>could afford it.
All right: a real technical point, and one that made some of my comments
inexcusable. But at the same time you shoot yourself in the foot a bit:
now you admit that some of the errors of minix were that it was too
portable: including machines that weren't really designed to run unix.
That assumption lead to the fact that minix now cannot easily be
extended to have things like paging, even for machines that would
support it. Yes, minix is portable, but you can rewrite that as
"doesn't use any features", and still be right.
>A multithreaded file system is only a performance hack.
Not true. It's a performance hack /on a microkernel/, but it's an
automatic feature when you write a monolithic kernel - one area where
microkernels don't work too well (as I pointed out in my personal mail
to ast). When writing a unix the "obsolete" way, you automatically get
a multithreaded kernel: every process does it's own job, and you don't
have to make ugly things like message queues to make it work
Besides, there are people who would consider "only a performance hack"
vital: unless you have a cray-3, I'd guess everybody gets tired of
waiting on the computer all the time. I know I did with minix (and yes,
I do with linux too, but it's /much/ better).
>I still maintain the point that designing a monolithic kernel in 1991 is
>a fundamental error. Be thankful you are not my student. You would not
>get a high grade for such a design :-)
Well, I probably won't get too good grades even without you: I had an
argument (completely unrelated - not even pertaining to OS's) with the
person here at the university that teaches OS design. I wonder when
I'll learn :)
>My point is that writing a new operating system that is closely tied to any
>particular piece of hardware, especially a weird one like the Intel line,
>is basically wrong.
But /my/ point is that the operating system /isn't/ tied to any
processor line: UNIX runs on most real processors in existence. Yes,
the /implementation/ is hardware-specific, but there's a HUGE
difference. You mention OS/360 and MS-DOG as examples of bad designs
as they were hardware-dependent, and I agree. But there's a big
difference between these and linux: linux API is portable (not due to my
clever design, but due to the fact that I decided to go for a fairly-
well-thought-out and tested OS: unix.)
If you write programs for linux today, you shouldn't have too many
surprises when you just recompile them for Hurd in the 21st century. As
has been noted (not only by me), the linux kernel is a miniscule part of
a complete system: Full sources for linux currently runs to about 200kB
compressed - full sources to a somewhat complete developement system is
at least 10MB compressed (and easily much, much more). And all of that
source is portable, except for this tiny kernel that you can (provably:
I did it) re-write totally from scratch in less than a year without
having /any/ prior knowledge.
In fact the /whole/ linux kernel is much smaller than the 386-dependent
things in mach: i386.tar.Z for the current version of mach is well over
800kB compressed (823391 bytes according to nic.funet.fi). Admittedly,
mach is "somewhat" bigger and has more features, but that should still
tell you something.