Letters to the Editor

by Various
“Linux Means Business: Highway POS System”

In Linux Journal, November 1997, there is an article by Marc Allen about Linux running a gasoline station. Mr. Allen, an employee of the vendor of the system, Schlumberger, states: “We are, however, the only Unix-based one.”

Not a bad story, but not completely true. At the gasoline station where my brother works, the whole system (pump control, sales, e-cash) has been working under SCO Unix for more than 1 year—24 hours a day, 7 days a week, running on a 80486 PC.

The company that makes the software is Sofitam of Belgium (Satam is the gasoline station equipment).

—Groeten Ben Erkens, The Netherlands berkens@airchips.xs4all.nl

Linux as Proxy Server

I would like to point out that in the article called “Linux as a Proxy Server” by Peter Elton in the December issue of LJ there was absolutely no mention of Linux's built-in firewalling and proxying support. As I think most seasoned “roll your own” kernel compilers will know, Linux can do almost all of what Peter describes without resorting to any extra user-level daemons or utilities. I am speaking specifically of the kernel's IP Masquerading, Transparent Proxying, Accounting and Firewalling features. From the included Listing 1, it seems that Peter was using a very antiquated kernel indeed and perhaps these features did not exist. When writing about bleeding-edge operating systems one should do the proper homework to be aware of current OS features.

—Oliver Jones orj@ihug.co.nz

Something Funny

I have been following LJ for over a year now and can't believe how good it's getting. I like the design changes, the way you shortened the “What is Linux” part, and every issue is a better mix of topics than the last one.

If you want to hear something funny, my brother works at a major American software company, and he tells me that developers there are bringing up the topic of porting their products to the Linux platform more and more frequently. Apparently there is a lot of Linux quietly installed around the world (enough to be seen as a significant market by a large American software player).

—Harold Sinclair morelife@stealth.net

Microway Screamer 533 Review

I'm writing in response to the review of the “Microway Screamer 533” by Bradley Willson which appeared in the January issue of Linux Journal. This review is especially timely for me as the research group I work with is purchasing a new computer for development work, and the price and performance of the Alpha-PC running Linux are extremely attractive. As I started to read the article, however, my excitement quickly waned. Nowhere in the review of the Screamer 533 are there meaningful benchmarks. Moreover, the benchmark that the author put together is worthless for precisely the reasons mentioned in the article: so why include it?

The author would have done better for Linux Journal and Microway if he had included results from the SPEC benchmarks (SPEC benchmarks run on the Screamer 533, not benchmarks from Digital with the 533/21164A chip running Digital Unix in some form of an Alpha Station), the BYTE and Bonnie benchmarks and, perhaps, some of Microway's own programs. All benchmarks have shortcomings but they are much more useful to convince coworkers and bosses with than stories of fast cars.

Please Linux Journal, give us meaningful hardware reviews.

—Rich McClellan rich@chemistry.ucsc.edu

I wrote to Ann Fried and asked her if she would make 533 benchmark numbers available on their web site. I have not received a reply yet.

For you, the article did not satisfy your questions and for that I apologize. I wrote the article for a less technical audience because of market demographics. There are simply more Intel/Linux users than Alpha/Linux people. The focus of the piece was to direct their attention to a machine they might otherwise overlook because of price, technical astigmatism or both. The academic and technical audiences generally have resources that allow them to own an Alpha and understand it, as you have demonstrated.

I realize that this does not help you sell the machine to management, and to that end I will continue to work with Microway to get some meaningful numbers to you.

—Bradley J. Willson cpu@ifixcomputers.com

Evil Cookies

In January's “At the Forge”, Mr. Lerner writes that cookie information cannot be shared between different web sites. True, but cookies still present a danger to people's privacy. The large banner ad sites all use cookies, and their ads appear as in-line images on many web sites. So it doesn't matter if you visit Lycos, the New York Times or some other site—as long as the banner ad is there, the banner ad site will be able to use its cookie to track where you've been and tailor the ads it shows you appropriately.

—Joey Hess joey@kitenet.net

Linux Ports

I am writing in response to Dave Blondell's letter in December, where he says “The sad truth of the matter is that Bentley, and for that matter most other software companies, don't get enough requests for Linux ports to justify the production costs.”

Perhaps it's true for ports from non-Unix environments, but it surely is not true otherwise. In the same issue, a look at “Linux Makes the Big Leagues” by Sam Williams and the “A Place for Linux” presentation by Chip Richards (mentioned by Sam) shows exactly how I persuaded our company to start using Linux. For only $250 we could have Linux with Metro Link Motif—what's more, we could use a cheap PC clone that put our HP715 to shame in the performance stakes.

