April 1999 Column

April 1999 Column


[ Site Index] [ Linux Index] [ Feedback ]


Bandwagon rolling

It's been another busy month in the world of Linux. A recent survey by IDC pegs Linux growth through 1998 at 212%, and gives Linux 17% of the total server operating system market -- as much as all the other flavours of UNIX put together. The speed of growth has taken vendors by surprise; but some of the big OEMs are finally jumping on the bandwagon. It may all fade away: certainly in part it is fuelled by Microsoft's perceived weakness in the face of multiple legal assaults, and by the apparent fact that Linux is replacing Java as the banner around which the anyone-but-Redmond crowd are rallying. But if even half the muttering is true, interesting times lie ahead.

The next big business stampede is going to be pre-installed Linux on servers. Servers are in fashion right now; basically just a PC tipped on its side, with a network card and the right server software installed, they act as workgroup hubs and provide mail, print, and file services to other systems. Linux, of course, is pretty good at this sort of thing, to the point where it could give such a product a distinct competitive edge over a Windows NT or 2000 server -- an edge worth a couple of hundred pounds and some extra feature points in a crowded and competitive marketplace.

Up until December 1998, you could only buy such boxes from smaller OEMs like VA Research; the big box-shifters like Dell and Compaq would quietly sell diskless servers, but wouldn't officially support Linux. Linux was taboo: just mentioning it might well screw their licensing agreements with Microsoft, to name but one. (Microsoft loves per-CPU licensing, because this naturally gives the OEM an incentive to put Windows on every machine.)

But we've seen this before. In March 1998, about the only databases you could get for Linux were free or marginal ones. Then the stampede began, and today you can get Oracle, Informix, Sybase, DB2 -- all the big names except Microsoft SQL Server and Access. A similar stampede has just started in the server market.

Compaq just announced that they're going to be shipping Linux pre- installed on some of their servers, and providing 24x7 support. Gateway 2000 are also going to be shipping Liunx boxes some time in the next few months. Rumours are circulating about a possible Dell product launch, targeting the low-end server market with a Linux box. Nobody quite knows what IBM is thinking, but they're already developing some expertise in the Linux world by way of DB2 and Apache. I doubt that IBM will be the last company to announce a Linux product. I'm going to stick my neck out and predict that by June the big question won't be "will Dell support Linux"; it will be "who doesn't support Linux, and why?"

This really is quite remarkable, when you consider that some of these companies (IBM, Compaq) have their own competing UNIX flavours. By reselling Linux, Compaq may well be hitting sales of Digital UNIX (or D/UX or Tru64Unix or whatever they're calling it this week -- it's always a bad sign when a company starts renaming products on a daily basis). But once a market sector begins to stampede, anyone who tries to go against the flow gets trampled in the rush. In the case of pre-installed Linux servers, the same "market externalities" that enabled Windows 95 to gain a stranglehold on the desktop apply. People run Windows not because they like it, but because they need to be able to run the same applications as everyone else. Application developers in turn develop first for Windows because they know that's where the users already are. Sheep have a herding instinct, and once enough of the herd begins to zig instead of zagging, the rest will feel panicky and out on a limb until they too are zigging.

This is having knock-on effects. Lower down the food chain, the people who build the chips and boards that go in the integrated PC's are waking up. Creative Labs recently advertised for a Linux specialist to work on drivers for their SoundBlaster boards; they're not the only people out there doing this. Currently, most hardware components come with Windows drivers; some come with MacOS extensions, but Linux drivers are unheard-of. This will certainly change over 1999, especially once people like Compaq and Dell start requiring Linux drivers from their suppliers. The real question here is whether or not the open source model will apply; are we going to see closed-source proprietary drivers that only work with a given kernel version distributed by some big box- shifter? Or are we going to see open driver source code freely available on the net? I'd like to think that the open source driver business has enough momentum to bowl over any vendors who try to go against it; closed drivers will simply be cloned and replaced by better, open ones. This already seems to be the case in some areas. For example, Linux has historically been short on scanner and digital camera drivers. But a quick look at SANE) shows an interesting , extensible architecture for running scanners and imaging devices on Linux. It will probably be easier for vendors to simply write SANE plug-ins than to re-invent the wheel.

