vince@bcsaic.UUCP (Vince Skahan) (04/22/89)
[... flame off but maybe soapbox on (occasionally) ...]
Well, here's the summary that I promised. I've heard lots of things
from other sys_admins from various colleges and companies. I've also
heard from lots of folks at Apollo and at least one of their competitors.
Sincere thanks to all who responded...
I heard that my posting was interpreted by some at Apollo as a long flame
without regard for Apollo's past efforts and accomplishments. Nothing could
be farther from the truth. My intent was to try to determine if there were
others out there with the same concerns and uneasiness about recent events.
With the minor exception of a couple of professional disagreements
over the idea of JLRU or not, I did not receive ONE letter or call from
anyone with disagreement with what I said. I got letters and calls from
over a dozen sys_admins literally worldwide who agreed virtually word
for word. There's a lot of pent up disgruntlement out there that CAN be
fixed up if the effort is made.
I've tried to summarize this stuff by general topic rather than just
going a bit nutso (like before, eh?) so that y'all can hear what I heard
with a bit more clarity...in most cases I paraphrased what I heard from
lots of sources and then threw in my two cents worth in rebuttal.
[...user and third party installable RAI...]
Basically, this is "coming someday" but there has not been a universal
clamoring for it. Since RAI is so complicated, they wish to make darn
sure that it comes out when it's ready and not before. (which sure makes
sense to me...how about telling us WHEN ??? 3 months ?? 15 months ???).
On the subject of RAI...we were told by the Apollo hot-line that there
is no "restart" option like the one with /install/install from SR9.
Is this really true ?? I get real cranky when things I depend on go away
in a new release...
[...equipment obsolecense...]
The technology is changing so fast that it passes the poor users by and
they get left with "the old stuff". State of the art today is old and
expensive and slow 6 months from now.
I agree and understand that. I would greatly appreciate it if Apollo
can try to consider their large installed customer base and give us
a few ideas with what we CAN use a 2 MB DSP80 for under SR10. I'm
not asking them to buy it back, just give me their considered technical
opinion regarding what we can do with a system with a 442 MB disk
but only 2 or 3 MB of memory. Right now, it's supposed to be a file
server and under SR10 I'm concerned that it might not be able to just
serve as a TCP gateway and run a parallel printer.
Wouldn't that be a lovely idea for a technical bulletin ???
[...the new DN3000's with only 4 or 8 MB boards...]
No response from anyone.
I still would like to know how Apollo can handle the case of selling a
upgrade from a 4MB system to 8MB and not leaving us with a 4MB board in
a box. If they want to have me pay the incremental 4 MB price and
swap boards, it's OK with me. If Apollo is willing to buy the 4MB boards
back that's OK too but I'm not buying any more 3000's without an answer.
In my opinion, this is one more lousy marketing decision that indicates
clear lack of regard for the existing installed customers. Sure, it will
get some short term profit but it will also make lots of existing users
real mad...and existing users are the best source of new business.
[... DPCC version 3.0 in /install/install format ...]
Version 3.0 was released before SR10 but the next version of DPCC will be
out in May in RAI format. Thanks to several Apollo folks for that info.
Once again, this is an example of lousy marketing. There is no way that
any Apollo versions for SR10 should exist without RAI installs. If the
new version of DPCC wasn't ready when SR10 shipped, someone should have
provided a RAI install of the OLD version.
[... SR9.7 X-windows in RAI format even though SR9 can't hard-link ...]
Basically the very unofficial response was something like "Yeah, I guess
that wasn't too smart".
OK...so what do we do now ??? I bought the product. How do I install it
if I don't have 74 MB free ???
[...known bug reports and patch tapes...]
I know there has been lots of discussion on this in the last few weeks
but bear with me...here's what I've heard...
First, patches are fixes for one-shot problems and are not
integration-tested to make sure they don't break something else.
Releasing them to the general public could cause more problems than
it solves (the idea there is that the potential exists for hypochondriac
sys_admins patching things that weren't broken in their configuration and
causing problems that didn't exist before).
Secondly, the hot-line folks wish to be the front line customer service
people. They recommend that we call them since can identify whether
user problems really need the patch(es).
..and of course, my two cents worth...
I agree that there are potential problems. Apollo should recognize that
we're all theoretically adults here and that we'll act responsibly.
I agree with the idea of letting the 800 line folks decide when we
NEED to install the patch(es).
Without exception...without dancing around the issue...TELL ME THAT
THE PATCH EXISTS AND FIXES A KNOWN PROBLEM. YOU'RE CAUSING US ALL
TIME AND MONEY BY WITHHOLDING THAT INFORMATION. Raise the silly prices
1 percent or something to pay for it...what's another 50 bucks when it'll
cost my company 75 bucks per hour for me to run around chasing my tail
on an unsolvable problem ???
Throw a big disclaimer on there saying "do NOT install any patches
without opening a Software Support call" but TELL US. Don't make us go
crazy trying to fix something that's known to be broken.
One administrator of a several-hundred node network put it best (regarding
the late release of the ATB on RAI problems) :
"At one point, while reading the ATB on installation disasters I didn't
know whether to laugh or cry, we have wasted so much time, when all the
problems were already known......."
Sure looks to me like there's a lot of people agreeing that this stuff
should be made public BEFORE it bites them...
[...three operating systems and no one all-inclusive manual...]
The responses I heard said "we can't just do one 'Administering your
Apollo system' because users who only load one OS don't want to wade
through all the stuff from the other OS's '.
I don't buy that argument. If you look at "Installing Software with
Apollo's RAI Tool" in Chapter 2 that's exactly what was done...and very,
very well. It details how to mount/unmount the file system in each
of the 3 OS's. Nice. Clear. Concise. Accurate. Perfect. I gave
that chapter to someone from Apollo Tech Pubs who was here as an
example of how to write GOOD manuals.
I very simply cannot give a sys_admin a desk full of manuals, tell
them to read all of them, handle the inconsistencies and unwritten
implications, and expect them to run an Apollo ring at all, let alone
do it efficiently.
This isn't a change from SR9. How many sites are out there running
Aegis TCP/IP 3.1 and dealing with local.txt and makehost.sh when all
they have to do is run the BSD4.2 version and just edit /etc/hosts ???
[sigh] How many sites out there just don't know how easy BSD TCP is
because nobody told them about it ???
Apollo can do better. If they can design the stuff, they can document
it and maybe the large overhead paying the 800 number can be better
spent...
[... JLRU documentation (cryptic and lousy)...]
I didn't really hear anything that gave me a good answer why the
SR10 documentation virtually ignores some basic unix stuff. There's
a whole book on Aegis printing but little info on /etc/printcap.
(as an example).
I think giving us 3rd party books (like for Unix Text Processing)
is a good idea but there's lots more that should be done.
[...JLRU or not JLRU...]
I was told that SR10 *was* real unix. My response was that it was
real unix-*compatible* but was not JLRU. I got in a long e-mail
discussion whether SR10 was (or was not) "real unix"...
Here's some of what I said in response to some concerned folks from
Apollo...
"The folks who influence whether the market considers you to be real
unix or not will just never agree that SR10 is JLRU.
I agree you're more source-code compatible now (under 9.5, "rn"
needed over 50 KB of apollo-specific patches) but as long as
there are REQUIRED Apollo-isms like edrgy, you are NOT real unix
even if you're better.
I recall the Unixworld review of the DN3500 or 4000 that couldn't
handle the idea of the // level. Sure, it's lots cleaner than
mounting filesystems with NFS. However, it is NOT real unix no
matter how wonderful it is.
People out there are buying Apollos expecting to edit /etc/passwd
to add accounts. They are being done a disservice. I have a
local guy who manages Suns and Ultrix systems who is totally and
completely lost regarding setting up one stand-alone Apollo
that I can set up from "in the box" to "in full production"
in 90 minutes BECAUSE I'VE DONE IT BEFORE AND I WROTE DOWN WHAT I DID.
You should be doing a much better job of telling folks how to set
their system up just as poorly as real unix if that's what they
really want (or just tell them up front you're unix-COMPATIBLE
but you can't run an Apollo ring like a generic unix network.).
At the same time, you should be killing yourselves to show why yours
is better and they should buy Apollo.
How come I don't see periodic technical bulletins that aren't just
sales brochures ???
I could go on forever..." (and might if I don't stop now :-) )
[...lprotect released with "don't use this" in big letters...]
I heard it was broken at the last minute but was allegedly fixed
in a patch. Is this true ??? I have a great need to use this
on EVERY node.
I've never found anything that indicates to me that it's fixed.
Is it ??? How about in 10.2 ??? We need it now but most of us are
willing to settle for a tenative date or version that works.
[..."open" means "closed" and "closed" means "open"...]
OK, it's broken... 'nuff said. Now, how to I fix it ???
Although the RAI documentation states "don't reinstall with RAI to
switch from 'open' to 'closed' ", we were told last week by the hot-line
that the desired solution IS to reinstall using RAI. Which is right ???
I really don't care to hear why it broke but I do need the correct
solution so I can know how to fix the silly problem.
Do I just reinstall, or what ? I totally refuse to accept the answer
in the RAI manual that says "just invol and re-install". That's not
good enough.
[... inprot without providing example templates...]
I heard very unofficially that it wasn't considered to be a hot priority
to provide templates. PLEASE MAKE IT A PRIORITY !!!!!!
Personally, it's in my top 3 "hot items" regarding SR10. I have a
definite need from folks who make lots more than I do to lock everything
up tight. I absolutely need the ability under SR10 to do the kind of
things I can do with acl_both and the acl option of install under SR9.
We have learned to depend on the ACL option of /install and use it on
EVERY node to do the following under SR9 :
- ensure that system software is secure
- ensure that protections let the users do their work
- ensure the stability of the local networks by making sure only a
small of people can alter the configuration.
We need to be able to depend on inprot at SR10. I need the following:
- "open" and "closed" templates for all OS types, big, medium, small
- "a clear, concise example of how to write my own. What
protections ARE required entries ???"
Would someone please respond to this ??? I need an answer very shortly
or I'll have to open the highest priority 800 number call you've ever
seen. We've got Apollos in Dept. of Defense classified areas that MUST
be guaranteed to be protected tightly.
This info MUST be readily available somewhere...
[...spiral bound manuals...]
The explanation was that people complained about pages ripping out of
the 3-ring binders so they chose to better bind the manuals and that
3-ring binders take a lot of (money, room, etc).
I know people complained about the 3-ring manuals. What you changed
to is worse. I attended a SR10 transition class last July in Washington
where EVERY person screamed bloody murder when it was mentioned. It's
a year later and no one listened.
I don't know why people seem to think that this is a trivial bitch
for flaming only... Apollo has never had manual update service (like
DEC does rather well) and you sure can't provide that service with
hard-bound books. Apollo's on-line manual product (whose name escapes
me right now) doesn't have all the books available yet and is too
expensive in $$$ and MB required.
[...RAI deinstalls patches on alternate installations...]
One person from Apollo actually wrote and said "I don't understand...
is this a bug ???"
I'm not sure but it sure sounds like one to me. At the very least, if
it was a feature and not a bug I would expect it to be clearly
documented and to have it report "de-installing patch <number>"
when it does its thing.
I do applaud Apollo for waking up and providing the RAI technical info
without asking. I hope that bulletin was not an isolated case, but
maybe the first in a continuing series.
I just wish whoever makes "policy" would also wake up and try to help
us find these things out before we find them the hard way. That's not
how you build trust. That's not how you get/keep customers. That's not
how you keep the customers you have. That IS how you drive people into
the arms of your competitors.
When I was in college, I had a nice little sports car. It was the best
car I ever had. But it broke a lot and kept getting recalled AFTER I
fixed the problem at considerable cost in time and money.
I sold it. I'll never buy another. Sure it was fun... it wasn't good
enough to make all the hassles worth it.
Sometimes blood-pressure wins out over technical superiority.
[...RAI de-installation option not available yet...]
I heard a lot about how tough it is to do. My response was for them
to drop $10,000 and buy an Ultrix Vaxstation 2000 and see how nice
and easy it is. It's beyond wonderful.
I installed Ultrix on a Vaxstation without manuals by sticking the
tape into the drive and booting off of the tape. The installation
procedure guided me through everything else...
Again, this is an excellent potential marketing tool. I can't believe
that Digital does NOT use it to say how easy their stuff is to
install and administer.
[... "Apollo disks don't fragment"...]
No response. Every sys_admin I've talked to believes that they DO
fragment and that invol'ing and reinstalling the software (although it's
a terrible workaround) does wonders.
Hey, let's either just admit they DO fragment and tell us what to
do about it or send out a bulletin telling us why they don't fragment
and explaining why we ALL see things slow down as time goes on that
re-invol'ing and reinstalling fixes.
[... Chelmsford's going to have to do a better job in having some more
consideration for their installed customer base...]
Shortly after my original posting, I was told by someone that I'd
get lots of response from many different Apollo individuals who
would see what insight and help they could provide.
Absolutely true. Many of the Apollo folks who regularly post in
this newsgroup wrote to fill in the blanks. Thanks to all...
you guys give us some hope that there ARE people who care...
I heard lots of folks saying "my local office breaks their backs
trying to do good but THEY are bound by silly policies and apparent
lack of communication between themselves and Chelmsford".
Amen to that. I have few if any significant bitches with the local
guys but they can't possibly do it all themselves. There are marketing
decisions being made that are just plain bad business. The local
guys hear things from us sometimes before they hear it from their
own company. APR's get acknowledged 15 months after they were
submitted if at all. There's a systematic problem here...
The first response I got to my posting came from a Sun salesman who
was telling me how he/they can help. That's the type of attitude
I'm looking for. I may not ever buy a Sun or any other unix system
but I'll sure as hell remember that guy. He's trying hard to provide
a service.
Apollo ( or HP... ) can do it if they really want to.
--
Vince Skahan Boeing Computer Services - Phila.
(215) 591-4116 ARPA: skahan@boeing.com
UUCP: bcsaic!skahan
Note: the opinions expressed above are mine and have no connection to Boeing...