In his inimitable way of imparting wisdom, baseball Hall of Famer Yogi Berra once said, "When you get to the fork in the road, take it." There are many reasons why this quotation is funny, not the least of which is that it doesn't make sense. But many in the tech community seem to be displaying a similar lack of understanding when it comes to forking.

Many pundits and industry leaders are predicting that Linux will fork or even saying that it has forked already. The main contention is that Red Hat Linux is moving away from other Linux distributions so that applications written for Red Hat Linux may not easily run on those other distributions.

What's unsaid but implied in these discussions is that Linux will fork in the same disastrous way that Unix did. The forking of Unix led to many separate and incompatible versions of the operating system and, to many people's minds, reduced Unix's competitiveness. Those who see Linux going down the same road believe Linux applications will eventually work on one Linux variant or another but not on all the distributions.

Some of you may agree with these predictions. After all, there are applications that are much easier to install on Red Hat Linux than on other Linux distributions. And there's still the issue of GNOME desktops versus KDE desktops. But there are some pretty big differences between Linux and Unix. The biggest difference, by far, is the Linux kernel itself.

When Unix forked, each variant had a different kernel. In other words, the core code of each Unix system was unique, which often resulted in incompatibilities and difficult cross-platform application integrations.

In contrast, the Linux kernel is tightly controlled by Linus Torvalds and some core Linux code keepers. As long as these people are around, there is little chance that the Linux kernel will fork like the Unix kernel did. The only differences among Linux distributions in terms of kernel is which version of the kernel each is based on.

That's not to say there aren't other differences among Linux distributions. There are, but getting around any problems these differences may cause is usually just a matter of adding more libraries or configurations.

As a point of comparison, the differences among Linux distributions are fewer and smaller than those between Windows 2000 and Windows XP. But the majority of applications developed for Windows 2000 will run on Windows XP with no changes required.

In fact, the biggest problem when it comes to applications running on multiple Linux distributions has nothing to do with code differences. The problem lies with large-enterprise application vendors certifying their applications for only one flavor of Linux—often Red Hat. The new Oracle 10g database, for example, runs on Linux, but Oracle provides support only for Red Hat Linux and SuSE. If you want to run Oracle 10g on any other Linux variant, you're on your own.

This is a significant issue, and businesses should demand that application vendors support products on whatever version of Linux a customer wants to use. And don't let the vendors tell you that they can't afford to do this or that support would suffer. The support differences among Linux distributions are minimal at most, especially if the application vendor builds an installer that demands certain requirements.

We'll probably see plenty of fallout and changes in the Linux market in the near future. Some distributions will probably fade into obscurity, and we'll most likely wind up with two or three major distributions that the majority of companies use.

And these distributions will have some differences—after all, it is a competitive market, and vendors do have to differentiate their products. But the distributions will all still be Linux, and they will all share the same underlying kernel and code base.

So when you are looking at different Linux distributions, pick the one that best fits your needs and have confidence that any Linux application will run on it.

And save the forks for dinner.

source :,1759,1561821,00.asp