Letters to the Editor


rsync Solves Networking Problems

Thank you and thanks to Mick Bauer for the articles on rsync [LJ, March and April 2003]. rsync's ability to “pull” as well as “push” solved a long-standing problem of how to synchronize through a firewall without too much hassle. rsync is also more intuitive than rdist.

Tom Kuiper

Pascal vs. C

Pascal and C arrived on the scene about the same time. As far as it went, Pascal was a better idea than C, but Pascal did not go far enough, and C won. Pascal inspired Ada, which was awful. C grew into C++, even more half-baked than C. It took Niklaus Wirth two decades to get Pascal fully grown into a finished product of the quality of the original idea. The result is Oberon-2. Unfortunately, it arrived after the train had left the station. For more see www.waltzballs.org/other/prog.html.

Donald Daniel

How to Authenticate Wireless Connections?

I want to set up something to regulate my wireless network so the person has to log on to the domain.

Aaron Egbert

NoCatAuth, nocat.net, does what you need. We plan to cover it next issue. —Ed.

Latin for Accountants

In response to a letter in the June 2003 issue, I was motivated to clear up a mistake. Kathy claims that “Debit on the left, Credit on the right” in double-entry accounting can be explained by the Latin for left and right. The Latin words for left and right are sinister and dexter, respectively. Credit actually comes from credo, to trust, and debit comes from debeo meaning to owe.


How to Pronounce Linux?

I have an ongoing debate with my son on the correct pronunciation of Linux. I say that it is pronounced either as in finish or as in helix, and my son says it is pronounced as in Lennox or tennis. Who is correct?

Ira Friedman

Listen to Linus Torvalds say it at www.kernel.org/pub/linux/kernel/SillySounds. —Ed.

Why Review SCO?

I've been a fan and a subscriber of your magazine for some time now. However, I was recently disappointed to see you running a review of SCO's Linux product, in light of their lawsuit against IBM [LJ, June 2003]. To get directly to the point, given SCO's opinion, and now their opening terrorism tactics to Linux customers, publishing a SCO product review is in bad taste and insulting to the entire Open Source Development community.

Dave Crown

SCO pulled their Linux distribution from the market, and made sweeping accusations that Linux contains code copied from SCO UnixWare, after we already had gone to press. But our timing wasn't that bad after all. Because we still have access to the SCO update service, we can substantiate the fact that SCO continues to offer Linux source code under the GPL: linuxjournal.com/article/6899. SCO's position on Linux, and the responses from developers and companies, are changing too rapidly to cover in a monthly publication. Check our web site for the latest. —Ed.

GNOME 2 Tips

I generally agree with the opinion from Dr Mark Alford on GNOME 2 [Letters, LJ, June 2003], but I believe some comments will help him and other readers.

You can still use sawfish on Red Hat 8 and configure it from the Extras→Preferences menu, including the keyboard shortcuts and window layout. You need to add the following lines in your .bash_profile file:


See the gnome-wm script in /usr/bin.

You can recover some of the chopped-off functionality of GNOME 2 by writing a Nautilus script. For example, if you want to see the list of files contained in an RPM file, write an rpm command in a script:

rpm -qlp $@ >/tmp/rpmlist.txt
gview /tmp/rpmlist.txt

Many script examples are at g-scripts.sourceforge.net.

Hiroshi Iwatani

Mind Your License Ps and Qs

