What OpenSolaris's death probably means for us
August 16, 2010
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:
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
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
* * *
Atom feeds are available; see the bottom of most pages.