Seeking a Development Environment (Sun?)

[Barnett Bruce G]

In article <173 at umix.UUCP> paul at umix.UUCP ('da Kingfish) writes:

>The idea that Apollo's Unix is an "emulation" or a "layered product"
>(like Eunice, for example) is really getting to be tiresome, and is a
>canard.  

I sorry you feel that I am spreading false and malicious reports.
But I have tried to be as accurate as I can be, especially since I haven't
had an Apollo machine in front of me for since the beta release of Domain IX.
Because of this, if I have erred, I have tried to err in favor of Apollo.
(But I can always count on the Net to correct my errors :-). 

But I cannot think of a better word than emulation to describe a software 
product that:

	1. Is optional. (or was at the time)
	2. Is layered on top of the native operating system (AEGIS).
	3. Is missing functionality that every version of Unix has.
	   (Functionality in an area I consider essential)
	4. That does not behave EXACTLY the same way as Unix does.
	   (I realize that unixes differ, but see below).
	5. That handles system administration information in a form unlike
	   any other version of Unix.
	6. That is derived from a proprietary operating system instead
	   of a standard AT&T release.

I know it's tiresome, but I am tired of people who tell me Aegis/AUX IS
REAL Unix. How can it be? 

Now emulations have good and bad points. Some functions are faster,
some are slower. Some system administration tasks become easier, some harder.
Apollo's is most likely the best emulation around.
But then, they have the ability to change the underlying operating system, 
when necessary.

My main point is that I do know KNOW where the areas of incompatibility
exist. I know they are there. If I believed people who told me that Aegis 
WAS Unix, I could get myself into trouble.

One of the most impressive features of Unix is the ability to monitor,
tune, and extend the operating system, EVEN IF YOU DON'T HAVE THE SOURCE
CODE!

For instance, if I wanted to write a program that would tell me what files were
currently being accessed, and what disk they were on, 
whether they were locked, being waited for, been modified, 
is shared by more than one process, the inode number, size, etc. etc.
then it would be a trivial task. I wrote such a program when I went to
AT&T's course on Unix Internals (Excellent course! I KNEW all those
strange files is /usr/include/sys were good for something! :-)

I would open file `/vmunix' (or `unix' or ...), use nlist(3) to locate the
whereabouts of the system data structures, then open and seek `/dev/kmem'
and using the data structures in /usr/include/sys/..., get the information
I need.
But AUX doesn't support nlist(3) or `/dev/kmem', so this can't be done.

-->		AND I WOULDN'T KNOW THIS UNTIL I TRIED. <--

The point is, if someone is using a particular technique on a UNIX system,
than I KNOW it can be done on a Sun or Vax. Also, if someone develops
some clever technique (like device drivers that can be re-loaded dynamically,
i.e. without rebuilding the operating system), it will most likely be developed
on a Sun or Vax. 

I LIKE this feeling of confidence. I LIKE being able to use programs like
William LeFebvre's top(1). I know UNIX and know that I can write some
very powerful programs if the need comes up.

I don't feel comfortable that a unix-look-alike will behave the same
way as a UNIX operating system. I would never know when a program
off of USENET would work, and when it wouldn't. I like being able to use
the latest techniques discussed at UNIX conventions.

Please don't tell me DOMAIN/AEGIS/AUX is REAL unix. I'm tired too.

>As I mentioned above, they do
>have a different kernel, with their own OS interface.  That can be
>risky to do, when other vendors trade on the safety of adherence to the
>beliefs of the past, and other signs of orthodoxy, like /dev/kmem.
>
>Apollo does "hide" some internals, in that you can't grope through kmem.
>Sometimes information hiding is OK, and in some contexts that is considered
>to be desirable.
.
.
>And there is no /dev/kmem.  (Although I think that is
>definitely a step in the right direction ... i.e., the 1980s.)

Like 1984? (Sorry, couldn't resist. :-)
But seriously, how can it be desirable to not have /dev/kmem?
You could always prevent access from everyone except root.
You could even delete the file, I guess, and change/delete all programs that
access it. Or you could fix the location of every data structure, and never
change the size/location of the structures in the operating system.
But *IF* they change, you have no method of verifying the *real* locations.

Now, I'm not disagreeing that there are times when hiding information
is desirable. But I can't see your point that eliminating it 
for EVERYBODY is a step in the right direction. 

It seems to me to be a step backwards.

>paul at umix.cc.umich.edu
-
Bruce Barnett
-someone who never believes managers who say: `We will never port this product'