[comp.sys.amiga] UN*X

richard@gryphon.UUCP (06/11/87)

This is being cross posted to both groups, because a similar discussion
is going on in both. For the benefit of Amigoids, AEGIS refers to the Apollo
OS, not Bill Volk et. al..

Re: UN*X as a replacement OS.

UN*X has a bunch of womderful features, and I don't mean to denegrate it.
At the time it was written, it extracted every whit of performence out of
the machine of the day, a PDP 11/45. Now we have new machines, that we 
couldn't even of dreamed of at the time. While UN*X may be a great place
to start, does it still make sense to view it as the end all in operating
systems ?

Granted, there are many reasons to support a *true* UN*X shell. Primarily
this makes administration of heterogeneous networks simpler, and the
portability aspect os nice. But I dont think this means REQUIRING that
/dev/kmem be supported; if you are messing about in here, A) your
code is non-portable, and B) you might be overlooking a better way to
do it.

Which brings us to the next question. What qualifies a UN*X system. Well,
I'll take a stab at it. If you can take a *reasonably* portable UN*X
program and compile and run it, with only an hour or so to fix those
local implementational anomolies, its probably a decent UN*X port. If 
you cant get there from, it probably should'nt be called UN*X. Of course
crufty old non-portable stuff doesn't count.

A UN*X port should be able to support any (valid) shell script 
thrown at it.

Would a system that had these features satisfy all you UN*X wienies out
there ? :-)

I use AEGIS at work and AmigaDOS at home, and would hate to be constrained
to a something that spoke to me over a serial line. I've just gotten used
to AmigaDOS/AEGIS, and think of UN*X is a little primitive. Sure you can
tack on TCP/IP and X, or NEWS or whatever, but they are still add on's right?
An OS designed with that stuff in mind is going to be quicker and slicker.

Apollo has the right *idea* making SR.10 be based on a Kernel that can
support *real* UN*X and AEGIS. This may make everyone happy (except Dennis
Ritchie, who might complain the kernel is too big).

To summerize ther blatherings, I feel it is very important to support UN*X, but
lets try to find a way to allow use the neat parts of the machine without
*having* to go through UN*X.
 
Is an Apollo a big Amiga, or is an Amiga a small Apollo ?
 




 
 
k
-- 
Richard Sexton
INTERNET:     richard@gryphon.CTS.COM
UUCP:         {akgua, hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!richard

cmcmanis@sun.UUCP (06/12/87)

In article <678@gryphon.CTS.COM>, richard@gryphon.CTS.COM (Richard Sexton) writes:
> This is being cross posted to both groups, because a similar discussion
> is going on in both. For the benefit of Amigoids, AEGIS refers to the Apollo
> OS, not Bill Volk et. al..

Not having followed the previous discussions, please forgive any repeating
of previously posted information.

> Which brings us to the next question. What qualifies a UN*X system. Well,
> I'll take a stab at it. If you can take a *reasonably* portable UN*X
> program and compile and run it, with only an hour or so to fix those
> local implementational anomolies, its probably a decent UN*X port. If 
> you cant get there from, it probably should'nt be called UN*X. Of course
> crufty old non-portable stuff doesn't count.

If you call something 4.2BSD 'compatible' UNIX it should be able to compile
and run anything that any other 4.2 bsd system can run without 'an hour 
or so' to port it. At least in the SR9 version of DOMAIN/IX there were
things you could not do (besides have the C compiler spit out assembly
code which would have been nice, try a ptrace() sometime).

> A UN*X port should be able to support any (valid) shell script 
> thrown at it.
> 
> Would a system that had these features satisfy all you UN*X wienies out
> there ? :-)

No, see above. There are many flavors of UNIX in the world, however when 
two systems claim to run the same flavor, code written in a HLL should 
not have to be modified in anyway to get it to compile. Just say 'make'.
 
> I use AEGIS at work and AmigaDOS at home, and would hate to be constrained
> to a something that spoke to me over a serial line. I've just gotten used
> to AmigaDOS/AEGIS, and think of UN*X is a little primitive. Sure you can
> tack on TCP/IP and X, or NEWS or whatever, but they are still add on's right?
> An OS designed with that stuff in mind is going to be quicker and slicker.

NeWS is no more 'tacked on' to UNIX than the Display Manager is 'tacked on'
to AEGIS. In all seriousness, if you use UNIX on something like a Sun or
an AT&T machine that was designed from the ground up to support UNIX and
windows and networks it doesn't seem primitive at all. The O/S *was* 
designed with 'that stuff in mind'. 
 
> Apollo has the right *idea* making SR.10 be based on a Kernel that can
> support *real* UN*X and AEGIS. This may make everyone happy (except Dennis
> Ritchie, who might complain the kernel is too big).

UNIX is an O/S, and as such can only reasonably be implemented as part of
the kernel. There is also a market for 'UNIX like' user interfaces that
duplicate the csh or sh interface, for those users who are more comfortable
with them. However, providing the user interface, and then calling it
UNIX is not a good idea. (I assume Apollo has discovered this and hence
the SR10 release, correct me if I am wrong)

> To summerize ther blatherings, I feel it is very important to support 
> UN*X, but lets try to find a way to allow use the neat parts of the 
> machine without *having* to go through UN*X.

Let's not call it UNIX shall we? Let's call it "UNIX compatible libraries to
make porting easier", or "UNIX like shell allows UNIX users to adapt to 
our *non-UNIX* O/S", but don't call it UNIX. 
  
> Is an Apollo a big Amiga, or is an Amiga a small Apollo ?

An Apollo is an Apollo, and an Amiga is an Amiga. 

-------
UNIX(tm) is a trademark of AT&T


-- 
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis   BIX: cmcmanis  ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses. But you knew that, didn't you.