[Ti] Apple's True Market Share!

[Loren Schooley]

Here's another perspective :-)
Perhaps fully functional could also mean: "For Sale at a Sun shop near you
--> Solaris 9 on x86 w/optional Gold support. Check your Sun Rep for
details" and "This is an attempt to escalate our $ awk '/Subject:/{print $4,
$5}', and that Microsoft internal Newsletter-  Headlines: "Holy Crap, Sun is
competing for our market share with Early Access software!"

Or do you think that Apples x86 market share could be dramatically
influenced by a few OSX port hacks by Apple development to x86 and some $20
beta users? (I admit it could actually cause a ding) Or wait-one more thing,
perhaps Sun already attempted x86 support, it failed miserably, and Early
Access is the remnant of that failed enterprise, which Apple couldn't help
to have observed.

Market share is marketing, not performance and capability you go on about. I
don't think people care what Microsoft runs on, they care about Microsoft,
not x86. Would Apple ever dare take a full step toward x86 support? No way.
Sun don't either, but they have a good thing going with Early Access, that's
a productive solution for what existing product they already have.

I said earlier that Sun quit supporting x86, that was kinda inaccurate. I
gathered that back when 9 came out x86 support was missing and no ISO's were
to be found, so at the time it was the consensus. Later of course, they had
this Early Access plan going on.


On 12/12/02 1:43 PM, "Mark C. Langston" <mark at bitshift.org> wrote:

> On Thu, Dec 12, 2002 at 12:52:44PM -0600, Chris Olson wrote:
>> Mark C. Langston wrote:
>> 
>>> That's not entirely accurate -- there is a private beta period.  Early
>>> Access is closer to a gamma test than beta test.  Still, this is a
>>> normal part of their development cycle.  There will be a final version
>>> of OS 9;  this isn't it.  It does, however, contradict the previous
>>> poster's claim that Sun has given up on x86 development.
>> 
>> We are a Sun support center, and I beta test everything that comes down
>> the pipe.  Solaris on x86 is not a fully funtional, production
>> environment operating system, nor will it ever be.  It is a
>> learning-point port only, for those who can't afford, or won't buy the
>> native hardware.  It has the problems that Apple would have if they
>> tried to port to x86 - a specific HCL (look at Darwin's HCL), and very
>> poor performance due to the inferior x86 processor design and it's
>> associated instruction sets.  If your hardware is not in the HLC, forget
>> it - it won't work.  As I also already posted, supporting all the
>> hardware on the x86 architecture is a nightmare for a truly
>> high-performance operating system.  There are major, major differences
>> in RISC vs. CISC architectures.
> 
> I've also been in various positions in a company providing Sun support
> (heck, we even designed portions of their certifications), from techie
> to CTO.  I've also personally been a beta-tester for various versions
> of Solaris (2.6 and 7, respectively.  I've been working professionally
> with Sun operating systems since SunOS 4.1.1, in large-scale production
> enviornments.)
> 
> What, exactly, do you mean by "not fully-functioning"?  All the daemons
> work just fine; the scheduler schedules.  The slicer slices.  The
> memory manager manages.  Now, if you want to complain that the graphics
> are slow, so be it -- When I hear someone complain that a Unix doesn't
> work, I start looking for basic operating system problems, like a
> poorly-written kernel, broken /dev trees, and the like.  I don't stop to
> think, "wow. This person means their pretty pictures aren't."  As far as
> I'm concerned, previous versions of Solaris x86 work just fine.  That is
> to say, their functionality is indistinguighable from the outside, and
> only marginally so when working on one as a sysadmin.  If you're using
> both as desktops and complaining, then sure, x86 sucks.  But then, so
> does the SPARC version...Sun's marketing department to the contrary,
> Solaris is not a good desktop OS, and was never designed to be.  The few
> attempts they've made towards it are either promptly disabled by
> competent admins, or replaced with better-beahved and better-written
> equivalents. 
> 
> 
> I fully expect SunOS 2.9 (nee Solaris 9) on x86 to be similar.
> 
> Yes, it's slower on a CISC architecture than a RISC architecture --
> no big surprise there.  It's a benefit of running on RISC, at the
> expense of a few extra cycles for the same task on occasion.
> 
> 
> If you're complaining that it only runs on a small subset of x86
> hardware, that may be a valid complaint against the x86 port of
> Solaris, but it has no relevance to your claim that Solaris on
> x86 is "not fully-functional";  it functions just fine, just perhaps
> not on the hardware you'd like to run it on.
> 
> So, please better define the phrase "not a fully-functional,
> production environment operating system".  Works just fine from where
> I sit; i.e., no better or worse than the same configuration on
> a Sun-branded box, modulo the expected performance hit from running
> on x86.  And if that is what you meant that phrase to mean, perhaps
> you should re-think it.  "Slow" does not equate to "broken".
> "Non-optimized", "resource-starved", or "underspec'd", perhaps.
> But not "broken".
> 
> 
> 
>> 
>> Despite the fact that BSD may appear to run fine on x86, I'd like to
>> point out that linux does too.  But set up several linux machines,
>> running on x86, PowerPC, and UltraSPARC, and thrash them thoroughly.
>> x86 performance ends up on the bottom of the heap.  I'll tell you flat
>> out that a 1.8 GHz x86 linux database server won't match an old PowerMac
>> 9600 with a G3/500 upgrade in it, also running PPC Debian.  Been there,
>> done it, the old Mac wins hands down.  P-IV's are nothing but hype with
>> a big heat sink.  You can *just* about heat the server room in the
>> winter time with a couple of those machines.  Admittedly, that's a linux
>> comparison, but OS X is looking to the future as a high-performance
>> operating system that is going to need it's own hardware platform to
>> deliver as promised, just like Solaris does.  Compromise on the hardware
>> to reduce aquisition cost, and you'll also compromise on the
>> performance, stability, and general overall reliability of the system.
>> I'm not saying somebody like AMD won't possibly come up with a decent
>> x86 processor in the future, but right now, I'm not seeing it.
> 
> 
> Here, you seem to have gone from complaining that Solaris x86 doesn't
> work properly (and being vague, at that), to simple (and unjustified)
> platform-basing.
> 
> I'm fairly sure you had a point to make.  I'm just not sure what it
> is.  I am, however, fairly certain there weren't any facts in the
> vicinity lending them support.
> 
> I've seen various statistics that each demonstrate Linux, Solaris, Mac
> OS X, Windows (various flavors), NetBSD, OpenBSD, and FreeBSD all
> outperforming one another on the same platform.  The one constant
> in each of these studies:  They're invariably done by institutions
> with a vested interest in the outcome, and are run by people who
> have no clue how to optimize the subjects of the tests for their
> respective platforms.  You can't just take, say, a database,
> and throw it one two radically different platforms, install identically,
> and NOT expect one to outperform the other.  That's an unfair
> test, because software, by its nature, is biased, from the ground
> up.  Optimize the subjects of the tests for the environments in
> which they're to run, such that each candidate is making full use
> of available resources, and *then* run a comparison, and perahps
> I'll take note.
> 
> 
> ...and before you jump on me, accusing me of attacking whatever
> platform you perfer to bolster, please take deep breaths, reread
> my post, and understand that I did not once elevate or degrade
> a CPU architecture, operating system, or piece of software; I
> merely took systematic issue with your claims, your support for them,
> and your clarity of presentation, which limits one's ability to
> discern and evaluate the first two.