Windows usability: followup.

Yesterday, I posted a blog post containing a list of issues with Windows, in response to a similar list for Linux, which has received quite some response; I've seen people +1 it on google+, and I've received a number of replies on the blog post itself. One of these replies was by the author of the original list; and as expected, he totally and utterly failed to see the point. He also has the audacity to claim I haven't installed Linux yet—what?!? The last time I used anything other than Linux on my personal machine for any real work was on Windows 98. And no, that was not because I was too cheap to buy the latest and greatest. I have used Windows in some cases since then, but never on my own hardware.

First of all, I should note that the list which I posted was only semi-serious (with tongue in cheek); the fact that it refers to Windows as the operating system which "attempts to replace Linux as the major operating system" should have been a pretty big clue to that effect. Like the original list that it was a reply to, my list contains things that are only true in a particular context (e.g., the one about requiring recent hardware), it contains things that don't matter for the large majority of Windows users (e.g., the point about focus-follows-mouse) but that are major arguments for why I don't use Windows, it contains things that are so alien to what most of us are used to that even most Linux users don't use it, while on the other hand some swear by it (like the SELinux argument), and it contains some things that a seasoned Windows user will call bullshit on but that are real actual problems for the non-seasoned Windows user that I am (such as the mouse argument). It also contains some actual facts, like the statement about most crashes being a direct result of faulty drivers—that's pulled directly from a scientific study on the subject conducted by Microsoft, together with some independent researchers. Like the original list, I don't expect this list to change anything for the better, precisely because it is flawed in exactly the same way.

But whether the items on that list were right or wrong isn't the point. This is:

Nobody (except nutcases) ever said Linux is perfect, or that it's useful for everyone; and while the issues Artem lists may be bugs or may be design flaws or any of a number of other things that could be real problems, the fact is that creating a long "list of issues" isn't going to solve anything.

If you find that there are problems with Linux, you basically have three options: fix the problem, get someone to fix it for you, or stop using Linux. Really.

Rather than better or worse, Linux is different. It will have its own set of problems, and it will have its own set of advantages. Some of the design decisions cause problems, but also have serious advantages, and focussing on only these problems (the existence of which I'm not denying) isn't very helpful.

A good example is the library model: under Linux, libraries are typically installed in a system-wide location, and use a SONAME which is (part of) the filename of that library and which defines the binary interface exported by that library. In contrary to the situation under Windows, Linux libraries also must use position-independent code.

The result is a more robust library model. The downside to that model, however, is that when you install older applications that require older SONAME versions of a particular library, getting those older versions may be a challenge. While in theory, installing an older version of a library is not going to cause any problem if the SONAME is different, in practice you'll often find that you'll need to go to (unsupported) older packages from older versions of the distribution, which may not install due to missing or conflicting dependencies, or which may expect data files in a different format in the same location that newer versions of the same library do, or which may have any number of other issues. When that happens, the solution is to either use an older version of the distribution in a chroot or some such, or to patch and/or compile the needed libraries yourself, and install them alongside the newer version of the same library. That's perfectly possible, after all, precisely because of the SONAME.

Another good example is the development model: where Windows has a central authority (Microsoft) which defines what it is to be "Windows" and what is and isn't part of that, the same simply isn't true about Linux. Yes, Linus defines what the official Linux kernel has, but he doesn't have any say about the user interface, the boot process, or any number of other things; other people make decisions there. As a result, in effect, who decides what it means to be a "Linux system" is, really, you, the user. If you believe that the Linux user space is completely wrong, you can just change it to something else entirely; and that's precisely what Google did when they created Android.

Since there's no central authority making decisions about what will and won't go into the system, this means that inevitably, at any given time, there will be many competing options for many subsystems. Usually this will be an advantage; e.g., the competition between KDE and Gnome benefits both. Sometimes, however, the competing options are so confusingly interwoven that even those who should know the system inside out can't make heads or tails of it, and debugging issues then becomes quite a challenge. Unfortunately, the Linux sound subsystem is currently an example of the latter.

I'm not saying that all the items in Artem's list are invalid; a minority are, in fact, actual problems for a majority of Linux users. Most however, are personal opinions, issues affecting only a small minority of Linux users, or, as above, things where he only talks about the downsides of a design decision that also has major advantages. As an example of something in the second category: it's easy, for example, to list hundreds if not thousands of issues relating to particular pieces of hardware that don't work under Linux, simply because the manufacturer doesn't provide any information, and the people developing drivers for Linux have to reverse engineer how everything works. If you're a bit careful in what you buy, however—much like MacOS users need to be careful, too—then using Linux isn't an issue. My Lenovo Thinkpad X220, for instance, has no parts that don't work; and this includes things like a docking station, and the fact that my (9-cell) battery life is over fourteen hours, which (I believe) is more than on the same laptop with the same battery under Windows.

So how is making a list of issues useful? The answer to that is simply, not at all. If you want to help, don't look for other people's problems; we can all do that. Instead, try to look for solutions to these problems. That's not always easy, and in many cases requires that you first understand why something is done in a particular way. If you don't want to spend time doing that, that's perfectly fine; but then don't expect that open source developers (who are already strapped for time, usually) will suddenly jump up and fix the problems you think are most important, as opposed to what they think should be worked on most urgently.

After all, most Open Source developers have their own sets of priorities what they think requires most work, and that's what they'll work on—not what's shown in a particular list by someone they don't know and have no reason to respect, somewhere on the Internet.

Finally, I'd like to note that any statement which claims that Linux isn't "ready" to be used on the desktop, when hundreds of thousands (if not millions) of people are using it in exactly that way for their day-to-day work, is insulting these people's intelligence. Since that includes me, it's also insulting my intelligence. And I don't like to have my intelligence insulted...