Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion LINUX is obsolete
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Linus Benedict Torvalds  
View profile  
 More options Jan 31 1992, 9:26 am
Newsgroups: comp.os.minix
From: torva...@klaava.Helsinki.FI (Linus Benedict Torvalds)
Date: 31 Jan 92 10:33:23 GMT
Local: Fri, Jan 31 1992 5:33 am
Subject: Re: LINUX is obsolete

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
efficiently.

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.

                Linus


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.