Troubleshooters.Com Presents

Linux Productivity Magazine

Volume 3 Issue 4, April 2004

Your New Linux Box

Copyright (C) 2004 by Steve Litt. All rights reserved. Materials from guest authors copyrighted by them and licensed for perpetual use to Linux Productivity Magazine. All rights reserved to the copyright holder, except for items specifically marked otherwise (certain free software source code, GNU/GPL, etc.). All material herein provided "As-Is". User assumes all risk and responsibility for any outcome.

Have Steve Litt write you a quick application!

See also Troubleshooting Techniques of the Successful Technologist
and Rapid Learning: Secret Weapon of the Successful Technologist
by Steve Litt

[ Troubleshooters.Com | Back Issues |Troubleshooting Professional Magazine ]

It works. It's free. Duh.
-- Paul Nelson, technology director Oregon's Riverdale school district, speaking of Linux


Editor's Desk

By Steve Litt
You gaze in awe at the promise of power emanating from its clean, sleak lines. Double the processor speed, double the RAM, double the disk space, with features only imagined the day you bought your soon to be ex daily driver.

The best part of getting a new computer is seeing the power in its powerful newness. The worst part is transferring your operating system, your apps, your data and your daily tools and riffs to your new computer.

What will work, and what will be a hassle? What will you remember, and what will you forget? How long will the cutover take, and what opportunities will be lost during that time?

These questions have nothing to do with Linux. Indeed, these questions appear whenever you buy a new computer, regardless of operating system. This month's Linux Productivity Magazine answers these questions from a Linux point of view.

As an example, this months magazine uses my recent transition from my 4 year old dual Celeron 300A (cranked up to 450) with 512MB of SDRAM and 80GB of disk, to my new Athlon XP2400+ with 1.5GB RAM and 400GB of disk. How did I decide on a new box? What were the pre-cutover, cutover, and post-cutover processes?

Here at Troubleshooters.Com, my daily driver computers obsolete at a rate of roughly one every three years. This was true in the 80's with DOS, in the 90's with Windows, and in the 00's with Linux. It's a hardware thang.

Linux has its pros and cons. This magazine shows you how to make the pros work for you, and how to dodge the cons, when upgrading to a new computer. If you're a Linux or free software user, of if you just want to learn more about these technologies, this is your magazine. Enjoy!

Steve Litt is the author of Samba Unleashed.   Steve can be reached at his email address.

Help Publicize Linux Productivity Magazine

By Steve Litt
Loyal readers, I need your help.

For months I've publicized Linux Productivity Magazine, expanding it from a new magazine to a mainstay read by thousands. There's a limit to what I can do alone, but if you take one minute to help, the possibilities are boundless.

If you like this magazine, please report it to one of the Linux magazines. Tell them the URL, why you like it, and ask them to link to it.

I report it to them, but they don't take it very seriously when an author blows his own horn. When a hundred readers report the magazine, they'll sit up and take notice.

Reporting is simple enough. Just click on one of these links, and report the magazine. It will take less than 5 minutes.

News Mag
Submission URL or Email address
Just fill in the short form.
Just fill in the short form.
Linux Weekly News
Just tell them the URL, why you like it.
Just tell them the URL, why you like it.
Just fill in the short form.
Newsfactor Network
Just tell them the URL, why you like it.
The Linux Knowledge Portal
Just tell them the URL, why you like it.
OS News
Just tell them the URL, why you like it.
Only for LPM issues involving the Linux desktop, not for programming or server issues.

If you really like this magazine, please take 5 minutes to help bring it to a wider audience. Submit it to one of the preceding sites.
Steve Litt is the founder and acting president of Greater Orlando Linux User Group (GoLUG).   Steve can be reached at his email address.

GNU/Linux, open source and free software

By Steve Litt
Linux is a kernel. The operating system often described as "Linux" is that kernel combined with software from many different sources. One of the most prominent, and oldest of those sources, is the GNU project.

"GNU/Linux" is probably the most accurate moniker one can give to this operating system. Please be aware that in all of Troubleshooters.Com, when I say "Linux" I really mean "GNU/Linux". I completely believe that without the GNU project, without the GNU Manifesto and the GNU/GPL license it spawned, the operating system the press calls "Linux" never would have happened.

I'm part of the press and there are times when it's easier to say "Linux" than explain to certain audiences that "GNU/Linux" is the same as what the press calls "Linux". So I abbreviate. Additionally, I abbreviate in the same way one might abbreviate the name of a multi-partner law firm. But make no mistake about it. In any article in Troubleshooting Professional Magazine, in the whole of Troubleshooters.Com, and even in the technical books I write, when I say "Linux", I mean "GNU/Linux".

There are those who think FSF is making too big a deal of this. Nothing could be farther from the truth. The GNU General Public License, combined with Richard Stallman's GNU Manifesto and the resulting GNU-GPL License, are the only reason we can enjoy this wonderful alternative to proprietary operating systems, and the only reason proprietary operating systems aren't even more flaky than they are now. 

