Seeking a Development Environment (Sun?)

[bobr at zeus.UUCP]

In article <30ceeabf.809c at apollo.uucp> mishkin at apollo.UUCP (Nathaniel Mishkin) writes:
>
>I object to the term "emulation".  What is Unix?  It's commands (programs),
>subroutine libraries, and system calls.  

It is also a standard file system, which has a structure and file formats
that are known in advance.  It does not have extra fields in /etc/passwd and
/etc/group, or a file structure which updates the modification date of a
file after a simple chmod, or a compatibility package which limits the
number of ptys to 16, or a C compiler which generates error messages
incompatible with standard error postprocessing techniques.  These may all
be bugs (and there are others, like malloc(), which I haven't mentioned),
but they are certainly incompatibilities between the expected UNIX
environment (BSD in my case) and the reality of the system.

>    I was under the impression that Apollo is still hiding the internals
>    from everyone. Do they even have a "/dev/kmem" ?
>
>I guess all I can say is that if you think that programs that read
>"/dev/kmem" are the wave of the future, I hope you're wrong.  I believe
>in procedural abstraction.

To some extent the issue is whether /dev/kmem exists, when it restricts the
portability of standard UNIX tools.  Obviously, the folks at Apollo have
some way to get around it, since they have an implementation of ps which
appear standard.  However, I have not yet seen any documentation about how
to get at such information as required by ps.  This means I have no
mechanism for building tools that look like "top", or "sps", or other publicly
distributed tools that I might want to have on an Apollo.

Robert Reed, Tektronix CAE Systems Division, bobr at zeus.TEK