Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!amix!ford
From: ford@amix.commodore.com (Mike "Ford" Ditto)
Newsgroups: comp.unix.amiga
Subject: Re: Amiga Unix and A3000UX announcement
Message-ID: <1041@amix.commodore.com>
Date: 10 Feb 91 23:59:20 GMT
References: <2022@cluster.cs.su.oz.au>
Organization: Commodore-Amiga Unix Development
Lines: 28

bruce@cs.su.oz (Bruce Janson) writes:
> >(Note that this is, of course, done with extra libraries for BSD
> >compatibility and a "/usr/ucb" directory for those commands that differ,
[ ... ]
> Yes, it works nicely but I prefer the way MIPS does it, e.g. /bsd43 is
> an alternate hierarchy that gets you access to their (MIPS') 4.3bsd 
[ ... ]

Funny, I really like the SVR4 scheme for BSD support; I think it's
done The Right Way.  Rather than adding a jillion new BSD system
calls, or an entire "BSD execution environment", they made new system
calls that are general enough to support posix, BSD, old SYSV and the
new SYSV stuff.  Then you just use whichever library (and associated
include files) that provide the interface your code needs.

There is one drawback, and that's when looking at truss(1) output.
"Hmm, my source code called `signal', why is the program calling
`sigprocsyssetmaskvec'?"  (imaginary exagerated example)

AT&T did do some stupid things in the SVR4 system interface, but the
BSD compatibility design isn't one of them, IMHO.

					-=] Ford [=-

"The number of Unix installations	(In Real Life:  Mike Ditto)
has grown to 10, with more expected."	ford@amix.commodore.com
- The Unix Programmer's Manual,		uunet!cbmvax!ditto
  2nd Edition, June, 1972.		ford@kenobi.commodore.com