OS GUI

A novice’s greatest fear is sitting in front of a motionless command prompt with no idea what to type; or, as so frequently happens, knowing a command that he copied verbatim from a document discovered on the internet somewhere, but with no idea of what it means or how to alter it if it doesn’t behave exactly as advertised. Linux has never quite escaped its reputation as an OS for geeks who like those command prompts. I made the plunge into Linux at the start of 2003 under the assumption that things had improved enough that I could get around Linux without the command prompt at all, or at least with minimal exposure to it.

Two Years Before the Prompt:
A Linux Odyssey

09 September 2004

A novice’s greatest fear is sitting in front of a motionless command prompt with no idea what to type; or, as so frequently happens, knowing a command that he copied verbatim from a document discovered on the internet somewhere, but with no idea of what it means or how to alter it if it doesn’t behave exactly as advertised. Linux has never quite escaped its reputation as an OS for geeks who like those command prompts. I made the plunge into Linux at the start of 2003 under the assumption that things had improved enough that I could get around Linux without the command prompt at all, or at least with minimal exposure to it.

What I want to report on here is some of the “gotchas” of being a new Linux user. I’ve tried at least half a dozen different distributions, and along the way I’ve been hit with just about every problem an inexperienced user could face. Partly this is because I push Linux to do so many things for me – web server, video player, email server, database backend, programming environment – including many that I had not previously tried on Windows. In spite of my title, however, I’m not going to try to make this article into a ripping yarn along the lines of Richard Henry Dana’s book Two Years Before the Mast. I’m also not writing a critique of Linux distributions, although I hope some developers out there might read this and get some ideas. My main purpose is to prepare new users for likely sticking points, as well as to reassure them about things that will not be as hard as they had feared. I went into my Linux experience with very little idea of what I was getting into; that makes it an adventure, but it’s probably not the best way to go about things. Sometimes it helps to read that such-and-such a process is difficult. At least then you can work your way through it slowly, without the persistent fear that there is some easy, one-command feature that you could be using if only you knew what it was.

All of the distributions I have used are of the more user-friendly type. The reason I have gone through so many is that I keep discovering different things in them. What works on one might not work on another, but hopefully I can learn enough from one distribution that I can tweak another to my satisfaction. It is, in fact, the very diversity of various distributions that makes using Linux such a challenge. Ask a friend and he may suggest a solution to your problem that doesn’t exist on your distribution. Naturally, anything can be configured, but it may be more trouble to get it to that point than to find a different solution. Therefore, I will not go into the details of each distribution, but rather give my overall experience, highlighting where distributions differ.

Linux distributions have put a lot of effort into making the install process as easy as possible, and this is definitely a good thing – if you can’t get it installed, you aren’t going to use it. I distinctly recall installing a version of Linux 6 years ago and trying to get XWindows (X11R6, for purists) running so I could escape the command line. I went through a lengthy setup process, but when it started asking questions like the horizontal and vertical refresh rates of my monitor, I knew I was in trouble. Nowadays, installation is often as simple as you make it: if you accept all the defaults, your only decision will be a password for the root user. I have had very little difficulty with any of my installs: keyboard, monitor, mouse, sound card, network card, and other essentials are usually automatically detected and configured without my having to do a thing. I did have one case of a disappearing monitor display and one of a non-functioning keyboard, and it is only fair to warn new users that these issues do crop up sometimes. To be fair, however, most people never have to install Windows, so they never have to deal with the issue of hardware compatibility and settings. Also, both of my installation problems came from pre-1.0 distributions. Usually the creator(s) of a distribution are especially willing to help with installation issues, since they are so fundamental. Configuring your system to work beyond the basics is more the user’s responsibility: help can be found, but not as readily.

Most of my hardware has been easy to configure, but there is one exception: things associated with the laptop have rarely worked quite as I hoped, if they worked at all. Several distributions have had no trouble recognizing the touchpad on my laptop, but I haven't found anywhere to configured its advanced functions – things like being able to tap directly on the pad rather than using a button, or being able to scroll by dragging my finger on the right side of the pad – which are, if not quite essential, certainly very important to making the laptop comfortable to use. I haven't had any problem with the laptop display itself, but when I use an external monitor, the desktop is bigger than the display area, so I have to scroll with the mouse to see the whole display. The biggest problem I've had, however, concerns power management. Apparently this is not compiled into the Linux kernel by default, which means you have to recompile it yourself (unless you bought a pre-configured system) in order to monitor your battery life and use features like suspend mode. I actually took the plunge and recompiled the kernel myself once in an attempt to add power management. It's actually a lot easier than it sounds, since most of the choices involve picking things from a menu of options – there are few, if any, obscure command-line controls to learn. The new kernel worked, but, alas, it did not add the functionality I had hoped, and I lost some other features that I had taken for granted. Perhaps the lack of power management galls me especially because a battery icon appears on my taskbar in KDE, but clicking on it only brings up a screen that informs me that power management is missing – the torture of knowing that the possibility is there makes the absence of it that much harder to bear. And I want to be clear that most of the functionality that I miss in Linux on my laptop – probably all of it – is available in Linux, somewhere. If I had been able to buy the laptop with Linux pre-configured on it, no doubt everything would be fine. My point is that, if you install Linux yourself, you should be prepared to live without some features – or else do some serious digging to figure out how to enable everything the way you want it.

