It's been tiring to hear the way both salespeople and insiders at vendors of proprietary Unix systems sneer at Linux. The conventional wisdom appears to be that Linux is many years behind mainstream Unix in areas of high-end scalability and performance. Sometimes such claims even show up in public. But even when the complaints are accurate I don't see the resolution being "many years away." Linux vendors say they're on top of it.
I heard similar whines about GUIs a few years ago, and from here it looks like the Linux desktop has surpassed the tired Unix offerings of Motif and CDE, both in usability and popularity. So let's turn to the area of big iron, and see just how long it will take before Linux can play with the big boys.
Linux vendors know the path they need to take, but at the present time that path goes through a minefield. Here's the problem: Some current solutions geared toward making Linux more usable on very large systems exist, and they've even been offered to the kernel development group. But they've been rejected, mainly because they demand tradeoffs that would hamper Linux performance on small systems. (A scheme that might allocate a bunch of megabytes of RAM for a special caching technique wouldn't run too well on a box that only has a couple of megabytes of RAM, period.)
So, when code containing solutions to some big-iron problems was offered to the kernel group by a well-known three-lettered hardware vendor, it was rejected. Compounding the problem was that some in the kernel group didn't even like said solution for large systems, and other opinions held that SMP-type multiple-processor systems were a poor answer to the issue of high performance in the first place. Whether you can guess the three-lettered hardware vendor or not doesn't matter, because the same problems apply to all big iron vendors.
Then there's the issue of trying to keep the core simple and straightforward, which is a key goal of chief cat-herder Linus Torvalds. "A lot of the problems, especially with NUMA, are that the solutions tend to add complexity that simply isn't needed at all on 'normal' machines," he said. (The NUMA clustering architecture is but one component that big-iron vendors would like to bring into the Linux kernel.)
Should the Linux kernel group be dictating to hardware manufacturers how to architect their systems? Of course not. But neither do hardware vendors have the ability to force the standard Linux kernel to make tradeoffs or implement "features" that kernel developers don't want. So how does a hardware manufacturer implement optimizations for their own high-speed architecture, or for large systems in general, that may conflict with the best overall compromise position of the Linux kernel group?
Last week I was presenting at a conference where I met up with an executive of the previously mentioned three-lettered company, who felt stuck between rocks and hard places. The company wanted to get the most out of its hardware but also wanted to keep in the good graces of the open source community. The company was concerned about what to do with its big-iron code that had been rejected. Most importantly, the company wanted to avoid the use of that awful four-letter word beginning with "f":
Fork.
The GPL open source license used by the kernel inherently allows any company to make changes to the kernel, providing the changes themselves are all open source. This is not the problem. Of far greater concern was said three-lettered company's fear that it would be perceived as trying to take a big-iron mutation of the Linux kernel into a different direction, never again to converge with the 'official' one maintained by Linus Torvalds & co. The creation of such a mutation would summon the demons of Unix wars past, and we'd all be engulfed in eternal hot stuff.
It doesn't have to be that way. It's possible to create and maintain the large system stuff in a consistent manner, in the form of patches that can be applied to conventional distributions. As the distributions progress, the patches can be updated to work against them. That way the big-iron system never diverges significantly from the core, it simply provides a parallel path that stays alongside conventional Linux without drawing away from it.
We already have some examples of this, the best known being SGI's ProPack. Rather than do its own big-iron distribution, SGI chose to provide a set of packages that install on top of conventional distributions (in this case, either SuSE or Red Hat). This is the Right Way to do things and I hope to see more of it. Maybe Caldera will see fit to contribute UnixWare code to the open source pool, so we can see just where the tradeoffs are and how much needs to be outside a general-purpose kernel.
The process of non-standard kernel patches is just fine with Torvalds. "On the whole we've actually tried to come up with compromises that most people can live with," he said. "It's fairly clear that at least early on you will see kernel patches for specific uses -- that's actually been going on forever, and it's just a sign of the fact that it takes a while to get to a solution that works for all the different cases." He continued:
"That's how things work in Open Source. If my taste ended up being the limiting factor for somebody, the whole point of Open Source would be gone."
Indeed. I would also hope to see vendors agreeing on a consistent way to develop big-system kernel modifications. After all, we already have a consortium formed to handle many of the same issues in the opposite direction, for embedded Linux on small systems.
Unfortunately, it's been my observation that cooperative ventures between big-iron vendors don't produce staggeringly productive results. (Need I go further than CDE itself?) That won't stop me from being optimistic here. Maybe the spirit of the Linux community will actually have some of these guys inspired to move -- albeit slowly and cautiously -- in the same direction: Forward.
Do you think Linux vendors are ready to make the leap into big iron? Let me know in the TalkBack below.
