Letters

Thank you for publishing the article "Inside Debian Hurd," by Jerry Epplin (DDJ, December 2000), which discussed the GNU HURD (the GNU kernel), and the Debian GNU/HURD operating-system project that uses it. I am writing to correct a couple of widespread confusions that were repeated in the article, and explain the political and historical context of the work on the GNU HURD.

Longtime readers of Dr. Dobb's Journal will recall that the GNU operating system is a free software replacement for the UNIX operating system. The GNU Manifesto, published in DDJ in 1985, described this project and its philosophical and ethical bases. The Free Software Foundation was organized shortly thereafter to raise funds for developing and encouraging free software in general, and GNU specifically.

By 1991, the GNU system was almost complete enough to self-host — only the kernel was missing. The GNU HURD (started in 1990) plus the already-existing Mach microkernel were meant to be the kernel of GNU.

The HURD's design made it somewhat of a research project, and it took many years to get it working. In the meantime, Linus Torvalds wrote a monolithic kernel, and released it as free software under the name Linux. Others then combined Linux with the almost-finished GNU system to produce a self-hosting free operating system. Variants of this GNU/Linux combination now have some 20 million users.

Alas, most users of GNU/Linux today think that the whole system is "Linux," and believe that its development was started in 1991 by Linus Torvalds. To help correct this confusion, please distinguish between GNU/Linux, the complete system, and Linux, the kernel. In addition to giving us a share of the credit for our work, this will also help readers learn the difference between a kernel and a whole system. See http://www.gnu.org/gnu/linux-and-gnu.html for more explanation.

Several companies package versions of GNU/Linux, but we work most closely with the volunteer group that maintains Debian GNU/Linux. They make freedom one of their priorities. That's why we appreciated their initiative to package a HURD-based version of the GNU system, called "Debian GNU/HURD."

According to Jerry's article, the GNU Project's goal is a "complete open-source UNIX-like OS." Actually, our goal is to make a complete free software UNIX-like OS. GNU is part of the Free Software Movement and has nothing to do with the Open Source Movement.

The Free Software Movement, founded in 1984 along with the GNU Project, is based on values of freedom, community, principle, and ethics. Proprietary software keeps its users divided and helpless; does not respect users' freedom to cooperate, and does not allow its users to treat each other decently. We work to replace proprietary software so we can live outside its dominion. We set out to develop a complete free operating system because nothing less would suffice.

The Open Source Movement was founded in 1998 specifically to reject our idealistic philosophy. They cite only practical advantages such as "powerful, reliable software" as the basis for everything they say, and studiously avoid deeper issues such as freedom and principle. By omission, this encourages people to think that freedom and principle are not relevant to the issue. Its leaders are sometimes even more explicit: Eric Raymond, president of the Open Source Initiative, recently said that "We (in the Open Source Movement)...don't think there's anything intrinsically wrong with proprietary software." The disagreement is deep and wide. See http://www.gnu.org/philosophy/ free-software-for-freedom.html for more explanation.

The Open Source Movement has had a great deal of publicity, and many people think it has replaced or absorbed the Free Software Movement. I receive mail every day addressing me as a fellow supporter of the Open Source Movement; sometimes the sender supports it because he thinks I started it. The confusion stems from articles that use the term "open source" to describe our work — exactly what this article did.

The open source people have the right to promote their views, but the Free Software Movement ought to have that chance as well. When you talk about the GNU Project, or the GNU/Linux system, or the GNU General Public License, please associate them with the Free Software Movement.

Richard Stallman

rms@gnu.org

Interrupt Latencies

Dear DDJ,

Hats off to DDJ for publishing articles on low-level issues. Lately it seems everyone wants to drive a BMW, rather than getting their hands dirty under the hood of the old Chevy. I was especially delighted to see "DOS for Embedded Systems: Interrupt Latencies" by Shai Vaingast and Ehud Cohen (DDJ, January 2001), since I confronted this same problem some years ago while developing my DAQARTA (Data AcQuisition and Real-Time Analysis) shareware. Their method is more quantitative, but mine was more colorful! Here's my approach:

Latency problems in sampled data show up most readily in the spectrum, because missed samples result in a large spectral "splatter" at each discontinuity. With color spectrogram capability already in place, it was easy to pick out tiny imperfections that were nearly impossible to spot in the raw waveform. (A color spectrogram shows time on the horizontal axis and frequency on the vertical, with the magnitude at each point encoded as color and/or brightness.) So when recording to disk, each transfer caused a bright vertical bar where samples were missed.

Because this software runs on any real-mode DOS system, I didn't have the luxury of picking a different OS with less latency. And, as it turns out, hot-rodding DOS has much bigger benefits anyway. The key is that the latency is all in the INT 13h disk handler, not in the rest of the OS. DOS hooks this vector at boot, so it's not clear whether the BIOS routine is replaced or just covered with a wrapper, but the net result is that interrupts are blocked during transfers. Vaingast and Cohen could have just pointed the vector directly at their five microsecond flash disk BIOS, since they knew where it was. But that's not easy to discover in an arbitrary desktop system after DOS grabs it, and normal BIOSes aren't that fast anyway.

So, I bit the bullet and reverse engineered a few BIOSes, and came up with a replacement handler that left the interrupts enabled throughout each transfer. This is not a good idea in general; this handler is only enabled for the direct-to-disk operation, and in real-mode I can make sure that nothing interferes. The sampling interrupts are really quick; they have to be, to sample at high rates. And disk transfers are buffered by the drive anyway, so this is not really as hazardous as you might think.

The result: Extremely low latency (that due to normal instruction times), allowing sample rates above 20 kHz on a 386DX-40, and over 120 kHz on a 200MMX system. These are absolute worst-case tests, using an acquisition board that has no independent pacer timer. That means that rather than starting each sample at a precise time and interrupting the CPU when data is ready, such boards rely on software that waits for a system timer interrupt and then starts the sample via software command. So any latency at all causes the sample times to jitter, whereas a pacer system only has problems when the latency is so long that a sample interval is skipped entirely. The jitter shows up as an elevation of the noise floor, and at the aforementioned limits it's just detectable as a faint vertical line in the spectrogram, but still not visible in the raw waveform.

By comparison, the same board under Windows would have serious problems just reaching 1-kHz sample rates, even without disk transfers. When it comes to the Holy Grail of "hard" real-time, good old real-mode DOS "ain't dead yet!"

Robert Masta

tech@daqarta.com

Setting the sqrt() Record Straight

Dear DDJ,

Contrary to Ben Laurie's letter in the February 2001 issue of DDJ, Todd Stephan ("Letters," DDJ, January 2001) is correct in claiming that the sqrt() can be omitted in the Traveling Salesman computation. Ben's letter in the February issue that addresses this contains an error. Ben states that omitting the sqrt() is equivalent to suggesting that a^2+b^2>c^2+d^2=>a+b> c+d. This is not true, since sqrt(a^2+b^2) does not equal a+b. It is sqrt(a^2+2ab+b^2) that does.

Saty Raghavachary

satysharon@earthlink.net

Due to production problems, Figure 7 of "Consistency-Based Diagnosis" by Girish Keshav Palshikar (DDJ, March 2001, page 56) contained erroneous symbols. Our apologies to the author and readers. The corrected figure appears here.

DDJ