Regarding “A Survey of Embedded Linux Packages” (LJ February 2001), thank you, thank you and thank you. I couldn't see the forest because all them damn trees were in the way. Your article really helped shed light on what the names are, who the players are and what the scope of the paradigm is.
Living in Northwestern Pennsylvania, we are kind of out of the Silicon Valley mail loop. I've been on Victor Yodaiken's RTL mailing list for two years and still didn't understand the landscape. Your article really helped.
Thanks for helping us stay current.
—Raymond C. Minich
There is an error in “The Best of Technical Support” in LJ February 2001. “ide-floppy” is not the appropriate module for ATAPI class ZIP drives. ide-floppy works for the original non-ATAPI IDE ZIP drives. The appropriate module is “ide-scsi”. This information may be found in the ZIP drive HOWTO.
This is a very serious difference. From firsthand experience, I know that using ide-floppy on an ATAPI class ZIP drive will seem to work but will invariably cause filesystem damage on the ZIP disk (unless one does read-only operations with it).
One of the examples in Mick Bauer's “101 Uses of SSH, Part II” article (LJ February 2001) gives a misleading impression of security. Listing 6 shows how FTP can be tunneled over ssh port-forwarding. If this were any other protocol (say POP3 or IMAP), things would be fine.
But FTP actually uses two connections, not just one. The primary connection (port 21) is used as a control channel, issuing commands to the server. The secondary channel is set up each time there is data to be transferred on a different and random port, if using passive mode. If you're not using passive mode, the situation gets worse. The server tries to make a connection back to you from port 20. Chances are this will be blocked stone dead by any firewall nearby.
Anyway, the ssh command will only forward the control channel and not the data channel. That is enough to protect your password but not the data that passes between the servers. This is a misleading state of affairs because the connection may well work, even though most of it goes unencrypted!
As far as I know, you cannot use FTP over SSH without implementing special “FTP watcher” routines inside ssh. This is not impossible; practically every NAT device on the market does the equivalent. An alternative might be to use the sftp command from ssh2. However, I'm not sure whether this is included in OpenSSH yet.
You're absolutely correct. While I do think there's some value in encrypting the control channel even if the data channel is not, that was a poor example, especially since I didn't point out that the data channel does in fact go in clear text. But it does work, even without an FTP-watcher: I've been using FTP over SSH in the manner described in my article for a couple of years now. SCP is still the most secure way to transfer files with OpenSSH. SFTP is cool, but only partially supported in OpenSSH (client- or dæmon-only, I can't remember which). But you can use SSH Communications' “official” SSH v.2 for free if you run it on Linux, xBSD, etc., thanks to a new “Free Use for Open Source OSes” clause in its license.
Out of all the articles I've read in LJ over the years, few have had as much impact on me as the one on vim (“That's Vimprovemnt! A BetterVi”, LJ February 2001). I often spend more time in vim than I do sleeping, and thanks to the article, I now have a few more tricks to use. Some of the most glaring features I was not aware of were the third mode (called visual), the command mode grep and split. I learned vanilla vi on Solaris, and there are a lot of features in vim I have obviously not picked up yet. That being the case, have you thought about a monthly feature on editors? Since I imagine a great deal of your readers spend a lot of time in editors such as emacs, vim, pico and the like, perhaps a regular feature is in order.
Regarding your 2000 Editors' Choice Award for open-source databases (see LJ December 2000), I disagreed with your pick for the year's best OS database. As per your suggestion, I had a stiff Tom Collins, followed by some White Russians and a few shooters. I became light-headed, then dizzy and finally passed out before reconciling myself to your pick. Having sobered up, I now take to my keyboard for a more formal protest; I suggest your readers contact NuSphere and evaluate their version of the MySQL database. While I realize we'll just have to live with your pick for 2000, I predict that the Editors' Choice for OS databases in 2001 will be NuSphere MySQL—hands down and bottoms up.
We met with NuSphere at LinuxWorld this past February, keep an eye out for a formal product review in an upcoming issue.
Okay, was this on purpose or not? (If it was on purpose, then it was extremely funny; otherwise it was also extremely funny but in a completely different way.) I think the quote, “Beware of bugs in the above code; I have only proved it correct, not tried it,” should be attributed to the great Donald Knuth, not Donald Knut (LJ February 2001, page 14).
I read your editorial (LJ February 2001, page 93) in which you mentioned that LJ is two-thirds the size of Martha Stewart Living with one-tenth the staff. You also mentioned that Martha doesn't have to lay out Perl code.
I wanted to let you know that we definitely do lay out Perl code here at Martha Stewart Living Omnimedia. Don't forget, we have an e-commerce site (http://www.marthastewart.com/) that does several million dollars' worth of business each year. Also, our magazine staff puts out three regular magazines (Living, Babies and Weddings), as well as many special editions.
Presently, our web site is running on NT servers, but we are in the midst of migrating our site to Sun Solaris. And, you might be interested to know that the server that streams media to the site is running Red Hat Linux 7.0! Many of us here at Martha Stewart are open-source fans with a particular interest in Linux. I personally have been reading Linux Journal since issue number one. As a developer, I am constantly looking for ways in which we can use Linux at work. Check the header of this message, and you will see it is coming to you on a Linux machine with Pine.
I wasn't offended by your article in the least, I just wanted to let you know that even companies like Martha Stewart Living are embracing Linux.
—Rick NoelleInternet Applications DeveloperMartha Stewart Living Omnimedia
In reading the February 2001 issue of Linux Journal, I noticed the article “Linux and the New Internet Computer”. There is a screen shot of the NIC with some apps running on it. Strange as it may sound, I'm very interested in the calendar program running on that screen.
I've been using xcalendar for years now, and I love its simplicity. However, it seems that it's not being maintained. The calendar running on that screen shot looks similar but different. I'd like to find out if it is a different minimalist calendar program.
The X “calendar” client you see on the desktop in the screen shot, you're absolutely correct, it is “minimalist”! Here it is:
cal | xmessage -file - -title "Calendar"
a better version is with the gcal command (which highlights the current day):
gcal | xmessage -file - -title "Calendar"
If you use the tcal command, tomorrow's day will be highlighted. Of course, if you have a big display (1600 <\#215> 1200), you can put up a year's calendar with:
cal -y | xmessage -file - -title "Happy New Year"
I know that this is a brain-dead calendar—if you want something with a bit more intelligence that can launch calendars, reminders and check your mail, look at the rclock client...its man page gives all sorts of interesting applications (such as changing your desktop's hues according to the time of day—brightest at noon, fading to darkness toward evening, etc.).
—Billy Ball www.tux.org/~bball