Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!oxtrap!mudos!mju From: mju@mudos.ann-arbor.mi.us (Marc Unangst) Newsgroups: comp.os.minix Subject: Re: dosread.c again Message-ID: <695.254152F7@mudos.ann-arbor.mi.us> Date: 22 Oct 89 05:34:35 GMT Organization: FidoNet node 1:120/129 - Starship Enterprise, Ann Arbor MI Lines: 98 In article <3767@ast.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: >In article <1989Oct21.013342.2168@ccu.umanitoba.ca> chan@eeserv.ee.umanitoba.ca (Andrew Chan) writes: >>I wish Minix could be more powerful as a multi-user system. >I am curious about what this means. Is MINIX slower than XENIX (probably)? >Has fewer features (Thank Goodness)? What is it that it lacks? This is a >purely academic question, since sight unseen I am against the answer :-(. I'm not Andrew Chan, but I can tell you the things MINIX lacks that it should have: * Full support for "large model" programs. I realize this would be difficult to add, but there are a lot of "real programs" out there that would be difficult or impossible to support because they have more than 64K of code. Rn, for example, or nethack, or Elm. * Some sort of virtual memory. I don't really care if this is demand-paging or swapping or whatever (and don't know enough to choose which one would be best), and I realize that this, too, would be difficult to impliment (especially if you also impliment large-model programs), but it's really needed. I have a 640K system, and it's silly to run out of memory when all you have running is cron(1) and cc(1). * A real shell. I've often had to pull apart shell archives by hand, because the MINIX shell chokes on them. In particular, I think the 'Configure' script included with most Larry Wall software makes MINIX puke because MINIX doesn't properly impliment the 'eval' command. * A version of UUCP. GNUUCP probably wouldn't be hard to port (it's written with portability in mind), but you might run into the 64K wall. * A real version of mail(1). Actually, I'm not even sure if MINIX comes with *any* version of mail(1), since I haven't gotten 1.4a running yet. If it doesn't, this is a major flaw. * Ability to put / somewhere other than a ramdisk. I have a hard disk, and I suspect many other "serious" MINIX users do also. Putting the root filesystem in RAM seriously handicaps users who have hard disks, users who would be happy to give up 400K or so of disk space in order to free up that RAM; 270K is over one third of the PC's total accessable memory. I don't think we'll suffer a large speed hit if MINIX has to go to a hard disk to read stuff from /bin or whatever, and I *know* I'd rather have the RAM than the speed. Users who are running floppy-only could always enable the ramdisk through a compile-time option or by booting off a different boot disk. This would also prevent the mistakes that happen when you update a file on the root filesystem (in RAM) but forget to update the root disk, thus losing the changes when you re-boot. * Ability to boot off the hard disk. This follows directly from the previous statement; IMHO, the only things floppies should be used for are backups and transferring files between systems. If you can store the root filesystem on the hard disk, you ought to be able to boot from it. "Protection against the hard disk getting trashed" is a poor excuse; you can always haul out the floppy if something goes seriously wrong, and then just mount /dev/hd1 or whatever. * "Real" job control. I'm not sure what this is, but I *do* know that I sorely miss the ability to suspend jobs, move them from the foreground to the background and back again, etc. that I have on my Sun-3. * The ability to format floppies from within MINIX. As I understand it, right now the only reason to keep DOS around is because you have to format floppies with it before you can use them with MINIX. This is silly; an OS should be self-sufficient. Plus, it will mean (with the addition of the above suggestion, job control) that if you run out of floppies in the middle of a backup, you can just suspend the job, format some more, and pick up where you left off. You won't have to quit, start up DOS, format some more, and then restart both MINIX and the backup. * The addition of "real" backup software. Does MINIX 1.4a have dump and restor? If not, why? If so, you can ignore this point... I think the problem with the 64K code-size limit (which you have, even if you use the split I&D asld) is what hampers most program development. I'm all for the "small is beautiful" way of life, but there are just some things that *cannot* be expressed in only 64K. I think we'll all agree that Nethack is a great game (I certainly think so, and its popularity speaks for itself), but the thing is much too big to port to MINIX. (It's probably much too big to be running on an 8088 pseudo-Unix machine, anyhow, but that's just an example.) I'll be the first to admit that most of these changes won't be easy, especially adding job control (which Andy has said would require major changes to most of the OS). I'll also be the first to admit that I probably couldn't do any of them, and am really in awe of the OS that we have all created. However, it can be made even better...With the addition of these changes (or at least most of them), I might consider eliminating DOS entirely from my machine. -- Marc Unangst Internet: mju@mudos.ann-arbor.mi.us UUCP : ...!uunet!sharkey!mudos!mju Fidonet : Marc Unangst of 1:120/129.0 BBS : The Starship Enterprise, 1200/2400 bps, +1 313-665-2832