🚀 go-pugleaf

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.

> <AmigaDOS?  More elegant than Unix?  Don't make me laugh.

> 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.

> <Logical volumes are among the few _good_ things about AmigaDOS.  Take
> <a gander at dos.library sometime, however.  Elegant?  Ha.

> 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.

> <Oh?  So you're saying the brilliant PIPE: AmigaDOS device is better
> <(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".

> <How about fork() and exec()?

> 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`