For practical purposes, the license requirements of "free software" and "open source" are almost identical. Generally speaking, a license that complies with one complies with the other. The difference between these two is a difference in philosophy. The "free software" crowd believes the most important aspect is freedom. The "open source" crowd believes the most important aspect is the practical marketplace advantage that freedom produces.

I think they're both right. I wouldn't use the software without the freedom guaranteeing me the right to improve the software, and the guarantee that my improvements will not later be withheld from me. Freedom is essential. And so are the practical benefits. Because tens of thousands of programmers feel the way I do, huge amounts of free software/open source is available, and its quality exceeds that of most proprietary software.

In summary, I use the terms "Linux" and "GNU/Linux" interchangably, with the former being an abbreviation for the latter. I usually use the terms "free software" and "open source" interchangably, as from a licensing perspective they're very similar. Occasionally I'll prefer one or the other depending if I'm writing about freedom, or business advantage.

Steve Litt is the author of Troubleshooting Techniques of the Successful Technologist.   Steve can be reached at his email address.

Your Daily Driver

By Steve Litt
The term daily driver comes from the automotive world. It means the car you drive every day, as opposed to the car you drive to car shows, or the car you drive on sunny Sundays, or the junkheap on blocks in your yard.

When I use this term for a computer, I mean the box on which you perform your day to day tasks. Not a dedicated file/print/web/email server, not a dedicated firewall, not an experimental computer you use to test various distros, and not a spare computer you use for travel or emergencies when your daily driver goes down. Your daily driver is the box on which you do your daily work.

Your daily driver computer has requirements and responsibilities other computers don't have. It contains the primary copy of voluminous data -- 18,000 files and growing in my case. It has configurations to optimize your productivity. It has all the right keystrokes -- all your tools and riffs.

Unlike experimental and junk computers, your daily driver must be up almost continuously so you can work when necessary. This means when the time comes to replace your daily driver, you must quickly cut over all functionality -- content creation, email, backup, menus, scripts, everything.

Your daily driver needs to shoulder a huge load, and should be able to shoulder it for 2 to 4 years before replacement.

The important thing to remember is that switching daily drivers isn't a trivial task like switching experimental computers. It calls for planning.
Steve Litt is the author of the Universal Troubleshooting Process Courseware.   Steve can be reached at his email address.

Picking the Box

By Steve Litt
Your daily driver must support the work you do on a daily basis, and must enable you to achieve hyperproductivity. First and foremost, it must be stable. No backwater brand motherboards. No overclocked processors or busses, except when such overclocking is performed in a way known in the world's literature to be stable (my overclocking my Celeron 300A processors to 450mhz was a well known legitimate overclock).

Eliminate any heat issues. Use plenty of case fans. Hard disk heatsinks and fans are an excellent idea. Spend the extra bucks for an excellent, high capacity processor heat sink and fan. If possible, ask the people who install it to use heat sink compound between the processor and its heat sink.

Your daily driver must have the muscle to handle the load. First and foremost, RAM is king -- get as much as you can afford. Get an obscene amount of RAM. I guarantee you that three years from now, it won't seem obscene, and might even seem anemic. Because my new motherboard takes only 3 sticks of DDR RAM, I was limited to 1.5GB of RAM. I could have purchased 1GB sticks (for a total of 3GB), but the price of 1GB DDR was huge back in 2003, when I bought this box. Disk space is dirt cheap now, so buy a bunch of it. I bought 2 200GB Western Digital 7200 RPM drives for $150.00 apiece, so I'm well poised to perform the photo and video editing tasks that will become possible and necessary in the next three years.

Spend the extra money for a high capacity, high quality power supply for your daily driver. Even when protected with a surge protector, a high quality power supply can make the difference between continuing uninterrupted and rebooting during a minor power glitch, or between rebooting and serious damage during a major lightning strike. The well being of your motherboard, CPU, RAM, drives, and daughtercards all depend on continuous and accurate delivery of the right voltages at any current draw. Don't trust all that to the $10.00 power supply packages with the average case.

I use an Enermax 550 watt power supply in my old daily driver. I also have a 450 watt unit normally used for out of the case experimental setups. After purchasing my new daily driver, I replaced the built in power supply with the 450 watt. Once there's no possibility of needing backtrack to my old daily driver, I'll replace its 550 watt with the original power supply from the new daily driver, replace the 450 watt in the new daily driver with the 550 watt, and once again use the 450 for out of case experiments.

You might have some special requirements. If you're a gamer or CAD guy, you need a serious video card. If you're heavy into audio, you need a serious audio card. Determine whether you need things like firewire, and how many and what type of USB ports you need.

Linux compatibility isn't the problem it was four years ago, but it's still necessary to check for Linux compatibility, especially with laptops. If you're buying a prebuilt box, slap in a Knoppix CD, reboot, and see if video, audio, and network work. If they do, it's a pretty safe bet that by obtaining and loading the correct drivers in the correct sequence, you can make it work with any distro. You can perform the Knoppix boot in the store, before the purchase. If the store doesn't like that, buy elsewhere.

