I would love to see a detailed explanation on the new Completely Fair
Scheduler in the Linux kernel, including areas where it may be inferior
to the existing scheduler and where it excels. Also, I'd like to see an explanation of
the tickless patches, which apparently result in significant power savings.
We'll look into a scheduling article, but we have an article on power savings in the works, including information on the tickless patches.—Ed.
I was very interested to read Shawn Powers' article on building an arcade machine based around Linux [LJ, August 2007]. However, one thing that concerns me is the lack of reference to cooling issues. If a PC is in a wooden box for any period of time without a fan to force cool air through, there would be a risk of heat damage to the machine, particularly the CPU and the hard drive (www.coker.com.au/energy/computer-power.html).
The above URL has the energy use of some computers I have owned at various times (the idle tests were idle at a Linux prompt—idle at a DOS prompt or the BIOS uses significantly more power). You will note that a P4 machine uses significantly more power than a PIII. I can only guess at the relative power requirements of a PIII and the original game hardware, but I expect that all PCs manufactured in the last ten years use more power and produce more waste heat. Even a PIII might have cooling problems!
One thing that is not widely known is that a P4 will generally take more clock cycles than a PIII to complete a given amount of work—a 1.5GHz P4 will often deliver the same performance as a 1GHz PIII! If a machine is to run in a poorly ventilated space, a PIII is a significantly better option than a P4.
Hard drives take as much as 5W when idling. Use of other mass storage devices (such as USB) might reduce the power use for such a machine.
I have a small stockpile of old PIII machines for occasions when I need
a low-power machine.
The Linux OS is the most glamorous (I'm serious) example of [the] trend [toward data anarchy], but Linux is only an outgrowth of a much bigger universe of collaborative software development that uses open-source licenses and techniques to leverage the talents and creative impulses of hundreds of thousands of people worldwide. Cheap MP3 players and P2P file-sharing networks are another.
Direct evidence of the trend is plummeting CD sales as users swap CDs, copy new ones, file share and port their files to any device they want. The efforts of the RIAA are becoming laughable, as they sue a few unfortunates and scold the rest of the population from a position of pious hypocrisy. They are the biggest thieves of all. Also pathetic are the many pop stars, now grown rich and fat sucking on the corporate tit, who parrot the RIAA's line. It matters not.
The only reason artists and record companies ever had control over music media was that it was impractical for listeners to create their own. Given that ability, most listeners will follow my own common-sense creed: when I get the data, it's my data, and I'll do with it what I damn well please.
The RIAA hands down morality lessons while cracking the lawsuit whip in hope of putting the file-sharing genie back in its bottle. They pretend that there is some moral code that forbids consumers to copy and give away music media. Their morality is based on laws that were manufactured by a Congress eager to be bribed. It's easy to burst the RIAA's moral bubble. Just travel back to 1850 in your mind and go hear a music performer.
In 19th-century America, the artists played and the people enjoyed. It had been that way for 10,000 years. If the artists were lucky or very good, they could make a living by performing. Many do that to this very day. It is an honest living. They work at what they love. It's their job.
It was a temporary quirk of technology that allowed artists and record companies to turn performances into commodities to be bought and sold. A few lucky artists could perform, record and then sit back and let the bucks roll in while they snorted coke and bought mansions. That's OK with me, and it still works for some. But, the data is written on the wall, and it is an age-old warning that applies to all: adapt or die.
Readers may wonder what all this has to do with cell-phone networks. Carl Brown suggested that there is nothing fundamentally blocking the concept of a user-created cell-phone network. It also is true that there is nothing blocking users from building their own worldwide data network, uncontrolled by governments or corporations. If I can share my Wi-Fi with the neighbors in my apartment, I can bridge to the guy across the street who can run a directional shot to his buddy a quarter-mile away who can...(ad infinitum).
The idea was not invented by me, although I humbly declare I thought of it myself. The idea is so obvious, anyone with an understanding of networks is likely to conceive of it. A quick Google search brings to light that user-operated and user-supported community networks are already providing free service to many people. The ISPs don't like it, but there's nothing they can do about it. Those simple networks, however, are only attachments to the Internet. They still depend on the corporate infrastructure.
Another and related sign of the trend toward anarchy is revealed in the project called Netsukuku (netsukuku.freaknet.org). That project community has created a dæmon that uses network interfaces to communicate directly with the same dæmon in a connected computer. In theory, the mesh network so created can mimic the Internet's TCP/IP layer with a decentralized domain name system that uses distributed architecture and builds routes that connect the computers attached to its network. It is, as the creators say, anarchical.
I do not claim to see the future. I only extrapolate what seems to be an
inexorable transfer of communications and data management power from the
elite to the masses. If you believe in people, this can only be a
good thing. If you fear people, or begrudge them control over their own
lives, then you will fight it...and lose.
I eagerly awaited the current issue of LJ [September 2007] to read the Ultimate Linux Box article. I plan to build a system very soon and hoped to get some ideas.
Unfortunately, I just skimmed the article and was very disappointed. What I really would like to see is a Practical Linux Box. No, your sidebar “Penultimate” doesn't address my needs any more than the ULB. Your ULB is really the Ultimate [Windows] Gaming Box, isn't it? For example, look at the Display Card section. It's the latest and greatest DirectX 10 card? How is this a good Linux box?
The things I'm looking for may not be what everyone else is looking for, but I'd like to think there are enough people to warrant some practical thinking in this type of article, such as:
Quiet/fanless power supply and case.
Small case with enough room for DVD and two hard drives.
Affordable: $2,000–$4,000 is not practical or affordable.
Onboard video is ok.
You could argue that I want a media PC, but that's not really my goal. I'd
settle for one. I'm estimating that I can build a system that fits the
above specs for about $700, without monitor. Other names for what I want
might be the Quiet Linux Box or the Affordable Linux Box.
The Ultimate Linux Box had nothing to do with Windows games or serving up DirectX 10, which isn't even very useful on Windows yet. We'll consider your desires for the next ULB issue though.—Ed.
I have to congratulate you on your /var/opinion “The Benevolent Racketeer” [LJ, August 2007].
Your imaginary letter writer speaks right out of the soul of
everybody. The crowd reading the lines will equally agree and see their
points addressed as the crowd reading between the lines. Luckily, I paid
my insurance money to Linux Journal, so you will not sue me for reading
this terrific piece of word code.
I too have a small nit to pick with respect to sample code and the lack of error handling. It is trivial to add at least some minimal error handling. In the September 2007 issue's Letters, Jack points out that mkdir error handling is non-existent. Bash scripts are notorious for not doing any error handling. As for the mkdir issue that Jack points out, I would suggest the following:
mkdir -p $dimension if [ $? -ne 0 ]; then echo "Error: could not create directory $dimension" return 1 fi
The -p switch to mkdir will create all directories in the $dimension string recursively and will not complain if any or all directories already exist. The main reason for failure will be user permissions. This is handled by echoing the error and returning an error value to the caller.
If the goal of these sample scripts is to instruct beginners to learn
techniques with bash, error handling cannot be ignored. The same
goes for Ruby, Python, Perl, C and C++. The code samples in the SCTP
(why does that make me think of John Candy) article are excellent in
I enjoyed your article in the September 2007 issue of LJ about the woes of cable TV and implementing a PVR for HDTV [see Nicholas Petrelely's /var/opinion].
I'm such a huge fan of PVRs, and I've had them for five years now with DishNetwork. Your article praised TiVo's PVR product, talking about ergonomics, and they do make a nice setup. They were the pioneers of the technology.
If you haven't used the DishNetwork HDTV box, give it try sometime, if you know anyone that has one. I'm absolutely blown away with all the trick things you can do with that box. You'll want one if you're as gaga about technology as I am. It's far better than my neighbor's DirecTV PVR by a longshot. I could fill this page with the things DishNetworks 622 box will do, but I won't bore you. The nuance you mentioned about TiVo predicting where you want to go when you push Replay—that's just the beginning for Dish. It's amazing how navigation ergonomics makes such a difference in this kind of an appliance, making what “could be” a complicated device very simple to use. I do like the DirecTV capability to set bookmarkers in each recording—that's cute, but it's not as valuable as all the other things Dish does.
Next year, we should talk about Datalight's (the company I work for)
support for Linux. We will be offering some new capabilities for
mobile Linux devices that you might be interested in learning about.
Our Linux support is about two months away, so January 2008 should be good timing.
I'll suggest to our marketing folks that they should get in touch with you to possibly
do an article.
Coincidentally, thanks to moving out into the country, I now use a DishNetwork HDTV, which I am told is based on Linux. I'll be writing about it soon.—Ed.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide