A thesis: Sun should fork Solaris

December 2, 2008

Right now, Sun has two markets for Solaris, that being the people who already run Solaris (their current customers), and the people that Sun would like to persuade to run Solaris, based on attractive things like ZFS and DTrace.

The first group has generally been running Solaris for years (usually on SPARC, which is one reason that it lingers on). They care a lot about backwards compatibility, and so they want Solaris administration and so on to keep working just the way they are used to.

The second group has to be romanced away from alternatives like Linux. Backwards compatibility with current Solaris is not an asset; in fact it is a deficit, since while Solaris may be winning on things like DTrace, it is losing horribly on things like modern package and patch management.

The first group, the legacy customers, are important for Sun's current revenue stream. The second group of customers are vital if Sun is to grow (or even to survive; pretty much by definition legacy customers only dwindle over time). Sun can't afford to alienate either group. But they have conflicting requirements for Solaris; the first group wants no changes, while the second group requires Solaris to change, to modernize to match its competitors.

This is an irreconcilable conflict; you cannot have one version of Solaris that is both backwards compatible and modern. Not if you want something that is not a horrible ugly mess internally, with multiple package systems cohabiting uneasily and so on.

So my thesis is that Sun should fork Solaris now. One version would be for the legacy customer base, with compatibility with all of the old tired programs, and one version would be for everyone else, modernized and brought up to competitive speed. The two should have the same base (kernel, core libraries and so on), but the new Solaris could break all sorts of tool-level compatibility in order to deliver something attractive to the customers that can actually grow Sun's business.

I think that such a fork would not need to be much extra work for Sun. Things specific to the legacy environment would presumably be basically static (since change is not considered an advantage there), and Sun already has to maintain the common base. This leaves the new Solaris environment, and Sun has to develop that anyways in order to be competitive. (I am aware that this is somewhat optimistic, but hopefully not too much so.)

(The inspiration for this entry is Tim Bray's What Sun Should Do.)


Comments on this page:

From 128.100.49.60 at 2008-12-02 12:48:53:

It's called OpenSolaris (not to be confused with Solaris Express). Current version is 2008-11.

It uses IPS packaging instead of the old solaris packages and the upgrading/patching system is simply "pkg image-update" or a GUI to select packages. There were performance problems in the image-update/GUI of earlier versions but I think it has improved and it's on the right track.

It uses ZFS boot/root and includes dtrace. It is fully open-source (some proprietary libraries normally found in Solaris/Nevada such as CDE/Motif are not included, but that should not be a problem unless you need the backward compatibility of Solaris)

http://www.opensolaris.com/learn/

OdR

By cks at 2008-12-02 13:50:33:

The problem with OpenSolaris is that it's not supported well enough. Specifically, any given OpenSolaris release is not supported for long enough; it appears that you only have support for roughly six months, unless you are willing to upgrade to the new OpenSolaris update every six months.

(Especially as I don't believe that Sun has made any promises of backwards compatibility in OpenSolaris updates; an update could thus introduce new radical changes.)

Written on 02 December 2008.
« My view on vi and vim (and nvi et al)
Mapping IP addresses to ASNs »

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

Last modified: Tue Dec 2 00:10:17 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.