Tuesday, July 27, 2010

Conspiracy #2 - Linux

If you've heard of Linux, which I imagine most people have, and you don't work for Microsoft, you probably have the impression that it's the best thing since sliced bread (a fairly low standard I should add, since sliced bread is no match for the real thing). People are falling over themselves to extol the benefits of community software development. But there are several issues that are clearly problematic.

1) Even software that is not in the "long tail" (e.g. Linux, Firefox) has components that are: dmraid, the module that supports fakeRAID seems currently to have only one developer, Heinz Mauelshagen (who is also responsible for LVM2), and in 6+ years since its launch is still a release candidate, not a stable production version. LVM2 is used in the default partitioning scheme in Enterprise Linux (including Rad Hat, CentOS, Scientific Linux)so Mauelshagen's time must be in great demand for LVM2 issues which perhaps explains the slow progress on dmraid?

2) There is the leading edge (such as Fedora 13 at the time of writing) and other 'experimental / testing' distributions, and the trailing edge (enterprise systems). The former have great hardware support, but can be flaky since the interdependence have not been debugged. The latter seem to lack breadth of hardware support - my 1920x1080 VGA /1680x1050 DVI dual displays on and old ATI Raden card were unsupported by the community developed drivers in CentOS and Scientific Linux. Using the ATI propriety driver helped a bit but there were all sorts of unexpected interactions between the community developed interface and the configuration file (xorg.conf) and the ATI supplied interface; neither write the file in a way the other understood and often the result was to completely confuse Xorg which then wouldn't start.

So my plan to avoid the problems of only partially debugged software (Ubuntu 10.04) ran up against a lack of functionality in CentOS and Scientific Lunix.

Why a conspiracy? Partly it's the frustration talking. But perhaps this is a situation that the key users and recommenders (who are in many cases also the authors) of Linux like; it makes their jobs safe. If they convince the organization for which they work to use community software, which is often not completely up to the task out of the box, their role in supporting IT becomes more pivotal, their jobs safer and their salaries higher.

Of course they won't see it that way - they probably believe they are providing an invaluable service to the organizations for which they work by managing a computing infrastructure that doesn't involve costly licensing fees. Their own time is seldom something they add into the cost-benefit analysis, since (they need to assume) this is a given, a fixed cost that is a wash whatever OS is selected.

Of course, nothing is perfect and MVS had bugs too. But I wonder how many of the large (or small) retail banks run their transaction processing systems on Linux?