Is Linux Annoying?

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:

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.

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.

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.