Altos 5000

Dick Dunn rcd at ico.isc.com
Fri Aug 31 04:11:57 AEST 1990


shwake at raysnec.UUCP (Ray Shwake) writes:
> 	What we DON'T need here is a spitting contest between the vendors
> of Intel UNIX...

Agreed.

> 	As Bart might tell Dick, "Don't have a cow, man!"...

I think Bart might tell Ti Kan something similar...or perhaps something
like "Hey, dude! It's just a machine, man..."  And he'd be right in both
cases...I won't plead innocent.

I'm not very good at Bartspeak, but maybe I could make my point more clear
by stating it more mildly?  What I was getting at is that there aren't
these major night-and-day differences among vendors.  We all work closely
with the source code.  We all have a serious interest in performance.  All
software folk who deal with hardware talk to the hardware folks to try to
get it right.  It really doesn't matter all that much that the hardware
folks are in other companies; the goal is still to get good, reliable,
cheap performance.

I don't think that a software engineer at Altos has any real qualitative
advantage over one working at SCO, ISC, Esix, etc.  Nor do I think that
the hardware folks at WD, Adaptec, etc., would care to be told they're not
able to build boards with the same sort of performance that Altos can get.
The differences are quantitative.  Sometimes its an advantage to have the
hardware folks in-house; sometimes you're better dealing with an outside
vendor who has a larger market and can do some things better based on
sheer quantity.  Sometimes you have leverage in-house by saying "here's
what we need, and we're your only customer"; sometimes you have leverage
outside by saying "if you can't build it, we'll get X to build it."  I've
done my time on both sides of this.  That's why I took some offense at the
suggestion that we can't spare the development effort for optimizations...
it just ain't so.

Or take the "number of users" issue.  OK, at some level of use (say non-
intensive data entry and some record processing) you can put 200 "users"
on the Altos 5000.  And it's true that other 486es are used as single-
user workstations.  But that's apples-to-oranges, and there's an apples-
to-apples comparison possible:  How many users can you put on some other
486 machine with reasonable disk space, etc.--*assuming* the same kind of
user as the 200 on the Altos machine?  A guess might be > 50 and < 100...
but we're back to a matter of degree, especially when you start factoring
in costs.

>...The Altos, like
> others of its ilk, seek to promote integrated solutions,...

And that's valuable.  They play by a slightly different set of rules than
we do; that gives them different advantages.  But the markets still over-
lap a lot.

> ...Yes, you
> pay a price for this, but note how many postings in this group are of the
> "I can't seem to get [product x] to work properly with [product y]"
> variety...

True, but you don't have to get yourself into that.  You can take a list of
"safe" known-to-work hardware combinations and build all your systems that
way; if it's not on the list, don't buy it.  ISC, SCO, et al, are always in
the situation of dealing with "The Frobozz 4-port serial voice VGA doesn't
work when I have two drives on a tertiary Xyzzy controller."  The
integrated-system vendors don't have that problem because they don't offer
that hardware combination.  Either way, you lose.

>...There's a place in this world for integrated solutions, as
> there is for unbundled hardware and shrink-wrap software.

...bringing us back 'round to Ray's initial point:  We don't need a
spitting contest among vendors.  I see a place in the world where either
integrated or unbundled solutions are viable, so I think each camp ought
to be more careful about telling the other that it can't possibly do the
job.
---
Dick Dunn     rcd at ico.isc.com -or- ico!rcd       Boulder, CO   (303)449-2870
   ...I'm not cynical - just experienced.
-- 
Dick Dunn     rcd at ico.isc.com -or- ico!rcd       Boulder, CO   (303)449-2870
   ...I'm not cynical - just experienced.



More information about the Comp.unix.i386 mailing list