In article <1992Jan29.231426.20...@klaava.Helsinki.FI> torva...@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
>You use this [being a professor] as an excuse for the limitations of minix?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. In particular, for years it ran on a regular 4.77 MHZ PC
with no hard disk. You could do everything here including modify and recompile
the system. Just for the record, as of about 1 year ago, there were two
versions, one for the PC (360K diskettes) and one for the 286/386 (1.2M).
The PC version was outselling the 286/386 version by 2 to 1. I don't have
figures, but my guess is that the fraction of the 60 million existing PCs that
are 386/486 machines as opposed to 8088/286/680x0 etc is small. Among students
it is even smaller. Making software free, but only for folks with enough money
to buy first class hardware is an interesting concept.
Of course 5 years from now that will be different, but 5 years from now
everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5.
>Re 2: your job is being a professor and researcher: That's one hell of aAmoeba was not designed to run on an 8088 with no hard disk.
>good excuse for some of the brain-damages of minix. I can only hope (and
>assume) that Amoeba doesn't suck like minix does.
>If this was the only criterion for the "goodness" of a kernel, you'd beA multithreaded file system is only a performance hack. When there is only
>right. What you don't mention is that minix doesn't do the micro-kernel
>thing very well, and has problems with real multitasking (in the
>kernel). If I had made an OS that had problems with a multithreading
>filesystem, I wouldn't be so fast to condemn others: in fact, I'd do my
>damndest to make others forget about the fiasco.
one job active, the normal case on a small PC, it buys you nothing and adds
complexity to the code. On machines fast enough to support multiple users,
you probably have enough buffer cache to insure a hit cache hit rate, in
which case multithreading also buys you nothing. It is only a win when there
are multiple processes actually doing real disk I/O. Whether it is worth
making the system more complicated for this case is at least debatable.
I still maintain the point that designing a monolithic kernel in 1991 is
>The fact is that linux is more portable than minix. What? I hear youMINIX was designed before POSIX, and is now being (slowly) POSIXized as
>say. It's true - but not in the sense that ast means: I made linux as
>conformant to standards as I knew how (without having any POSIX standard
>in front of me). Porting things to linux is generally /much/ easier
>than porting them to minix.
everyone who follows this newsgroup knows. Everyone agrees that user-level
standards are a good idea. As an aside, I congratulate you for being able
to write a POSIX-conformant system without having the POSIX standard in front
of you. I find it difficult enough after studying the standard at great length.
My point is that writing a new operating system that is closely tied to any
Prof. Andrew S. Tanenbaum (a...@cs.vu.nl)
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.