It is fortunate that distributions have taken to assigning reasonable defaults to most installation choices, because the one thing you will find about Linux (and open-source software generally) is that the number of choices available is enormous. If you were afraid open source software would leave you dependent on a single, common solution to various computing problems, you will be pleasantly surprised. Go look at your desktop settings and find that you can make your widgets look like Motif, Motif Plus, Plastik, Platinum, SGI, Compact, CDE, MS Windows 9x, and even .NET. If most of these are unfamiliar to you, don't worry: exploring Linux is half the fun. There is usually a Windows-look-alike alternative if you're feeling insecure in your new environment, but it's always interesting to play with the more traditional Linux alternatives. By default, Linux usually opens programs with a single click, instead of a double click like Windows; double-clicking on the title bar of a program “shades” it (reduces the window to just its title bar) instead of maximizing or restoring it, as in Windows. I actually prefer Windows behavior on these two items, but the point is that you can make it any way you want it – mixed, matched, and mis-matched, if you choose.

After you have spent days playing with all the different styles available to you, you can experiment with a completely different desktop environment. I normally use KDE, but Gnome is also very popular. A lot of the behavior is configurable the same way as in KDE, but there are alternatives as well. One feature of Gnome that I like is the ability to add “mini-icons” around the sides of an icon to indicate that a file is important, belongs to a certain category, or just that it's cool. After you've tried Gnome and KDE, you can learn that there is an entirely different layer underneath them, the “window manager,” which you can also change. If you have a small amount of memory or like to use the keyboard for everything, IceWM may be for you. If IceWM isn’t the solution, there are probably a dozen other alternatives, all of them more or less configurable to match your preferences. If the difference between widget style, window behavior, desktop environment, and window manager is still unclear to you – well, that's probably because it's unclear to me, too. I have certain notions of what they each mean, but I could not begin to give a good definition of each. The great thing is that you don't need to. For most purposes, you can choose what you like at each level, without having to know too much about the details behind them. If you find yourself wanting to do more advanced things, the ability to configure every detail to your heart's delight is readily available, and most of the resources for learning how to do it. All it takes is time and persistence.

Configurability is the forte of Linux, and OSS generally. It seems that every program has its “.conf” file where it stores its settings. Changing a feature is usually a matter of editing the .conf file to enable or disable options, point to different directories, or allow or disallow certain users permission to do something. I have to admit that I was not enamored of .conf files in the beginning. My first reaction was, “You want me to do what?” For the average Windows user, the idea of editing a configuration file is about as foreign as having to install the operating system himself. Since I am considerably more comfortable with computers than the average Windows user, I think I should prepare you for .conf files now: get used to them. Although things are getting better – and something like OpenOffice will not ask you to edit a text file to get it to work the way you want – the fact is that most Linux programs still operate this way. This fact would not be nearly so frustrating were it not that, often, the same program will have a gui configuration in Windows but only a text .conf file in Linux. Having written some cross-platform software before, I have trouble understanding why this should be the case, but I realize that the best thing to do is not to complain about it. The best thing would be for me to write a gui configuration tool for Linux; failing that, I need to learn about .conf files and use them. The fact is that, once you accept the idea of it, editing .conf files is not that difficult. You never have to leave your friendly gui environment; just fire up kate (the advanced KDE text editor) and make the changes there. Almost all .conf files that I have actually looked at are very user-friendly: most options are already included, even if they are commented out, and come with a sentence or two explaining what purpose they serve. While potentially intimidating, .conf files are not as bad to use as they might appear.

I mention the “kate” editor because it is my favorite Linux text editor, but it may not be available on your system. If not, Kwrite or some other gui editor is probably available, but you may find, on occasion, that you need a text editor that can run without a gui. If you’re lucky, you will be able to use “nano,” a friendly text editor that makes most of its commands visible at the bottom of your screen. If you’re not lucky, you will be stuck using Emacs or Vi, two very old editors that have been around since before gui interfaces were an option. I’ve learned enough Vi that I can use it if I have to, but personally I think it is a crime to leave any end-user with nothing but these tools for console-based editing. They are optimized for efficiency, but only if the user is experienced. If you’re not experienced, good luck remembering commands like “:quit!” to exit Vi without saving, or “ZZ” to exit and save – without any menus to guide you.

Linux developers have worked hard to make the Linux prompt as unnecessary for the user as the Windows prompt is for users of that other operating system, and they have come a long way. I’m afraid, however, that there is still a ways to go. To pick one example: This weekend, my wife was using my Linux computer and discovered a Macromedia Flash plugin for Linux. I was thrilled, since I didn’t even know that one existed. But she had to call me over to get it installed. She watched as I opened a console and un-tarred the package, and asked in a puzzled tone, “Can’t you just right-click on it or something?” I answered, honestly but sheepishly, “You probably can, but it’s easier just to open a command prompt.” You see, when I right-click on a package in KDE, I get three different options for how to compress it, but nothing for how to un-compress it. I don’t doubt that there is some way of un-compressing it from the gui, but I long ago learned how to use the tar command, and I haven’t gotten around to figuring out the “normal” way (which I would still prefer on occasion).

