Thinking about why Solaris has failed here

May 31, 2012

First off, as I rambled yesterday, to say that Solaris has failed here is not to say that our use of Solaris has been a failure (or that our Solaris machines have been); our fileservers are stable and run (generally) without problems and work. But at the same time it's clear that Solaris has failed to catch on here. The only strong reason our fileservers run Solaris is ZFS, and we've not even running anything close to a current version of Solarism at that (cf); at this point our fileservers are less servers and more sealed black-box appliances. We've never had any interest in using Solaris for anything else and we're not very enthused about Solaris even for ZFS; to put it one way, we pretty much use ZFS despite Solaris not because of it.

(There's good alternatives to Solaris for ZFS nowadays, but as it is our fileservers work and switching just to get away from Solaris seems uncompelling. Or even insane.)

Recently I've been thinking about the question of why Solaris failed here. At one level (as Solaris fans will tell you) Solaris is not unattractive; it has a number of nice features, including ZFS. But it clearly did not hit it off with us. Why? I think there are two major reasons.

The first is that Solaris is, frankly, somewhat erratic, flaky and buggy; it's not the kind of simple and solid system that, say, OpenBSD is. OpenBSD doesn't do very much but what it does just works and works reliably, which makes it a pleasure to use within its areas. Our Solaris machines are pretty stable but getting them there took a significant amount of work and local invention, and the reason they're stable is that we don't change anything on them and we don't ask them to do things that we know are problematic. Since Solaris has problems where we have looked, it probably also has problems where we haven't had to look yet.

The second is that Solaris doesn't have the package availability of many Linux distributions or FreeBSD, where you have a wide selection of relatively current open source software that is maintained by the vendor. There are outside efforts to provide open source packages for Solaris (and we use one of them), but outside efforts can disappear (and are not official) and so are intrinsically less trustworthy and confidence inducing than something the vendor itself supports. Unless Ubuntu absolutely explodes, a relatively current Apache is always only going to be an apt-get away and someone else will always handle security fixes for it. This is not something we could ever say about Solaris.

(Part of the problem of third-party packaging is that Solaris itself ships with any number of very old versions of things as official packages. All of the resulting options are bad ones.)

A significant contributing factor is that Solaris is simply not that pleasant to administer, partly because it is almost totally without modern niceties and partly because what it has in the way of administrative tools are often terribly bad (try to tell me with a straight face that Solaris 10's patching system is at all tolerable). Solaris administration is full of things that might have been good ideas if they were competently implemented but, well, they weren't.

(I understand that some of this has changed in modern Solaris, but by this point that's too little, too late (for us).)

The combination of these attributes in a single OS means there's nothing here to really feel enthused about using Solaris for. It lacks a speciality and a niche that it can really dominate in the way that OpenBSD dominates firewalls and related networking stuff, and it lacks the wide package availability (and administrative convenience) that would make it easy for us to deploy a Solaris machine to do <X> for some <X> like 'provide IMAP'.

(Our directly user accessible machines are essentially forced to run Linux (and Ubuntu at that), but we have plenty of servers that users don't log in to and that could theoretically run almost anything.)

As always, everyone's circumstances are different. For instance, if you build your entire software stack from source yourself in order to maintain full control over it you don't care in the least about Solaris's lack of prepackaged open source software; if it existed, you wouldn't use it anyways.

Comments on this page:

From at 2012-05-31 03:42:40:

Some good points Chris.

The other issue with Solaris now is the unfavourable licensing and support (and by support I mean 'patches') model imposed once Oracle took over. If you have non-Oracle x86 hardware then forget it and if you do happen to have a Sun/Oracle SPARC system you'll need an (expensive) support contract.

I can see the future of Solaris becoming ever more niche, I suppose eventually ending up as "that software layer between Oracle Database and the hardware".

By cks at 2012-05-31 08:12:10:

I thought about throwing in the whole mess of Oracle's Solaris licensing (and you're absolutely right about it, all by itself the licensing might well doom Solaris here today), but when I looked back it was clear that Solaris had failed here even before Oracle made it probably too expensive to use. It's not that the Sun to Oracle transition made us suddenly unenthused about Solaris; we were already not using it for anything besides fileservers well before then.

(There are other pragmatic problems with Solaris that I also left out because I felt that they were less important or I could consider them symptoms of higher level stuff.)

As for where Oracle's going with Solaris, I've done some speculation but I have no real idea. Oracle appears to like surprising people.

From at 2012-05-31 11:32:26:

I feel like the failure "before" all of the licensing changes was still that Solaris just wouldn't run on a broad enough swath of hardware. For true Enterprise stability, one tended to need to go with Sun hardware which of course was fairly cost-prohibitive (at one point we were able to get extensive discounts -- up to 50% off, but Oracle killed those).

Solaris' hardware support increased significantly with OpenSolaris to the point where it would run well even on SuperMicro class hardware. We immediately began running Solaris 10 + ZFS on these cheap boxes.

However, Oracle put an end to that as well with their support model change. At this point it's a complete non-starter to pay 10x the hardware cost.

We've basically shifted to Nexenta for our ZFS needs and have been fairly happy. Especially now that we've basically standardized on Dell PowerVault hardware (which is fairly inexpensive and doesn't change as frequently as the SuperMicro stuff does).

From a Systems Administration standpoint, prior to ZFS, patching was always a PITA compared to Linux. LiveUpgrade on UFS wasn't all that straightforward and was certainly challenging to centralize and automate. It just helped to prevent Solaris from growing here from a management perspective even though those old SPARC boxes just keep running and running.

From at 2012-05-31 15:18:18:

I think the most telling thing about Solaris' future with Oracle is the fact that by default, their Exadata appliances are running Linux. There are some changes coming with that, but the previous commenter was absolutely correct. Oracle is more interested in selling appliances these days, not in general purpose database or server systems.

I've tried for some time to really like Solaris and I have found a few things that I like about it, but most of my frustrations come down to patches and packages, openCSW helps with one, but definitely not the other.


Written on 31 May 2012.
« What it means for an OS to succeed or fail
What OSes have succeeded or failed here »

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

Last modified: Thu May 31 01:47:52 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.