I have to raise an objection (or five) to the Magnatune article in the August 2007 Linux Journal.
First, Apple's iTunes uses AAC, the same audio codec for DVDs you get off the shelf. This codec is much tighter in compression but has better audio quality than MP3.
Second, DRM'd iTunes music is encoded at 128kbps using AAC. A buck a song at 128kbps sounds rather decent.
Third, EMI's non-DRM'd music will sell for $1.29, but it will be double the encoding rate, 256kbps, so it will sound much better. This doubling of the bandwidth (which I doubt will all be used) will make the files pulled bigger, and thus the extra cost is justifiable.
Fourth, the non-DRM'd music is still encoded in AAC format and possibly wrapped in an MPEG-4 container. It won't be MP3'd; it won't be WMA'd—both for Apple's legal eye will require licensing the codec. Plus, iPods can't listen to Ogg Vorbis files either. Apple hasn't thought about putting in the free (as in freedom) codec in the iPod's firmware as well as QuickTime.
Fifth, EMI's music catalog isn't all DRM-free yet.
Apparently, the person who wrote the article forgot to do his
research. I believe the keynotes of the past WWDC and MacWorld
conferences should help. They're still up on iTunes as podcasts for
free (as in beer).
—
Kelly "STrRedWolf" Price
Being a UNIX/Linux user for more than 30 years and seeing the evolution of computers has been very interesting. First, we had large pieces of iron on raised floors and huge air conditioning bills and large support staff, and we all carried large boxes of cards for the larger programs.
I got my PhD in Astrophysics in 1972, and my dissertation required more than $1,000,000 in computer time on a CDC 7600 and then later on a Cray 1S. It was taking 3.5 hours per case for simulation of light transport in real planetary atmospheres. Now I can do a case in less than ten minutes on an AMD64. I still wonder if people fully realize just how much compute power they have at their fingertips.
I wrote a book in 1978, and in Chapter 1, I wrote that I had figured out what the human race was doing overall. We are trying to get all of human knowledge at the fingertips of every man, woman and child on the planet. We are about to get there.
Back to your article [Nicholas Petreley's “Amazing Free Distributions Abound”, July 2007]. I used SUSE for years and years. But last year, I was converted to Kubuntu, and with 7.04, there is no way I can ever go to another distro. It has, with all the official repositories, given me access to more programs and utilities than I'll ever need.
Last year, I developed a short Intro to Linux course for free adult training centers and continuing education facilities. I use Kubuntu 7.04 because of the live CD and the ease of installation. I also use a cheap Airlink USB Wi-Fi critter for $10 on sale at Fry's Electronics that plugs and plays without intervention by the owner and really, really helps get things going.
I am working on getting freshmen high-school students to start up on Linux. Think about it. They would never have to buy another piece of software for the rest of their high-school and college careers. They'd have every compiler they ever would need. They would have OpenOffice.org for their reports and spreadsheets, and LaTeX for engineers and mathematicians for any mathematics they encounter. The list goes on and on.
I developed and taught all the courses at Silicon Graphics until I retired 12 years ago, when SGI started downhill. So, I guess it's still in my blood to continue the fight against ignorance. “Push back the frontiers of ignorance” was my motto as a prof and instructor. Get a thought to go where no thought has gone before.
Keep up the good work.
—
Chuck Adams
In the Tech Tips column in the July 2007 issue, a method to prevent services from starting is described for those who do not want to use the graphical interfaces. However, there is a specific command-line tool available just for that task, chkconfig. I think this tool works even better than crowding the /etc/rc[0-6].d directories with unclear links.
From the chkconfig man page: “chkconfig provides a simple command-line tool for maintaining the /etc/rc[0-6].d directory hierarchy by relieving system administrators of the task of directly manipulating the numerous symbolic links in those directories.”
To follow the example in the magazine, instead of renaming S25bluetooth
to s25bluetooth, simply type chkconfig bluetooth
off (and chkconfig
bluetooth on to turn it back on again).
—
Stefan Roels
It's a little late to be writing about the June 2007 issue, but I just reread the Lua article, and I'm a bit disappointed, so I thought I'd write.
In general, it seems to be a pretty good introduction to Lua. However, the author did a lot of comparing to Python, and I think that comparison was done unfairly. Whenever such a language article is written, it really should be reviewed by an expert in the language it's being compared to. The author is clearly not very experienced with Python, and it shows.
Lua has a key advantage for its intended purpose (its impressively small
size), but people should select it for its real advantages, not because
of mistaken impressions. In general, it looks to me like many of Lua's
traits make it quite unsuitable for large programs, which is fine, as
it's not intended for that. However, Python is pretty darn suitable for
both large and small.
—
Chris
I have really been digging Linux Journal ever since I subscribed to your
fine publication. Lately, I've been enjoying the shell scripting
articles,
and in the July 2007 issue, the article on vector graphics was rather
interesting. In the future, I think you guys should do some more articles on
Ruby and Ruby on Rails. I really enjoyed the one edition almost completely
dedicated to Ruby. It would really tickle my fancy if you put some more
Linux Web-development-related things into the magazine. Anyway, keep up
the good work with making my favorite Linux publication.
—
Patrick
As a developer of embedded systems, including Linux, for the past two decades, I was very interested in the article “Standard Operating Procedures for Embedded Linux Systems” [August 2007]. The article seems to describe a limited approach to embedded Linux development and certainly not an “SOP”.
The primary software described, buildroot, is a terrific and powerful tool for embedded developers, as are many packages from uclibc.com; however, such high-level tools come with limitations. Buildroot, for example, is heavily entwined with the uClibc library, which is not a viable choice for every system. The “five standard procedures” violate basic design methodology by selecting the hardware first. Once all packages are selected, only then can a tool like buildroot be considered; only amateurs select the tools before determining the task.
The article appropriately focuses on reducing memory and storage requirements, but no mention is made of alternate compressed filesystems, Flash filesystems and especially the new xip (execute in place) file support. Understanding the limitations of the space-saving software, such as uClibc and BusyBox, requires deep knowledge but is ignored in this article. Using packages that are not designed for cross-build is very difficult, despite the article's statement that it sometimes makes good sense to build these packages on the target. Bootup and shutdown time is important for many embedded systems, and this has design implications regarding hardware and software but isn't mentioned. Often, some new kernel feature is required, but upgrading the kernel may not be possible (many BSPs are dropped or rendered nonfunctional in time), so devising a solution is difficult, which is not addressed.
I wish we could download a tool, run a configurator and have a
functional image pop out, trim a little “fat”, install and ship, but
life is rarely so simple. It's a nice article on one group's basic
development process, but there is nothing standard here. “One size fits
all” isn't yet a viable approach for embedded Linux.
—
Steve Alexander