Dr. Dobb's Journal April 2001
Last month I announced my intention to switch development platforms from Lose32 to Linux KDE. You can read that column to understand why, and I shall not belabor that rant any further. At the time I wrote that announcement, all I had were good intentions based only on what I had read about Linux. This month my intentions are replaced by real progress, and that's what I'll discuss. I haven't written any Linux programs of consequence yet, but I now know a lot more about Linux than I ever wanted to.
I say "real progress," and such it is, but the rate of progress has been abysmally slow. My goal is to eventually replace the Windows user and development platforms here at home and in my road machines with Linux platforms. That means a working LAN with at least one integrated Windows machine so I can begrudgingly support old projects. I need at least one good machine with a high-end sound card for MIDI and audio applications. I need dial-up Internet access on the road and cable modem access at home. And, of course, I need a full software development environment for applications, network and driver programming, and perhaps kernel modification.
All those things I want and need are mostly possible with Linux. Mostly. I'll address some of the deficiencies later. But here's the irony: If you wanted to build such a system based on the ubiquitous, monopolistic, evil-empire Win32 platform, it might take you a day to get it up and running. If you needed to climb the learning curve, maybe three days maximum. MicroSmurf ("Little Blue") really understands that aspect of a successful software product. If typical users can't install and configure it, typical users won't use it, and it will make nary a dent in the desktop marketplace. Whatever else they did, they got that part right.
It's been a month since I started installing and configuring Linux, I have worked on it steadily during that time, and I am far from achieving anywhere near my objectives. I have made some progress but not nearly enough given the time it's taken.
In the past two months, I also mentioned the inept defense that Microsoft mounted against the relentless attack waged by the Justice Department. Probing Linux reveals another example of that phenomenon. The case against Microsoft centered around its integration of Internet Explorer into the Windows environment, an act that eliminated the competition posed by Netscape by making commercial web browsers unnecessary. This integration and the effect it had on competition was core to the government's charges that Microsoft used its monopoly position to engage in predatory competitive practices.
At present, the only viable alternative to using Windows on the x86 platform is Linux, which now has several GUI desktops from which users can choose. Thus, Linux (as Steve Balmer recently acknowledged) is the only real competition to Windows.
Guess what? The Linux desktop integrates web browsing into its explorer windows exactly like Windows does. Connect to the Internet, open a file folder with Disk Navigator, type a URL into the Location text field, and presto, chango, you are surfing the net from within the desktop's explorer window. So far, the Linux browser does not support everything a web site can use, but it's only a question of time.
When the Microsoft legal team tried to explain to Judge Jackson that web browsing is a natural, integral extension to an operating system, did it ever occur to them to argue that their only competition sees it exactly the same way?
Do you suppose those guys will enjoy being lawyers once they get the hang of it?
An article in the February 2000 Linux Journal speculates that the next domain for Linux to invade and perhaps overtake is the desktop users market. To do that, Linux has to be relatively easy for the typical desktop user to install and use. Relative to what, you ask? What else? Windows, of course. The open source volunteers who work on KDE and the GNOME developers have made a lot of progress toward building congenial user interfaces. Linux developers have a long way to go, however, in the installation department.
Linux is simply too complex and difficult to configure and install. There are some would-be congenial GUI applications that ease the configuration process, but they only make the interface to the internal stuff easier; they do not raise the users' level of abstraction even one thin layer. To configure Linux you have to know a lot of low-level stuff about TCP/IP, modems, video hardware, LAN and Internet architecture, and so on.
Furthermore, Linux does not work with some of the hardware that OEMs distribute. The drivers don't exist; entire classes of common devices are unsupported. OEMs will not offer preinstalled Linux as an option if it doesn't work with their devices.
Does it sound like I'm saying the volunteers aren't doing enough or going fast enough? I am. Don't tell me how your noble efforts are going to bump off the commercial competition unless you are willing to put in the effort. Don't criticize me for being critical from outside without being a part of the solution, either. That's the job of a pundit. So before rushing to your mail program with sanctimonious flaming intentions, hear this: I am not the enemy; I am on your side. But I digress.
In the September 1994 issue of DDJ I discussed problems with installing, configuring, and using IBM's OS/2. My mailbox was immediately filled with flames from outraged OS/2 aficionados asserting that a self-proclaimed computer expert like me should be ashamed for having so much trouble with their darling operating system. I responded that I did indeed get it installed, but that getting and keeping it going required most of my skills as a systems programmer and operating- system specialist. (I once did 360 OS Sysgens, lest you doubt my dubious credentials, and may I never have to repeat that particular IBM-foisted horror.) I suggested then that if IBM wants OS/2 to achieve a respectable share of the desktop market, they'll have to surmount the installation woes and frequent crash blues so that typical users can install and use it. Furthermore, said I, unless they heed that advice, OS/2 is doomed to obscurity if not virtual death. Guess what? RIP OS/2.
And IBM was paying their programmers to get OS/2 working.
Should I say I told you so? Isn't it great being right?
The Linux cognizanté might wonder why it took me so long to see the light and embrace Linux. The Linux kernel is almost 10 years old. Distributions of the kernel with compilers and command-line tools were available seven years ago. Why didn't I jump on the bandwagon sooner? The answer is: I don't blaze trails. Dennis Ritchie and Ken Thompson blazed trails. Bjarne Stroustrup blazed trails. Linus Torvalds and Alexander Stepanov blazed trails. Bjarne told me you can always tell who the pioneers are: They're the ones with the arrows in their backs.
I learned my conservative approach from fellow author and DDJ contributing editor Ray Duncan who wrote the authoritative DOS programming book, Advanced MS-DOS, which sold a kazillion copies. Jumping on what looked like an early trend, and eager for more royalties, Ray did his research and wrote a trail-blazing follow-up book on OS/2 programming, a great book that bombed. Ray and his publisher anticipated a trend that did not happen. Nobody followed the trail he blazed. I learned a lot from Ray's experience. At about that time my publisher was encouraging me to write a book titled something like Turbo C for the Macintosh. He even got an ISBN assigned to it and sent me a Mac. The book is listed in the Library of Congress's catalog of published books. Except that Borland never released the product and I never wrote the book. There shall be no arrow scars on my back.
As a programmer and computer user I ignored Linux for years except when I developed CGI programs for web sites with Linux hosts. Waiting for it to catch on, you see. Now, for all the reasons I explained last month, and because I am bored with writing Lose32 applications, I decided to switch. There's another reason. Looking forward to my columns of the future, there isn't much about C and C++ programming in my sights because nothing interesting and new is happening, all the press releases I get notwithstanding. I already secured my position as president of the Dead Horse Molester's Society by flailing on the issues of C++ standardization. I already published all the Windows tools and applications that interest me. I refuse to blaze any C# trails. (C# looks like just another cure for insomnia, and I hereby predict a fizzle.) I beat up Microsoft until I was blue in the face. What's next?
Linux is what's next. It fills my bill because it looks like fun and it isn't a trail that needs blazing. A trip to Books-A-Million reveals a shelf load of new Linux books. Most of them are out-of-date by the time they hit the shelves — the target moves so fast — but their presence indicates that people and programmers outside the inner sanctum are showing interest in Linux. Publishers don't put out books until they think plenty of people will buy them.
I've abandoned good intentions in the past, but I hope this won't be one of those times. Here's why. Having now installed Linux on several machines and having actually gotten some of it to work, I can say this with some measure of surprise: Linux has never crashed on me. It has behaved strangely as I groped through the configuration files and tried this and that to get stuff working, and I've found a few bugs, but Linux has never crashed — even though I keep it running all the time. No wonder countless ISPs use Linux for web servers, DNS servers, FTP servers, dial-up servers, and so on. Linux is a remarkably stable operating system.
By comparison, my new belch-fire, neck-snapper 933-MHz P-III HP Pavilion with Windows ME installed has an interesting feature. The top of the system unit has a lid that looks like a typical boom-box CD player. What it covers, however, is a storage compartment for a couple of CDs. What's this for, I wondered. I opened it to find a cardboard CD-sized disc inside. The disc is labeled in three languages, "Store Your Recovery CDs Here!" Holy mazoley! How's that for inspiring confidence in the latest version of the world's most pervasive operating system? They expect it to crash so often that a bookshelf or desk drawer is too far away for the recovery discs.
There are many varieties of Linux. You can get distributions from RedHat, SuSE, Corel, Mandrake, Debian, Caldera, and others. You can even download the source code and build your own distribution. I've worked only with RedHat because that's the first one I got. Corel announced late last year the sale of its Linux business because the product lost money in 2000, which reinforces my notion that it takes a really creative marketing department to make money on something that is perceived by the marketplace to be free.
There are other free UNIX knockoffs, too, for the x86 platform. FreeBSD derives from 386/BSD, a project originally described by its developers in DDJ in 1991 and 1992. OpenBSD is the system my ISP chose to replace Linux for his web server machines because of security issues.
A Linux distribution includes the Linux kernel, several text-mode and GUI shells (desktops), and all the command-line tools. I'm most familiar with the RedHat distribution, which is currently up to Version 7.0, and a visit to the bookstore reveals spanking new RedHat titles that address and include CD-ROM Versions 6.0, 6.2, and 7.0. My experiences with 6.2 indicate that you really want 7.0. The question is, how relevant is the current literature and how much has changed?
The biggest Linux hurdle — installation and configuration — is what changes most as the RedHat developers keep trying to get it right. The 7.0 version of the linuxconf tool, which presents a GUI front end to the bewildering maze of Linux configuration files, and which covers only some of them anyway, is considerably different than its 6.2 version. But the linuxconf help database hasn't changed at all; it describes some other, presumably earlier, version of linuxconf, and it addresses things that aren't in the later versions of the program.
All these variations and versions involve a certain amount of incompatibility, which means that a binary distribution of an application that was built for one Linux might not, probably will not, work on others, even when they use the same hardware platform. For this reason developers typically distribute source code and instructions for building the application. This distribution model almost certainly discourages for-profit developers from writing for the Linux market. Eventually someone might figure out how to make piles of money with Linux applications, but I think that time has yet to come.
I installed RedHat 6.2 and then 7.0 on a Satellite 1625CDT laptop. The installation went mostly okay with three significant problems.
Solving the sound card problem was not easy. RedHat includes the OSS/Free drivers, but they do not support the laptop's CS4281 chipset.
I downloaded the ALSA drivers (http://www.alsa-project.org/) and set about to install them. I can't remember when I have read installation procedures that are more abstruse. I'll have to get a lot smarter about Linux even to understand what they say. This is one of my main criticisms of the Linux community. Many of its members don't know how to write clear instructions because they don't understand that they have to write down to an audience that knows less than they do. The drivers are free and they support my laptop's sound chipset, but I haven't a clue about how to install them.
Next I downloaded the Open Sound System drivers from http://www.4front-tech.com/. These drivers cost big bucks — twenty dollars — but you can try before you buy. Having a price tag motivates a developer to make a product usable, and I had no problem following the instructions and installing the drivers. After I did, Linux automatically uses the correct sound hardware. That's how it ought to work, and it's well worth twenty bucks. I don't know why we must keep relearning the economic realities of the open-source development model.
The OSS drivers are buggy, though. Under certain circumstances when playing .wav files, the sound has annoying pops at regular intervals. It seems to happen when something happens on the screen such as updates to the Media Player's progress display. But it doesn't always happen.
There's not much that can be done about the laptop's internal modem. It simply is not supported. I'll have to take an external or PCMCIA modem on the road with me. I read a bunch of stuff on the Web about internal modems and Linux, and here is another place it falls way short of being acceptable for mass use. There are places where you can read how to get various internal modems to work, but the one in the Satellite is not one of them.
The Satellite laptop uses video circuits that Linux's probe recognizes, but its monitor is unspecified. It came with Windows 98 installed and the Win98 Control Panel's Display Properties dialog says only that a "default monitor" is used. Linux uses X11 as its underlying display engine and the RedHat installation program wants that laptop to use something called the "generic monitor." This setting supports only 640×480, which is simply not enough real estate for GUI desktops. It took some playing around to find that the "generic multisync monitor" selection works and permits 600×800, which is what I wanted. If you want to change the settings later, you have to use a program called "Xconfigurator." Of course, Xconfigurator does not have entries for "generic monitor" and "generic multisync monitor." It has a different list of monitors and simply defaults to the "Custom" mode where one is expected to provide sync and scan rates, which I do not know. Trying to set it to something always changes the configuration file even when you decide you don't know what you are doing and need to abort the process. This can make the system not boot the X server correctly and you have to work on the problem in command-line mode or completely reinstall the operating system. It's a mess.
The easiest part about getting Linux up and running was the LAN. Linux is really good about recognizing network adapters as long as they aren't too old. The daunting part was figuring out what to use for IP addresses and how to assign host names. Each network adapter and modem on a computer gets an IP address, each one gets a primary name and domain name, and the computer gets a host and domain name. I still haven't sorted out the meaning of these different names, but it's getting clearer. All the books I have explain it. Only one of them comes close to clarity. More about that later.
Linux uses the PPP protocol to connect to the Internet via a modem. Getting that to work can be a substantial effort. I recommend a careful reading of http://www.theory.physics.ubc.ca/ppp-linux.html. This web site steps you through what it takes to get connected, authenticated, and onto the Internet.
It begins by saying, "The key problem in hooking up a PPP link...is that the ISP's seem to compete with each other as to who can find another obscure way of authenticating users...The chief difficulty of connecting to an ISP is discovering which technique is actually being used by the ISP in an orderly way. Since few of them know anything about Linux, and since few of them even understand what technique they actually use, this procedure should allow you to set up without their help, or to understand what their help means if it is given."
The author's procedures get the job done, but he implies that connecting to the net is difficult because of ignorant or incompetent ISPs. If that were true, Windows users would have the same problems, and they don't. The real problem is that Linux is not smart enough to figure these things out on its own, and users have to jump through hoops to get it working.
The clarion call of the open-source movement is that software is free. You can get it for nothing, and you can get the source code. True. But can you get by with just that? Maybe you can. I can't. Stacked in front of me is a pile of books totaling about $500 retail and probably representing a fraction of what I'll spend before this is over. I mentioned some of these books last month.
My collection includes an old book on UNIX System V, necessary because most Linux books neglect to teach much about the commands and architecture. Why do they assume you already know about things like mount and /dev/ and the like? I have a manual on how to use KDE, a book about music and sound, a book that discusses Linux in the business environment, a user's manual for RedHat Linux 6, one for RedHat Linux 7, and one for FreeBSD.
The reason I need so many user's books is that they all seem to have different strengths and weaknesses in explaining arcane subjects, which are the foundation of Linux. As I learned more about what I needed to know, I'd head to the bookstore and thumb through all the books until I found one with the best explanation of whatever was bothering me at the time.
For example, the best explanation about setting up a simple LAN was in a book my ISP gave me, titled The Complete FreeBSD, by Greg Lehey (Walnut Creek CD-ROM, 1999), which isn't about Linux at all. Lehey diagrams a small network with a LAN and router and gateway configuration for Internet access and describes how to set that configuration up. His example is almost exactly what I am trying to do. The book falls open to the diagram on page 400, telling me that my ISP spent a lot of time referring to it when he built his network.
The best overall RedHat user's book, hands down, no contest, is the Red Hat Linux 7 Bible, by Christopher Negus (IDG Books, 2001) with my very favorite acquisitions editor in the whole world, Debra Williams Cauley, listed among the credits. It includes the RedHat 7 distribution on CD-ROM and has been the most informative of all the books I have. So far it hasn't failed me when it comes to understanding and configuring Linux. If there's something I need to know, this book has it.
(By the way, world-famous IDG books, purveyors of the For Dummies books, Teach Yourself books, the Bible series, and other successful lines of computer books, has changed its name to Hungry Minds, Inc. Don't ask me why.)
I have four programmer's books so far and I think I'll need one more — KDE 2.0 Development, by David Sweet, et al. (Sams Publishing, 2001). You can read this book online at http://www.andamooka.org/reader.pl?section=kde20devel, so maybe I won't have to buy it.
An essential book for Linux programmers is Linux Internals, by Moshe Bar (McGraw-Hill, 2000). It explains all that close-to-the-metal stuff you wish you didn't have to know. If you want to do network applications, another one is Linux Socket Programming By Example, by Warren W. Gay (Que, 2000).
As I get further into programming with Linux I'll let you know which books I find particularly helpful.
Being impatient and with an operational Linux in tow and a network almost working, I set about to write my first Linux C++ program. Well, not my first, actually. I did some CGI programming in C/C++ for a commercial web site on a Linux host a couple of years ago. But this was my first one here.
Since I do not have any of the KDE GUI development tools installed, I went straight to the command line and used the vi editor to write a "hello world" program. I compiled the program with gcc and gave it the name "test." It compiled properly and the binary executable file named "test" was there in my subdirectory. I typed the test command. Nothing happened. There was no shell message saying the test command was not found and no console "hello world" output, which there should be if it was found. I tried everything, and it would not work. As a last resort I ran the program with the gdb debugger, and the console output displayed properly. What is this, I wondered? Believe it or not, this back and forth went on for several days, and like the typical male driver who refuses to ask directions, I neglected to go online and ask about this anomaly.
Finally, two things came back to me in a dream from my long ago UNIX days. There is a UNIX command program named "test" that does not do anything if you give it no command-line options. But why was I running that one instead of my own? Then the muse slammed me again right between the eyes. Unlike MS-DOS, the current logged-on subdirectory is not automatically in Linux's execution path. I typed in ./test and the program worked. After several days of head scratching.
I have to find another line of work.
Until then, I shall continue my project of building a full Linux development environment. Once I get the network running properly, and a cable modem router set up, I'll start experimenting with the KDE development environment and libraries, and I'll report about that experience. Then maybe I'll build a real application or two. This could take all year.
DDJ