You may be wondering why I couldn’t just double-click on the package to go inside it. The answer is that I could have, but that wouldn’t have done me much good. The instructions from Macromedia explicitly state that the configuration tool must be run from the command line, so I needed something that would not just open the package, but unzip it and store it somewhere. And even then, I would still have had to get to a command line to install it. Since I spend a lot of time praising Linux to my wife (and anyone else who will listen), I was disappointed that I didn’t have a self-extracting package that she could just double-click on to install, the way it always works in Windows. Here we come to Linux's weak spot: installing new software. There are at least three layers of problems here. The first is that most open-source software is under constant development, so there is no clearly-defined endpoint for a finished product. Compiling the latest version of the source code is, therefore, a common approach. But making a package is not all that difficult, and here we come to the second layer. Because Linux comes in so many different distributions and with so many different options, it is not always clear what a self-extracting package should actually do. For example, not all versions of Linux use the same default path for user-installed programs, and, even if they did, they frequently get adjusted by individuals. Gnome and KDE have different locations for icons on the desktop and programs in the main menu (the “start” menu in Windows), so which should the install package look for? If someone builds a package, he typically expects that the user can figure these things out for himself. It is rare to have a program that will install itself, create a desktop icon, and put itself in the menu tree. Actually, I don't think I've ever experienced this. So, if these things are important to you, you will do well to figure out how to do them yourself.

But the biggest problem by far with installing programs on Linux is the issue of shared libraries. These are the common functions that are used across multiple programs. A shared library gets installed once, in some accessible location, and then is used by various programs which link back to it. This saves disk space, because you don't have to make a copy of the same functionality for every program. Unfortunately, it comes at a serious cost: compatibility. In Windows, this issue is known as “.dll hell.” In Linux, you might call it “.so hell” (“so” being the extension for these “shared objects”). It has probably caused me more frustration and hair-pulling than all the other issues in Linux combined. In principle, the issue seems simple: you can't install a program if the shared objects that it depends on – its “dependencies” – are not on the system. Any attempt to install the program will generally inform you what dependencies are missing, and it usually isn't too much trouble to go find the needed files on line somewhere. The problem comes if you need, say, version 4 for your new program, but you already have version 3 installed. You can't simply overwrite version 3, because then all the existing programs that depend on it will break. Apparently you can't just have separate copies of 3 and 4, since I have yet to find an installation tool that will let you do this. Instead, you...well, frankly, I don't know what you do. I have yet to solve this problem, and it continues to bother me. Most distributions seem to have adopted the solution of developing their own packages of software, designed to work with their version of Linux. This is important because, remember, some very basic parts of the run-time environment, such as which widgets are used, are not built-in. A programmer has to decide if he wants to use GTK+ or Qt, and whichever he chooses has to be available on the computer the program runs on. Since a distribution comes with a large amount of software installed, it is important to make some basic decisions about which versions are being used at the distribution level. Then you can compile the appropriate packages of an array of commonly-used programs and make them available for download, with the assurance that the package should work with the distribution.

At its best, this works pretty well. A distribution may have hundreds of programs in its dockyard, all OSS, all available for convenient browsing and download. Unfortunately, there are always programs not in the dockyard that I want to install. Sometimes they work, but it seems at least as common that they fail on some dependency. Sometimes when I try to install a program with a missing dependency, I will go find the needed file and install it, only to find that it, too, is missing a dependency. This process of finding deeper and deeper dependencies will continue until, ultimately, I find something that conflicts with file I already have, and there my searching ends. It is a long way from double-clicking on a self-extracting installation file.

It would be pointless for me to beg the Linux experts to come up with a solution to this problem. I'm sure they are aware of it and would have done something if they could. What I hope for at best is more tutorials on how to deal with software installation. My little contribution here is just to make new users aware of the fact that it is, indeed, problematic. At first I couldn’t believe it: how could Linux, which is so much better than Windows, be so much more difficult to install software on? If I had started with the knowledge that there are more issues than under Windows, that there are good reasons for this, and that there are certain steps that one can take to help make the process go smoothly, I would have been much happier.

I am a second generation Linux user. The first generation of Linux users are dedicated hackers with the in-depth knowledge needed to install, configure, and even modify Linux to run on their computers. The second generation are ordinary geeks, computer power users who are curious about this alternative to Windows and are willing to spend a good amount of time getting it running, but who don’t have the same intimate knowledge of the technical side of computing, and don’t have the ability to, say, write device drivers if their printer, modem, or sound card doesn’t work. This group, in which I include myself, has benefitted from the maturing of the Linux os, especially the addition of GUI components that help smooth the transition from the traditional Windows framework. The third generation of Linux users – if they come to exist, which I sincerely hope they do – will be mainstream users who don’t ever want to see a command prompt or edit a config file. This group will require a fully mature desktop environment, in which almost anything that can be done at the command prompt can be done through some GUI configuration tool.

Derek Croxton
Developer III

< Prev