The following post has been sitting in my “drafts” section of WordPress for a good while. I don’t know why I never posted it — it’s been there for more than a year. I think I just thought the article deserved such careful attention that I never sat down to really edit it and prepare it for publication.
The topic is on the common criticisms of Linux, and I think it’s time for me to finally post my thoughts, given the upcoming release of Windows Vista and related products.
Awhile back, /. posted an article entitled “Is It Wrong to Love Microsoft?” The article is horribly written, but does have one point to make: why is it that on /. and other technology news sites like OSNews and Kuro5hin, everyone loves Linux almost unconditionally, and hates Windows unequivocally? I personally am unfond of blind faith as much as I am offended by blind hatred. I’ve thought long and hard about the pros and cons of Linux and Windows, and think I can come up with a pretty balanced evaluation of the two.
Oftentimes the criticisms thrown at Linux are hard to parse, mainly because the authors of these criticisms don’t know much about system design themselves. Having studied it at University, and having been a 10-year user of Windows and Linux (and a 6-year user of Mac OS since version 9), I figured I should chime in.
First, as often happens when evaluating arguments of any kind, one needs to identify the different kinds of critique, and break them down into the smallest possible groups so that they can be evaluated fairly. Broad statements like “Linux is broken” or “Linux is impossible to use” do not identify specific problems, but merely express sentiments, probably acquired through firsthand experience with a particular set of conditions.
Futhermore, attacks mounted at Linux aren’t mounted at Linux “the kernel” but at the whole set of Free (and sometimes, commercial) Software that runs on Linux, which is quite broad and diverse (and not accountable to any one development team, not even distributors). As a result of this, the attacks often seem focused on the whole system, when in fact concern only a small part of the system, and quite often that small part is already in the process of being “fixed”. So, in order to evaluate these arguments, I will begin by pointing out the general complaint lunged at Linux, and then break it down into the proper categories and evaluate each of those in turn, placing whatever context I can to help understand the situation better.
Note for FSF/GNU folks: yes, to your dismay, I will refer to the entire system — kernel, shell, command line utilities, graphical desktop, etc. — as Linux. The GNU folks (especially Richard M. Stallman, whose persistence on this issue is just plain childish at this point) will insist I call it GNU/Linux. Fine, call it GNU/Linux when you refer to it. But truthfully, on my desktop at least, I find GNOME/Linux more appropriate, and on my webserver I find Apache/MySQL/Tomcat/Linux more appropriate, so this petty argument really has no substance. Let’s please set it aside for now.
With that out of the way, let’s continue to the major complaints.
Complaint #1: It’s Hard to Use
Perhaps the broadest and most common critique of Linux is that it’s just plain hard to use. “You’d have to be a geek or a programmer to use Linux.” This complaint has some merit, but often it places too much blame on a particular group (often it is either a big distributor, like Redhat or Ubuntu or SuSE, or the only “widely-known” developer group, e.g. GNOME hackers). The complaint refers to a lot of often related but very specific problems with Linux, so I’ll break it down.
Complaint #1.1: Hardware Doesn’t Work
A user installs Fedora Core or Ubuntu on their laptop, and then discovers the wireless adapter doesn’t “just work.” Maybe their driver isn’t supported, or is only supported through ndiswrapper. If they need ndiswrapper, they might need to go compile the project’s source from source (or worse, CVS) and then find a copy of a Windows driver for ndiswrapper to use.
But maybe the Windows driver comes from the manufacturer’s website packaged as an EXE, which they can’t run on Linux, and so they need to boot into Windows, extract the files, come back to Linux, drop into the command line, place the files in the proper location where ndiswrapper expects them, and then run ndiswrapper’s installation script. Even if the user makes it past this all, he may be at a loss for how to configure his wireless network. He asks on IRC and the forums and people tell him to use iwconfig, iwlist, ifconfig and dhcpcd, all command-line tools, and the user isn’t used to the command line, so this seems very complicated.
I actually quite sympathisize with this criticism. But in this case what you’re criticising isn’t all of Linux, but just one particular part of Linux’s otherwise massive and extensive hardware support. So now, let’s take a look at the full story: in reality, Linux has the most hardware support of any operating system on the market. How’s that you say? Well, Microsoft may have the most hardware support all things considered, but in terms of hardware supported provided by Microsoft as opposed to hardware support included with the Linux kernel, Linux wins hands down. At OSCON 3.3, Greg Kroah-Hartman reported on the status of the Linux kernel and pointed out that “Linux supports more hardware on more platforms than any other operating system in existence, including NetBSD,” and that is why a lot of other operating systems are aiming to simply support Linux drivers so they don’t have to reinvent the wheel. What makes Microsoft “seem” to win is that every hardware manufacturer provides third-party drivers for Windows, and many users are even shielded from this fact because OEMs pre-install 3rd party drivers on computers. There are hardly any Linux OEMs, and even if there were, third party manufacturers tend not to package drivers for Linux. That said, Linux hackers should be proud: they have more built-in hardware support than any OS in existence.
This means that if it weren’t for Microsoft’s anti-competititive practices, third-party hardware manufacturers would have a much easier time getting their hardware to run and supported into perpetuity, since the task of driver development/maintainence would be taken care of by kernel hackers. OEMs would have an easier time shipping Linux systems because driver support would be taken care of for most hardware (not to mention preloading software like CD burning applications and office suites would be free and taken care of by Linux distros). Users, most importantly of all, would be much better off. They know their old hardware will be supported even if the platform evolves, since the source code will always be open.
That said, Linux does have some hardware support issues. But many of these may even be blamed on the users themselves.
This may be hard to swallow. Why are we at fault for the lack of Linux drivers for some desktop peripherals?
In short, because we don’t complain.
A hardware manufacturer will never produce drivers for an operating system with a tiny market share unless the users clamor for that driver to be written. But even more important than drivers, we don’t complain for open specifications. Oftentimes, the biggest roadblock to Linux driver development is that no one even knows how the hardware works. The driver developers have to practice reverse engineering to get a working driver, which is a time-sucking process.
Writing open drivers used to be easier because in the early days of computer hardware, before computers became so ubiquitous, hardware manufacturers often shipped thick manuals with the peripherals they sold. But these weren’t just “use” manuals, they were also specifications of the hardware itself: if the hardware included circuitry, it outlined the functions of the registers, or perhaps the significance of certain pins on a parallel port connector, etc. (Admittedly, I was very young in those days, so I can’t say this firsthand, but both my father and a Computer Science professor have told me about these old manuals, and my professor even once showed me the manual that came of a sound card he bought in the 80s which included full technical specs, which he then used to write a 4.3BSD driver).
Nowadays, with computer use no longer restricted to computer hobbyists, this would be impractical: what’s a typical Windows user need a big thick technical reference for? However, what would be totally practical is for documents like these to be provided on manufacturer websites in PDF form. These documents must exist, since the Windows driver developers needed something to work off: that is perhaps the most frustrating thing. Even more frustrating is that something resembling a specification would exist if any third-party manufacturers open sourced their Windows drivers, but since the culture of free software simply doesn’t exist in the industry (these are still “trade secrets”), the manufacturers don’t even think about it.
To provide some anecdotal evidence against this claim against Linux’s ease of use from a hardware point of view, let me tell you my experience getting support for my AMS E-Cube. That is the system I use as a desktop, which uses a Intel chipset with on-board Realtek ethernet, Intel graphics and Realtek ALC650 audio. I installed both Linux and Windows on this machine. When I booted up with Libranet Linux a couple years ago (before Ubuntu existed, it was the best Debian-based distro), I had to do no hardware configuration. I really mean zero. Every piece of hardware was supported immediately by the Linux kernel. Sound, LAN, 3D graphics, USB devices, everything was working.
Contrast this to Windows. In order to get the hardware fully supported there, I had to go to the hardware manufacturer’s driver page, and install the following drivers: Intel Chipset software (needed for full ACPI support), Realtek ALC650 audio driver (audio had “chirping” noise without this driver), Realtek 8100 LAN driver (LAN wasn’t detected by Windows), ICH5 USB 2.0 driver (otherwise, my system would only work at 1.1), and Intel accelerated graphics (needed for full 3D support). Moreover, every driver came as an EXE which I had to extract, run a setup program, and then reboot my computer. Admittedly, this is because my computer isn’t from a top-shelf OEM, but it does expose the Windows (e.g., Microsoft-led effort) hardware compatibility myth.
Perhaps the most unfortunate thing about Windows hardware support is the inability to easily migrate from one piece of hardware to the next. I had Windows installed on a previous AMS G-Box, and was upgrading to the E-Cube. But because the hardware was so drastically different, simply “swapping the hard disk” caused Windows XP to really crash and burn: blue screen of death, etc. I tried all the directions online for “cleaning out your registry” and “resetting the hardware database”, but even once I got the machine booting it was slow, and unstable. So, like most Windows users, I had to “wipe” and “install fresh.” (This wouldn’t be so bad except that when you wipe a Windows machine, you really have your work cut out for you: you have to reinstall each piece of software again, since there is no package management system; more on this later).
Libranet, OTOH, “just booted” fine. When Libranet came up, I had no kernel panics or anything. All my new hardware was detected, and the drivers for the old hardware didn’t load up anymore.
But I’ve been used to this problem since the Windows 98 days. What’s funny about XP/2000 is that it’s supposed to be able to handle these hardware migrations, as it uses Windows NT’s “hardware abstraction layer”. And even stranger is that I think on some hardware it does handle these migrations. But on my hardware, no dice.
Why did I bother with this anecodte? I think it actually points out one of the big misconceptiions about Windows. See, in my opinion, the only reason Windows hardware support is good is because hardware manufacturers tend to sell computers with Windows preloaded on them. As a result, the hardware manufacturer has to make Windows work with that machine. When you buy a laptop from Dell, it would be unreasonable for Dell to expect you to install drivers for the laptop yourself. To make your laptop work, Dell didn’t just put together the hardware and then install Windows XP on it. No no, they installed Dell’s special driver for this, VIA’s special driver for that, and a handful of other third-party utilities. And then hardware manufacturers provide other functionality missing the “basic Windows install” by licensing third-party programs: To play DVDs they bought a license from PowerDVD, to burn CDs they bought a license from Roxio, to archive files they bought a license from Winzip, to protect from viruses they bought a license from Symantec, etc. See, in the Windows world, functionality of hardware is aggregated only by backroom dealing, with the costs hidden from the consumer, so no one ever knows about it. This probably affects your price tag, something Linux users have often labeled the “Windows tax“. The software certainly isn’t free, so someone’s paying the licensing cost.
I remember I once called Dell about Linux support on my friend’s laptop, and the guy responded with disbelief: “but you’re not supposed to run Linux on our laptops. Our laptops only support Windows.” Indeed. But running Linux on a laptop isn’t like other kinds of “unsupported uses” of a given product. Take a lighter: a lighter manufacturer only guarantees me their lighter will light my cigarette; if I buy a lighter and the spark doesn’t work or it’s clogged and no gas comes out, I have a good reason to return it for another. But if I use my lighter to open my beer bottle, and instead I end up with a bloody hand and a broken lighter, I can’t really complain. That’s a totally unsupported use.
Computer manufacturers aren’t supposed to make computers that “just run Windows,” since users should be allowed to run whatever damn operating system they want on their computers. Some may respond saying “Why? Why should hardware manufacturers care about other operating systems?” Because using Linux on a Dell isn’t like using a lighter as a beer bottle opener. Forcing users to run Windows since it is the only supported operating system is like forcing users of your cigarette lighter to smoke Marlboros because it is the only supported cigarette. “But I’d like to smoke Camels or Carlton Light too, they’re all cigarettes, after all, and all your lighter has to do is light them up” the user says. “Too bad, we only support Marlboro.” Do you think that would be a fair thing for a lighter manufacturer to restrict?
When evaluating Linux’s hardware support, you have to sort of forget about the stuff that is the fault of hardware manufacturers. That is, you have to forget about it when judging Linux on its merits, rather than judging it on someone else’s faults. Look at the good: Linux has open source, working drivers for most of your hardware. But we also need to face up to reality: Linux will never have the “just works” support for all your hardware that Windows has until hardware manufacturers start either producing well-functioning Linux drivers for their hardware, start open sourcing their Windows drivers, or start releasing open specificatioins for their hardware. And that’ll never happen until either we, the users, speak up, and tell hardware manufacturers we want to smoke whatever brand of cigarette we damn well please when using their lighters.
Complaint #1.1: The Desktop Software Experience is Bad
So a user plugs in his iPod to a Linux machine and… nothing happens. We often hear a complaint of this kind, where the iPod can be anything (a USB memory stick, a scanner, a DV camera, whatever). This particular complaint is valid, and has been taken head-on by the desktop development community. Both the GNOME desktop and KDE have been working hard to provide solutions for these problems, and often they have been doing it together through the FreeDesktop.org (fd.o) project. But we have been slowed by the fact that lower-level userspace programs that run in the background (called daemons) weren’t built from the point of view of running Linux on a fully-graphical desktop. So a lot of hackers are at work redesigning some stuff that is under the GNOME/KDE hood, like hal, udev and d-bus. The idea is emit messages when certain events important to a user occur, and provide nice suggestions as to what to do (Copy photos off a camera, open a nautilus window for your memory stick, open up the GIMP for your scanner, whatever). A lot of this work has already been implemented in the latest versions of both desktop environments. It’s certainly not perfect yet, but it’s getting closer and closer everyday.
As for other desktop experiences, I think most of these arguments against Linux desktop software are outdated. I can only speak from a GNOME perspective with authority, but nowadays I think we have good software for doing day-to-day tasks. I personally do document writing in Abiword, which I find much more enjoyable to use compared to the clunky, slow, and featuritis-plagued MS Word. I do browsing in Firefox 2, which I find vastly superior to IE. I do e-mail, contact, calendaring and task management with Evolution, which I find vastly superior to Outlook XP and slightly superior to Outlook 2003; in Microsoft’s latest version, Outlook really got much nicer, but is still catching up to Evolution. Since this claim about Evolution will no doubt be met with skepticism and trolling, I’ll point out that the features I “can’t live without”, and then send you to this article which gives a nice overview of Evolution 2.x: Smarter searching based on “rules”, saved searches, VFolders, powerful filtering, spamassassin-based junk filtering, full iCal support, and integration with the GNOME date/time applet.
So there’s browsing, e-mail and word processing, the Big Three tasks of the average desktop user. What else do I use? There are almost too many choices for music players. I am an old-style guy who likes beep-media-player (which is basically “WinAmp” for Linux) as I’m not really into “music management and categorization” a la iTunes, but there are lots of tools that do that too. File management is made simple with Nautilus, which is quite comparable to Windows explorer and continues to get improvements which make it surpass Windows Explorer (and start the catch-up game with Finder). Check Davyd’s overview of some of the new features from a prior release of GNOME.
All the basics are there, with the one exception of well-done file searching which is being quite rapidly developed by the Beagle guys. When I wrote this article, Beagle was still in its infancy stages, and Deskbar Applet didn’t exist. Now that they both do, file searching as a problem has been solved better than it has been in Windows, even with the latest “Windows Live Search.” I suspect it may be better than Vista’s search support, at least when it comes to support for various backends and its extensibility.
Now you want other applications, like image editors, sound editors, programming tools, document layout programs, and more? Linux has got them, in one form or another, all Free. (More on this later, but just check out e.g. gnomefiles.org if you don’t believe me.)
Complaint #1.3: I have to use the shell (command line), and that’s hard to use
A lot of users complain that the main problem with Linux is that “too much stuff happens at the command line.” For example, I shouldn’t have to drop into the shell to mirror a website with httrack, I should have a website mirroring tool like Teleport Pro.
This goes all against the general UNIX culture. The main reason the command line tool is preferred by UNIX users to the graphical application is that the command line tool is often more flexible. For example, wget, being a command-line tool that generally does fast retrievals from a variety of Internet sources, can be used from any other program that needs to do that task. Furthermore, it can be used by the UNIX user in scripts or scheduled tasks (cron jobs). I’m pretty sure a lot of graphical Linux download managers actually use wget behind the scenes. Because, really, why reinvent the wheel? Why design a whole new application to do spidering and mirroring of websites when you have a high-quality, debugged, speedy tool that does the job.
(Technical aside: It’s true that ideally, re-usable components of software shouldn’t be binary applications. One common problem in UNIX world is that scripts that spawn off lots of separate processes are often a very rapid means of development, but usually aren’t very performant. For example, the UNIX wc utility can be used to count the number of characters in a document, but if you were to code a text editor that ran wc -c on your text document every time a new character was created, it would slow things down quite a bit. Honestly, if the UNIX system were built on a more structured programming environment than C (like Python), we’d probably be better off; that said, the basic contract that UNIX utilities follow (as to standard input and standard output) enables a level of code re-use that’s rarely found in other systems.)
Other command-line tools (generally a part of GNU) have lots of really practical uses, like grep and sed. The tools may have strange syntax, especially for someone coming from the Windows world, but these are very “usable” tools. All you need to do is spend a couple hours learning how the UNIX shell works (including commands like man and info for getting help) and you can find it very natural and productive to use the whole offering of UNIX command line tools. Indeed, recently I attended a two-week long UNIX course in which most students were newcomers to Linux (mostly Java and C# developers). I found that in this two-week course, these students knew more about the UNIX system than I even did. At the end of the day, the “usability” of the UNIX system is quite good, it just has a bit more of a learning curve than “point and click.”
The command line, like windowing systems, is a kind of interface to the user. When I had to train my Mom to use Windows years ago, nothing seemed natural to her. She couldn’t understand concepts like “Windows” and “buttons” and “links” without having me explain things to her very carefully. She couldn’t tell the difference between double-clicking and single-clicking (so she just double-clicked everything). It was hard for her to understand things like “clicking and holding down on the titlebar lets you move the window around.” What’s the titlebar? Why do I have to click there? The task bar at the bottom where each button “represents” a Window and allows you to switch between them. And before she learned the concepts well enough, she always wrote everything down as tasks: “HOW TO OPEN A WEBSITE (1) Click Blue IE button on desktop (2) Click on address bar (3) Type website address and press enter.” Etc. Etc.
When I reflected on that training, that took her a few days to get to be productive in a windowing system, I realized that the command-line’s lack of usability is simply a myth. The command line has a very clear interface: you type in the name of a program, followed by options for what you want it to do, and it will do it. The command line isn’t necessarily a worse interface, it’s just different. And people, when faced with strange and unknown things, do not know what to do with them. Windowing systems may seem highly usable to you, but that’s only because you’re, well, used to them. So you download files by “clicking on a blue IE icon, typing in a url, and clicking save as” and I download files by typing “wget “. That’s only because you understand that process in terms of “Internet Explorer is a web browser which can download files, so I need to pull up a browser window which is ran by double-clicking that browser’s icon, typing an address in the field that application has for web addresses, and using the action the program makes available to save that file.” Meanwhile, I understand my process as “wget is a program that retrieves files, and it takes URLs as its argument, so all I need to do is run wget with the URL as its argument from my shell.” In the end, one can’t really say one process is any better than the other, they’re just different. They have different strengths and weaknesses (yours has a lot of pretty graphics involved with it, mine doesn’t; mine is quicker to do, yours is slower). I don’t want to do web browsing or image editing from the command-line, because the command line isn’t suited for those tasks. But if I need to rename a bunch of files, search through a bunch of text files, mirror websites, or convert thirty jpegs to png files, the command-line is my friend, and should be yours too.
Linux on the desktop is getting to be wonderful because you need the command-line less and less for day-to-day tasks, but it’s still there to give you the proper and needed bit of automation or time-saving functionality. Microsoft realizes this, which is why it’s trying to play catch-up with Windows Services for Unix and Windows Powershell. But due to significant cultural differences, I don’t think either of these efforts will ever lead to the full-featured and inter-connected UNIX system that us UNIX users enjoy.
End of part 1 of this series, “Common Criticisms of Linux, parsed and analyzed.” Part 2 will deal with a second major complaint, “Until Linux runs X, I won’t even look at it…” where X is MS Office, Adobe Photoshop, Macromedia Dreamweaver, and a whole slew of other commercial applications people have grown attached to on Windows.