If you're building it yourself, check compatibility on the Internet. If the motherboard has builtin video, audio, and/or network, be sure you can turn them off in the bios and put in your own, Linux compatible cards, if worst comes to worst. Of course, the purpose of builtin components is price reduction. You don't want to spend an extra hundred dollars on sound, video and network cards. So before buying a motherboard, try to have the store let you boot Knoppix on complete computer with that motherboard, and verify functioning video, audio and network.


NEVER cannibalize your old computer to build the new one. I did that once, and when the new computer didn't work, I was stuck with no computer at all. My business was down for several days.

Yes, it costs money to buy all new hard disks, all new CD ROMs, all new power supplies, and the like, but if you value continuity of business, never cannibalize the old computer for parts to use in the new one.

Pick the right vendor. I once bought a box from an outfit that competes on price. They have a 15% restocking fee, even when the returned item is defective. The mobo I bought was a cheapo brand, and upon getting it home I found it dead on arrival, so I returned it. At the store, these guys made me stand around for over an hour, with my three children, while their technician first worked on other units, and then tried every possible way to prove my diagnosis of a defective mobo false. An hour and a half later he declared it defective an authorized an exchange.

By this time I wanted these guys out of my life, so I demanded a refund. They charged me a 15% restocking fee, even though the original mobo was defective. I considered the $12.00 restocking fee a small price to forever sever my ties with these guys.

I then went to a quality retailer, LEK computers in Winter Garden Florida (URL in URLs section). For just a little more money, I bought a good mobo from them. I've done business with LEK for three years. When something's defective, they refund or replace it. That's why I've spent thousands of dollars with them.

I have a rule of thumb. Don't buy a new daily driver until you can afford double the memory, double the CPU speed, and double the disk space. If you don't double those values, your speed and performance increase won't be noticable. If you can't currently afford to double all three, limp by with your current daily driver, save your money, and wait for the day when the price of doubling all three factors falls within your budget.

Once you've picked your new box, it's time to get acquainted with it.
Steve Litt is the author of Rapid Learning: Secret Weapon of the Successful Technologist.   Steve can be reached at his email address.

Getting Acquainted with Your New Box

By Steve Litt
You've just gotten it home. Every fiber of your being wants to install Linux, install any extra-distro apps, copy your data, and begin using your box. Don't do it!

First, it's possible that you'll need to return it, so you don't want to spend huge amounts of time before ascertaining that it works. The likelihood of return varies with quality: Maybe 2% probability for Abit or Asus or equivalently high quality motherboards, to as much as 50% for those price conscious brands and backwater boards. As far as processor quality, in the last 2 years I haven't been able to conclusively rule in favor of either Intel or AMD in terms of reliability -- they both seem excellent to me.

Instead of switching your daily driver on the day of purchase, you want some time to get acquainted with your new box. Every box has its own strengths and idiocyncracies. The time to get to know these is BEFORE your daily work depends on the box.

Start by booting Knoppix, and verify video, audio and network. While you're at it, take a look at printer, scanner, camera, and any other major peripheral functionalities you use with your computer.

What I like to do is keep the computer as an experimental computer for awhile, so I can really learn my way around it. The Athlon XP2400+ computer on which I'm typing this magazine spent a month as an experimental computer, then several months as my son's computer, then another couple months as an experimental computer, and then finally I started the process of making it my daily driver. The computer it replaced, a dual Celeron 300A (cranked up to 450), spent over a year as an experimental computer before becoming my first Linux desktop. One could argue that both these computers spent their most valuable days as experimental computers instead of enhancing productivity, but the fact is that when I pressed them into daily service I knew them the way a mother knows her child, and that helps during the cutover process.

When it's time to get serious about making the box your daily driver, install the simplest possible install of your distro of choice -- maybe excluding X. The idea here is to verify that you can install. Installation is one of the most intensive tasks a computer can perform. Many computers that can run an operating system perfectly choke during the installation of that operating system. I've seen this in both Win9x and Linux. If installation is a problem, tweak with BIOS settings, substitute components, and generally troubleshoot until you can install. You might need to choose a less intensive installation mode, such as 640x480x16, or even text mode. Be aware that in general, installing Linux in text mode is quite time consuming, so look for another alternative.

Once you can perform the simple installation, try a default installation. That's quick because you make no choices. Modern computers can perform the actual installation quite quickly.

Mess around with the box. Make sure that video, audio, network, and if needed scanner, printer, camera, and any other peripherals work properly. If not, troubleshoot. Test major programs.

Now create a list of all your vital applications, including Internet tools such as browsers and email, and perform an installation that installs all those apps. Test them and make sure they work.

NFS Installs

All these installations take time. Worse, they require attended time because of all the CD swapping. You can eliminate the CD swapping, and beyond that actually increase the raw install speed, by performing an NFS install.

If you have room on your old computer, copy the installation materials to a directory tree, and NFS export that tree. Different distros have different requirements. Red Hat, bless their hearts, require only that you dump the .iso files in the directory. Mandrake requires you to actually copy the contents of the CD's to the tree.

I'd highly recommend NFS installs. They're faster, require less attention, and succeed more often than CD installs. NFS installs take a little time to get used to, but once you're used to them, you'll never want to go back.