Since we associate closely with some of our clients, they often visit and get to see some of the new enhancements that are under development. Often they noticed how fast Linux was compared to other platforms, and switched to Linux.

And the best part is that I never need to change a line of code when compiling across platforms—I use simple shell scripts that are used as CC and LN. The combination of Linux[Intel] with its BIG ENDIAN architecture and HP-PA RISC with its nice LITTLE ENDIAN (same as networking) provides a nice combination of test beds to ensure both byte swapping and 64/32 bit compatibility are tested.

At the end of the day it is no extra effort to provide a Linux solution. Probably the biggest deterrent is the loud anti-commercial chorus. Those folks who don't mind paying for software should be more vocal.

While not everyone may appreciate or use any of the free software that I have contributed to the Linux community, some of the credit must go to my employer (who does not provide free software as a rule), for the skills and resources I used to create my free software were gained from them; in return, they use some of my free software.

—Ross Linder ross@mecalc.co.za

Author Photos

Did you guys happen to notice how much the author Richard Sevenich bears a resemblance to the author Dean Provins? By golly, they could be brothers.

—M. David Gelbmand gelbman@npiny.com

Yes, we did notice. Unfortunately, at the same time you did—when the magazine arrived from the printer, not before we sent it to be printed. We apologize to both Mr. Sevenich and Mr. Provins for the mixup —Editor

Articles on Beowulf Systems

Thanks for the articles on the Beowulf systems and PVM. I have known Patrick Goda of the Loki system for three years now, since he came to our local Linux User's Group this past spring to talk about Loki.

I was a little disappointed that there was no mention of what I consider to be the ultimate in “Freely Distributed Systems”: the “Stone SouperComputer”. The Stone SouperComputer is a project at the Oak Ridge National Labs, the same laboratory that gave us the PVM software.

It seems that a project at Oak Ridge needed some computer power, but had no budget for it. They decided to implement a Beowulf system using donated computers. By using older 486 and low-end 586 systems donated to them, they were able to create a no-cost supercomputer. It now has 48 system boxes working together to do real-world work. You can find the web pages at http://www.esd.ornl.gov/facilities/beowulf/.

I am very excited about the “Stone SouperComputer” project, because for the first time it demonstrates that any university, college, high school or even grade school can put together its own “Soupercomputer” using a freely distributed operating system and allow students to tackle the most difficult type of coding, that of a parallel environment. It also paves the way for low-cost, highly available, high throughput systems for research or even administrative work.

—Jon “maddog” Hall, Linux International maddog@zk3.dec.com

Microstation 95 Update?

We have contacted a Bentley re-distributor in our area who informed us that they could in fact secure us a copy of Microstation 95 for Linux. We have also checked with the supplier of our current add-on software to make sure that their software for Microstation would run on the version for Linux, and we were informed that not only did it run on Linux, but that they had customers already doing just that. While it is possible that the other customers may include academia, I don't believe they all are. This leads me to believe that, with the help of a good re-distributor, users outside academics should be able to get a copy. Although the distributor stressed the “unsupported version” heavily, with a demand for the Linux version this may disappear. Please keep up the great work.

—Medina County Engineers lfilak@ohio.net

Red Hat CDE Article

As an owner of Red Hat/TriTeal CDE, I was interested in the CDE article in the January 1998 issue of Linux Journal. However, I'd like to add one thing to the article concerning the root dtlogin “problem”. This isn't actually a problem, per se, it's a “feature”. Refusing dtlogins by root was chosen intentionally for security reasons. However, this feature can be disabled, as I discovered when I asked Red Hat support about it. Here are the three things that they suggested could be done:

1: Add dt to the /etc/securetty file.2: Remove the /etc/securetty file.3: Remove the line in the /etc/pam.d/dtlogin file referencing secure tty.

I simply did number 1, and now I have a nice X root login.

—Matt Harrell mharrell@voyager.net

URL Error

For your information, there is an incorrect URL in your “Ricochet Modem” article by Randolph Bentson (January 1998)—www.metricom.net does not work. The correct address is http://www.metricom.com/.

—Thomas K. Pedersentpedersen@kraft.com

Comments about January 1998 Issue

I am happy to see an issue devoted to parallel processing, but I am curious why you did not include information on the Linux SMP project which is at http://www.linux.org.uk/SMP/title.html? This project is directly related to parallel processing.

Also, will LJ make any future effort to make an archive CD-ROM of all the past issues? I hope so, that would be great.

—Steel Viper sviper@soli.inav.net

I wish we had room for everything about our focus but there are only so many pages in a magazine. I would like articles about SMP and the Stone Soupercomputer program mentioned above, but they will have to be in the future. As to your second question, an archive CD-ROM of 1994 and 1995 will be available in March —Editor

Load Disqus comments