Although my employer is very supportive of Linux (it's our primary operating system) and open-source development in general, our legal department recently has become quite sensitive to the contents of open-source licenses. Specifically, they are concerned about some of the licenses that require any modifications to code to be distributed back to the original authors—even if it is not otherwise publicly redistributed. They also have discovered some odd parts to licenses, such as “you can use this software, but you have to buy me a beer if you're ever in Boston.” The net result is that we now have to obtain legal approval before downloading, installing, using and especially modifying any open-source software. (They're equally restrictive about proprietary licenses, but that seems justified.) Although I appreciate the levity some open-source “licenses” have, it seems that we may need better standards in licensing to encourage its adoption in litigation-heavy corporate environments.

Doug Cooper

Once you add terms like the ones you mention, the license is no longer a Free Software license or an Open Source one. These issues do not affect the standard free software licenses such as the GNU GPL and the Apache license. Can you get your legal department to approve the standard licenses, so you don't need a program-by-program review? —Ed.

Freedom Powers Software Market

In the June 2003 issue of Linux Journal, a letter from John was run under the title “Freedom Threatens Some Companies”. In this letter, John wrote that he felt the integrated library system Koha, www.koha.org and other free software projects represented a threat to small- to medium-sized commercial software companies. He argued that it seemed likely that a single free software project eventually could dominate a particular market niche and thus drive out the commercial competition. I think he's wrong, both in the case of Koha and in the larger case of free software in general. I can't give specific information about other projects, but I can see how Koha can help, not hurt, the library automation marketplace. Koha is a thriving little free software project. Several mailing lists are devoted to it, nearly 40 people have CVS access, and a growing number of sites use it. Currently, at least three commercial ventures work on Koha actively, and several others offer commercial support for the platform. Any library automation vendor is perfectly able to pick up Koha and create an offering built around it—in fact, I'd encourage them to do so. If Koha doesn't meet their needs, perhaps one of the other free library systems will. Libraries who adopt Koha take on a level of commitment resulting in their giving back to the larger Koha community. In some cases this means developing new features or fixing bugs in Koha themselves, in other cases they might hire someone to do so. Some libraries invest in Koha by reporting bugs, writing documentation, answering questions on the mailing list or explaining library-specific knowledge to developers without library backgrounds. This same kind of commitment is seen from many other users of free software. Not everyone gives back, but enough do to keep the community viable.

Pat Eyler
kaitiaki/manager, the Koha Project

Learning to Document Software

For every line of code we write, every class or function that we make, there must be documentation. My professors all have commented on my documentation or the lack of it. As a self-taught programmer, I see coding as more of an art form than a how-to guide. I had written hundreds of lines of code and projects that do amazing things, but no one could follow my source code. Now that I am helping to develop open-source projects, using documentation is imperative. The Open Source community has brought me into the light. With documentation we can all make beautiful software together. Thanks to Linux Journal for making me a comprehensive programmer.

Carl Jones
Student at Southeastern Louisiana University

C'est magnifique!

Being an apprentice DIY chef and a passionate Linux worshiper, I always enjoy reading Cooking with Linux. Some days ago I was preparing some cookies that reminded me of you wearing a chef hat. I couldn't resist taking some photos and sending them to you! Hope you enjoy them.

Gianluca Insolvibile


I've got to comment on the article “Introducing the 2.6 Kernel” by Robert Love [LJ, May 2003]. Training strictly as a network engineer for 14 years, programming jargon was always over my head. Mr Love kept the developer's jargon in sync with the rest of us out here in the network field, which made it the most pleasurable article I've read to date. I actually understood what the kernel was doing and as such, now have a greater appreciation for what's happening on the inside. I hope you can convince Mr Love to write ALL future kernel release articles for Linux Journal.

Lyndon Tynes
Intel Solutions Center Network Engineer

Keep watching Kernel Korner for more from Robert Love. —Ed.

Fighting C++ Rumors

Bravo on the C++ editorial. The clock is ticking, and die-hard C/procedural programmers are running out of excuses to eschew the notion of C++ as a suitable language for small- to mid-sized projects. The year 2003 is upon us, hence the time to dispel some old rumors (or, in some cases, review some old facts):

  • “C++ is slow”: modern compilers are closing the C/C++ speed gap. Some of C++'s fabled performance lags may be due to proper (and automatic) calls of constructors and destructors, the sort of initialization and cleanup that you already should have in your C code anyway. To close the remaining gap, we can replace certain object hierarchies with template programming, in which we perform decision making at compile time rather than runtime.

  • “Compiled C++ libraries are incompatible with one another”: compilers are stepping up to the line drawn by The Standard, which means this soon will be a thing of the past.

  • “C++ is the worst of both worlds”: this is purely an issue of perspective: imagine the cleanliness of encapsulation, constructors/destructors, exceptions and inheritance when needed, plus the speed of pointers when wanted.

  • “C++ is fat and complex”: is this really C++ or just the OO paradigm? It takes some exercise to get one's mind around it and to write true object-oriented software, but once you understand it you'll never go back. For those thorough procedural programmers, imagine being able to wrap those cleanup-style calls into a function that is automatically (or automagically) called at scope exit.

  • “Not everyone knows C++, and a common language is key for community-style projects”: although is this true in a certain sense, the only way it will change is if people buckle down and experiment with C++. At one point in its lifetime, every computer language was new and therefore not as well known as some others.

With those complaints out of the way, developers can now make a more educated decision as to what language should be used for a given project.



Free Dummies Books
Continuous Engineering


  • What continuous engineering is
  • How to continuously improve complex product designs
  • How to anticipate and respond to markets and clients
  • How to get the most out of your engineering resources

Get your free book now

Sponsored by IBM

Free Dummies Books
Service Virtualization

Learn to:

  • Define service virtualization
  • Select the most beneficial services to virtualize
  • Improve your traditional approach to testing
  • Deliver higher-quality software faster

Get your free book now

Sponsored by IBM