My experience tells me that the toughest thing to get working on a desktop computer is email. There are so many little gotchas, any one of which can hang you up. To make matters worse, if you test the new box's email on your new box, the emails you download won't go to your old box (unless you use IMAP or deliberately configure POP not to delete downloads). I'd highly recommend you obtain a spare email address and use that one for testing.

Start by configuring the email client itself to pull from the POP or IMAP server. Once that's been done, you can incorporate fetchmail, procmail, and spamassassin. Troubleshoot if there are problems.

Once you have a working email system, be sure to back up all the config files, for the new box, into a backup directory on the old box, so that future installs can be accomplished easier. In the same light, document the steps you needed to take.

Once you have a good feeling that everything you need, including email, will work on the new box, it's time to perform the real install. But before performing the real install, you must first renumber your old box...
Steve Litt is the author of Samba Unleashed.   Steve can be reached at his email address.

Renumbering Your Old System

By Steve Litt
Unless you're a much better planner than I, you'll spend quite a bit of time copying various files from the old box to the new box. That implies they're both on the network at the same time, which requires they have different IP addresses and different hostnames. Because you want the new box to have the same IP address and hostname as what you have now, you need to change the IP address and hostname of your current box to accommodate placement of the original IP address and hostname on the new box.

Always back up your computer's data before renumbering. If something goes wrong with the renumbering, it's likely you won't be able to boot. For the same reason, this would be a good time to create a boot floppy using the mkbootdisk command, or whatever command your distribution supports for this purpose.

Every distro has various GUI methods of renumbering and renaming. If you trust them, by all means use them and be done in 5 minutes. I don't trust them.

I use grep to find all relevent instances of my IP address and hostname. My hostname is mydesk and my IP address is So I run the following commands:
su -
rm -f
grep -l -r "mydesk" /etc >>
grep -l -r "" /etc >>
grep -l -r "mydesk" /var/named >>
grep -l -r "" /var/named >>
grep -l -r "mydesk" /home/slitt >>
grep -l -r "" /home/slitt >>
grep -l -r "mydesk" /d >>
grep -l -r "" /d >>
The preceding creates a file listing every file containing or mydesk in the /etc tree, the /var/named tree, my user directory, and my data directory. Once the file is created, you can use sort -u to delete duplicates. Then you edit the file to run gvim on all of them, and within gvim change all mydesk to myolddesk and all to Run the script, reboot, and your computer should now be renumbered. Be sure to add myolddesk at to any other DNS servers on your LAN.

Now that your original computer is renumbered, you can install the new one using your original IP address and hostname.
Steve Litt is the author of the Universal Troubleshooting Process Courseware.   Steve can be reached at his email address.

The Real Install

By Steve Litt
I performed about 8 trial installs on my Athlon XP2400+ before doing the final, real install. Set aside a few hours for the final install, because this time you'll need to hand pick every app, driver and other piece of software.

But before you start the installation process, you must plan the installation.

Plan Your Partitions

Your trial installs probably allowed your installation to partition the disk for you. This time you must partition it yourself. Naturally, the easiest method is to have one root partition and one swap partition. Trouble is, if  something runs that root partition out of space, your OS will die, possibly taking data irretrievably with it.

A second problem with the single partition method is that it's nice to have all your data on its own partition, and even better to have your own data on its own physical hard disk. These require separate partitions.

Additionally, some partitions grow by their nature, while others are relatively static. Some are read and written, while some are primarily read. All these things point to multiple partitions. Here are some of the partitions you might want, with suggested sizes based on cheap availability of disk space (160GB, for instance):



Root partition must contain /etc directory, and provide mount points for others.
If this partition runs out of room, the system crashes, possibly with irretrevable data loss.

Tiny partition containing boot code
By making this tiny partition at the beginning of the physical disk, you assure booting of any Linux distro on any IDE hard drive with any BIOS.

Contains stuff written by the operating system, such as logs, print queues, mail queues.
Very read/write, very likely to fill up without proper maintenance (such as log rotation).

Contains software installed with the operating system
Can be mounted readonly and unchanging if software installed after the fact is installed on a different partition, such as /opt or a separately mounted /usr/local.

Home directories of all users
Size according to number of users, and extent to which users place their personal data in their home directories.

Temporary files
Written by many processes, but most well behaved programs write only small files which are subsequently deleted by the system

Software installed after the operating system
Often this is not a separate partition, but instead a simple subdirectory of /usr. If it's a separate subdirectory, and if no software is subsequently installed in /usr, then /usr can be unchanging and mounted readonly

Software installed after the operating system Very similar in purpose to /usr/local

User data
The intent of using /d instead of /home/username is so that valuable data is not intermixed with various config files, cache files, programs installed in the user's home directory, and the like. Implicitly, anything in the /d tree is expected to be backed up, which may not be true with the /home partition.

Scratchpad directory
Huge partition for holding huge files, temporary output from programs, files for concatenating, large intermediate files, quick backups of projects, and the like. If a partition becomes too fragmented, its contents can be copied to /scratch, the partition recreated, and then the contents copied back. Not intended for backup, it nevertheless might contain directories that do get backed up.

