My column last week on virtualisation and the Linux kernel drew some flak from readers who didn’t agree that VMware’s VMI (Virtual Machine Interface) proposal offered a better approach than that of the open-source Xen project.
“Contrary to the tone of your article, all is not perfect with VMware’s VMI interface,” writes Pete Flugstad. “It requires loading a binary ‘blob’ into the kernel, which would not be open source.”
Pete is, of course, correct: VMware has no intention of open-sourcing its virtualisation products. Instead, VMware is proposing a generic kernel interface that would allow it to load its virtualisation code in binary form at run time. Anyone else could use the same interface to load open-source virtualisation code, but VMware would essentially be using it to skirt the licence restrictions of the Linux kernel source.
I still believe that VMware’s proposal is better than Xen’s. That’s not the same as saying VMware has the moral high ground; that would be going too far. But the dirty little secret of real-world Linux installations is that they load and execute proprietary “binary blobs” all the time, and users hardly bat an eyelash.
At the heart of the matter is hardware. Hardware vendors have been reluctant to delve too deeply into open source. They worry that by releasing open-source drivers for their products they will give their competitors too much information about their hardware. As a result, Linux users are regularly forced to compromise their “pure” open-source environments for the sake of hardware.
Wireless networking cards are one example. Wireless drivers for Linux often come in two parts: a GPL-compatible module for the Linux kernel, and a closed, binary firmware that gets pulled in as the driver loads. For particularly poorly supported cards, hackers have even managed to load entire Windows device drivers into the Linux kernel — a technique other developers have used to gain full read/write support for Microsoft’s proprietary NTFS.
The worst culprits, however, are graphics card drivers. Most Linux distributions come with open-source drivers that take care of the basics for most cards, but the specs for advanced features such as 3D acceleration are typically kept under wraps by hardware vendors, making it impossible for independent developers to support those features. If you want full use of the latest card from ATI or Nvidia you have no choice but to use a proprietary driver supplied by the vendor, which effectively loads a binary blob into your system every time you log in.
Is this an ideal situation? Of course not. But the reality is that the number of Linux users who are staunch open-source idealists pales in comparison with the number who defer to simple pragmatism: it’s better to put up with proprietary code than to give up a capability altogether.
Kudos to Intel then for not forcing us to make the choice. Intel recently announced fully open-source drivers for its 965 Express graphics chip set. The code is available under a combination of the MIT and GNU General Public Licences, no strings attached.
Could this be the start of a trend? With AMD acquiring ATI the possibility of an arms race between AMD’s and Intel’s graphics chip divisions seems increasingly likely. The benefits of open source for the vendors are clear: closer alignment with the Linux market and the ability to leverage community development to squash critical flaws such as the exploits that recently plagued Intel’s wireless drivers. If other vendors follow suit, it could be the beginning of a boom time for Linux hardware support.
It would be nice if VMware could get a little more open, too, but it’s going to take longer for some companies to shed their reliance on binary blobs than others. VMware is betting that its closed, proprietary code will always be better than anything the open source community can build on top of VMI.