There are even signs of growth, outside the Intel world. Applix figure that PowerPC Linux is a big enough market to be worth porting and selling the ApplixWare office suite; quite a remarkable discovery, given that PowerPC hardware is a minority pursuit, and PPCLinux is a minority pursuit of a minority pursuit. Even wilder rumours are circulating that Apple, of all people, are considering shipping a Linux system. (This would be quite remarkable, given that MacOS X Server is basically a high-speed collision between BSD 4.4 UNIX and the venerable Macintosh System. One possible sneaky reason is that PPCLinux is likely to be more stable in general use, at least initially; MacOS X may be a great leap forward from the non-memory-protected MacOS world, but it's still largely a new system with quirks and bugs to be ironed out.) As a point of note, if you have a Power Mac, you might want to look into LinuxPPC. And if you've installed Linux on your PowerMac and still want to run Mac applications, you can do worse than investigate SheepShaver. (Real nutters who want to run Mac applications on Intel Linux boxes will have to be content with something like Executor from ARDI.)

In the software development sector, IBM are apparently uncertain how to deal with the eye-watering demand for their DB2 database (betas of which are free for downloading now). In the wake of serious enquiries from banks and big businesses with deep pockets they've realised that DB2 on Linux isn't going to be just a plaything for bored computing students, and maybe they can make money out of it. No announcement has yet been made about commercial support for DB2, but it's looking increasingly likely.

All this wibbling about commercial outfits notwithstanding, it is important to remember from time to time that Linux is, essentially, a free software phenomenon. In the past month or so, Kernel 2.2 should finally have arrived, although new features are still being integrated (and at the time of writing they're still working on bugfixes, so that it doesn't follow the 2.0 kernel's example and go through twenty updates before it's stable enough for J. Random User).

If you're more interested in a pretty face than support for NT filesystems, KDE 1.1 should keep you happy. KDE 1.1 is an incremental improvement over the last version, and it's acquiring the sheen of useability that indicates a really solid piece of software. It's themable; you, too, can have windows that whistle at you and make lewd suggestions when you move them, or a desktop that looks like a nest the hive-queen from ALIEN would have been right at home in. The key bindings and mouse actions are a lot more configurable, and you can have a single context-sensitive menu bar at the top of the screen (like the Mac) if you dislike the one-menu-per-window layout common to X and Windows applications. There are bags of extra little utilities, screensavers, and widgets to make life easier, including the excellent disk navigator (a pop-up menu that literally lets you go anywhere accessible in your filesystem and acts as a repository for recent applications and files). I'm using KDE 1.1 as my working environment, now, and it feels a lot slicker than the usual lash-up of window managers and applications with bizarre custom widget sets.

Meanwhile, GNOME has reached version 0.99.3. I'll be testing it out soon, and hope it can live up to the competition from KDE: Linux is about diversity, and the advantage of having two big desktop environment projects is that good ideas from one creep into the other. I use KDE because it showed up in a usable form before GNOME was available: once GNOME hits 1.0, I'll be able to make my choice on the basis of which environment I prefer to work in. (It's a far cry from the "one size fits all" approach of the Mac and Windows worlds.)

Choosing a Distribution, Part One

There's a lot of confusion about what Linux is, and what a distribution is. Technically speaking, Linux is just an operating system kernel. It is a piece of software that runs on the bare metal of your computer, and provides services to other programs (such as memory management, scheduling, inter-process communications, access to shares resources like filesystems, disks, serial ports, and so on). Linux was originally written by Linus Torvalds, and is now maintained by Linus, Alan Cox, and a host of others.

But what most people mean by Linux is something quite different: they mean an environment in which they can work, with everything from a graphical user interface to tools for manipulating files; not just a skeleton you could build such a system on top of.

In the beginning, around 1992, if you wanted a complete system you had to build it yourself. You had to patch the kernel by hand once you'd laboriously copied it onto your reformatted hard disk, so that it would recognize that it was running on an appropriate type of device instead of a floppy. Then you had to copy the basic tools into the right directories -- things like ls and cp and rm -- then use them to copy in the shared libraries and GNU C compiler, and finally begin compiling and installing everything else. It was all a bit like building a kit car; you had to know a lot about auto engineering before you could drive to the shops.

Around 1993-94, this began to change. Some shareware libraries were finding an increasing demand for Linux; and some Linux users had the idea of putting the whole thing on a set of floppies (or a CDROM) so that they could get a basic system running without having to bolt it together the hard way each time. Such a system is called a distribution, because it's redistributable -- the older kit-car systems were one-of-a-kind items, so tightly tailored to the machine they ran on that they probably wouldn't work on anything else.

The whole installation would go into a spare disk partition, not occupied by something like DOS or Windows. Using the LILO boot manager, you can select which partition you boot from. Using the FIPS repartitioning tool, you can scavenge space from an under-used Windows partition and make it available for fdisk to repartition for use by Linux.

The first distribution was SLS (Soft Landing Systems), which evolved into Slackware. SLS Linux consisted of a set of floppy disk images divided into alphabetized categories (sometimes more than one disk per category). You used a boot floppy to load a RAM disk then boot a minimal Linux system off it; this would then run an installation script which would copy files from floppy disks as you inserted them. The packages were typically gzip-compressed TAR archives -- known as tarballs -- containing all the files associated with one task; you could selectively install different tarballs, or upgrade a subsystem by overwriting its tarball with a more recent one.

Tarballs leave a lot to be desired. They're the UNIX world equivalent of a DOS/Windows ZIP file: a group of files stored in one compressed bundle. The problem with this is that lots of Linux subsystems share files. As with most modern operating systems, Linux uses dynamically linked libraries of code that can be shared between programs; this means that programs can be smaller (they draw upon shared libraries when they need to load some features, instead of having to duplicate the common code) and use less memory when running (two programs can use the same shared library simultaneously, so the code need only be loaded once).

But suppose you have two packages, A and B. Both of them rely on a shared library called C. Both tarballs, in fact, contain a copy of C, just in case. But A is linked to C version 1.01, and B is linked to C version 1.02. If you try to run B with version 1.01 of the library it won't work, because it requires some feature that was only added in version 1.02. Now suppose your installation package tries installing both packages, A and B. If you install A then B, you will get version 1.02 of the shared library C, and both packages will run. But if you install B then A, version 1.01 of C will overwrite the copy (version 1.02) installed with package B, and the result is that B will stop working.

This nasty problem is called a package dependency conflict; packages B and A depend on C, and moreover they depend on specific versions of C being in place. Tarballs have no mechanism for resolving package dependencies, which is why the Linux world has latched onto a couple of more sophisticated package formats for distributing software.

The format that seems to be winning is RPM, the RedHat Package Manager format. RPM archives contain dependency information; in our example above, if you tried to install the packages in the wrong order, the RPM tool would spot the problem and alert you before you could blow away another package. RPM has other advantages; programmers can add post-installation scripts to their files (to do things like set up machine-specific databases and configuration files, or ask the system administrator useful questions). RPM is open source, fully documented, and currently used by several leading Linux distributions -- Red Hat, Caldera, and SuSE. It is also used by some meta-distributions.

Note, however, that RPM went through some hairy evolutionary stages. You can't install a recent RPM file on an antique Linux system because they've been extending the RPM format. And there's a big split right now between distributions that use version 5 of the standard C library (libc), and those which use version 6 of GNU libc. (GNU libc adds native multi-threading for applications, and of course breaks everything that came before it.)

Debian, the GNU Linux people, chose a different package manager, the DPKG system. I'll discuss this when I get around to covering Debian Linux.

Anyway. We now know roughly what a distribution is -- it's a collection of Linux software that can be installed to give you a complete, working system. It relies on some sort of packaging mechanism which should also track dependencies between applications.

Which distributions are available? How do you get them, what do they come with, and how do they differ?

The original commercial distribution was Slackware. Note that "commercial" is not used here in the same sense we might use it of, say, Microsoft. (You can get all the main distributions for free, and copy them freely. Indeed, InfoMagic sell a Linux Developers Resource 6 CDROM collection, updated quarterly, that consists of the free editions of the main commercial distributions.) The distribution companies don't mind this copying: they make their money by selling support services, not by building and selling software, so free copying is just free advertising.

I'm not going to dig into Slackware here. It indisputably works, and works well. However, if you want to upgrade anything you need to be able to handle dependency conflicts the hard way -- it relies on tarballs for installing files, and has no dependency checking mechanism. The safest way to upgrade a Slackware system is to compile and install the source code by hand. This can result in an efficient, finely-tuned system; however, it doesn't make for a distribution that is easy for neophytes to play with.

Probably the most popular distribution overall (at least outside of Germany and Japan), and the one everyone keeps talking about, is Red Hat Linux. Red Hat started out as a two-man startup in 1994, specifically to bolt together a linux distribution. They met the package dependency problem early on, and came up with RPM as a solution; the result is probably going to be pigeon-holed as industry history in a few years, if anyone cares.

If you buy Official Red Hat Linux, you get a box, a couple of CDROMs (including the source code as well as a bootable installation CD), a couple of floppies (in case your PC can't boot off a CDROM), and a book. You also get a cute bumper sticker and a registration card that entitles you to two months of installation support. This seems to be about par for the course among the commercial Linuxes.

Red Hat's installation script is pretty straightforward; personally I find it no harder to live with than the Windows 95 installer, and a trifle easier than MacOS 8.5 (despite the fact that both those systems throw up lots of pretty icons and pictures while Red Hat simply uses some character-mode menus and forms). The installer is extremely flexible, giving you the option to mess around with virtually any packages you want. If you miss anything important out it will warn you and automatically fix any dependency problems before going ahead.

Feature-wise, Red Hat is fairly good. It doesn't include KDE, however: Red Hat don't consider the core Qt library's licensing policy to be acceptable for free software, so instead they are backing the GNOME desktop environment. (A pre-release of GNOME comes with Red Hat 5.2, the current release.) Since release 5.0 Red Hat has been based on GlibC; the current 5.2 release is fairly stable and also includes the egcs experimental optimizing C++ compiler (while retaining traditional GNU C 2.7.2 as a C compiler). X11 configuration isn't fully automatic, but some attempt is made at walking the user through setup while Red Hat installs it. There's also a rather ho-hum set of macro-driven X11 configuration scripts that set up a couple of different desktop look-and-feel environments (including a NeXTStep-like one and a Windows-like one). To their credit Red Hat include a fairly comprehensive system administration front end (control-panel); and unlike SuSE and Caldera, they include sound support (albeit only for a limited range of cards, such as the original Sound Blaster and SB16) out of the box.

I rather like Red Hat; I run it on most of my PC's. However, I've been using Red Hat since release 2.1, back in 1995. If SuSE or Caldera 1.3 had been around then, I might be singing a different song now -- and I still might be, in a release or two's time. Next month I'm going to continue talking about distributions, with a discussion of the pros- and cons- of the RPM based kits and the other solutions (such as Debian), and a look at meta-distributions.


[ Site Index] [ Linux Index] [ Feedback ]