Installation directory
This is where you place downloaded or purchased installation sets. The idea is that if you back up this directory, you can restore all programs by reinstalling them, even if your kids manhandled your install CDs with peanut butter covered hands.

When planning your partitions, if you have two hard disks, try to have all the data partitions on one disk. /d, /home, and maybe /scratch would be good candidates. These are partitions that typically would NOT be reformatted during an install, and therefore you could conceivably transfer the data just by moving the hard disk from one box to the other.

Plan Your Software

Do you use OpenOffice? LyX? Gimp? IceWM? Hylafax? Gnumeric? GNUcash? Make a list of everything you use, and have the list ready so when you install the OS, you enable all the right software. Although it's true that you can install apps later, it's more difficult, and apps installed after OS installation aren't automatically included in the system menus.

Plan Your Users and Groups

NFS has a dirty little secret: It only works if users and groups have identical numbers on all NFS connected machines. Otherwise you run into all sorts of permission problems. Make sure that your username, and those of any other users, have identical numbers on the old and new machines. Same with any groups. Some distros allow you to specify the numbers during installation, while others require you to actually edit /etc/passwd and /etc/group. In the latter case, after you change the numbers, you'll need to perform recursive chmod commands on all directories owned or grouped by those users or groups that you changed.

Perform the Install

Find a block of time of at least 2 free hours, and perform the installation. Very carefully pick the partitions and the apps, services and other software to install. Do not test the video during the install -- it's too likely that it will fail. If asked, create a boot floppy -- it might help you get back in if the install bombs.

Test the Install

Briefly test the video, sound and network. Briefly test some of the apps, and maybe email. Troubleshoot as necessary. When everything's running, it's time for the cutover.

Steve Litt is the author of the Universal Troubleshooting Process Courseware.   Steve can be reached at his email address.

The Cutover

By Steve Litt
Like any cutover, you need to make this cutover quickly, because you will not be able to use either computer during the cutover. Using the old one isn't an option, because the new data won't be transferred to the new computer.

Go Off the Air

Let all your friends know you'll be off the air for hours or days. Let them know you're switching computers. Then disconnect from the Internet, and cease all work activities on your old computer. Do not perform work activities on your new computer, either.

Perform a Final Mail Retrieval

Email must be on one computer or the other. Never try to alternate. For the last time on your old box, retrieve all your email, and if necessary have your email client pull the contents of /var/spool/mail/yourname into your personal mailboxes, typically located in /home/yourname/Mail. Make sure that /home/yourname/Mail is backed up (it should be part of your regular backup anyway).

Perform a Final Backup of the Old Computer

Perform a final backup of your old computer. At the very least back up your data. You might want to back up various other things, such as your home directory and the /etc and /var/named trees, and perhaps parts of the /scratch directory. Be sure to verify the restorability of the backups, and you might even want to create two backups. Mark the backup(s) something like "20040414: Last dual celeron backup". Keep this backup forever.

Get NFS Working

By far the fastest and easiest way to transfer the data is NFS. Make sure that all necessary directories are correctly  enabled in /etc/exports. Make sure each computer can mount each other's NFS exports. If NFS won't work, it could be your firewall. While your entire LAN is disconnected from the Internet, you might want to very temporarily create a wide open firewall.

Copy the Data

There are a million ways to copy the data. The easiest is to NFS mount the new computer's /d on the old computer, cd to the old computer's /d directory, and issue this command:
cp -Rp * /mnt/newbox/d
This is easy, but it presents some problems. If you inadvertently mount the wrong directory, you could scatter all sorts of files where you don't want them. If, unknown to you, the mount fails, /mnt/newbox/d would be a subdirectory on the root partition, which would quickly fill up from such a copy. Last but not least, the transfer of so many files and directories is a major undertaking for both the computers and the LAN, and can fail.

