What makes an operating system attractive

August 3, 2012

A commentator on yesterday's entry wrote:

The feature set of Solaris 10, which I thought was quite outstanding from an OS point of view at the time, never seemed to gain much traction with decision-makers (possibly because they tend not to have an "OS point of view").

Over time I've come around to believing two general things about operating systems (partly as a reaction to dealing with Solaris and reflecting on how I feel about it).

First, operating systems are commodities. Not in the sense that they're easily substituted for each other, but in the sense that no one is very interested in an operating system by itself. What matters is what you do on top of the OS, not the OS (a computer with an OS but no applications is fundamentally an expensive doorstop). What you could call the OS point of view only matters to a certain sort of technical person.

(This was a hard lesson to learn because I'm the sort of technical person who does care about the OS. At least to some degree, and finding the limits of that caring was sort of humbling when it happened.)

Second, most systems work almost all of the time. Most people and places don't run or deploy unstable systems and are not pushing the limits of what their systems can do. In fact people generally prefer to stay well back from the edge (sometimes to the despair of technical people when management picks the nominally tried and true safe choice over others). One consequence of this is that fault tolerance and fault diagnosis features are generally not all that attractive to people, because most people never expect to need them. Another consequence is that what actually matters is how the system works in day to day operation, because that's most of how people will interact with it.

For server applications, Unix OSes are in a peculiar situation because from the commodity viewpoint they actually approach being a true commodity. Many programs will run on top of most or any of them, so your choice of which Unix OS is often not forced by the higher-level software you want to use; instead you can make it based on other criteria.

All of this leads me to a two-part view of OS attractiveness, especially for Unixes. To technical people in most environments, what matters is how easy it is to get the software you want set up and how much of a pain it is to run the system in routine use, especially in day to day operation. To decision makers what matters is partly what their technical people want to use, partly what the software (and its hardware) costs, and partly whether the OS is seen as a safe, sensible choice.

Actual technical quality doesn't really come in to this, certainly not directly (not once you have a level of basic competence). Technical quality may well affect other aspects that do matter but by itself it's not sufficient; a technically solid OS can easily fumble the higher level issues, for example suffering from being costly, unpopular, and a pain to administer.

(This is not irrational decision making on the part of management, either. Management's job is to deliver results, not to love technology. (Actually that's everyone's job, but that's another topic.))


Comments on this page:

From 194.168.32.194 at 2012-08-03 04:12:56:

Thanks for picking up on this. To clarify my comment slightly, I was thinking of specific examples where the features in Solaris 10 (zones, ZFS) were a direct business benefit to the end system, in terms of lowering costs or reducing management overhead. However, the stakeholders for those systems likely had no view or appreciation of those advantages and so, when it came time to upgrade or replace the systems, these features would not figure in their calculations. At which point, it results in "Linux is cheaper/more common and it's still UNIX, we'll use that". (Some of those advantages have been denuded by progress and further commoditisation; for example, rather than save disk space by cloning a snapshot to produce a second environment, system designers say "We'll just add another 200GB, SAN disk is cheap". But they will still lose the ability to rapidly clone an environment for testing, assuming that continues to matter.)

Indeed, the obsolescence of Solaris has occurred partly because the problems it helped solved no longer figure so largely. "Zones? We'll just add more VMs." "Snapshots? VMFS does that" [really badly compared to ZFS, but never mind]. "Dtrace? Debugging is the vendor's problem."

From 203.97.214.3 at 2012-08-06 04:54:08:

I think there's a few elements that hurt Solaris 10:

1/ Early 10 was... not reliable, to put it mildly. We were running the first M5Ks in our region. Kernel panics, odd behaviour by ZFS, and other delights were the norm (and some hardware faults). 15 years ago I would have said, "If I wanted unreliable shite which customers are expected to debug, I could use Linux", but I think in this day and age that would be unfair to SuSE or Red Hat. That's not what you expect when you shell out big money ot vertically integrated platforms.

2/ A lot of Solaris benefits are, let's face it, marginal in a lot of environments. By the time 10 was released, touting (as one of my colleagues likes to) that Solaris claims better performance in 64-way systems than Linux is pretty irrelevant for a world in which hardware has advanced to the point most shops are trying to work out how to divide systems into little bits. Which leads to...

3/ Zones are elegant, but in our neck of the woods were oversold to management as "VMWare". They aren't, for better and worse. The limitations on networking, a shared kernel, and so on, poor support and documentation in the early days and so on... not so attractive.

4/ Commodity hardware had almost totally overtaken what Sun were offering apart from edge cases like hardware partitioning (and it's hard to convince a guy with blade chassis he needs 5-10U servers with domains instead).

5/ Huge amounts of stuff that could only be had on commercial Unix is now on Linux. We have almost nothing left that's Solaris-only now SWIFT Alliance supports Linux, and what we do is actually mostly internally-developed applications, rather than external stuff.

6/ ZFS is nice, but... Look, compared to UFS it's magical and wonderful. But when I hear Solaris guys with limited real-world Linux experience sperging about, say, ARC, I roll my eyes. Maybe that was new to have bundled with Solaris, but decent handling of caching the VFS... really? That's a bold new thing? Welcome to 1998, guys. Similarly, the attempts by Sun to convince me I shouldn't be relying on my SAN for RAID but should do it on my servers? Not helpful in high-end environments. Tell me about error-checking and ease of management, not how I can do software RAID.

Honestly, Sol 10 felt like it needed another year baking, although I understand Sun were desperate to push it out anyway.

rodgerd

Written on 03 August 2012.
« Can Oracle make ZFS much more attractive?
Oracle, ZFS, and Linux (and Solaris) »

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

Last modified: Fri Aug 3 02:20:21 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.