[ Site Index] [ Linux Index] [ Feedback ]
The bottom line is zero
Lately I've been thinking gloomy thoughts. Probably it's the effect of autumn, the long nights drawing in, and the need for a regular paycheque, but one question has been on my mind lately. Which is: Why is it that, although Linux is doing well as a platform for users, companies that try to base business plans on it seem to be haunted by a terrible curse?Linux and free software are doing well, so well that we don't gasp with astonishment these days when we hear that the Bundestag (German parliament) is contemplating switching to Linux, or that the Scottish police forces have dumped Microsoft Office and switched to Open Office, that Sun are replacing their old proprietary Motif/CDE user interface with GNOME, and so forth. When a staid IT consultancy such as Gartner Group recommend to their clients that they ditch Microsoft's IIS (Internet Information Server) and switch to Apache because it's more secure, stable and reliable, it's fairly clear that the battle to be taken seriously has been won. In fact, being taken seriously can bring its own problems; the music and film industries seem to have decided that computers and the internet in general, and free software in particular, are lethal threats to their monopolistic grip on the entertainment market, and are taking steps to stamp on us (see "What the DMCA means to You" in Shopper 166 for more on this scary topic).
But the real puzzler is the Linux business itself. For an operating system that is now probably the #2 best-seller, it's generating remarkably little revenue -- and worse, companies who base their businesses on selling Linux products are piling up losses rather than growing. Or are they?
(First, the bad news. Then the hidden good news. Finally, a possible explanation.)
The Linux industry dates to about 1993 when, in Germany and the USA, some enthusiasts banded together to take a Linux kernel, the GNU utilities produced by the Free Software Foundation, the X11 windowing system from MIT, and a bunch of other stuff -- and burn it onto a CDROM and then sell the disk in a box with a manual. SuSE started small in Germany and remained a regional phenomenon until 1999, while Redhat started even smaller in North Carolina but snowballed amazingly fast. Other companies followed suit, building distributions; but not all distributions are corporate. In particular, the Debian project maintains a very high quality Linux distribution through volunteer labour -- and their product is sufficiently good that nobody has been able to come up with a Debian-based metadistribution that provides a compelling reason for not using the free product.
Distributors were the first wave of Linux companies, and the first companies to go public -- and the first to go bust. Stormix and Progeny (both Debian-based) have shut their doors. Yggdrasil have not been heard from for years. Corel spun their distribution off to a start-up in an attempt to keep it from sucking money out of their threatened balance sheet. Both Caldera and SuSE have recently lost money at a frightening rate (due to gearing up for expansion right before the onset of a worldwide recession) but managed to recapitalize privately and stabilize themselves, albeit with large job losses. Part of the problem is that you don't really need to buy a boxed Linux distribution if you want to run Linux; all you're getting is the media and the books, along with a cute installer and some credit for telephone installation help. The components of the distribution are free, and in an economic race to the bottom the customization work of the distributors tends to be free -- those who don't release their tools under an OSI approved license tend to be seen as bad players.
With this in mind, the distributors have moved towards selling support and services -- which are at least bankable assets. The big exception is Caldera, which is trying to go proprietary, charging a per-seat license fee for their distribution (which is in turn being pitched at big corporate customers who haven't heard, or don't care, about open source licensing and the Debian project).
In addition to the companies trying to sell disks, manuals, and bumper stickers (plus installation support), there's another good way to lose money on Linux; sell computers with it pre-installed.
One of the dirty little secrets of the computer industry is that Microsoft sells Windows to OEMs under some rather interesting license conditions. Vendors can get Windows at a fantastic discount -- if they agree not to sell machines with other operating systems, and plaster the desktop with whatever advertisements Microsoft deems right and proper. The standard OEM license is itself considered a trade secret by Microsoft; a vendor who talks about their special terms in public is in breach of the contract and loses their discount. (This is how Microsoft has managed to keep the contract out of the courts, to date: nobody is willing to cut the throat of their business, just for the dubious pleasure of testifying that Microsoft run an illegal price fixing cartel.)
A company that ships Linux servers can't ship Windows workstations at the same price as a company that sells only Windows boxes. So the nascent pre-installed Linux business tended to specialize -- and got hammered by the economic downturn. Take VA Linux, for example. (Your columnist owns shares in VA -- and wishes he didn't.) A huge proportion of their customer base consisted of dot-coms who wanted to run Linux on their public servers. When the bottom dropped out of the internet industry, the bottom dropped out of VA's business plan -- now the company is re-focussing itself on being a large-scale web portal and software business, but only time will tell whether they survive or not.
The thing about Linux is this: the software is free. This means that you can't make money by selling it -- someone will always undercut you. You can make money by selling books about Linux (with a CD enclosed), or by selling telephone support, or by selling machines pre-installed with Linux. But you can't make money off the software itself. The bottom line is zero.
But there's a way out of the abyss.
Take IBM, for example. IBM has got Linux religion. Linux now runs on every range of machinery that IBM sells, with the solitary exception of the RS/6000 minicomputers -- which run a strain of UNIX called AIX/5L (the "L" standing for "Linux compatible"). You can get Linux to run on your AS/400 minicomputer. You can run it on your S/390 or zSeries mainframe. You can go to the IBM online store and buy a T22 laptop with Linux pre-installed. They're even negotiating with Citizen about bringing their prototype embedded Linux wrist-watch to market. (Which would be surreal enough, except that Hewlett- Packard promptly announced that, erm, they're in negotiations with Swatch about selling their own Linux wristwatch, and that theirs would look better, so there. The mind, she boggles.)
Why did IBM get Linux religion, and is there a lesson in it for the rest of us?
A common misconception in the public media is that IBM is a computer company. Nothing could be further from the truth. IBM started life as the Holerith Tabulator Company, making punched-card sorters for the last US census of the 19th century. Along the way, they diversified into cash registers, typewriters, and anything else that was useful to business. Today, IBM's identity is less ambiguous -- they're a business solutions company. If your business has a problem, go and talk to an IBM sales rep and they will see if they have a solution to your problem. It could be anything from forecasting the weather to running a production line or counting sheep on a hillside in Wales -- if there's money in automating it, the odds are good that IBM will be in there.
What IBM sees in Linux is not simply a piece of software they can sell, or an operating system to put on their PCs to cut down on royalty payments to Microsoft. What they see is a pot of glue. Because Linux source code is freely available, it is comparatively easy to write device drivers for Linux that talk to odd bits of hardware. It's also comparatively easy to add protocol stacks for new types of network. People who do this sort of thing for their own use very often donate the source back to the common pool -- and the result is an operating system that can talk to old DEC mainframes using DECNet, serve files to Macintoshes via AppleTalk/IP, and interface to an Oracle database at the same time. If your problem involves counting sheep (using a Macintosh), printing sheep invoices using an old Vax, and you want to future-proof the system by storing all your transactions on a modern Oracle system, what better way to go about it?
Using VAXen, Macs, and Oracle is a bit of a stretch for IBM, but if you want to replace them with S/390 mainframes, PC's or AS/400 minis, and DB2 IBM would be all too happy to give you an account manager who will roll out the red carpet and steamroll over any pot-holes on the road to your becoming a 100% integrated IBM shop. And Linux makes a brilliant one-size-fits all glue/pothole-filler. (It's a floor polish! It's a desert topping! And it gets everywhere.)
Now we're probably going to see the next big company to IBM get religion. In the past couple of months, Hewlett-Packard and Compaq have merged into one mammoth corporation -- only a little behind IBM in size. Both HP and Compaq have incompatible ranges of UNIX workstation (running HP-UX and Tru64 UNIX respectively). The PC-end picture is clearer, but HPC faces the same vertical integration problem that bedevilled IBM for so many years. If the HPC merger doesn't hit the rocks, it would be astonishing if HPC doesn't look in the obvious place for the pot of glue that will let them integrate their disparate product ranges without having to terminate any particular lines.
Partitioning
On an entirely different note, I've been helping a couple of friends install Linux for the first time recently. While the warm fuzzy hand-holding graphical installers make this a lot easier than it used to be (anyone else remember slaving over a stack of Slackware floppies?), a couple of big gotchas are always lurking, ready to jump out and mug the unwary installer: and the biggest of these is partitioning.Just what is a partition, and why does it matter?
If you're new to Linux or UNIX, coming in from the Windows or Mac world, you may not be familiar with partitions. You're used to the idea of a hard disk; it's where you keep files, and it shows up as something called C: or "Macintosh HD". But your files don't actually live on the raw surface of the disk -- they are stored in a complex scheme called a filesystem, which in turn occupies only part of the physical disk surface.
The real structure is three layers deep. At the bottom, there's the physical hard disk surface, divided into sectors and tracks and blocks, each of which has a numerical address. Contiguous tracks can be assigned to a partition: each disk has up to four primary partitions, and a small section at the start of the disk, called the partition table, indicates where the boundaries lie. Within each partition there can be either a filesystem (such as the DOS FAT filesystem, or a MacOS HFS filesystem, or a Linux ext2 filesystem), or another 'extended' partition table.
Now, how does this affect you when you install Linux?
For starters, you have a choice: you may want to give the entire hard disk to your Linux system, or you may want to keep another operating system around (such as Windows ME). Mac users may even want to have three OS's to hand -- MacOS 9 (aka MacOS classic), MacOS X (which is based on BSD UNIX), and Linux. Each of these systems will want a partition of its own, formatted in its own manner, to boot from; beyond that, some of them can read filesystems in each other's partitions and some can't. For example, Linux can read just about every filesystem type out there, and MacOS can read Windows filesystems -- but Windows tends to refuse to acknowledge the existence of any other systems.
To make it even more complex, each operating system has its own partitioning requirements. Both Windows and MacOS use a hidden file to provide virtual memory; this lives within their bootable filesystem, and thus they can cope with a single filesystem in a single partition. Linux, however, prefers to use a separate partition for swap space (you can tell it to swap to a file instead, but this tends to be slightly less efficient).
And you need some idea of what you're starting from. Many PCs pre-installed with Windows today come with two partitions on their hard disk, configured as drives C: and D: respectively. But what if you're starting with just one? Or with a Mac?
This being the Linux column, I'm going to ignore issues associated with partitioning for Windows or MacOS. If you want to do that, you're on your own. Instead, here's how we prep a drive for Linux: if you want to add another operating system you just need to leave an empty primary partition for it.
The first thing to do is to decide if you're going to repartition the entire hard disk, or just the space occupied by drive D: (on one of those machines that provides a second DOS filesystem for you to store your data on).
Linux gives you a variety of tools to mess with your partition table. The classic one is fdisk -- similar to the old DOS utility of the same name, but more flexible. Linux fdisk allows you to delete and create primary partitions (numbered 0-3) on a hard disk. For example, to mess with the partition table of the first IDE hard drive, you'd issue the command:
/sbin/fdisk /dev/hda(while logged in as root). You can designate one of these partitions as an extended partition; fdisk then allows you to create scads of sub-partitions within the extended one. But note that extended partitions aren't bootable. The Windows/DOS fdisk only knows about DOS filesystems, but the Linux version gives you a huge table of partition types to choose between. Each partition has a two-byte flag to indicate what it is; the common useful ones are 82 (standard ext2 filesystem for Linux) or 83 (Linux swap partition). Fdisk isn't a friendly program, but it's not the only option on offer. Redhat wrote something called Disk Druid, which attempts to take the pain out of partitioning. Then there's cfdisk, a CURSES-based fdisk replacement that actually has menus and some online help. If cfdisk doesn't give you the warm fuzzies, there's GNU Parted. Parted isn't widely available on general Linux distributions yet, but has the ability to resize existing partitions (and the filesystems saved in them) rather than simply destroying them and letting you create something to fill the hole. Finally, all the major distributions provide some kind of graphical tool for editing the partition table while you're installing Linux. When preparing to install Linux, you can get by with a single partition, if you manually set up swap space in a file. But it's sensible to use two partitions; one to contain your filesystem, and one for swap space. The swap partition should ideally be roughly twice the size of your system RAM -- if you have 512Mb of memory, you want 1Gb of disk space assigned to the swap partition. Of course, not all your files need to live on the same filesystem -- and indeed it's usually a good thing if they don't. For example, to recover a deleted inode (file) you really want a second filesystem to save it to. Again, you may want to encrypt your personal files -- stored in your home directory, under /home -- and the system spool directories stored under /var. To do this effectively you really want to have /home and /var as separate filesystems stored in separate partitions, using some encryption scheme (such as the loopback driver provided with SuSE 7.2 and later). This leads to filesystem proliferation: we're now looking at a system that wants:
- a partition for the root filesystem, /
- a partition for swap (virtual memory)
- a partition for the filesystem for home directories, /home
- a partition for spool directories, /var
- a partition for Windows to boot from (maybe!)
That's five, and we can only put four primary partitions on a disk. So how do we plan a disk layout? The first thing to do is to decide how much space we want for Linux. Suppose we've got a 20Gb hard disk, and we know we want to leave 5Gb for Windows, that leaves us with 15Gb. Our machine has 256Mb of RAM, so we need to leave 512Mb for a swap partition. So we know that our basic partition layout should look a bit like this:
Partition 0 - 5000 Mb, reserved for Windows Partition 1 - ??? , for Linux Partition 2 - 512 Mb, reserved for Linux swap Partition 3 - ??? , for Linux A smart move would be to make Partition 1 really small. It's going to store a simple Linux ext2 filesystem, mounted on /boot. /boot is where FHS compliant distributions keep the bootable kernel, a ramdisk image with loadable kernel modules, and other stuff needed to get it up. This can be quite small; 64Mb is fine. Keeping the kernel on a small filesystem means we can use LILO, the boot loader -- which has to be able to read the filesystem vmlinux lives on -- without being restricting to an old-fashioned ext2 filesystem for our root filesystem.
We'll now examine Partition 3, which is where everything else needs to go. We're going to create an extended partition within Partition 3, and a bunch of sub-partitions. Let's create three sub-partitions, numbered 4-6. The lions' share of Partition 3 is going to go into #4: 5Gb of space, which will contain our root filesystem, /. This should be formatted as ext2, for speed: it's where all the system software (except the boot kernel) is installed. #5 gets just 512Mb, which is plenty to spool news and mail in; it wants to be an ext3 or ReiserFS filesystem, and we're going to mount it on /var. Finally, partition #6 gets everything else. It's also a ReiserFS or ext3 filesystem, and it lives on /home; it's where your personal files live. Both /var and /home are to be formatted as ReiserFS or ext3 because these are journaling filesystems -- you won't lose data in event of a crash or power failure.
If using SuSE, you might want to flag /home and /var as encrypted filesystems. But remember not to lose the password, otherwise you won't be able to retrieve anything you've stored in them!
So at the end our filesystem plan looks like this:
+ /dev/hda | +---- /dev/hda1 (Windows, 5Gb) | +---- /dev/hda2 (Linux /boot, 64Mb) | +---- /dev/hda3 (Linux, swap, 512Mb) | +---+ /dev/hda4 (Extended partition for Linux, containing ...) | +---- /dev/hda5 (Linux, /, 5Gb) | +---- /dev/hda6 (Linux, /var, 512Mb) | +---- /dev/hda7 (Linux, /home, 8.9Gb)Confused, yet? We haven't even looked at the Logical Volume Manager, Linux's built-in RAID system that allows us to build filesystems that span multiple disks and partitions. That'll wait for another month; in the meantime, this is roughly how my laptop is laid out (minus the space for Windows, of course).
Happy installing!
[ Site Index] [ Linux Index] [ Feedback ]