What makes an operating system attractive
August 3, 2012
A commentator on yesterday's entry wrote:
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:
* * *
Atom feeds are available; see the bottom of most pages.