2010-08-16
What OpenSolaris's death probably means for us
For those of you who haven't heard, OpenSolaris is dead; see the leaked internal memo for details (via here, here, here, or even Slashdot). In a way, I can't say that I'm too surprised, but I am rather unhappy.
We don't run OpenSolaris in production so in one sense we aren't directly affected. But there are at least two areas where this is likely to hurt us, possibly quite badly. The big one is what is happening with OpenSolaris source code. To quote the memo, with the emphasis mine:
We will distribute updates to approved CDDL or other open source-licensed code following full releases of our enterprise Solaris operating system. [...] . We will no longer distribute source code for the entirety of the Solaris operating system in real-time while it is developed, on a nightly basis.
At this point it is not clear whether 'Solaris X update Y' will be considered a full release or not. If it is not, well, the last full release of Solaris was Solaris 10 at the start of 2005, which didn't even have ZFS, and the next one is theoretically due sometime in 2011. This would make OpenSolaris source code completely useless for trying to investigate Solaris's behavior, which we have had to do periodically, especially when there are problems. Given our bad support experiences, being unable to take a good shot at diagnosing things ourselves is a serious problem.
(This is especially serious because libzfs is an undocumented interface
and official commands like zpool
are unsuitable for a number of the
things we do here. We have a number of internal tools and systems that
could not have been built without access to relatively current ZFS
code and which are in fact rapidly going to get less useful as the ZFS
interfaces change but we can't find out about the changes because the
source code is no longer accessible.)
The other area is the loss of OpenSolaris binary builds. I care about
this because these builds used to be the best and in fact only real way
of getting access to ZFS debugging and repair tools; the ability to do
any number of things to problematic pools appeared first in builds,
often well in advance of its availability in official Solaris patches.
We once came quite close to temporarily importing production pools into
an OpenSolaris scratch environment in order to fix them up, and there
are plausible future cases where we'd need to do this. We've now lost
access to this emergency fix mechanism; instead, our only recourse is
the tender mercies of Sun Oracle support.