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.
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).
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.
I have really been digging Linux Journal ever since I subscribed to your
fine publication. Lately, I've been enjoying the shell scripting
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.
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.
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
|Trying to Tame the Tablet||May 08, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
- Readers' Choice Awards
- Android is Linux -- why no better inter-operation
2 hours 8 min ago
- Connecting Android device to desktop Linux via USB
2 hours 37 min ago
- Find new cell phone and tablet pc
3 hours 35 min ago
5 hours 4 min ago
- Automatically updating Guest Additions
6 hours 12 min ago
- I like your topic on android
6 hours 59 min ago
- Reply to comment | Linux Journal
7 hours 20 min ago
- This is the easiest tutorial
13 hours 34 min ago
- Ahh, the Koolaid.
19 hours 13 min ago
- git-annex assistant
1 day 1 hour ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?