bob@grebyn.UUCP (04/15/87)
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.
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.
Keyboard handling is also bad, due to arbitrary assumptions and a
too-low-level interface tied to assumed hardware.
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.
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.
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.
- 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-2809go@orstcs.UUCP (04/16/87)
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)
cavender@drivax.UUCP (04/16/87)
In article <288@grebyn.COM> bob@grebyn.COM (Robert A. Baumann) writes: >Well, I've gotten the executable files and had a chance to play. I >am, in a word, disappointed. OK so far. In reading the accompanying textbook "Operating Systems: Design and Implementation" I've learned quite a bit about design considerations and compromises made by AST to keep things simple. Even though I haven't received the disks yet, I know quite a lot about what to expect from the system when it does arrive. I'm looking forward to studying Minix and tinkering with it. I'm not planning on receiving a production multitasking system, with uucp, or X windows, etc. for $80. >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. Hold on. Here comes trouble. There's at least one good reason to bypass the BIOS for everything, and boy is it GOOD. Minix is a multitasking system, while the BIOS is simply polled about most operations. Yes, interrupts are used in a few places, but those interrupts are not communicated to a higher level than the BIOS itself. If you used the BIOS for the keyboard, for instance, the keypresses are buffered up by the BIOS, and you would not be able to interrupt an application any better than you can under MS-DOS, which is a real problem. >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 correct solution here is not "Use the BIOS" but "Write a more correct video driver". It's been done before. There's no mystical power the BIOS has that can't be duplicated in a real device driver for an MT system. ... >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. The same problem with the BIOS applies to loadable device drivers written for MS-DOS. Yes, I know that they have a "strategy" entry point and an "interrupt" entry point, but they still haven't been designed or built for an MT system. >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 ... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ good luck ... >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. OK, fine. > - Bob Baumann >-- >Robert A. Baumann, CCP, CDP {decuac, seismo}!grebyn!bob -- Steve Cavender Digital Research, Inc.|(My opinions. You can't have them.) USENET: cavender@drivax.UUCP |"The size of the FAT for a 128 giga- Telex: 9102406616 TAG SEMI SEA UQ |byte disk is unpleasant to contem- EasyLink: 62211010 |plate." -- Andrew S. Tanenbaum
vizard@dartvax.UUCP (04/17/87)
In article <505100007@orstcs>, go@orstcs.cs.ORST.EDU writes: > 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. .... text deleted > >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. > 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. > 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. O.K. Time for my two-cents... True, for my birthday, I'd like a VAX-785 running 4.3BSD, but it's not going to happen. MINIX is an affordable UN*X alternitive. It is also designed as a teaching aide. I've learned quite a bit about both MINIX and UN*X and op-sys's in general by playing with it. It may not be as great a developement tool as MooSe-DOS, but it's much more enjoyable to use, and I can hack the sources. Cheers for Andy for the learning experience, and for my work/research I'll continue to use the 785 my employer provides. Todd Krein vizard@dartvax
mhorne@tekfdi.UUCP (04/19/87)
[] In a previous article, Bob Baumann (bob@grebyn.COM) writes... >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. Sorry, Bob, but UNIX (or minix) was never meant to live on top of an existing operating system. Have you ever looked at the sources for Sys V or 4.X? They are tied very closely to the hardware because they ARE the operating system for the target system they are on. Come on, Bob, the BIOS was meant for MS-DOS and nothing else. >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. Bob, when you add a new device and/or device driver to an existing UNIX (or clone thereof) kernal, you have to re-make the kernal. Usually this does NOT entail recompiling the whole OS, but rather just compiling the new driver source and the existing object files for the parts of the OS that aren't affected by the new driver. It is a fairly simple process (re-making the OS, not writing the driver!). What you want is a good OS which is as simple minded as MesSDOS but powerful enough to sport things like multi-tasking, multi-user, mind-reading, etc. Sorry, Bob, that time hasn't quite come yet. >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. > > - Bob Baumann >Robert A. Baumann, CCP, CDP {decuac, seismo}!grebyn!bob Translation -- "I want it all, but I am not willing to expend any money/time. I want to be able to plug it in and it works, regardless of what I want it to do." Bob, you are a user. I don't think you have a feel for what is really involved in an OS. You say you have read the book 3 times, but I still don't think you have learned what is really involved, and what minix was meant to be. Hopefully you will be content in your MesSDOS world... - MTH (My opinions, not Tek's) -- --------------------------------------------------------------------------- Michael Horne - KA7AXD UUCP: tektronix!tekfdi!honda!mhorne FDI group, Tektronix, Incorporated ARPA: mhorne@honda.fdi.tek.com Day: (503) 627-1666 HAMNET: ka7axd@k7ifg
tim@sunybcs.UUCP (Timothy Thomas) (04/19/87)
In article <893@tekfdi.TEK.COM> mhorne@honda.fdi.tek.com (Mike Horne) writes: ... >Bob, you are a user. The ultimate insult!!!
djfiander@watmath.UUCP (04/19/87)
In article <893@tekfdi.TEK.COM> mhorne@honda.fdi.tek.com (Mike Horne) writes: >Bob, when you add a new device and/or device driver to an existing UNIX >(or clone thereof) kernal, you have to re-make the kernal. Usually this >does NOT entail recompiling the whole OS, but rather just compiling the >new driver source and the existing object files for the parts of the OS >that aren't affected by the new driver. It is a fairly simple process >(re-making the OS, not writing the driver!). What you want is a good OS >which is as simple minded as MesSDOS but powerful enough to sport things >like multi-tasking, multi-user, mind-reading, etc. Sorry, Bob, that time >hasn't quite come yet. Why does an operating system have to be simple-minded to support dynamically loaded device drivers? I have a friend who owns a tandy CoCo running OS-9, A multi-user, multi-tasking OS running in 64K of physical memory on a Motorola 6809 which supports all the standard Unix System calls. If he wants to read an MSDos diskette he loads a disk driver which understands that format (without having to reboot, let alone relink), sticks in the disk, and reads it. When he is finished, he unloads the driver. This is the way drivers should work as far as I'm concerned. -- "Are you police officers?" "No ma'am, we're musicians." - The Blues Brothers UUCP : {allegra,ihnp4,decvax,utzoo,clyde}!watmath!djfiander CSNET : djfiander%watmath@waterloo.CSNET
stuart@bms-at.UUCP (Stuart D. Gathman) (04/24/87)
In article <12904@watmath.UUCP>, djfiander@watmath.UUCP writes: > to read an MSDos diskette he loads a disk driver which understands that format > (without having to reboot, let alone relink), sticks in the disk, and reads it. > When he is finished, he unloads the driver. This is the way drivers should work > as far as I'm concerned. This is in fact the way it does work in MINIX! Try the dosread and doswrite commands. -- Stuart D. Gathman <..!seismo!dgis!bms-at!stuart>