This morning, I came across two Phoronix articles (here and here) generating some sort of hype with regards to a ZFS port for the Linux kernel, with article headlines as Native ZFS Is Coming To Linux Next Month. My response to this, as I will explain below is: Why?
First of all (as the first article cites) there has always been the ZFS over FUSE project. There was a reason as to why this project was initiated and that is primarily a result of a conflict in licensing. ZFS is CDDL’d while Linux is GPL’d. The one is incompatible with the other. I will not spend any time in the details of this but you can read some of my opinions with the licensing here. Although using any file system over FUSE has its drawbacks; one of which is performance. But you still had ZFS functionality. In a worst case scenario, you can always deploy Solaris, (at one time) OpenSolaris, Nexenta, FreeBSD, among a few other lesser known operating systems using ZFS.
Despite the reasons given in the articles for porting ZFS to the Linux kernel, it becomes almost irrelevant that (a) it will never be integrated into the mainline kernel (unless Oracle were to re-license it, but then it would become incompatible with Solaris 11+ and Solaris 11+ Express), (b) will never obtain any real commercial support, because if it does, then most likely Oracle will step in to destroy everything in its path for infringement of patents and other intellectual property. Also, (c) you will never be able to commercially redistribute the code, binaries and modules in a custom Linux enabled appliance because if Oracle does not get you for IP infringement, other companies such as NetApp will. Who will protect you then? Finally, (d) it will be a long while before this ZFS port is considered stable for Linux. Especially when it will not be in the mainline kernel to receive additional exposure. These reasons alone are enough for a storage company to not seek interest in this port.
At the end of the day, all of this excitement means nothing. Who cares if this ZFS port for the Linux kernel comes out next month? I don’t. Don’t misunderstand me. I love ZFS as I use it all the time on Solaris and OpenSolaris. It is a wonderful file system. This Linux port is also extremely limited in functionality. Today, the GPL’d Btrfs, a competitor to ZFS, is considered “generally stable“. Why not use that instead without all the concerns listed above?
Well, it has been quite a week, last week. Not too long after the OpenSolaris Governing Board issued an ultimatum to Oracle and closely following the unveiling of the Illumos project, Oracle officially announced (in a memo to internal employees) that they will be leaving OpenSolaris behind. To most (including myself) this is not at all surprising. The writing had been on the walls, yet many still felt hopeful. It is disappointing news for more than one reason. OpenSolaris was a solid and great operating system. Not many of my readers may really know too much about the SunOS family but when Sun Microsystems developed a software product, it was always a quality product; that is, stable and extremely well polished.
When I think of Sun Microsystems, I think of a true engineering company. Although being all engineering and little to no marketing may have been one of many paths to its decline and eventual downfall. Either way, Sun gave us NFS, Java, ZFS, DTrace and plenty more. And whenever I stepped behind a Solaris or OpenSolaris system, I always felt comfortable. I would never use a GUI as most seasoned UNIX and Linux administrators don’t. The command line was my main access to the system’s facilities and this is where Sun had it right. Managing volumes and exported shares, boot environments, services and more. They had simplified and polished the ability to manage the system and all of its capabilities. Unfortunately Linux lacks in some of these but who is to say that someone will not take ownership and develop similar tools in the near future.
It is my opinion that this focus to detail and a stable and simplified environment is going to slowly disappear under the direction of Oracle. Again, Sun was an engineering company and nothing more. Oracle has more of a concrete vision and focus; that is, making money. How much will quality of products such as Solaris 11, VirtualBox, OpenOffice.org and especially MySQL (among others) suffer when deadlines are trying to be met and corners must be cut, because a late product won’t bring in revenue. I will admit that this is most likely where I will end my use of Solaris, unless Oracle surprises the world and continues to maintain the type of quality that Sun brought to the operating system.
In what is supposedly a leaked internal memo to Oracle staff, the adoptive parent company of Sun’s OpenSolaris had announced the fate the project’s (and binary release’s) future. That is, they will support it no more outside of CDDL’d package updates for future Solaris (i.e. Solaris 11) releases.
“We will distribute updates to approved CDDL or other open source-licensed code following full releases of our enterprise Solaris operating system. In this manner, new technology innovations will show up in our releases before anywhere else. 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.Anyone who is consuming Solaris code using the CDDL, whether in pieces or as a part of the OpenSolaris source distribution or a derivative thereof, would therefore be able to consume any updates we release at that time, under the terms of the CDDL, LGPL, or whatever license applies.”
“All of Oracle’s efforts on binary distributions of Solaris technology will be focused on Solaris 11. We will not release any other binary distributions, such as nightly or bi-weekly builds of Solaris binaries, or an OpenSolaris 2010.05 or later distribution. We will determine a simple, cost-effective means of getting enterprise users of prior OpenSolaris binary releases to migrate to S11 Express.”
Reading this is somewhat disappointing as OpenSolaris was truly an excellent operating system.