Re: LINUX is obsolete
[Prev][Next][Index][Thread]
Re: LINUX is obsolete
In article <1992Feb6.092240.16377@wpi.WPI.EDU> entropy@wintermute.WPI.EDU (Lawrence C. Foard) writes:
>In article <1992Feb3.051258.4153@menudo.uh.edu> kevin@taronga.taronga.com (Kevin Brown) writes:
>>Dr. Tanenbaum claims that the microkernel architecture is the way to go.
>>He has a great deal more experience with operating systems than I have.
>>It's an understatement that it's likely that there's some substance to
>>his statement. :-)
>
>I tend to prefer seeing for myself rather than accepting "expert" opinion.
>Microkernels are nice asthetically, but there are times when practical issues
>must also be considered :)
I agree. This is why I qualified my statement the way I did. :-)
Having seen both monolithic and microkernel architectures running, though,
I tend to agree that microkernels are generally the way to go, all other
things being equal.
But as you say, all things are not always equal. That's when it becomes
a judgement call. Which is better? Depends on what you're trying to do.
>I've been told by people who have used both that Linux is significantly
>faster. There are certainly several factors involved (certainly using 32 bits
>helps alot), but the multithreading also makes for much lower overhead.
Yup. I think that if Minix were arranged so that it had message queueing
and a true multithreaded filesystem, it might be comparable to a monolithic
kernel in terms of speed. It's hard for me to say, though. I haven't
played around much with multithreaded filesystems, so I don't know how
hard it is to make them work efficiently. I'd think, though, that it would
depend enormously on how efficient your device drivers were, and how much
data copying you'd have to do (ideally, you'd pass references to the data
buffers around and do your actual data transfers directly to the user's
buffer).
>>However, as a *multiuser* operating system, i.e. an operating system designed
>>to efficiently meet the needs of multiple users simultaneously while also
>>performing batch operations, Minix is lacking, as far as I'm concerned.
>>The main reason, of course, is the single-threaded file system (hereafter,
>>STFS). Now, Dr. Tanenbaum may feel that a multi-threaded file system
>>(hereafter, MTFS) is merely a performance hack.
>
>I think this is a very valid problem. There are two ways a single threaded FS
>could work and both have substantial problems. If the FS blocks while waiting
>for I/O it would be completely unusable for "real" work. Imagine several users
>accessing a database, if the FS blocks for I/O they will have to wait
>eventhough the data they are looking for is already in the cache. If it is
>designed to be non blocking then it is even more complicated than a
>multithreaded FS and will have more overhead. I hope it is atleast the second
I haven't gone deeply into the source code of the Minix file system, but
the impression I get from my perusing of it is that it blocks on disk I/O
but not on terminal I/O, the idea being that disk I/O requests will almost
always be satisfied relatively soon after they are made, whereas terminal
I/O requests can take an indefinite amount of time to satisfy.
But it seems to me that if you're going to implement the mechanism to handle
I/O where the file system doesn't block waiting for it, why not use that
mechanism universally???
>>However much Minix may be lacking from my standpoint, it is nevertheless
>>a very useful and welcome enhancement to my system. In spite of the
>>impression that I may have given everyone in my last posting, there will
>>always be a soft spot in my heart for it, if only because it's the first
>>decent operating system I've had on my system that I've had source to.
>>I don't have to tell you people how incredibly useful it is to have source.
>>You already know.
>
>I will agree here, Minix is infinitly better than Messy-Loss :)
Which is why I try to avoid using MS-DOS whenever possible. I'll bet a
lot of us Minixers do the same. :-)
>>Given the reasons Linus wrote Linux, I think it's hard for anyone to fault
>>him for writing it the way he did. And he was extremely nice in making
>>his code freely available to the rest of the world. It's not something he
>>had to do. In my book, that makes him almost beyond reproach.
>
>I think more effort has been put into making practical use of Linux possible.
>An educational OS is nice, but there is a world outside of colleges that
>is suffering from the lack of cheap and useful OS's, I've been stuck doing
>most consulting work in Messy Loss because customers don't want to fork out
>$1000 for UNIX.
Even students can make good use of something like Linux. I have 8 megabytes
of RAM on my machine, and 410 meg of harddrive space. Yet I can barely
run SBProlog on my system, even though my system is considerably more macho
than most. If I had demand paging on my system, this wouldn't be a problem,
but the only patches I have for demand paging seem not to work very well.
Once Linux becomes more stable (and gets support for Seagate ST-02 SCSI),
I'll snag the sources and check it out. Since I already own Minix, I can
legally transport *everything* over to it, and since both share the same
filesystem layout, I can do the transporting with a minimum of hassle.
>>Dr. Tanenbaum didn't make Minix free. His goals were different. Minix
>>is a teaching aid above all else (unless Dr. Tanenbaum has changed his
>>views about Minix :-). That means that he must be concerned with the
>>most efficient way to get Minix to the student population. At the time
>>Minix was released, Prentice-Hall was a good solution, and has been for
>>some time. However, I must wonder whether or not this is still the case.
>>Dr. Tanenbaum: do you still feel that free distribution of Minix via the
>>net is not the best way to distribute Minix?
>
>I would guess that Prentice-Hall would have some objections :)
No doubt. :-(
--
Kevin Brown Disclaimer: huh?
kevin@taronga.com kevin@nuchat.sccsi.com