Is Linux Annoying?

edwardhayes

Is Linux Annoying?
by Paul Weinstein
09/11/2003
Attentive web surfers for all things Linux have probably already noted that O'Reilly is working on a new Linux book, Linux Annoyances. Indeed O'Reilly wants to follow up its success with the Windows Annoyances books by doing one on Linux. This of course brings to mind the question, what is a Linux Annoyance?


As one of the authors tasked with answering this question, I recently shuttled off to my local bookstore, went up to the information booth and asked the clerk, "Do you have a copy of Windows XP Annoyances?"

The clerk turned to his computer and started smirking. "Windows Annoyances you say? Must be a bestseller?"

I'm not quite sure about this, but I think he was talking to the computer, not me. Nah, must be my imagination.

"Yes, here it is. We have one copy on hand. Let's go see if we can find it."

Off we went. Sure enough there it was, a nice yellow book with the trademark O'Reilly animal on the cover; in this case, a Surinam toad. "Thank you", I said to the clerk. He nodded, paused for a second, as if to remember something, looked at me (maybe he wanted to ask me something), and went back to his desk.

After putting together an initial outline I found myself on IRC chatting with my potential coauthors, Justin Davies and Dee-Ann LeBlanc. We were frustrated. We couldn't come up with an outline that O'Reilly wanted to use. Did they not see the care I took in outlining a vendor neutral chapter on the problems with various software packaging systems? Did they not appreciate Dee-Ann's whole chapter dedicated to regular expressions? How many Linux books care to explain the pain and glory that is regular expressions in Perl for Linux users and administrators?

It seemed our approach to the Annoyances title wasn't right. Sure, I lose my stack whenever the computer spits back error: Failed dependencies for the third package in a row. Doesn't everyone? Guess that's not enough of an annoyance to build a book on. Who knew?

"You know, the Windows Annoyances book was based on a site that had collected issues with Windows since Windows 95 was still in beta", I mentioned to Justin, filling in a moment when Dee had stepped away.

"No, I did know that" popped up on my screen as a reply. "Yeah, it was", Dee seconded, back at the keyboard.

"I think that's my problem in outlining these chapters. I have some suggestions from friends, some personal insights, but not something to build a whole book on."

We needed an army, an army of friends. Or at least an army of computer bookstore clerks, all freely sharing their stories of pain and suffering at the hands of Linux.

"We could setup a list or forum to collect people's stories", typed Dee, as if reading my mind from several hundred miles away. Mailing list it is. It would seem my reading up on the past O'Reilly Annoyances books at the bookstore was prudent thinking. Now how do we go about letting all those frustrated bookstore clerks know that they now have a venue to vent in?

What the Heck is a Linux Annoyance Anyway?
David Karp, author of the Windows Annoyances books, defined a computer annoyance more in terms of how one perceives a problem than anything else. He noted in his introduction to Windows XP Annoyances, "an annoyance is a way of looking at a problem [sic] it's an attitude that gives you fortitude."

Karp's definition of an annoyance is designed to challenge your perception of how to deal with computer problems. If you feel overwhelmed at the thought that the number of computers in our world continues to grow and that the majority of these computers use variations of Microsoft's Windows, you'll probably feel at a loss and simply become numb to the trials and tribulations that we all encounter daily, even when all you need to do is look up a book in a bookstore.

But Linux Annoyances? Surely, Linux users of all types—hobbyists, administrators, and engineers, to name the classics—feel that the work of the free and open source world is to empower users with choice. After all, if one operating system is annoying, then simply choose another. If Windows is not the right option, how about a BSD variation, such as Mac OS X? If not Mac OS X, why not give FreeBSD a try? If not FreeBSD, why not Linux? If one Linux distribution is troublesome, use another. Can too many choices be just as annoying as no choice at all?

Let's consider software packaging. This is something that all platforms have to deal with. Everyone has a love-hate relationship with software packaging since it can relate to something as simple as installing binaries for Mac OS X to something a bit more complex, unpacking and building source code from scratch on Linux, or anything in between. Any number of issues can crop up depending on what method or operating system is being used.

Since several Linux vendors have selected to use RPM as their packaging solution, it only stands to reason that people would find issues with how RPM works.

On the Linux Annoyances mailing list, John Andersen suggested the following method for dealing with what is commonly known as RPM Hell:

You try to install XYZ package but it has a prerequisite for abc.lib.so.7.

You take a swig of beer.

You Google around a bit and find that abc.lib.so.7 is supplied by package abc-2.19-45.rpm.

