[10ren]

Oracle has brilliant opportunities at the moment: they own a great processor (Sparc) that they could closely integrate with their database, application software and even Java... and (finally!) give IBM a run for their money. They have the cool and fast technology of both Sun's JVM and BEA's JVM (JRockit). They have acquired other brilliant technologies, and have in practice endless resources to acquire more: http://en.wikipedia.org/wiki/List_of_acquisitions_by_Oracle http://www.oracle.com/us/corporate/acquisitions/index.html

But... although it's simple to appreciate the advantages of combining technologies, it's very very hard to actually do. For example, the IBM 360 project, of a series of machines of increasing power (and price), that were all compatible, so customers could upgrade, is a simple idea. But implementing this was a bet-the-company project, it was celebrated as an incredible, miraculous achievement, and the lessons learnt from it remain popular to this day (The Mythical Man Month, by the leader of the 360 project, Fred Brooks.)

To pull off these technical feats, you need the public superstar developers, but also the hidden superstar developers (the x100 coders; the people who, after working closely with them for a while, you observe, oh that guy's a genius); and then the x10 coders, who want to hang out with the geniuses and learn from them. It's places like HP used to be, where Woz wanted to work, at almost all costs (Woz himself being a x100 guy.)

If you only have x5 or x7 coders; and if you don't support them (with infrastructure, secretarial etc - not just compensation, adequate decision-making power, and some kind of recognition.), then, well, you can't do these technical feats. You may seek but not find; ask but it shall not be given; knock but it shall not be opened. Though this is not a disruptive issue, the same factors occur of the difficulty for an established successful company to change its culture and business architecture. And Oracle doesn't want to change anyway.

[Tamerlin]

" they own a great processor (Sparc)"

I'm not so sure about that.

For years x86 has been chewing up the market for Sparc processors, and one of the reasons that Sun had such poor finances is that it was selling x86-based servers more than Sparc based servers (they cost considerably less, and perform better).

Fujutsu's Sparc implementation significantly outperforms Sun's.

Contemporary Xeons outperform both these days.

Besides, Sun has had a long history of massive screwups -- and they put "don't tell anyone we screwed up" clauses in their support contracts. One company just gave up when they got their UltraSPARC3 rig, found that not only was it not nearly performant enough to meet expectations, but also in order for it to function reliably, they had to disable the 2nd level cache on every CPU, or else a cache glitch would bring down the entire server (32 procs).

It's not a great processor. It hasn't been for a long time. Sun has been the "flock of chickens" vs the POWER "bull" as a result.

[jbarham]

For those who don't get the chickens vs. bulls reference:

"If you were plowing a field, which would you rather use?... Two strong oxen or 1024 chickens?"

- Seymour Cray

There are a lot of other great Cray quotes.

[sprout]

Of course, look at any modern Cray ads and Cray is using the same 1024 chickens everyone else in the livestock industry is using.

Sparc isn't failing because it's inferior to x86. Sparc is failing because Solaris is failing, and no other OS is built from the ground up for Sparc. You can run Linux and other Unix-likes on it, but given the choice between x86 and Sparc, you choose x86 because that's what's least likely to cause incompatibility issues.

[protomyth]

Well, to be fair, Seymour Cray is sadly not around anymore to build some better oxen and Cray has changed hands quite a few times.

[Tamerlin]

It's a circular problem actually. Sparc is failing because Solaris is failing, and Solaris is failing because Sparc is inferior.

Cray got reborn in the form of SGI's Altix, which to abuse the analogy would be a pack of wolves compared to the POWER bulls.

The successor to Altix is an x86 cluster using the same high-performance, zero-latency interconnects that they used in Altix (part of the technology that SGI gained from the Cray acquisition).

x86 costs quite a bit less than Sparc. It has far higher performance than Sparc. It runs everything that Sparc does, including if you want it, Solaris. So what's the selling point for Sparc?

Java? Oh, wait -- that's what enabled everyone using a Sparc server to save money by abandoning it.

Amazon saved $17 MILLION by dropping Sun. Ebay dropped Sun (and saved millions in maintenance costs as a result) after a 2-day outage because their Sun boxes crapped out on them, and Sun support dropped the ball.

There are others, of course. Sun tried to stem the bleeding by partnering with AMD, and also by acquiring Afara and attempting to put their CPU designs into practice. x86 ended up beating them at their own game -- lower power consumption, higher throughput, lower cost...

Sparc's probably doomed. I think that Oracle bought an albatross there. There is some worthwhile technology that they might be able to use, like the system interconnects that Sun got when they bought the company that made the Connection Machine, assuming I'm remembering the name correctly. (Thinking Machines, IIRC?)

[hga]

And its a great metaphor for http://en.wikipedia.org/wiki/Amdahl%27s_law, which was one of the "secrets" to the success of the Cray 1: even when you couldn't use the vector hardware it was blindly fast (80 MHz in the mid-70s).

[hga]

When I learned about their "no service unless you sign this NDA" policy plus their attempts to blame their customers ("your machine room's environment isn't good enough") for this problem of their own making (see my other comment in this thread: they cut costs by omitting parity/ECC) I knew they were never going to make it in Big Iron. Sun's predecessors had defined an informal SLA or social contract that Sun just didn't recognize or was able to implement.

When I learned that their internal sales force total focus on big contracts made it literally impossible for most startups to buy medium levels of Sun kit (by and large no more than could be put on credit cards (Sun's "VARs" were supposed to handle this business but few did, clearly Joyent found an exception)) and that people were buying less desirable Dell servers simply because Dell would actually sell and deliver them (HP's sales function was also totally screwed up at this time) it became clear that no small company that was going to become big was going to do it on Sun hardware (SPARC or x86).

At that point it became crystal clear Sun was doomed; final straws included Sun cost cutting or otherwise screwing up their servers (details on request, but e.g. Joyent stopped buying Sun hardware while they continue to use Solaris).

If I want to get nasty, I'd have to wonder about how much Sun's recent (post Java 6) stewardship of Java made Oracle want retain Gosling and his peers.

[rbanffy]

> One company just gave up when they got their UltraSPARC3 rig

On the other hand, the Niagara family seems very interesting. Sadly, never had the chance to characterize its performance under my loads, but I suspect there is a lot of stuff they can do better than the same price x86 box.

A T3, with its many multi-threading cores resembles much more a "flock of chickens" than a Xeon does.

[gaius]

There is Solaris x86 (x64) now, but it was always the red-headed stepchild, badly supported, minimal HCL, no work done on the compiler to optimize for that architecture, lagged behind for patches, both from Sun and from vendors like Oracle.

A world in which you could have Solaris on your Intel boxes and your SPARC boxes and compile fat binaries a la NeXTSTEP that would "just work" all the way from the desktop to the datacentre is a compelling one. But Sun lacked the courage to invest in Solaris on Intel until it was too late.

[brisance]

Gosling also wrote about being at the mercy of suppliers impacting SPARC and it probably contributed to the problems.

http://nighthacks.com/roller/jag/entry/at_the_mercy_of_suppl...

[hga]

Do some Googling and mroe reading and you'll find their problem was that they cut costs by assuming the memory supplied was perfect and that they didn't need to include parity checking or error detection and correction. This is the UltraSPARC3 problem that Tamerlin is talking about.

[10ren]

OK, my mistake. I assumed Sun were still great at building processors (and they got killed only because they were disrupted, in the Christensen sense, like Digital were.)

I now make a further assumption that the remaining echo $((`wc -w`-6)) 315 words about the importance of technical talent are OK. :-)