Dr. Dobb's Journal August 2001
It's my anniversary again. I started writing this column in the August issue of 1988, 13 long years ago. Among the many benefits of this assignment is a collection built over the years of an impressive technical library. Trade journalists get lots of books and software from publishers who hope we'll favorably review their products and, when absolutely necessary, we might even buy something. Having limited bookshelf space, I periodically purge the shelves of the older stuff and donate whatever I don't need any further to a local computer user's group. I made such a contribution last week. Since I shifted the emphasis of this column to Linux, the books have been pouring in. My shelves are jam-packed with Windows programming books and software, and there is no room for the new Linux books that arrive every week. As I pulled down the stuff and boxed it up for the user's group, something occurred to me. Since Linux applications software does not come in pretty, multicolored, glossy boxes with expensive manuals and CD-ROMs, we computer users won't have any Linux applications to give away when the apps become obsolete. But worse, there will be no charitable contributions we can write off. Linux software is free. Mostly you download it from the Internet with the blessings of its altruistic authors. I wonder if these upstart Linux developers realize the economic impact their generosity will have on a system of free enterprise that depends heavily on tax write-offs — depreciation, contributions, and all that. Maybe that's what that Microsoft executive meant when he said that open source is unAmerican.
A recent column generated more mail than any column in the baker's-dozen-year history of the "C Programming" column. When I described my quest for the perfect Linux programmer's editor and explained why, for me, emacs is not that editor, the mail just came pouring in. Nothing stirs a programmer's heart more than a discussion of text editors, and you responded in kind.
I had worried that my complaints about emacs might generate flames from its loyal users. I admitted that my problems were because I did not understand and could not easily find adequate documentation about how to configure emacs, which involves a text file named ".emacs" that uses a Lisp-like script language. I was wrong about the flames. Maybe there are emacs zealots who would flame a foundering columnist who was struggling with their favorite tool, but those programmers must not be reading my column. Or else they think I'm not worth the trouble.
Most of you who responded confessed having had similar difficulties with emacs as you learned its use. Many of you explained how to address one or more of my issues. Many sent copies of your own .emacs configuration files. Interestingly, not one reader was able to address all the issues, although all the issues did get addressed by a combination of the messages. Several of you reported that you could not find how to fix one or another of my problems, even after a thorough search of the online help documentation. These were experienced emacs users, too.
I won't publish all those .emacs configuration scripts here. If you need one of the solutions, let me know and I'll forward one of the appropriate responses.
Another camp of respondents reported that they, too, had dismissed emacs as being too arcane for their tastes. These readers each named their favorite editor as something I should consider. An overwhelming majority supports an open-source editor called "nedit" (http://www.nedit.org/). Nedit is included on the Mandrake 7.2 distribution I run on my laptop, so I was able to try it. This version (5.1.1), dated March 2000, is the most recent. Like the Kwrite editor I mentioned before, nedit does not do word wrapping intuitively. Maybe a newer version will do it better. Word wrapping is not an essential feature for a programmer's editor, but I have to write prose in addition to code and need to wrap my words. This version of nedit does not integrate well with the font setting system, either. I haven't yet gotten it to set a font I can see well on the laptop screen. Finally, nedit uses the Del key wrong. It works the same as the BkSp key, which is counterintuitive. I don't need two character delete keys that delete the character to the left of the insertion point. There doesn't seem to be a way to change it, either. Nedit looks like a full-featured programmer's editor, but I'll have to wait until I see a more recent version before I choose it for mine.
A few of you wrote that your editor of choice is VIM (which stands for "VI iMproved"). Vi is the venerable old *nix text-mode editor from the days of yore and VIM runs vi in a window with other enhancements. Those few readers each accompanied their confession with an apology as if they had been caught doing something naughty. Apparently it's not cool to like vi and its descendants. I used vi quite a bit in the past. It was the best of two editors available at my ISP's server site when I was experimenting with CGI programming a few years ago. The other editor was TECO. I don't care to repeat either of those experiences, so I haven't looked into VIM at all.
Last month, I reported from the rural farmland of Pennsylvania that my exile was exacerbated by having to use an old version of Red Hat Linux on an old laptop. I wanted to report about Red Hat's latest distribution, Version 7.1, which includes lots of new stuff and the latest Linux kernel, Version V.4. But I couldn't because the release candidate would not install on the old laptop, which did not have sufficient memory and hard disk.
This month, I'm back on the farm, but with my newer laptop fresh from the repair shop. It has plenty of space and I have the official released RH 7.1, not just a release candidate. Guess what? 7.1 won't install on this newer laptop either. Consequently, I'm still stuck in the dark ages, running the 2.2 kernel under Mandrake 7.2.
(Now, please don't rush to your mail writer to demand to know why I am not using Mandrake 8.0, recently released with the new 2.4 kernel. I am not using it because I don't have it. It's as simple as that. We trade journalists get lots of freebies, but not everything comes our way.)
There's nothing exotic about my hardware, just your plain, vanilla Toshiba Satellite P466. But Red Hat's installation program freezes consistently during the process where it's asking about the mouse and the screen and all that. Total lockup. Reboot required. Installing in text mode does not fix it. The stupid setup program sees a graphical video system and ignores your decision to run the installation without a GUI. I had this problem with the release candidate, too, and hoped it would get cleared up before the candidate got sworn in, but no such luck. It makes you wonder. Why doesn't the leading Linux distributor ensure that their setup program works with one of the most popular laptops? Makes you wonder, too, what else might be wrong in Red Hat country. Read on.
I successfully installed first the release candidate and then the official released version on my desktop at home before leaving on this trip, and I have the following items of bad news to report. First, some things got broken between the release candidate and the release. For one, the KDE dialer program that connects my modem to my ISP got flaky. It can't seem to stay in sync with whether the connection actually went through or not. It worked fine under the release candidate. For another, the annoying behavior of earlier versions that require you to tell it to shut down the OS twice has returned.
There are other problems with 7.1. I reported last month that Red Hat distributed a broken, unauthorized GCC compiler in Version 7.0 and that people were upset about it. Red Hat did not correct this situation in the new release. I guess it would have required them to admit they were wrong. Heaven forbid.
Red Hat 7.1 does include recent versions of the KDE GUI operating environment and the KDevelop IDE. This is a good thing, because programmers can use this distribution to experiment with developing KDE, GNOME, and QT applications from within KDevelop. But experiment is all you should do unless you upgrade the compiler and recompile the libraries. It wouldn't be wise to distribute software developed and tested with an unauthorized compiler.
KDevelop looks and feels a lot like Microsoft's Visual Studio. It supports development of programs under the various GUI operating environments and console applications, too. It has a decent programmer's editor and integrated debugger and has become my Linux development platform of choice.
(Being on the farm again, and not having KDevelop installed on this laptop, I am writing the following description from memory. If I get something wrong, be advised that I shall wear my flame-retardant long johns all next month. Fire away.)
Among KDevelop's strong points is the automatic generation of scripts and configuration files necessary to integrate an application's source code into the open source way of distribution. To distribute your program to all its potential users, you must set the code up to be built and installed on all the *nix platforms that the program should support. This procedure involves automatic source code and makefile configuration scripts.
When you install an open-source program, you typically start by running the ./configure command from within the source-code directory followed by the make install command. The first command examines the application's configure scripts, source code, and some system files that cooperating platforms must include. If everything is in place, the command generates the makefile. The second command builds the application from source code to execute on your configuration. Along the way, the procedure determines whether you have the prerequisite libraries installed on your system. These processes involve utility programs called "autoconf" and "automake" that operate on configuration scripts that the open-source developer provides.
Presumably, by using KDevelop, you can let the IDE generate the configuration scripts for you. How nice to be able to ignore these abstruse details of automatic configuration, building, and installation. But it might be a good idea to learn the architecture that underpins those procedures. We programmers like to raise our levels of abstraction to higher layers so we can ignore underlying technical details. That's why we have high-level programming languages, information-hiding class libraries, IDEs, and such. But even though you might not want to be that close to the metal, sometimes you need to know what the metal is all about. Consider the work of a network administrator.
Another thing got broken in Red Hat 7.1, which might be because of the new 4.2 kernel. There are several Windows and Linux machines at my house, and the main desktop is also the gateway to the Internet. One dialup connection lets the other machines access the Internet. I used procedures from the Chris Negus book, Red Hat Linux 7 Bible (Hungry Minds, 1999), to configure the gateway and the other computers, which involves some trickery with the fwchains command and something called "IP masquerading." The procedure worked fine with Red Hat 7.0 and does not work with 7.1. Something is wrong with DNS resolution that was not wrong before.
All of which leads me to a conclusion I made about Linux administration. You can't learn it by using a cookbook approach. You can't simply find a procedure that works in one particular book author's configuration and expect to understand enough about it to deal with things the author never encountered. In this case, the author was writing about a previous version of the kernel. Even so, authors of distribution-oriented books tend to teach the use of the GUI configuration tools that accompany the distribution, and those tools hide the details of the underlying architecture from their users.
Linux is configured with combinations of internal kernel tables, configuration text files, and shell scripts. You manage internal table entries with commands from the command line, and you manage the configuration files and scripts with your favorite text editor. You do, that is, if you know what you are doing. The distribution vendors, in their zeal to provide a dumbed-down interface for the typical user, and in their ultimate hope to make Linux a mainstream desktop operating system (not in my lifetime), wrap the administration commands and file management in GUI applets. Only they never seem to get it right. The authors teach the applets rather than the underlying architecture, and the applets never seem to work 100 percent. Authors are usually limited in their experience to the configurations at their houses, so they rarely anticipate everyone's administrative needs. And the distribution vendors keep changing the applets in an effort, I suppose, to get it right. The books are usually out of date by the time they hit the shelves, and even when they are not, you never learn quite enough to get the job done.
I have been criticized for depending too much on books to find solutions to Linux problems. I should be using newsgroups wherein, I am told, power users lurk, waiting for novices like me in need of their expert assistance. My experiences with newsgroups indicate that you can indeed find quality help there but, like everything else on the Internet, you have to separate the expertise from the bovine droppings, and when you are looking for technical details, it's not always easy to tell the difference. And, of course, you expose yourself to fools who similarly lie in wait only to flame you for not already knowing the answer to the question you are asking. Unmoderated anarchy has its place, I suppose, but it takes its toll in time wasted.
Realizing a need to understand network administration from a lower level, I turned to Linux Network Administrator's Guide, Second Edition, by Olaf Kirch and Terry Dawson (O'Reilly & Associates, 2000). This marvelous book is available online at http://www.oreilly.com/catalog/linag/. Being old fashioned, I prefer the printed version, which works a lot better out here in the hinterlands where the Internet doesn't reach. You probably shouldn't start with this book, but you should eventually get to it. After muddling your way through understanding the architecture and not getting it right and not getting your network running the way you want it to, and with only enough knowledge to get yourself into trouble, this book is for you. So far, the book has handled all my needs with Linux network administration. Highly recommended.
DDJ