Solaris 11 Binary Incompatibility?

Once upon a time, it used to be in Sun’s DNA to guarantee that if your code were written to a public, published interface (no fair hacking kernel data structures or using undocumented system calls), Sun would guarantee that your code would not have to be ported when they released a new version of Solaris, just re-tested and re-certified should you choose to (and most ISVs did). This was binary compatibility at its best: your code would just run and come up with the same results on the new OS. After the painful SunOS 4 to Solaris 2 transition of the mid-1990s, this was music to the ears of Sun ISVs and it attracted a lot of them to the new Solaris platform. For years, it was an informal gentlemen’s agreement, but was later codified into an actual guarantee somewhere around the Solaris 8 timeframe. Here is a snippet from the current wording on that page:

“If an application runs on Solaris 2.6, 7, 8 or 9, including their initial release and all updates, it will run on Solaris 10, including its initial release and all updates, even if the application has not been recompiled for Solaris 10 — guaranteed.”

Pretty strong stuff. So when Oracle CEO Larry Ellison recently said that the SPARC SuperCluster running Solaris 11 was “100% upward compatible with the huge SPARC/Solaris installed base” and EVP of Systems John Fowler showed a Solaris 11 slide saying  “Your Applications Just Run”, I suspected that these statements were probably no longer true. Anyone who had watched Solaris 11 incubate in OpenSolaris or Solaris 11 Express over the years knows that years of binary compatibility had piled up a lot of old interfaces, and Sun’s desire to include some open source software over the last few years of its life meant that at some point they had to modernize their own interfaces and update some over which they had no control.

See for Yourself

Oracle has published an End of Feature Notices page that lists a number of old interfaces that exist in Solaris 10 and will disappear in Solaris 11. The word for this is “deprecation”. Now some of these interfaces may be old or obscure, but if Oracle can eliminate published programming interfaces, you might want to consider what value their binary guarantee can have to you. Can you be sure that your ISV software doesn’t use these interfaces, directly or indirectly? Are you prepared to sift through every non-Oracle binary in your collection to find out?

One of the more important ones, however, is the OpenSSL library, which became a fully-supported API in Solaris 10 (systems administrators, look for it under /usr/sfw). In Solaris 10, it’s version 0.9.7d, but in Solaris 11 Express it’s been upgraded to 0.9.8c. A blog entry on Oracle’s own website clearly identifies the two versions as not binary compatible (see also OpenSSL’s own change log), and for some reason, OpenSSL didn’t make it onto Oracle’s End of Feature page at the time of this writing. But this is no obscure interface. Just about any modern application or plug-in that securely touches a network uses this library, and if all you’ve got is an old Solaris binary, you’re out of luck. And by the way, free-range OpenSSL is now at version 1.0.0e, which, one would assume, represents another binary break looming in the future.

Now, my first impression was that Oracle would explain this away by requiring customers to run such applications in a Solaris 10 branded zone, which is alluded to several times on their End of Feature page.  In this case, those of you who have heard of Solaris 8 or Solaris 9 branded zones under Solaris 10 know that Oracle will very probably charge you for the license and maintenance for Solaris 10 in addition to the license and maintenance for Solaris 11. Oracle claims that the guarantee will continue to cover binary compatibility in non-branded Solaris 11 environments, but has declined to elaborate how they intend to accomplish this.

What It All Means to You

The way I see it, Oracle’s SPARC customers should be asking some hard questions about the blanket statements being made by Oracle’s senior executives. It looks like Oracle has provided itself a get-out-of-jail-free card: if you look at their Solaris 11 Preflight Checker, you’ll see that “it’s still possible to build applications that, even though they compile and run successfully, … use deprecated interfaces, which may cause the application to break at some point in the future [emphasis mine].” This is a far cry from the once-legendary guarantee that made ISVs come running to SPARC and Solaris in the past.

But maybe that’s the point. Whatever its aspirations may be, Oracle is first and foremost a software company and, in stark contrast to Sun’s systems mentality, probably isn’t interested in fostering a platform on which their competitors thrive. And considering the fact that SPARC hasn’t been selling as well as Itanium for two years now, many ISVs must be re-thinking their support for the dying platform. Not that such re-thinking is causing any concern at Oracle: their closed appliance world view doesn’t leave much room for best-of-breed third party ISVs anyway.

Maybe the remaining Solaris 11 engineers will have pulled some technical sleight-of-hand I haven’t thought of to handle this obvious contradiction by the time Oracle formally announces Solaris 11 in November. Or maybe customers and ISVs will be pointed to some fine print in an obscure legal document that gives Oracle an “out”. But in any case, former Sun customers should get the details from Oracle’s engineers. They should be asking for them to come clean about the conditions of their guarantee before assuming that their Solaris 10 applications will just run on Solaris 11.

Because what Larry Ellison and John Fowler seems to be saying is, “If an application runs on Solaris 10 it will run on Solaris 11 — unless it doesn’t — guaranteed.” Long-time Solaris users were used to better than that from Sun.