The consequence of Oracle's Solaris decisions

August 1, 2010

The title of this is a little bit misleading; ultimately, the really important thing about Oracle's Solaris decisions is not what those decisions are, it is about how they were implemented. I don't like the decisions, but the real problem is their abrupt, no-warning implementation.

Let me be completely clear here: by making these decisions, Oracle screwed people. By implementing them with no advance warning, Oracle screwed people harder.

The consequence of this is that Oracle has lost my trust. I can't really trust companies that blatantly and abruptly screw people, because someday they may screw us in a similarly charming way. (We are mostly but not entirely unaffected by all of the Oracle changes, at least so far. The need to add that provisio is a demonstration of the problem.)

If you can't trust Oracle any more, Solaris stops being a stable platform to build things on top of. Who knows when the next change to patch entitlement will come along, for example, or what it will be? Even if your existing systems are covered by some grandfather clause, being unable to deploy new systems is a crippling limitation in many environments.

(You may still choose to build things on top of Solaris, but now you are clearly taking a risk and I happen to think that it's a not insignificant one. It may still be worth it, or you may be stuck in a situation where you have no real choice, but either way people are not likely to enjoy the experience very much.)

Sidebar: how Oracle's decisions screw people

If you were running Solaris on non-Sun hardware, the new need for a support contract in order to stay secure plus your inability to get a support contract on non-Sun hardware has left you very screwed.

If you were running Solaris on Sun hardware, the surprise need to budget a potentially significant chunk of money as an ongoing yearly cost may have left you screwed. This is especially likely to be the case at universities, where it is much easier to get one-time money (to buy the hardware) than to get ongoing money (to buy the service) and researchers do not necessarily have any extra unallocated money sitting around that they can spend freely.

(If this was not a surprise, you could bundle some years of support into the one time purchase price of the hardware (this is common with one time grant funding money). But surprise ongoing money? That's quite hard to come up with, even with grant funding.)


Comments on this page:

From 198.102.62.250 at 2010-08-02 11:02:58:

To be fair, you can get a support contract for Solaris on non-Sun hardware. Our reps confirmed this "reversal" in policy a month or so back and we have been able to continue ordering Solaris 10 subscriptions for our Silicon Mechanics and VMware hosts running Solaris (actually, I'm curious -- have you tried and been turned back recently?).

That said, the back and forth nature of it all and the lack of "official" announcement doesn't do much for us in the way of creating trust in Oracle consistency in decisions going forward...

From 192.43.65.245 at 2010-08-02 14:05:04:

There's an official document on Solaris on 3rd party/whitebox hardware here: http://www.oracle.com/us/products/servers-storage/solaris/non-sun-x86-081976.html

If you're o.k. with foggy legalities: http://www.sunhelp.org/pipermail/rescue/2010-July/129405.html

You can get a Solaris license for a nominal cost. Just buy new DVD's/CD's for each update.

By cks at 2010-08-04 03:20:51:

We haven't tried to buy Solaris support on anything recently, and we don't have Solaris on third party hardware; somewhat through luck, we wound up running Solaris only on genuine Sun hardware, and we have a campus Solaris support agreement (although we did run into the firmware access issue). I'm glad to know that Oracle has changed their mind about this, at least for now.

Buying new DVDs isn't really an option in production, because you need prompt access to security patches. Waiting three or six or nine months to close security holes is not really an option.

Written on 01 August 2010.
« The other peculiar effects of grant funding at universities
How OpenBSD's pf source-hash maps internal IPs to NAT pool IPs »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Aug 1 23:20:58 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.