Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!sugar!peter From: peter@sugar.hackercorp.com (Peter da Silva) Newsgroups: comp.sys.amiga.tech Subject: Re: Minix, Unix on the Amiga, and flames on AmigaDOS braindamage... Message-ID: <4084@sugar.hackercorp.com> Date: 5 Aug 89 13:21:11 GMT References: <1610@uw-entropy.ms.washington.edu> <195@VAX1.CC.UAKRON.EDU> <26900@agate.BERKELEY.EDU> Organization: Sugar Land Unix - Houston Lines: 122 In article <26900@agate.BERKELEY.EDU>, mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: > You obviously haven't tried adminstering a Unix machine. The entire > system is much more fragile than AmigaDOS. I guess that depends on whether you're administering a relatively clean commercial UNIX, like System V or Xenix, or a fancied-up PD-quality system, like BSD. I've been doing some really horrible things to various 68000- and 80386-based System-V systems, as well as the 80286-based Xenix boxes that are the main development machines, and the biggest problem's I've had have been with various third-party device drivers. Even having the source to them hasn't helped much. > Minix may be a vast improvement on Unix (i.e. - almost tolerable), > though. I haven't tried to run such a system. Minix has a long way to go. > Why should you laugh? Are you really that unschooled in OS design? Because unlike you he understands that AmigaDOS is the name of the Tripos derived file system. The rest of the system, the Exec, drivers, etc..., are together called AmigaOS. > Unix also chose the wrong basic object for IO operations, the file. The claim can be made, and in fact has been made, that so long as you choose a single object and stick to it it will work just fine. > AmigaDOS (among other OSs) got it right, and chose tasks for basic IO > objects. If you don't think this is right, I'll write a task that uses > a disk and acts like a file. You write a file that acts like a task > (using whatever hardware you need). Actually, every part of AmigaOS *except* AmigaDOS uses tasks as the basic object. AmigaDOS uses a task interface, but the basic object is the lock or file handle. Mixing models like this is a bad idea, and the main reason people get frustrated with AmigaDOS. > AmigaDOS doesn't > have a way to force processes into seperate address spaces, but that's > not something you have to code around. Rubbish. Every AmigaOS program has to have a substantial amount of code devoted to resource tracking... a job better assigned to the O/S. If you don't want to call that "coding around" the problems, then you're just playing games with words. > Comapred to what Unix does to do DOS calls? Yes, it is. But in UNIX the program doesn't have to *know* what goes on inside the kernel. You have to dig around in internal AmigaDOS data structures to do all sorts of vitally important things... like getting a list of devices, an operation that comes for free with UNIX. > <(and more elegant!) than Unix's pipe() system call? > You haven't looked inside of a modern pipe() system call, have you? Who cares what's inside. UNIX isolates the programmer from that junk. AmigaDOS forces the programmer to be aware of it. > Elegant is hardly the word. Of course, if you just want a "here's a > pair of fd's" type interface, that's not hard to build on top of > PIPE:. If you want it transparent to the programs being piped, it sure is. The only decent implementation of *that* is Bill Hawes' PIP device, which uses a non-standard call to get a pair of file handles that really do work like UNIX pipes. It's a botch. > You wanna try and do the opposite? I'd like to know how you're > going to escape pipe()'s need for communicating processes to have a > cooperating common ancester. Look at modern UNIX, Mike. "mknod p /pdev/mypipe". > What about them? The versions in my Amiga library are slightly > different than the ones on Unix, but not enough to cause any problems. Unless you want to port reasonably sophisticated UNIX software, such as ASH. > Sorry, but that's not quite true. That AmigaDOS could be quickly > integrated into the Exec message-passing is to it's credit. You just > flat couldn't do that with Unix. What part of UNIX? The only part that matters is the program interface. What's on the other side varies widely. Compare and contrast Mach (the basic object is an address space) or Minix (tasks and message ports) to conventional UNIX (co-routines) or Eunice (emulation on top of VMS). They're all UNIX as far as the program's concerned. > So, where do you buy a v7 system? Prentice-hall. It's called Minix 1.3. > Oh, BTW, did you know that the v7 > kernel is much larger & slower than v6, and only added one new kernel > facility? Which one are you talking about? Environment variables? The relatively more robust file system? Process accounting? The improved terminal driver? Long offsets to seek (lseek)? Multiplexed files (removed in 2BSD, returned within the streams system for SysV, or as ptys in 4BSD)? Improved fstat()? Umask()? Did you ever actually use V6? Are you aware that V6 was much bigger than V5, which still had substantial amounts of assembly code? -- Peter "Have you hugged your wolf today" da Silva `-_-' ...texbell!sugar!peter, or peter@sugar.hackercorp.com 'U`