Linux has fought its way to the gates of the enterprise by equipping itself with smoother installs, better usability and a wider range of applications. But as it approaches victory, is it also adopting some of Microsoft's more controversial technical practices and becoming too Windows-like?

One partition to rule them...
Microsoft's first questionable design choice is the single C:\partition that blends together boot, system, application and user data. It stops administrators taking user data offline for, say, a file system repair, while leaving the rest of the system running. It also encourages sloppy file storage habits in users, who collect data files in My Documents, in the C: drive root, in application subdirectories of Windows' Program Files folder and in user-created directories in the C:\ drive root. Some Linux distributions have inched closer to the same choice. Red Hat's default installs drop everything except the /boot partition and swap space into /. Installers can manually fix that behaviour after Red Hat's Disk Druid partition tool has set up the disk, but it would encourage good data storage practice if Red Hat installs "suggested" a separate /var partition and preferably a separate /home partition, leaving administrators to resize them or move them back into the / partition if required.

Pre-packaged installs and DLL hell
Easier application installation is a key factor in encouraging Linux adoption by the enterprise. Binary package installation files, such as Debian's .deb and SuSe/Red Hat's .rpm packages, are fighting hard to reduce the traditional three-step process of "unpack, configure and make" to a more Windows-like routine of "double-click setup.exe". The goal, of course, is to cut down the system knowledge required by application installers in order to save time and reduce salary requirements. The problem with the packaged binary approach is that it creates opportunities for application installations to fail due to dependencies that may not be met, depending on how well the package was built, as well as the state of the target machine's operating system. That would be no problem if business scenarios always provided plenty of time for audit, requirements gathering, research with vendors and for fixes, before applications are installed. The fact that businesses do not operate with adequate lead-time creates opportunities for a Linux version of Windows' "DLL Hell". Faced with an urgent request for a simple CRM system that would enable a customer to make sales and collect sales prospect data until a customised CRM system became affordable, Seattle-based integrator CoroWare tried to prepare demonstrations of Microsoft CRM and Anteil's open source OpenCRM. What follows is a commented trace of the Open CRM demo install:

[[email protected] OpenCRM]# rpm -ivh anteil-1.1.1-1.i386.rpm
error: Failed dependencies:
usr/local/udb/bin/format is needed by anteil-1.1.1-1

Comment: this suggests we need to install the udb package first.

[[email protected] OpenCRM]# rpm -ivh udb-1.8-25.i386.rpm
error: Failed dependencies:
libtbr.so is needed by udb-1.8-25
libudb.so is needed by udb-1.8-25

Comment: two missing libraries are preventing this install. They appear to be in an earlier version of the udb package so let's try installing that and then the later package.

[[email protected] OpenCRM]# rpm -ivh udb-1.5-1.i386.rpm
error: Failed dependencies:
libdb.so.3 is needed by udb-1.5-1
libmysqlclient.so.6 is needed by udb-1.5-1

Comment: this package has its own library dependencies that should be resolved first. Google says libdb.so.3 is on the rpmfind website, so install it, install libmysqlclient.so.6, then work backwards to udb-1.8 and thence to anteil-1.1.1-1

[[email protected] OpenCRM]# curl -O ftp://rpmfind.net/linux/rawhide/1.0/i386/RedHat/RPMS/compat-db-3.3.11-3.i386.rpm
curl: (9) Couldn't cd to i386

Comment: libdb.so.3 seems to be unavailable and we are now way out of scope for a simple demo install. After this, CoroWare presented only Microsoft CRM, which the customer selected. Anteil subsequently told us that the libtbr.so and libudb.so libraries required by udb-1.8-25 exist in the package itself. That means the original error message was inaccurate and the subsequent research unnecessary. A perturbed Anteil said it will release newer RPMs but that it anticipated that OpenCRM would usually be installed by programmers.

Buggy drivers
Windows has something of a reputation for buggy device drivers. According to Microsoft, bug-ridden device drivers are the single most common cause of Windows crashes. In response, Microsoft introduced driver signing and system rollback in Windows 2000. System rollback allows a system to be rolled-back to a state prior to the addition of a driver or application that is subsequently found to be buggy. A quick search for the phrase "buggy Linux module" on Google will show that buggy drivers are not limited to Windows. However, provided its drivers are being installed as kernel modules (rather than compiled into the kernel itself), buggy drivers can easily be taken out of service until fixed. Where Linux has a more disabling driver problem - from an enterprise perspective - is in the poor, or slow, availability of drivers. Take 802.11g - the 54MB/sec. wireless protocol for which manufacturers are now churning out cards. Their lack of Linux support has left half the open source community trying to reverse-engineer drivers for the common Prism and Atheros wireless chipsets, while the other half tries to wrap 802.11g Windows drivers in compatibility layers from the ndiswrapper project, or from Linuxant. The result is complex install instructions and - often - insufficient return on investment. The installation instructions for Prism54.org's Prism GT/Duette driver are a good example. They show fantastic engineering, but deployments based on either of the complex methods described there are unlikely to win anyone a "Productive Employee of the Month" award.

The Windows' registry
Yet there's one area where Linux has robustly avoided the urge to fail the Windows way - the registry. Windows' registry is Microsoft's attempt to build a machine readable system and application configuration file that is easily backed up. It uses "typed definitions" to prevent poorly written software from writing configuration values that might crash the system. But the Registry's obscurity, and Microsoft's own warnings about touching it, have made it a haven for malware writers. In it, they leave stub code that reinstalls Trojans or that works with Internet Explorer's own vulnerabilities to track user activity, knowing that users will not easily find or fix it. Useful features that are easy to customise on Linux - such as the history file that "replays" command line instructions - are an obscure and risky edit in Windows' Registry. Over time, system performance will slow if it is not cleaned -and most engineers are familiar with the deadly consequences for the boot process if one of its files becomes corrupted. The best known effort to create a Linux Registry is Yodanet, which aims to eradicate inconsistencies in multiple text configuration files and reduce Linux configuration backup to a single file-copy task. How little the open source community shares that goal is evident from Yodanet's forum, which lies dormant. The Casbah project - proposed writing Linux configuration files into a single XML human-editable text database called Coptic. That effort has been dormant since September 1999. The Windows registry is a feature that Linux is unlikely to emulate soon. But beware the day the open source community proposes registering system/application configuration details in a central mySQL database.

In summary…
So, has Linux emulated Windows? In part, yes. And in some areas the open source effort has produced a worse effort than the proprietary route, especially when it comes to driver support. But when it comes to architectural issues, the open source community has so far avoided the worst sins of Windows' lashed together architecture. The real question, which only you can answer, is why it matters...