Building the Ultimate Linux Workstation
Creative Labs used to be in the same situation as NVIDIA is now. Their top-of-the-line product, the Soundblaster Live!, wasn't supported with open-source drivers. After realizing they have nothing to lose and much to gain, Creative launched the opensource.creative.com web site last year to host an open-source driver for the Live! There's now ALSA support, too. Creative is also cosponsoring a new standard called “OpenAL”, billed as “OpenGL for audio”, that will let developers create cross-platform three-dimensional sound applications. The Live! sounds great now, and will also be your ticket to the 3-D audio show of the future. Don't forget to write “Linux” on your warranty card.
If you just need a decent basic sound card, the days of scrounging antique ISA Soundblasters or messing around with ISA Plug-and-Play are over. The Creative Ensoniq AudioPCI, model ES1371, is an inexpensive, well-supported, and, as you might be able to tell by the name, PCI card.
Servers use SCSI, because it's the best way to connect a lot of drives. Cheap desktop machines (see Jason Schmaker's article, page 88) use IDE, because motherboards include an IDE controller for free and the drives are cheaper. But the place where people are actively debating SCSI vs. IDE is in midrange or high-end desktop systems.
The very fastest drives, at 10,000 RPM, are available in SCSI versions only. So, for a true ultimate system, SCSI is best. And as you add more drives to your system, you'll appreciate the fact that SCSI doesn't hog interrupts like IDE does.
When you compare mechanically identical SCSI and IDE drives, the IDE drive will have a faster raw transfer rate, because the interface is simpler. But Eric Raymond says, “As fast as disks are getting today, the difference is effectively noise. The real advantage of SCSI (and the reason it's faster overall) comes from its extra brains.”
For our ultimate Linux box, we'll choose the latest SCSI technology, Ultra 160. You don't need Ultra 160 for the amount of SCSI bus traffic created by two drives, but (1) this the ultimate Linux box; and (2) the price differences among SCSI cards are small enough that you might as well get a card that's going to last you through several sets of drives.
Rick Moen once advised me to select hardware that's flexible enough to be incorporated into the next Linux box you build. Some of the parts you buy for your ultimate workstation today could end up in your Freenet server next year. The Adaptec 29160 is a good example of this kind of (almost) future-proof hardware. When you do upgrade to 64-bit PCI, you'll still be able to use it. The 29160 is still new enough that the kernel you got with last year's Linux distribution might not recognize it, so you might need to upgrade. Check your distribution's hardware compatibility list to find out.
Symbios is a SCSI card vendor that's popular with the Linux hardware vendors. Their cards have good performance and are well-supported too.
The money you spend on a killer SCSI card is wasted without fast drives, so choose two or more 10,000RPM drives from IBM, Quantum or Seagate. One good rule of thumb is to choose the same drives the reputable Linux system vendors are putting in their servers.
If you do decide to save money and go IDE, stick to one of the top three drive vendors mentioned above. Earlier this year, kernel hacker Andre Hedrick, the maintainer of Linux's IDE driver, tracked a user's problem to the fact that Western Digital drives don't do error checking correctly. He posted to linux-kernel, “WDC drives blow off the CRC check of UDMA.... This is BAD and STUPID.” Western Digital fired back on their web site with, “If there's a problem using these drives in Linux the problem most likely lies with the software driver and not the hard drive itself.” I'm going to believe the kernel hacker over the hardware vendor, and stay away from Western Digital drives.
Eric's advice is to put your own precious files on one drive, and your distribution on the other. That makes restoring your system after a disk crash easier. “If you have two, maybe the crashed one was your system disk, in which case you can buy another and mess around with a new Linux installation knowing your personal files are safe. Or maybe it was your home disk; in that case, you can still run and do recovery stuff and basic net communications until you can buy another home disk and restore it from backups.”
And two drives are faster than one, if (as often happens) you're dealing with both /tmp and /home, or /home and /var, simultaneously. You can also use Linux's software RAID to mirror the same set of file systems on a pair of disks. Don't rely on a spare hard drive in the same machine as the only backup for the main drive, though. Often a power supply failure can fry both drives at the same time. Back up over the Net to another system, or use tape.
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|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
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