[Ti] Apple's True Market Share!

[Mark C. Langston]

On Thu, Dec 12, 2002 at 05:23:14PM -0600, Chris Olson wrote:
> 
> OK, so which post should I reply to?  And where did this come from? 

It came from your claim that Solaris on x86 isn't fully-functional.

> 
> I would disagree on being fully funtional.  It suffers a significant 
> performace penalty on x86, only supports limited hardware, and Solaris 
> is first and foremost a server OS.

I fail to see how "is not as fast" equates to "lacking in
functionality".  Have you attempted to isolate the areas that are
creating the bottleneck?  Have you used sar, iostat, vmstat, or any
of a number of other tools to analyze major and minor page faults,
blocked reads and writes, load per CPU, disk access time, etc., and
then made use of that information to actually adapt a stock,
out-of-the-box OS to the platform on which it's running?  Perhaps you've
heeded the wisdom of people such as Adrian Cockcroft or Jim Mauro, and
applied what they have to say to the task at hand?

No?  And you complain that it's slow?  Shame on you.  To paraphrase
an acquaintence of mine, that's like responding to a customer that's
repeatedly banging a dead parrot on the counter by swapping out the
counters in the hopes it solves the problem.


>  As a server, the x86 port is broken 
> in several areas, most notably LDAP support, 

It's the same LDAP implementation found on the Sparc version. 
Could you be more specific?  In particular, what does the SPARC version
do that the x86 version appears not to do?

>and the fact that it 
> crashes more often than Windows 2000 Server. 

That sounds more like administrative error than a problem with the OS.
As is, believe it or not, similar problems with Windows products.
When you're allowed to specify the hardware on which an OS runs, and
you're responsible for seeing that the OS is configured properly and
matched to that hardware, it's very rarely the OS's fault when 
something goes wrong, no matter how much you may wish it were
otherwise.  Lack of knowledge or expertise does not translate into
a de facto software fault.

 

> We've tried it on HP file 
> servers and get an average uptime of ~12 days between crashes.

Without further information, this is not only anecdotal, it's
meaningless.  I've had Solaris run for years unattended.  I've had
Enterprise 4000's and 3000's crash every day. 


You see, it's not the hardware that's to blame; it's not the software
that's to blame.  It's how one uses both, and the effort one puts
into ensuring the synergy of the two is appropriate for one's needs.

Though I'm sure you did a stack trace on the coredump, involved the
appropriate Sun software engineers, and can provide us with the bug
references in SunSolve to demonstrate that these crashes were an actual
problem with the OS, and not just some mismatch between what you
were trying to do, and what you were trying to do it on?



Find me a hardware platform, and I could almost certainly find you
someone who has horror stories of repeated crashes.  From PDP-7's
onward.  Some of those stories will be legitimate OS problems.  Some
will be application problems.  Some will be configuration issues.
Some will be PEBCAK.  Some will be willful or accidental misuse.
Most, if not all, would have a basis for claiming one or the other,
beyond running in circles, screaming that the OS is to blame because
it crashed.




>  Running 
> the c compiler is also an excellent method of getting it to crash. 

That'd be Sun's C compiler, or gcc, or ...?

Yes, C is an excellent gun, which really gives you a wonderful view
of one's foot.  Or are you trying to get me to believe simply invoking
the precompiler, the linker, or somesuch causes a kernel panic?
I'd imagine you've much more likely written something that contains
a memory leak or stack over/underflow, and tried to run it.


> Running it alonside linux on identical hardware, reveals how poorly x86 
> Solaris really does perform as a server. 

Really?  How fascinating.  You take two systems -- one originally
developed for x86 hardware (the 386, to be specific, since it was the
first to have an MMU), and one originally developed for SPARC hardware
and an architecture that never included IDE drives or a PCI bus
-- run the two side-by-side on x86 hardware without any sort of
tuning, and then proudly declare that the one developed natively for
x86 runs better?


Why, nobody would ever believe that!  It's incredible!  Absolutely
flabberghasting!


Perhaps you should re-read my segment on what constitutes a fair test.


I'd wager I, or others, could configure said system to provide you
whichever winner you so choose, simply by changing OS, disk, memory,
and application parameters.  There are _always_ optimizations that
will favor one OS or another.  There is no "ceteris paribus" in
cross-platform testing, period.  Anyone who claims otherwise is
trying to sell you something.


I don't know where people got the idea that _any_ OS sold for
commodity hardware -- or, indeed, even for a small line of vendor-
provided hardware -- should perform optimally for all applications 
out-of-the-box in any hardware configuration.  There are several
steps to setting up a Unix server:

1)  Determine uses to which system will be put
2)  Determine resource requirements for uses
3)  Determine performance requirements for uses
4)  Adjust 3 in light of 2
5)  Buy everything
6)  Install everything
7)  Remove everything that's not relevant to 1-3
8)  Tune everything else to minimize 2 and maximize 3.


However, every time I see one of these, 'X runs better than Y on Z'
comparisons, it seems the ONLY thing they've done is 5 and 6.
Worse, it seems that many people in the IT field thing 5 and 6 is
adequate for deploying production systems.


You'll have to excuse me if I remain skeptical.  You see, I come from a
more professional background than that, where systems only break for a
reason, and that reason is always eventually known, and then learned
from.  And the system is built from the ground up to minimize such
experiences, because it's designed to meet the needs it will serve.

You don't need your hardware, application, or OS vendor to do this for
you.  Any set of the three that provide the features you need can be
configured to meet most any performance requirements, as long as they're
part of the design phase.  If you just slap something into a generic box
(or worse, a box that was spec'd for the same task, but using different
OSes and applications), it'll only meet your needs if you're lucky,
because then you're expecting the vendors to know what your specific
needs are.  That's your job, not theirs.


Now, back to your, "x86 is evil" sales-pitch:


> If I were allowed to do so, I 
> could post several pages of results from extensive bench tests we've 
> done on it, on a variety of x86 hardware, but that's comparing it to 
> linux, not to OS X on x86, so it probably wouldn't make any difference. 
>   But compare to linux on SPARC vs Solaris on it's native hardware, and 
> then things are different.  That's *not* what I would call fully 
> funtional or production environment quality.

Really?  I still fail to see how "slow" equates to "lacking
functionality", or how "slow on a given specified platform" equates to
"shouldn't be deployed in a production environment", except to say that
the mouth-breather who deigns to deploy said slow hardware when knowing
said specification is slow should be fired or demoted, if there's any
way to appropriately spec the system prior to deployment, or protest its
deployment.

In short, don't blame Solaris x86 because you got chewed out for
inadequate QA and performance testing prior to deployment.  If it's
known-slow on configuration X, you don't deploy configuration X.  You
deploy configuration X+$FOO, where $FOO is enough to give you the
performance you need.  See, that's the thing with commodity hardware --
it's a __commodity__.  When you don't have enough, you just go out and
buy more, until you do have enough.

Unless you don't have the budget, in which case your mistake was going
down that road to begin with.  Again, that's _your_ problem, not Solaris
x86's.


> 
> Your recitation of how stable releases of Solaris are developed, tested, 
> and released, is correct.


Thank you.  I don't need your confirmation, but perhaps it'll quiet
another person who keeps insisting that "Early Access" is some symbol of
Sun's unwillingness to support Solaris x86, or to release a final
version.

-- 
Mark C. Langston                                    Sr. Unix SysAdmin
mark at bitshift.org                                       mark at seti.org
Systems & Network Admin                                SETI Institute
http://bitshift.org                               http://www.seti.org