Re: Minix VS Linux
[Prev][Next][Index][Thread]
Re: Minix VS Linux
In article <1992Feb03.141611.6995@crash.cts.com> cwr@pnet01.cts.com (Will Rose) writes:
>
>kevin@taronga.taronga.com (Kevin Brown) writes:
>
>>It has been brought to my attention that my last posting was exceedingly
>>harsh. Having reread it, I'm inclined to agree.
>
>Didn't seem so to me - or is everyone else getting much more tactful in
>the 'kinder, gentler' 1990s?
Guess it depends on whether or not you agree with what I had to say. ;-)
Some people read other people's postings with an implied "IMHO". Others
don't. Those that don't will probably think of that posting as exceedingly
harsh. Since I try to be as explicit as possible, I would say I didn't
put enough "IMHO"s in.
>>Despite that, Minix is quite usable in many ways as a personal operating
>>system, i.e. one where there is usually only one person logged into the
>>system.
>... lines omitted
>>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).
>
>In fact, Minix has noticeable problems even as a *single-user* system; such
>a user is likely to be developing code in an 'edit - compile - test' cycle,
>and on a multitasking machine compilation can conveniently take place in
>the background using multiple processes. Given the small amount of memory
>on the early Minix machines, it probably wasn't practical to edit in the
>foreground during a compile; but a low-end XT such as mine can now put the
>ram-disk in expanded memory and have 500KB free after the OS is loaded.
>However, editing during a compile is still totally impractical; the standard
>1.5 scheduler can't cope, and keyboard response time is both long (seconds)
>and variable. The fix is simple, use Kai-Uwe Bloem's (spelling ?) patch.
>KuB's scheduler algorithm isn't the last word in sophistication, and the code
>change is a small one, yet it is extremely effective. I don't understand
>why the original scheduler lasted so long.
I agree wholeheartedly. In fact, Bruce Evans sent me a very simple patch
that gives an I/O bound process like an editor effectively infinite
priority: it causes the process that's being readied (in the ready()
routine in proc.c) to be added to the beginning of the process queue
instead of the end. This fixes the problem for sure, but it causes
CPU bound processes to suffer rather badly in the face of I/O bound
processes.
>Broadly speaking, when porting programs to Minix, or writing them from
>scratch, the main problems are not details of kernel implementation but things
>that are simply missing, such as non-blocking reads or SIGHUP.
I've had the SIGHUP problem solved on my system for some time, but I've
got weird problems with the signal handling as relates to process groups
and signalling a parent process in a process group before signalling the
child. Causes very strange things to happen (like the FS to restart!
You get the message "executing in protected mode" as a result of killing
a parent process before killing the child process). This is the primary
reason I don't have UUCP going on my system already. I don't trust it
enough to handle a UUCP connection going away (dropping carrier) in the
middle of a transfer.
>If a program
>is to be used on the majority of Minix systems, then it must be written for
>the lowest common denominator ie: the standard current release, and this has
>significant limitations. Only after these are overcome does the lack of
>memory space, or lack of filesystem performance, become important. (It
>is quite possible that many of these problems will be fixed in 1.6, but
>that still lies in the future. By the time it arrives, the goalposts will
>have moved again... )
What he said. :-)
>>Someone, either here on this newsgroup or over on alt.os.linux, made a
>>very valid observation: the cost of a 16 MHz 386SX system is about $140
>>more than a comparably equipped (in terms of RAM size, display technology,
>>hard drive space, etc.) 8088 system. Minix is $169. In economic terms,
>>Linux wins if you have to buy Minix.
>
>This may have been drawn from a comment of mine, concerning the recent
>replacement of a dead 286 motherboard with a 386SX; it was part of an
>example of just how fast hardware prices are falling. The *board* price
>was $140, ie: $90 more than an XT board. Memory is about the same price
>for both boards, but obviously the system price for the 386 will tend to be
>higher with the use of faster, larger disk drives, more memory, and so on.
Right. The only time the architecture bites you is when your applications
are larger as a result of using a 32-bit memory model, though. So while
you tend to use faster and larger disk drives, more memory, etc. for the
386, that's because you *can* more than anything else. The architecture
supports it. I figure the larger and faster hard drives come as a result
of having more memory to stuff programs into. :-)
If the price difference is only $90, then the 386SX *definitely* wins. For
the $80 I save in buying a 386SX and getting Linux, I can get another 50
meg of hard drive space, or perhaps even more, depending on where on the
price/capacity curve I am.
>In the last year PH has started marketing Minix as a small general-purpose/
>training Unix, but if Minix 2.0 isn't released for another year, I think it
>will become strictly an adjunct to a successful textbook. It won't run
>enough of the then-available PD code to be useful for anything else, since
>such code will mostly require gcc and megabytes of memory, implying at least
>a 386. (I'm assuming that the cheapest hardware will still be Intel/ISA bus).
I don't know. While I agree that many of the applications will be too
large, there's something to be said for small, efficient programs, and
something to be said against large, baroque programs. Having lots of
features isn't necessarily a good thing, despite what the marketers
might tell you.
>Linux seems well-placed to pick up on this wave; whether it will also make
>inroads into academe via easy FTP availability (a version of 'OS Design and
>Implementation' without Minix is coincidentally in hand) remains to be seen.
Maybe we can get Linus to write a book on operating systems. :-) :-)
>Will Rose
>cwr@pnet01.cts.com
Kevin Brown