I started reading Avi Deitcher's article titled “Simplicity and Performance—JavaScript on the Server” in the April 2011 issue. I just wanted to let you know that the command given to clone the Node repository from git:
git clone git://github.com/ry/node.git
should be changed to:
git clone git://github.com/joyent/node.git
at least as of March 21, 2011. As I couldn't get the first command to work, I did a little looking around and found the correct repository.
I'll try using this program (Node) to do some experimenting with JavaScript using Node and see how well this works. Thanks for the article, and keep on doing such a great job each and every month.
PS. I've been a subscriber since 1999 except for a few short lapses when
I purchased my monthly copy from a local bookstore. Thanks.
—
Michael Soibelman
Avi Deitcher replies: Ha, great! Ryan (the original inventor of Node) works for Joyent. At some point the company must have decided it owned the intellectual property and made him move it.
I was surprised to read in Joey Bernard's March 2011 UpFront article that the statistical analysis language R was “developed at Bell Labs”. Although Bell Labs has given us much to be thankful for, R actually was developed by Ross Ihaka and Robert Gentleman from the University of Auckland in New Zealand. Of course, being an open-source (GPL) project, it has attracted contributions from all over the globe.
At the NZ Open Source Awards in 2010, Ross Ihaka was presented with the
“Catalyst Lifetime Achievement in Open Source Award” for his work on R and
for supporting the R community.
—
Grant McLean
Joey Bernard replies: Mea culpa. This comes from not reading documentation closely enough. The language S was the one developed at Bell Labs, and R was developed at the University of Auckland, as you said. Thank you for correcting this and making sure that the hard work of Ross Ihaka and Robert Gentleman is recognized properly.
I've slowly been migrating my many sites and services from a well-known hosting
provider using Plesk to self-hosted at Linode. One thing I've been
procrastinating on is DNS. Kyle Rankin's article [“Your Own Personal
Server: DNS”, April 2011] shows how simple it really
is,
and it was the inspiration for me finally to migrate over. Many of the BIND/DNS
books out there go very in-depth, but over-complicate configuration. Had I
realized it was this simple, I would have pulled the trigger months ago.
Kyle's article did a great job of covering the basics.
—
Ryan Duff
I've been reading Linux Journal for decades and appreciate the fine work you do.
I wanted to comment on Keith Reed's letter to the editor on Net Neutrality legislation in the April 2011 issue. You will doubtless be swamped by hundreds of other letters on this topic, but it is an important issue to to me, so I wanted to offer my two cents.
Discussions of Net Neutrality legislation frequently conflate three issues:
The ability of network providers to charge for the actual bandwidth and data delivery they provide.
The ability of network providers to shape traffic to meet Quality of Service (QoS) guidelines.
The ability of network providers to impose surcharges or to shape traffic based on destination.
In my opinion, the first two issues are red herrings raised by opponents of Net Neutrality legislation to distract from their actual goal, which is #3 above. I don't know of anyone seriously calling for restrictions related to issues 1 or 2. My concern, and the concern of many, is that my network provider not be allowed to filter or shape my traffic based on the destination of my packets.
The argument that the network providers built these networks and should be allowed to run them as they see fit, conveniently overlooks the fact that the networks largely were built as public/private partnerships. The network companies were granted local monopolies and obtained the easements for their cable plan through the government power of eminent domain. They were granted these extraordinary benefits because they promised to act as common carriers, providing a public good.
If the network companies want to create purely private networks, they are
free to do so. They just have to give up their remaining local monopolies
and pay fair value for the easements for their cable plant. Until they do
so, I insist that they should operate as common carriers.
—
Charles E. Grant
I agree with you, but I think #2 is also key in their plan as well. By crippling things like VoIP, ISPs can offer their own services and have them “just work”. Granted, that is related to #3, but the QoS part of the equation is worrisome for me as well. I know it can keep prices lower for the average consumer, but there needs to be an option for users like, well, me. I fear the future of the Internet without some form of Net Neutrality.—Ed.
Audible says, “At this time Audible is not compatible with the Linux operating system. Audible is actively pursuing compatibility with Linux in all versions by pursuing support from the Open Source community that develops this platform.” I joined Audible in 2002 and saw that exact message shortly after, and it has not changed to this date today.
Audible is one of the big reasons I have heard people say they will not switch to Linux. There already are ways to take out the protections and turn the audio books to MP3 files, but I have a very large library on Audible's site and need (as do many other people) for it to just work. “Just work” is what Ubuntu is all about. If you do not think it is serious, do a Google search for “Audible Linux”, and you will end up with a different frame of mind.
Could someone please contact the Audible folks and tell them how much money they are
losing? In the process, please offer to work with them to make Audible
compatible with the Linux operating system. Ubuntu is the largest and
should have a little bit of pull in whatever negotiations are needed. It
would help if the other OSes would get on the wagon for the long haul.
—
Victor Jones
I think the recent release of an Android client is a huge step in the right direction. Hopefully, we'll see Audible continue down that road.—Ed.
How does a review of the D-Link Boxee Box [April 2011] qualify for inclusion in
Linux Journal?
It has nothing to do with GNU/Linux, and worse, the Boxee is HDCP-crippled.
—
Ian Stirling
The Boxee Box runs Linux, thus its inclusion in the magazine.—Ed.
In addition to the reasons you give, in your answer to Gary Dale's letter, about people switching back to Windows after trying Linux, I will suggest another one [see the April 2011 Letters section]. You can't just buy hardware at your local store and expect it will work under Linux. Some hardware vendors have a policy of ignoring Linux. Presumably, they can afford to, since they sell enough products to Windows users. And, it's anybody's guess whether Microsoft offers them financial incentives for noncooperation with Linux.
Then there is the attitude on the part of some Linux workers that anything
but
absolutely open-source software is immoral to use. I was having quite a bit
of
trouble with the wireless adapter in a new laptop computer, trying to use
the
open-source driver. Then someone mentioned to me that a Linux driver was
available from the Broadcomm Web site; I downloaded that, and things have
been
fine ever since. Recently I bought a Brother scanner/printer. The SANE Web
site does not mention this model; and all the other Brother machines they
mention
are listed as unsupported. But, I found easy-to-install SANE and CUPS
drivers
on the Brother Web site, and the machine works fine. I'm willing to thank
Broadcomm and Brother for supporting their equipment under Linux, rather
than
denouncing them for not open-sourcing their drivers.
—
Jim Haynes
I agree with your positive attitude. Yes, I'd prefer everyone open-source their drivers, but supporting Linux users with binary-only drivers is a huge first step. This is similar to my views on things like Netflix. If Netflix released a binary-only player for Linux, I would give it tons of credit. As it is now, people can play Netflix under Linux (Roku, Boxee Box), but desktop users can't do the same. That's frustrating.—Ed.