Cooking with Linux
It's the time of month again when I manage to dig myself out of the piles of source code listings, overdue bills, and technical manuals that invade my desk, just long enough to take a deep breath and make a wry comment on the status of the computing community. Please excuse any spelling errors; my eyes are still adjusting to the light.
By now, you've (hopefully) gone over this Buyer's Guide issue with a toothpick and magnifying glass, noting every minute detail, pitting distribution against distribution, vendor against vendor, in a fierce battle of marketing wit and technical expertise. Unless, of course, you flipped immediately to this column, realizing; along with so many other readers; that this is the only part of Linux Journal that condenses any genuinely useful information.
At any rate, after digesting the product reviews and coverage of major Linux distributions and software, you've more than likely reached the stark conclusion that you're no better off than before you picked up the magazine. There are just too many distributors out there, and too many software distributions to choose from. How on earth can anyone decide amongst them all?
You may be tempted to employ the infamous Monte Carlo method. Blindfold yourself. Open the magazine to a random page. Put your finger down. Remove blindfold. Pick up the phone and order whatever your finger happens to be pointing at. (“Hello? Yes, I'd like to order... uh... Ian Murdock please. What? He's not for sale?”)
Certainly you can see the futility of this approach. A better method is the one that I suggest to true die-hard Unix hackers who have, oh, a few months to kill. That is to forego this distribution nonsense and to put together your own system from the kernel up. Can't be done, you say? Impossible? Not so. The only requirements are: One (1) personal computer. One (1) small Linux system on a floppy; for example, the Slackware boot/root disk combination. And, one (1) Finnish computer science student named Linus Torvalds. If you happen to have all of the above ingredients, you should have no problem at all.
Needless to say, things were easier back in the Good Old Days, when the only “distribution” was a pair of floppy images made available by H.J. Lu. Back then, users had no choice but to build a system from scratch. Those rugged survivalists that made it through the ordeals of Linux prehistory are now known as “old hats”. Some of them live in caves. (Some of the caves have Ethernet drops, which is certainly convenient.) Others have moved onto bigger and brighter things, such as writing editorials for a certain Linux-related magazine. Still others are nowhere to be found.
All right, all right, but what about the rest of us; those who don't have the hard-headedness required to install Linux the old-fashioned way? After all, this magazine is literally teeming with Linux distributors, right? Can't the choice of a Linux vendor or distribution be boiled down to a simple, straightforward, no-frills answer? Why the runaround? Why don't I get to the point?
I seem to have forgotten the point.
But I do remember this: Selecting a Linux distribution is not unlike buying a new car. You are faced with many questions: Do you want a sporty and fun convertible (Slackware), or a family-sized minivan (Yggdrasil)? Or are you comfortable enough with your Unix hacking repertoire to test-drive an experimental new design (Debian)? Do you want to go for a newer, and perhaps more expensive model, with all of the options (anti-lock brakes, air conditioning, and the Linux Documentation Project manuals), or are you content with a rugged, do-it-yourself version (such as the InfoMagic CD-ROM set)?
The list is endless. The best advice that I can give is to talk with other Linux users, who have survived the adventure of selecting and installing a particular distribution, and hear about their experiences. Given the fact that Linux is free, you can always borrow or copy the software from a friend. Using the UMSDOS filesystem, you can even install Linux in a directory of an MS-DOS partition, saving yourself from the time-consuming and destructive repartitioning process; which usually requires you to backup the entire system.
So, what are you waiting for? Pick a distribution and give it a spin. Kick the tires. Find a country road and floor it. Crash it a few times, if you can. If it works, and if it feels like the system for you, take the plunge and buy the darn thing.
Fuzzy dice and vanity plates sold separately.
Matt Welsh (email@example.com) is often seen standing by the roadside of the Information Superhighway, holding a cardboard sign, which reads: “Will Hack Linux for Food”.
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