Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ucbcad!ucbvax!decvax!decwrl!hplabs!hp-pcd!orstcs!go From: go@orstcs.UUCP Newsgroups: comp.os.minix Subject: Re: First Impressions of Minix Message-ID: <505100007@orstcs> Date: Thu, 16-Apr-87 01:17:00 EST Article-I.D.: orstcs.505100007 Posted: Thu Apr 16 01:17:00 1987 Date-Received: Sat, 18-Apr-87 04:32:56 EST References: <288@grebyn.COM> Lines: 118 Nf-ID: #R:grebyn.COM:-28800:orstcs:505100007:000:5570 Nf-From: orstcs.cs.ORST.EDU!go Apr 15 22:17:00 1987 In response bob@grebyn.com: >/* ---------- "First Impressions of Minix" ---------- */ >Well, I've gotten the executable files and had a chance to play. I >am, in a word, disappointed. > >The basic problem is that the thing is too closely tied to the >hardware. There's no good reason to bypass the BIOS for everything. Yes there is!! If you want a multitasking system to work correctly, you need drivers that support multiple threads. All DOS drivers are simple-minded. For example, the only form of low-level call to a disk driver, loops waiting for the disk interrupt. It's surprising they even *used* an interrupt the way MS/PC-DOS is structured, but that's the way it is. This mess MUST change when Microsoft/etc. finally come out with multi-user/tasking systems, but for now, the "DOS" model is what we have -- device calls don't return until done. I thought Tanenbaum was quite specific on that point. >Specifically, MINIX goes straight to the screen. This is fine, when >you do it right. But MINIX doesn't, so MONO and EGA screens get >garbaged in odd ways. The right way is to call the BIOS to set modes, >set cursor scan start and end, etc, and then and only then - when you >know exactly what adapter you're dealing with - write directly to the >screen memory after checking for vert or horiz scan. I'll grant you two-points on this one. However, the DOS method of communicating to the character mode devices is still rather primative -- it uses software to scroll things rather than the hardware that is on-board. Unfortunately, the only "standard" model is to use the first nk as character+attributes and you scroll it yourself. Minix tries hard to be more efficient here, relying upon the "definition" that IBM developed, but was "improved" by numerous other vendors of display controllers. Hence, incompatibility. > >Keyboard handling is also bad, due to arbitrary assumptions and a >too-low-level interface tied to assumed hardware. I's a simple driver. The ATT Un*x world suffered this stupid don't-know-how-to-erase-tabs model for a long time (until the last few years). Besides, the "too-low-level" interface is the driver. Replace the driver for another system, and you will make it work. But (again) Tanenbaum tells why Minix cannot use BIOS. >After reading the book three times, I have formed the opinion that >Tanenbaum knows less about DOS than he will admit. He is just plain >wrong about many things (like his statement that DOS does a physical >write of a disk block whenever you add even 1 char to it), and >academically snobby / vague about others. > >Due to this low-level implementation, you can't use any of the >thousands of DOS device drivers (like for my Bernoulli box, my custom >clock chip, etc). I'm not impressed by a so-called operating system >that has to be recompiled to move from my XT to my XT + Bernoulli >system. My original comment still stands. The forefathers of MS/PC-DOS did not develop a model that encouraged driver development for Un*x/Minix type systems. In the MS_DOS world, the "driver" is nearly always *on* the circuit board for that device (I'm speaking of disk drivers here.) Other drivers are loadable, but the "system" device driver has to be there at boot time. Consequently, we're stuck with basically polling-type interfaces. So, someone develop loadable device drivers! Minix comes a darn sight closer to making that possible (with drivers as separate processes). That should be "easy" compared to a "real" Un*x system. (By the way, when you bought your Bernoulli, did you buy one that allows booting or simply running? You see, even with DOS it's not enough to simply have a "driver".) >What to do? I have scoped the effort needed to convert MINIX to >something useful viv-a-vis the rest of the PC world. This includes >supporting DOS device drivers first and foremost, and handling the >screen right so my EGA doesn't spend half it's life blanked out, and >supporting ASYNC ports, etc. Add all of this up and you're talking an >awful lot of work. > >Is it worth doing? I don't think so. What do I gain once I've fixed >it up? A minimal UNIX, with more overhead than useful features. I agree. I don't think it's wise to base something like Minix (or Un*x) on such a stupid architectur. We can only hope that the developers see the light on the next generation (i.e. 386) machines. There destined to become another "standard" so let them do it right. I also agree about Minix vs. DOS. I use DOS all day at work for "real" software development. But when I come home, I rejoice for having a real operating system to play with. I haven't had this much fun in years. > >Weigh the plusses against the minuses, and in my opinion it's not >worth spending any more hours on MINIX. It's neat as a teaching tool >(if you take lots of the DOS stuff with a grain of salt), but I've got >real work to do. I'll stick with DOS. The one "MAJOR MAJOR" thing Minix has over Dos (in my opinion) is that it shows a significant effort went into "DESIGN". A word I think too many software developers don't know how to spell. > > - Bob Baumann >-- >Robert A. Baumann, CCP, CDP {decuac, seismo}!grebyn!bob >Computerwise Consulting Services bob@grebyn.com >P. O. Box 813 bob%grebyn.com@seismo.css.gov >McLean, VA 22101 (703)-280-2809 Sorry for the tirade, but I REALLY appreciate what Andy and his "crew" have done. I felt that one sour note should be countered by a more upbeat one. Gary Oliver, CCP ...!hplabs!hp-pcd!orstcs!go (until they pull my plug)