What you might want to do instead is to create a tarball on the old box, NFS copy it to the new box, and then untar it on the new box. Start on the old box (
sudo mount -t nfs -o rw /mnt/newbox
cd /d
tar czvf /scratch/d.tgz *
cp /scratch/d.tgz /mnt/newbox
Then, on the new computer, do this:
cd /d
tar xzvf /scratch/d.tgz


The mount command usually can be performed only as user root. However, you can use the sudo command to accomplish it. To enable sudo to run the command as root in your behalf, you must enable sudo to do so by running the visudo editor. View man sudo and man visudo for details.

If you have data besides /d, copy that in the same way. Some examples might include /inst, /home, and maybe parts of /scratch. Be sure to copy your /home/Mail directory so you have all your old email.

Configure Your Computer

Get DNS running. It should be as simple as copying /etc/named.conf and /var/named/* from the old box to the new box, and then renumbering back to the original name and number. Similarly, copy and renumber the old box's smb.conf, and use smbpasswd -a command to install all necessary Samba users and passwords. Similarly configure all your new box's services. If you connect to a separate firewall box, be sure to configure that.

If you connect to a separate firewall, I'd leave IPTABLES configuration until last, because a strict firewall often messes up many services and even apps. As long as you have one level of firewall, it's probably better not to worry that factors involving IPTABLES might cause problems with other software. On the other hand, if you have no dedicated firewall, you MUST secure the computer before it's attached to the Internet.

The more of your old computer's configuration was kept in your data partition, the easier configuration of your new computer will be. For instance, if your smb.conf file was really just a symlink to /d/etc/samba/smb.conf, creation of a similar symlink on the new box will restore the configuration. Much of a box's configuration is kept in administrator created scripts, and to the extent that these are kept on the data partition, they become part and parcel of the new box upon data copy.

My computer's primary user interface is UMENU, a text based, keyboard driven menu system I created (available to all under the GPL, see URL's section). UMENU's entire menu structure is defined in a file called steve.emdl which is kept on the data partition. Once I transfer the data, I simply run the EMDL compiler to recreate the menu system, and bang, my menu system is reproduced on the new box. This cuts valuable hours out of the transition process.

To the extent possible, keep your personal configuration in your data partition.

Get Email Running

The biggest challenge is getting email running. Carefully recreate the email system on the new computer. Test and troubleshoot as necessary.


Test your new computer. The idea is not that everything works, but that you have a computer enabling you to work, however slowly.

Back Up the New Computer

You want to make sure that any kind of glitch won't bomb you back to the old computer. Back up the data, and strategic parts of the config (DNS, Samba, Email, etc.). Once you're backed up, you're on the new box to stay.

Begin Using the Computer

At this point you should be ready to use the computer. Get back on the air, announce completion of your project. You're done with the toughest part.
Steve Litt is the author of Rapid Learning: Secret Weapon of the Successful Technologist.   Steve can be reached at his email address.

Continuing Adjustment

By Steve Litt
It would be nice if the installation and cutover produced an ideal environment. Unfortunately, it's almost certain you'll have forgotten certain things. Configurations will be left out. Needed software will remain uninstalled.

For these reasons, your old computer should remain on the LAN so that you can observe any configurations and copy any files as it becomes necessary. When you can go for a couple weeks without referring to your old computer, it might be time to redeploy it.

Steve Litt is the author of Rapid Learning: Secret Weapon of the Successful Technologist.   Steve can be reached at his email address.

Redeploying the Old Computer

By Steve Litt
Eventually you'll want to redeploy the old computer. Give it to one of your kids. Use it as an experimental computer. Use it as a server. Even use it as a backup daily driver.

However you use it, you'll need to delete the old data. Even if you use it as a backup daily driver, the old data must be deleted to prevent it from accidentally overwriting modern data.

It's likely that most uses of the old computer won't be as demanding as its former daily driver role. That might free up internal hardware such as hard disks, cd writers, extra RAM, top notch video cards and power supplies, internal fans and heatsinks, and the like. Once you're satisfied that you have no need for the old computer as a primary desktop nor as a reference to the former setup, it can be cannibalized and redeployed in another role.

Redeployment is economically essential in a small business. Computer trickle down enables multiple people to upgrade when the person at the top of the food chain gets a new box. For instance, your old daily driver might become your new experimental box, your old experimental box might go to your wife, your wife's box might go to your oldest child, your oldest child's box might go to your youngest child, your youngest child's box might become a file server, your filesserver might become a firewall box, and your old firewall box might go to charity. Naturally this all involves labor, so it's possible you might quit after only a couple passoffs, but trickle down is a way to maintain a large fleet of computers with very few purchases.

Steve Litt is the author of Rapid Learning: Secret Weapon of the Successful Technologist.   Steve can be reached at his email address.

A Couple Months Later

By Steve Litt
A couple months go by since your cutover. You retained the old box for a few weeks, then cannibalized and redeployed it. You've been working on your new box, and it seems like it's been your daily driver forever. One day you pull out a spare computer to take to a LUG meeting, and you remember that once upon a time, that computer was your daily driver.
Steve Litt is the author of Rapid Learning: Secret Weapon of the Successful Technologist.   Steve can be reached at his email address.

Life After Windows: New boxes: Linux vs. Windows

Life After Windows is a regular Linux Productivity Magazine column, by Steve Litt, bringing you observations and tips subsequent to Troubleshooters.Com's Windows to Linux conversion.
By Steve Litt
Which is an easier install -- Linux or Windows?

Moving to a new computer is always a challenge, regardless of operating system. One such move brought me to tears. It was a challenge when I used DOS, when I used Win9x, and now that I use Linux.

I should mention that I've never installed WinXP, having migrated to Linux before XP came out. It's possible that XP has solved all possible computer migration problems. But I doubt it. First, there's the forced registration thing. Imagine having to beg Bill Gates for permission to reinstall your own operating system. Then there are the horror stories I hear on the Micrografx Windows Draw mailing list concerning getting Windows Draw to run on XP. Some have an easy time, and some can't do it. Nobody has found the distinction between success and failure in installing Windows Draw.

Hardware Compatibility

Last century, installing and configuring a Linux desktop box was a test of faith. Your choice of desktops was typically molassis slow KDE and Gnome, or user hostile fvwm2. Most hardware wasn't Linux compatible, and much of what was required some serious configuration and gyrations with modprobe and the like, or even recompiling the kernel. I remember trying network card after network card before getting one to work. After repeatedly failing to get sound, I went on a special shopping trip to buy a Soundblaster compatable Ensonique sound card.

Move forward five years. Almost any video card -- even if built into the motherboard, is recognized by the average new Linux distro. If it isn't, probably the next version of your Linux distro will.

Gone are the days when you needed a Soundblaster compatible sound card or a select network card. Today, many sound cards and most network cards are recognized. In fact, I'd go so far to say the average network card is easier to install on a Linux box than on a Windows box.

Some bemoan the fact that hardware manufacturers don't issue Linux drivers for their cards. Personally, I'm glad they don't. Life gets ugly when you need to save install CD's and floppies from every daughtercard you've ever bought, and you need to remember which is which. In the case of CD's, all too often the hardware manufacturer places install programs for 50 different products on that CD, and it's your job to figure out the exact model number you have, even if you've lost the original box. In most cases I trust drivers made by the free software community over drivers made by the manufacturer.

There are occasional exceptions, such as video accelleration, where often because the manufacturer cannot give source code to the free software community, the free software version of the acceleration is inferior or nonexistent.

Lesser used hardware components must be selected with care. Scanners, digital cameras, camcorders, synthesizers, radio and TV cards are all examples of hardware which must be selected with Linux in mind. Today, such hardware is where video, sound and network cards were 3 years ago -- choose right, find the right driver software, and install carefully. I'd imagine 3 years from now they'll be where video, sound and network cards are today -- drop em in and they're detected and working.


Software's like hardware. When it comes to often used applications, the free software offerings are equivalent, and often better than the proprietary ones. OpenOffice is neck and neck with MS Office -- no mean feat because MS Office is excellent. In my opinion open source Gnumeric is better than any other spreadsheet I've ever used. Open source Gimp beats Paintshop Pro hands down, and from what I hear even gives $649.00 Adobe Photoshop a run for its money.

As far as Internet clients, I prefer Kmail over Eudora and MS Outlook. Mozilla Firefox and Galeon blow the doors off  the Internet Explorer and Netscape of my youth. My Mandrake 9.2 is bundled with Xchat and other irc, news, and other internet clients. Linux was born on the net, and it's completely at home on the net.

New open source packages make their mark each year. One great example is the VimOutliner project. I started it in 2001 so as to provide an outline processor -- any outline processor, that would run on Linux. I GPL'ed it, and others joined the project and improved VimOutliner. In 2003 I handed management of the project over to Noel Henson. Under Noel, VimOutliner has really blossemed. It now has checkboxes, hoisting, a calendaring script, an easy install script for Linux, and now a Windows version. VimOutliner's website ( is top notch in terms of information, downloads and support.

The one of the two places I see proprietary software having the edge is in specialty software. At computer shows, I salivate over the midi creation software on sale there. But it runs under Windows -- no Linux users need apply. Similarly, audio  and video manipulation software is more mature in Windows. But Linux has a history of catching up.

Where Linux might never catch up is software crippled for legal reasons. I've heard the xmmx bundled with the latest Red Hat Linux does not play .mp3 files due to software patents. After all, you cannot license a patented technology and then issue its source code to all comers. The more DMCA/CDBTPA type laws that are passed, the more of a problem this will become. To me it's not that much of a problem -- any recordings I make go into .ogg format.

Software Development Products

First a confession. After using the Clarion 2 (DOS) and Clarion 4 (Windows) application development environment, everything else designed to create a data enabled user interface looks like junk to me. Perl/TK, Glade, Visual Basic, Delphi -- in my opinion they're all marginal compared to Clarion. If Clarion were ever offered in a Linux format, I'd buy it.

When it comes to batch processing, Linux has the edge. Your Linux distribution comes with C, C++, Java, Perl, Python, and Ruby, as well as the Postgres and MySQL DBMS products.

User interface is another matter. I've yet to see free software as quick and easy to use as VB, Powerbuilder, Delphi, C++Builder, and especially Clarion.

There's good news though. You can purchase Borland's Kylix 3 Open Edition development environment, which is "Delphi for Linux". Better yet, you can purchase Kylix 3 Professional New User for $249.00 -- not bad for the kitchen table developer wanting to produce vertical apps.

Piracy Prevention

Proprietary installations are really painful due to piracy prevention. Have you ever lost the key numbers to your installation CD? Just typing in those strings takes a couple minutes if you want to get them right. And then there are the minutes the installation takes scanning your hard drives looking for evidence of a former product. Of course, all of this is trivial compared to forced registration, where you need to beg Gates and Ballmer for permission to reinstall the software you purchased with your hard earned money.

None of the preceding are issues in Linux installs. You just install it. As many times as you'd like.


Which is easier to configure -- Linux or Windows? I think it depends with which you're familiar. As a person familiar with both, I'd give the nod to Linux for a simple reason -- you have the option to forsake your GUI config tools in favor of configuration by editor. Configuration by editor isn't always easy, and it's not always what you want, but when your GUI configuration tool fails, it's always nice to be able to go in with Vim and configure your box.

Data Transfer

I'd say data transfer is easier between two Windows boxes, because of Network Neighborhood, and because Windows sharing is a little easier to set up than Linux's NFS.

That being said, when things get a little hairy, I'm glad I use Linux. Linux has much better scripting facilities so that you can make unusual tweaks.


Operating system installations are difficult, no matter what the operating system. The vast majority of Windows users never install their own operating systems, whereas the vast majority of Linux users do. When you hear Linux is "harder", consider that fact.

Setting up a Linux desktop machine in the 20th century was a trial by fire. Most hardware was not supported, requiring the owner to obtain all sorts of untested driver code from all sorts of places. It was often necessary to recompile the kernel. In the bad old 1990's there were few apps, and most were kludgy. The desktop managers of the day were either pathetically slow (KDE, Gnome), or pathetically useless (fvwm2).

Move the clock ahead five years, and what a different world it is. Both KDE and Gnome have been rewritten for speedier response, plus the fact that the average $500.00 PC has adequate power to run KDE and Gnome in a snappy fashion. Fvwm2 is now a perfectly respectable desktop manager. And today's user has many other options: Blackbox, Fluxbox, WindowMaker, IceWM, SawFish, Enlightenment, and several others.

Today, all but the bleeding edge or most antiquated video, sound and network cards are supported by Linux, and correctly probed without user input. Contrast this with the gyrations a Windows user must perform with the vendor's installation CD, and Linux installation is a delight. Some less used hardware components such as scanners, cameras, camcorders, radio and TV cards don't support Linux and are harder to install, but things are getting better every day.

Linux software has caught up to and even exceeded proprietary software in mainstream software catagories. Lesser used categories are still easier with Windows, and certainly Windows is still an easier place to develop integrated user interface database apps, but Borland Kylix is helping to level the playing field.

Data transfer is usually a little easier in Windows, while configuration is usually easier in Linux.

Bottom line is that in this man's opinion, although it's a tough call, I think it's easier to switch between two Linux boxes than between two Windows boxes.
Steve Litt is the founder and acting president of Greater Orlando Linux User Group (GoLUG).   Steve can be reached at his email address.

Letters to the Editor

All letters become the property of the publisher (Steve Litt), and may be edited for clarity or brevity. We especially welcome additions, clarifications, corrections or flames from vendors whose products have been reviewed in this magazine. We reserve the right to not publish letters we deem in bad taste (bad language, obscenity, hate, lewd, violence, etc.).

Submit letters to the editor to Steve Litt's email address, and be sure the subject reads "Letter to the Editor". We regret that we cannot return your letter, so please make a copy of it for future reference.

How to Submit an Article

We anticipate two to five articles per issue, with issues coming out monthly. We look for articles that pertain to the GNU/Linux or open source. This can be done as an essay, with humor, with a case study, or some other literary device. A Troubleshooting poem would be nice. Submissions may mention a specific product, but must be useful without the purchase of that product. Content must greatly overpower advertising. Submissions should be between 250 and 2000 words long.

Any article submitted to Linux Productivity Magazine must be licensed with the Open Publication License, which you can view at At your option you may elect the option to prohibit substantive modifications. However, in order to publish your article in Linux Productivity Magazine, you must decline the option to prohibit commercial use, because Linux Productivity Magazine is a commercial publication.

Obviously, you must be the copyright holder and must be legally able to so license the article. We do not currently pay for articles.

Troubleshooters.Com reserves the right to edit any submission for clarity or brevity, within the scope of the Open Publication License. If you elect to prohibit substantive modifications, we may elect to place editors notes outside of your material, or reject the submission, or send it back for modification. Any published article will include a two sentence description of the author, a hypertext link to his or her email, and a phone number if desired. Upon request, we will include a hypertext link, at the end of the magazine issue, to the author's website, providing that website meets the Troubleshooters.Com criteria for links and that the author's website first links to Troubleshooters.Com. Authors: please understand we can't place hyperlinks inside articles. If we did, only the first article would be read, and we can't place every article first.

Submissions should be emailed to Steve Litt's email address, with subject line Article Submission. The first paragraph of your message should read as follows (unless other arrangements are previously made in writing):

Copyright (c) 2003 by <your name>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, version  Draft v1.0, 8 June 1999 (Available at (wordwrapped for readability at The latest version is presently available at

Open Publication License Option A [ is | is not] elected, so this document [may | may not] be modified. Option B is not elected, so this material may be published for commercial purposes.

After that paragraph, write the title, text of the article, and a two sentence description of the author.

Why not Draft v1.0, 8 June 1999 OR LATER

The Open Publication License recommends using the word "or later" to describe the version of the license. That is unacceptable for Troubleshooting Professional Magazine because we do not know the provisions of that newer version, so it makes no sense to commit to it. We all hope later versions will be better, but there's always a chance that leadership will change. We cannot take the chance that the disclaimer of warranty will be dropped in a later version. 


All trademarks are the property of their respective owners. Troubleshooters.Com(R) is a registered trademark of Steve Litt.

URLs Mentioned in this Issue