You hunt around for that RPM on the Web (since a quick ls abc* | less on the distribution CD didn't turn up anything) and you find it on a Bulgarian web site and download it.

You try to install it, and it requires lib-hij.so.2.

You take a swig of beer.

You Google around a bit and find that lib-hij.so.2 is supplied by package efg-5.10-54.rpm.

You hunt around for that RPM on the Web (those dang CDs again) and you find it on an Australian web site and download it.

You try to install it, and it requires lib-klm.so.1.

You take a swig of beer.

"Hmm", you think to yourself, "maybe I'll just download and compile the source code".

No good, the configure script will just die on you, with unresolved externals and more prerequisites.

In John's immortal words, "The whole experience sours one on the whole concept and were it not for the beer, would lead to many suicides and divorces."

And no, before you ask, this isn't just some clever college drinking game. I'm not advocating drinking on the job; after all, one bookshelf starts to look like another to any drunken bookstore clerk. But drinking is tempting when you have to configure a half dozen servers in a nightlong install-fest.

Surely, there has to be another way to install software without using a different operating system or Linux distribution not built on RPM. Sometimes using another platform just isn't an option.

In the philosophy of the Annoyances books, if we take it upon ourselves to understand the annoyances of a particular problem and instead of just giving up, we position ourselves better for dealing with the problem at hand.

Another poster, Alex Butcher, suggests the following process for avoiding RPM Hell:

Stick to RPMs built for the distribution you're running. If in need of a package from an outside source, try a third-party RPM repository dedicated to the Linux distribution you have on hand. For example, the following websites focus on packages for Red Hat's distributions of Linux:

http://freshRPMs.net/
http://ftp.falsehope.com/
http://www.fedora.us/
Moreover, Alex points out, if you do need a package for which no RPMs are available, try the following:

Take the source RPM for a similar distribution or from a later version of the same distribution.

Adjust any explicit dependencies in the .spec file.

Rebuild the binary for your distribution.

Of course, Alex admits that this process is easier said than done, but points out that it becomes quite straightforward with a bit of practice and a little knowledge from the RPM documentation.

Finally Alex suggests that before using a third-party RPM or rolling your own, double check that the file or package needed isn't included on hand after all.

Red Hat, for example, includes a fully populated RPM database that can be queried using the --redhatprovides and --redhatrequires command line options. Simply install the rpmdb-redhat package beforehand.

$ rpm -install rpmdb-redhat-9-0.20030227.i386.rpm

$ rpm --redhatprovides libxml
libxml-1.8.17-8

$ rpm --redhatrequires libxml
GConf-1.0.9-10
bonobo-1.0.22-4
dia-0.90-11
galeon-1.2.7-3
gnome-pilot-0.1.71-2
gnome-print-0.37-4
libglade-0.17-11
libgnomeprint-1.116.0-6
libgnomeprint22-2.2.1.1-3
librsvg-1.0.2-8
libxml-devel-1.8.17-8
mrproject-0.9-4
soup-0.7.10-4
In three easy steps you can find out which Red Hat package provides libxml and which packages require libxml . Another option is to create a local listing of RPMs on hand using rpm's query option.

$ rpm -qilp /mnt/cdrom/RedHat/RPMS/* >
install_cd_1.txt
Then if you come across a package that has a specific requirement, you can quickly grep a personal list of RPMs to find the proper package. For our little Red Hat Linux 9 system you can see that if libxml version 1.8.17-8 is needed you can find the proper file on the Red Hat Install CD 1.

$ cat install_cd_1.txt | grep libxml | less

Name        : libxml                      Relocations : (not relocateable)

Group       : System Environment/Libraries Source RPM : libxml-1.8.17-8.src.rpm
The libxml package contains an XML library, which allows you to
/usr/lib/libxml.so.1
/usr/lib/libxml.so.1.8.17
/usr/share/doc/libxml-1.8.17
/usr/share/doc/libxml-1.8.17/AUTHORS
/usr/share/doc/libxml-1.8.17/COPYING
/usr/share/doc/libxml-1.8.17/COPYING.LIB
/usr/share/doc/libxml-1.8.17/ChangeLog
/usr/share/doc/libxml-1.8.17/NEWS
/usr/share/doc/libxml-1.8.17/README
/usr/share/doc/libxml-1.8.17/TODO
Of course the real advantage of this last option is the ability to create a listing of RPMs from any source of RPMs for future searches.

At the core is the simple idea of presenting solutions that enable you both to customize and troubleshoot, to borrow from Karp's introduction again. Just because Linux may be the least annoying solution for a problem, it does not follow that a Linux system has no idiosyncrasies to deal with. After all, there is no "one true operating system".

All of this highlights the perspective of the free and open source philosophies: users are as empowered as anyone else. We are not here to complain or to criticize but to learn, understand, and fix.

Call for Annoyances
My question for you is What Linux Annoyances have you had to deal with? If you've found a solution, what is it? Generalities as well as specific annoyances are welcomed. Take note, this mailing list isn't designed to be technical support for Linux Annoyances (we have to save something for the book). Nor is it meant to be a collection of "oh, I found this bug once and I was like where is that Bugzilla thing?" This is "I can't believe they design it this way and think it works for people! What are they smokin'?"

Got your Linux Annoyance? Good, now go point your web browser to join the mailing list and share your favorite (or least favorite) Linux annoyance. Who knows, you may end up seeing it in an O'Reilly book followed by a helpfully solution or two. Trust me, I should know. I'm coauthoring a book on Linux Annoyances for O'Reilly and I need your help. We have a lot of bookstore clerks to save.

Paul Weinstein is the Chief Consultant for Waubonsie Consulting.