Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!oliveb!ames!rex!uflorida!novavax!weiner
From: weiner@novavax.UUCP (Bob Weiner)
Newsgroups: comp.sys.apollo
Subject: Re: Elm and other mailers for Apollos
Message-ID: <1314@novavax.UUCP>
Date: 31 May 89 22:51:11 GMT
References: <43290411.f81c@gtephx.UUCP> <1274@novavax.UUCP> <43657eac.1b147@apollo.COM>
Organization: Nova University, Fort Lauderdale, FL
Lines: 64
In-reply-to: nazgul@apollo.COM's message of 23 May 89 16:54:00 GMT

In article <43657eac.1b147@apollo.COM> nazgul@apollo.COM (Kee Hinckley) writes:

   In article <1274@novavax.UUCP> weiner@novavax.UUCP (Bob Weiner) writes:
   >Unfortunately, Apollo currently does not distribute either smail or GNU
   >Emacs, though they could if they cared enough to support better
   >interactive environments and communication interfaces.  (HP probably
   >will distribute at least GNU code sometime in the future.)

   Apollo's policy has always been, right or wrong, not to ship things that
   we don't have the resources to support.  We are fully aware that there are
   *lots* of utilities, tools, etc. that we should ship and support.  But
   we can't do them all, so the best we can do is make them available via
   ADUS for those people who are willing to work with unsupported software.

I sure Kee believes Apollo is doing the right thing.  But there is no
justification for any of the following:

1.  Not sending every customer a full listing (at least once a year) of
the full complement of ADUS distributed software including summaries.

2.  Not shipping up to date, complete 3rd party software listings for
Apollo platforms for at least the last year.  As I understand, marketing
(I have to say, a very feeble organization, at best) cannot decide
whether it is 'appropriate' to print these catalogs now due to the HP
acquisition.  No amount of pounding for the last six months has put one
in my hands.  Lest you think I want something for nothing, my group of
less than 15 people put $250,000 in Apollo's hands in January.

3.  Not documenting, in print, the many useful examples loaded under the
/domain_examples directory.

4.  Not providing a simple way of writing programs to access the high
performance features of Apollo systems.  Something along the lines of
the NeXTStep programming environment is what I have in mind.  We have
100's of Apollos down here used by software engineers (mostly
cross-compiling for other platforms) and I don't know one who is fluent
in Apollo's large set of system calls.  Hence no one can write an
application that makes good use of the graphics, network communication,
or other powerful parts of Apollos systems.

5.  Not educating vendors as to the current state of Apollos system.
Most software vendors I speak to have not ported their software to
Domain/OS (SR10) and truly believe in their hearts that Apollo's OS is
Aegis and Aegis alone.

6.  Not putting an alias facility in the Aegis shell and then providing
a set of common UNIX aliases.  Do you know how many people are in the
process of weaning themselves from the Aegis shell and command naming
conventions.  Many, many.  Apollo's support of this is virtually nil.
In my sleep, I could write the alias facility, in fact I did (I was
awake though) two years ago.  Then I would put together a simple two
page summary that maps common Aegis commands and options into their UNIX
equivalents.  Apollo should do this so that all users benefit.

There is more to say, but I won't burden everyone.  The point is, there
was much more behind my original statement about good environments.  I
hope you understand my vantage point, Kee, and that I wouldn't take the
time to write this if I didn't feel that there were seeds of greatness
buried below Apollo's surface.


-- 
Bob Weiner, Motorola, Inc.,   USENET:  ...!gatech!uflorida!novavax!weiner
(407) 738-2087