Troubleshooters.Com and
The April 2001 Troubleshooting Professional Magazine Present

Troubleshooters.Com's Windows to Linux Transition:
The Whole Story
Copyright (C) 2001 by Steve Litt. All rights reserved. Materials from guest authors copyrighted by them and licensed for perpetual use to Troubleshooting Professional 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.

By Steve Litt
The 19 year old company widely know as Troubleshooters.Com is officially named American Troublebusters. Before 1990 it was known as Steve Litt Business Systems, and before 1986 as Steve's Stereo Repair, which was founded in 1982 with an old voltmeter, a card table, and pens and 3 by 5 cards for marketing. This company had a computer for every second of its existence.

The first computer was a soldered together Heathkit ET6800 Microprocessor Trainer with a 16 key hex pad to input programs in hexadecimal. It had four 7 segment LED's for output. I soldered an RCA jack to one of those LED segments, plugged it into an amplifier, programmed it to play music, and used it as a marketing tool to get Steve's Stereo Repair into the computer business. The ET6800 had an 8 bit Motorola 6800 processor, 256 bytes of RAM, and absolutely no method of storing programs or data once the power was turned off.

In the summer of 1983 brought a $100 Timex computer with a Z80, a whopping 2K of RAM, a Basic interpreter, and a tape recorder interface to store and retrieve data on audio tape. Obviously there was no data to be transferred from the Heathkit.

After becoming a programmer in March 1984 I spent $1450 in December 1984 for a daisy wheel printer and Kaypro 2X computer with a Z80, an unbelievable 64K of RAM (who could ever need that much?), two ~160K floppy drives, and a slew of software including Turbo Pascal and Wordstar. Finally a "real" computer. It couldn't read my Timex tapes, so once again I started clean.

In the summer of 1986 I plunked down $2500 for a 10mhz 286 with 640K, 40Meg, and MS DOS 3.1. My Kaypro data consisted of maybe 100 Turbo Pascal programs and Wordstar documents already on floppies, so I just bought a conversion program called Uniform and read them in. Wordstar docs were simply text with the high bit of the last letter of each word flipped high, so I wrote a Turbo Pascal program to flip the bit back down and I had the docs ready to print or import into WordPerfect 4.2. None of this data was really integrated with my business, so I could afford to be haphazard about the imports and conversion. It wasn't until 1988 that the computer finally became central to my business.

1990 brought Windows 3.0, but it could execute DOS programs, so no conversion was necessary. 1995 brought Win95, but except for some easily solved backup problems it was a non-event, as was Win98. I cracked open my first Linux distro in October 1998,  and by December 1998 Linux was firmly planted in Troubleshooters.Com as a Samba, Apache, DNS and DHCP server. But there was no transition because it was the first experience I'd ever had with servers. I literally learned networking on Linux.

Spring of 1999 brought the opportunity to be a contributing author to Red Hat Linux Unleashed and Linux Unleashed, and that August I began writing Samba Unleashed as the main author. Linux was now a very strong part of my business, and even though I had previously viewed Linux as a server, it occurred to me that I might want to switch to a Linux desktop. That idea was solidified when the evil UCITA legislation was recommended by NCCUSL July 29, 1999. The next day I began planning my slow, deliberate move out of proprietary software.


I began hearing about UCITA in early 1999, thanks in no small part to the work of Infoworld's Ed Foster. It sounded like something out of Rollerball -- corporate greed and payoffs gone amuck. For the most part it was no threat, because it would force any sane person into Open Source software. Would anyone really agree to automatic software shutdowns, bans on publication of negative findings with the software, and complete absolution from warrantee? The one part that worried me was the clause on reverse engineering. How can a Samba exist without reverse engineering? For that matter, how can I ever use another word processing package on my Word documents if reverse engineering is illegal. But this legislation couldn't really pass in this country. Americans have common sense.

On July 29, 1999, a day that will live on in infamy, the National Conference of Commissioners on Uniform State Laws (NCCUSL), with heavy lobbying from many software manufacturers, plunged a dagger into the backs of software users. The NCCUSL recommended UCITA.

The next day I instituted a policy that Troubleshooters.Com would purchase no new proprietary software, and install no new proprietary upgrades. The programs I had on that day could be imported into other programs, and I had no intention of giving up that advantage.

The Virginia House of Representatives passed the horrid UCITA legislation on February 16, 2000. Maryland followed suit a few months later. My assumption that common sense and established contract law would prevail were sorely misguided. Like it or not, I had to get serious about migrating to the Linux desktop.

The Dream Machine

Flush with various Linux server victories, Linux favorable press, with high hopes, I bought a dual Celeron 450 with 512Meg and 20Gig in February 2000. This would be my first Linux desktop machine. I threw Caldera Linux on it and got to work. I secretly hoped I could transition before my publicly stated July 2000 cutover date.

For those of you who like to turn to the last page of the book, let me tell you I'm writing this material on that computer, using Netscape Composer (and some VI) with a Mandrake 7.2 Linux operating system. My old windows box sits in the corner, powered down.

But the journey wasn't simple...

The Days of Disappointment

Editors Note: The point of this section is not to denigrate Linux on the desktop, or discourage people from migrating. But without a realistic look at the challenges of Linux desktop migration, all Linux desktop advocacy is bound for failure. Please read this section, and then read the following section to find how these challenges were met.

First, there was the problem of which distro. I kept installing and uninstalling. First Caldera, which back then was the acknowledged leader on the desktop. But I found it kind of quirky. Then Corel. A thing of beauty, but the more I used it the more difficulty I had. I even considered Red Hat on the desktop, but I'd kind of typecast Red Hat as a server OS, and passed. Finally Chris Young suggested Mandrake. I installed it, I liked it, and I kept at it.

And there were problems. Except for web authoring, everything I did on the desktop was absent from Linux. I could find no fast outliner to replace that of MS Word. Worse yet, I could find no word processing program that had an outline view like MS Word. For awhile klyx appeared to come close, but inexplicably it had no way to create a heading within the structure view.

And there was the graphics thing. On Windows I used Micrografx Windows Draw for vector drawings (cartoons and the like) as well as diagrams. And I used Paintshop Pro version 3 (in version 4 and beyond they removed movable rubberbanding, making later versions useless for my purposes). I found no equivalents in Linux, at least not at first.

PPP is a mess. I'm sorry, it's horrid. Every time I install a new distro it's 4 hours work to hook up to the net. That's disgusting.

Even my attempts at installing hylafax met with failure.

Netscape doesn't work as well on Linux, especially Netscape Composer. It has bugs that made the authoring process longer.

I had used and loved Eudora Lite on Windows for three wonderful years. Its features allowed me to work with my 100+ daily emails with dispatch. Sure, it crashed a lot, but I could still make it burn 100 feet of rubber. Everything I found on Linux seemed to pale by comparison.

More and more, it seemed like Linux on the desktop was a recipe for lowered productivity.

Cut and paste seemed quirky and inconsistent in KDE. A days work for me involves a few hundred cut and paste operations between different apps.

The keystrokes seemed weird and unproductive.

The Linux mouse was snail slow.

As my July 2000 transition goal came and went, I found myself disillusioned with Linux on the desktop, and farther than ever from desktop adoption.


In hindsight, all of this is easily recognized as normal conversion jitters. A temporary crisis in confidence caused by the importance of my computer in my business. But back then it seemed a showstopper.

Why am I telling you all this? It's because your business will likely hit a similar wall when  transitioning away from Windows on the desktop. It's perfectly natural. Flush with Linux victory on the server, you expect a similar easy victory on Linux. Maybe you brag that any time now you'll have a better desktop system that doesn't crash, is a lot more. We Linux advocates have almost universally made the mistake of extrapolating our huge server successes onto our claims for the Linux desktop. In doing so we hurt our credibility with the business community, and more important, with ourselves.

If you decide to continue with your Windows to Linux desktop transition, you'll get past the disappointment stage in the same way as I did -- by scaling back your expectations. The Linux desktop isn't hugely better than the Windows desktop. Each has its advantages and disadvantages, but they're roughly on a par with each other. Of course, the Linux desktop is improving much faster than the Windows desktop, so its future is brighter.

That brings up the obvious question. Why in the world should I make this difficult, costly and time consuming conversion to a product that's "roughly on a par" with Windows? The answer is simple:

Who owns your data?

Do you want Bill Gates and Steve Balmer to control your access to your own data? Do you want to beg them to keep your license in force when your company merges with another one? Do you want to bet that they won't totally screw up the apps with which you access your data, or triple the price for the next version and prevent you from using your existing version?


The low point in my Linux transition was January 7, 2001. I bought a new Logitech Dexxa Optical mouse in an attempt to fix the slow mouse problems in Linux. In Windows I can set my system so two inches of mouse travel moves the pointer from the top to the bottom of the screen. In Linux it took 6 or more inches. Of course I could jack up the acceleration to the point where a quick 2 inch movement would traverse the screen, but that makes mouse movement inaccurate. Mousing becomes like a golf game -- a drive, a tee shot, and a couple putts before your pointer is over the target. Not exactly a formula for productivity.

I bought the Dexxa Mouse on 1/6/2001 and installed it 1/7/2001. It made my mouse performance even worse. The Linux mouse was as bad as a notebook computer's stick mouse or thumb pad, but without even the remedy of plugging in a different mouse. I decided to abandon my desktop transition, confine my future work to the Linux servers, and stick with Win98 while hoping for a miracle.

Reduced Expectations, Enhanced Performance

Before I tell you how I got past my Linux mousing problems, let's talk about my era of reduced expectations, which overlapped the days of disappointment. The era of reduced expectations began a couple months after the days of disappointment, and ended a couple months after the end of the days of disappointment. In fact, the mouse problem could be considered the last hurrah of the days of disappointment.

This is important to every business, making any transition. Years of accumulated knowledge and keyboard/mouse reflex can't be instantly replaced. Wordstar, WordPerfect, and MS Word all served me well, but all started with disappointment, followed by reduced expectations, and then finally satisfaction.

In early 1999 I began using uudecode to decode some chapters emailed me by Macmillan. Next came development. In fact, when I got an assignment to do a complex Perl/CGI app on NT in the spring of 2000, I developed it on my Linux box and ported. The port took maybe an hour, but the development speed on the Linux box saved many hours. VI became an integral part of my business, and soon became my only editor, both on Linux and Windows.

In May of 2000 I was in the depths of the days of disappointment, so I wrote the June 2000 Troubleshooting Professional, themed "Making it in a Post Microsoft World", as a blueprint for the rest of my transition. And very slowly, I began to execute that plan. Linux slowly began to work its way into my everyday work. But PPP was such a pain that I seldom used the box on the Internet.

October 19, 2000 was a major turning point in my Linux transition. Phil Barnett gave a presentation on the Smoothwall Linux firewall distribution, and made it look so easy that I bought a $100 computer and installed Smoothwall.  On the LEAP mailing list I posted this little parody (sung to the tune of The Wall by Pink Floyd), to commemorate Troubleshooters.Com's Smoothwall installation:

We don't need no creeps and crackers
Our net-work is in control
No dark hat trojans in our boxes
Crackers leave our net alone

All in all there are no holes - in our smooth wall!

But the real news about Smoothwall was that its default installation handled PPP in such a way that any box on its subnet can connect to the net through Smoothwall. No more PPP worries! I began more extensive surfing and even a little emailing on my spare mail account. As I used my Linux box more, I found little productivity tricks using cut and paste to make my work faster. I occasionally used Netscape Composer on my Linux box to write content for Troubleshooters.Com. But other difficulties loomed...

About this time I was starting to meet with some skepticism from those who felt I would drag my feet forever, and never convert. At first this skepticism prodded me to move faster, but when the level became too much I slowed down out of ornaryness. These guys just couldn't understand that this wasn't an email machine, a server, or a gaming machine I was transitioning. This was my entire business, complete with 16,000 data files (that's data files, not stuff in /usr and the like).

In retrospect, I owe those skeptics a vote of thanks for teaching me valuable Linux advocacy lessons. I was highly motivated to switch, and these guys discouraged me. Imagine how they'd affect a guy who was "sitting on the fence".  Embarrassingly, I used to advocate the way these guys did. That was OK in 1999 when the people you were reaching were rabid technologists. But those types are now all converted, so rabid advocacy does nothing but preach to the choir. What's needed now is a business focus. I now know that I lose all credibility if I simply brush aside concerns about training, procedural changes, and yes, money. The real question we advocates need to ask is "who owns your data?".

So I guess you're wondering how I fixed the mouse problem. On January 7 and 8 of 2001 I read man pages, docs, web pages, and everything I could get my hands on, trying to speed up the mouse without accelerating it (acceleration merely makes it less accurate). I finally found that I could put Option "Resolution" "1600" in my XF86Config-4 to traverse top to bottom with an inch and a half of slow mouse travel.

That did it. The days of disappointment were over. It had finally dawned on me that unlike Windows, any Linux problem is soluble. I was going to make the switch. The only question was when.

The Last Days of Windows

It happened unexpectedly. After making a skeleton for the March 2001 Troubleshooting Professional (XML), I FTP'ed it to my Linux box so I could write code and author the page on the same box. Using Netscape Composer on Linux and Linux cut and paste methodologies slowed me down a little bit, but not enough to matter. And as days went on I found new shortcuts to speed progress. When I'd finished the 32,000 word magazine I FTP'ed it back to Windows to do some cleanup with Netscape Composer, Windows version. The primary cleanup was that the Linux version couldn't do relative links -- all links were absolute.

Later, while riding my bike on a Woodsy trail, my thoughts drifted to that Netscape bug and how it threw a monkey wrench in my transition. And then I realized that a simple VI macro, to convert all instances of /d/tdotc/ to the proper number of ../ to match the location of the current page, would cure the problem. I had worked in the Windows world for so long that I'd forgotten that some operating systems give you tools to work around little application bugs.

Now it was time to publicize the XML tutorial. I used Kmail to send out a hundred or so announcements. And as I got more proficient at Kmail, I found I was every bit as productive as I had been on my beloved Eudora Lite. Then I hit a snag.

Kmail has a killer search facility, but being new to Kmail I couldn't find it. I panicked. I always search my sent messages so I never send an announcement to the same person twice. That's considered rude. Kmail had no search (so I thought), what could I do? I finally made an icon that ran the VI in read-only mode on the sent messages, and used VI's search for the mailing address. Problem solved.

Yet again,  I had worked in the Windows world for so long that I'd forgotten that some operating systems give you tools to work around little application bugs. Apps in Linux don't need every last feature, because Linux has tools to add functionality. A Linux app can do one thing and do it right, knowing that third parties can add functionality with various tools. What a refreshing concept after Windows.

With the magazine finished and publicized, I took a couple days well needed rest, during which time I realized the time had come.  I'm a regular participant on the mailing list of FLU, Florida Linux Users (Gainesville). As a final test of KMail ability to handle my day to day emailing needs I unsubscribed, and then resubscribed from my spare email address, and for a few days I used Kmail, from the spare address on my Linux box, exactly as I would in a production environment, filters, sigs, replies and all. It worked.

I ordered a 60GB 7200 RPM IBM Deskstar to serve as the system disk, planning to make the existing 20GB the data disk. I bought an extra fan. On March 12, 2001, I took out my screwdriver and began my conversion.

The Conversion

I took my sweet time. I prodded, poked, installed, uninstalled, and anticipated. The first problem, and it was a doosy, is that I couldn't reliably recognize my drive. It didn't occur to me the BIOS could be at fault, because I'd always been taught Linux goes around the BIOS for disk I/O. Well, I can tell you now, it mostly does, but not always. A trip to the ABIT website produced a BIOS upgrade specifically made to "recognize drives over 40G". There were tense moments when I flashed my BIOS without a UPS :-). And then victory as the I could correctly see the 60G drive.

There was experimentation. I'm lucky enough to have IDE 1 and 2 for normal disk work, and IDE 3 and 4 for UDMA. I put my 60G on IDE1, my CD on IDE2, and my 20G data drive on IDE3. That way no IDE channel would be shared by two devices, enhancing performance. But why did I put my 60G on a slow IDE port?

I wanted everything as simple as possible. No LILO tweaks to boot to /dev/hde. So I ate a little performance to make this transition go smoothly. I have the rest of my life to tweak the box. That's the same reason I used stock Mandrake 7.2, rather than the superior Mandrake 8.0 beta. No surprises.

I partitioned my disks, and installed Mandrake.

Let's talk about data. My philosophy for my business (your mileage WILL vary) is you have your data on one box. When I wrote the March Troubleshooting Professional, my data was on the Windows box. When I was done I FTP'ed it back to the Windows box. The last thing anyone wants is to have dueling versions of a file or document. It's for that very reason that I never receive email on more than one box. Wherever my email is, that's my main desktop box. And that box is where my backups are, and those backups are assumed to have ALL my data. So I had to quit all email and authoring activities before doing my final Windows backup. On Tuesday, 3/13/2001, at 2:15PM I wrote my crew at LEAP telling em I'd be off the air for awhile:

X-Sender: slitt@
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
From: Steve Litt <Steve Litt's email address>
Subject: [LeapList] I'll be out of touch for awhile
Date: Tue, 13 Mar 2001 14:15:13 -0500

Hi Yall,

I won't be receiving email for awhile. I'm beginning the pre-switch backup
of my W98 box's data. Once that begins, I can neither recieve nor author
email, nor do any development or write any content, until my new machine is
in place.

If I don't talk to you before, I'll see yall Thursday.


I took 3 complete and verified backups -- one local, one offsite, and one out of state.

Then I Samba'ed my data across to the new box. Without going into gruesome details, I basically copied the entire tree from my Windows D: drive to my Linux /d tree, which of course is mounted to its own partition on my data drive.

Next I set up Kmail mailboxes and filters equivalent to the ones I had left behind in Eudora. Around 7:15PM that day I began to receive email on the new system, and the filters worked perfectly. Just before midnight I began replying to posts.

I was back, and Windows was gone.

But my only backup was of a Windows machine, meaning that a major data failure would knock me all the way back to Windows. On the next day, 3/14/2001, I did some rearranging of my data, then created a backup script to tar.gz all my data. Because my CD burner is still on the Windows box, I burned the CD's there.  Now a data failure simply meant restorral from the Linux box's data backup. I'm in Linux to stay.

I spent Thursday sort of goofing around with my new system. But I was still in limbo. Can you guess why?

Er, umh, there's that little matter of DOS text file termination. Those pesky little carriage returns. You know, Ctrl+M. ^M, \r, \015, char(13), whatever you want to call them, DOS for some reason felt it necessary to add those to the front of the traditional UNIX linefeed for line termination. My Linux box now had thousands of data files with the wrong line termination. Every file comprising the Troubleshooters.Com website (and JobSecurity.Com, MoreTime.Com, and CarreerSuccess.Com too) had the wrong file format. I couldn't work on these websites til I fixed the problem.

One might imagine a simple sed script could be fed by a find command to cure the problem. It's not nearly that simple. Take my Python files. What if somewhere in my DOS/Windows past I made a WordPerfect 5.1 file ending in .py. Imagine I simply extracted all Ctrl+M characters from that file. It would be damaged irretrievably, and it might be years before I knew it. Maybe it would be so long that I couldn't read my last Windows backup. Maybe I could delete only Ctrl+M characters preceding a Ctrl+J linefeed character, so that I could "put back" the Ctrl+M's if I made a mistake. No, in a binary file not all Ctrl+J would be preceded by a Ctrl+M.

I spent Friday and Monday constructing a script that would:

I also spent a lot of time constructing a command to drive this script, using find, grep and xargs. And I succeeded. But in the end I constructed a list of all files to be converted, then used VI to edit that list into a script to call my conversion script for each file. It's safer that way. There were also matters of case conversion. On DOS .txt or .TXT or even .tXt mean a text file, but on Linux they all better be .txt. I did those type of conversions too.

I tested my conversions on a scratch partition until I was satisfied. Then I backed up my data yet again, and ran the scripts. It took more than a day to complete this data conversion -- it was mind-numbing manual labor, but I dared not make it more automated for fear that I might make a data destroying mistake. Obviously, when I finished this drudgery, I took another backup so I wouldn't need to go through it again.

Today, 3/20/2001, Troubleshooters.Com is once again in business with a stable desktop machine. This material is being written on that machine.

Challenges Ahead

I can't reformat my Windows box. I have 550 Micrografx Windows Draw  files and 1178 Word documents:
$ find /d -type f | grep -i "\.drw$" | wc
    550     550   17849
$ find /d -type f | grep -i "\.doc$" | wc
   1178    1178   36864
That's not counting huge numbers of other files I have in an archive tree disjunct from /d. I have nothing in Linux that could import the Windows Draw files reasonably correctly. As far as Word docs, I could import them into Kword or Abiword, but those have no provision for user defined styles, and I fear that much of my information would be lost. I could import them into Star Office, but as far as I know Star Office isn't Open Source either. If I don't own my data, I don't see a big difference between Star and Word, except that Word has better features for a guy who writes 300 page books, and Word 97 docs (remember, I never upgraded) are more universally readable.

So for the short and maybe medium term, MS Word and Micrografx Windows Draw must be kept to ensure access to my .doc and .drw data, and I'll probably be using Windows Draw for new cartoon and symbol type drawing. Future diagrams will of course be done in Dia, the GPL diagramming program that stores your drawing in XML form. Future books and documents over 30 pages will continue to be done in Microsoft Word 97 because, bluntly, it's the best self-publisher's book writing tool I know of. New shorter docs will probably be done in Star Office, or if they're simple, Kword or Abiword.

My Troubleshooting Courses are in MS Powerpoint format so they're easily used by companies of every size and stripe. I'm sure when a customer wants to buy it in a Kpresenter form, I'll make that available.

I have some other files with obscure Windows centric formats. Some are in a form called Envoy. Some are data from the DOS based Grandview outliner (which hopefully I can run on my Linux box with a DOS emulator).

Rome wasn't built in a day, so some of my hardware is still on the Windows box. My CD burner is on the Windows box -- a situation I'd like to rectify soon so that I can make 1 step backups. My Zip drive's still on the Windows box, and I'll bring that over one day. My $59.00 scanner is on the Windows box, and that scanner (Microtek Scanmaker 3600) doesn't support Linux, so it stays on the Windows machine until I buy a scanner that supports Linux.

My Windows box will be around for a minimum of 5 years. But now it's an MS Word and Windows Draw appliance, plus an appliance for a few other apps and a few pieces of arcane hardware (soon to be VERY few). If it gets a virus I reinstall Windows and maybe 5 apps, and I'm done.

In the long run I must find an Open Source vector drawing program as good as Windows Draw, and I must find a way of importing my MS Draw files into them. Or worst case changing them to bitmaps. I need to find a book authoring tool as good as MS Word, or else change my book authoring methods to match what's available now that I have everything in the Open Source world to choose from.

I also need to learn how to interact with a world that's still 80% Microsoft. What are my policies on sending out .doc files as it gets more and more inconvenient to make them? How about presentations? (I like HTML presentations created in htmlslides, myself).

I still use Windows. But as time goes on, it assumes ever less importance.

Lessons Learned

This is where I usually say "if you don't want to cry like I cried, don't do what I did". But this time there's not very much I'd change. I made a plan (the June 2000 Troubleshooting Professional, "Making it in a Post Microsoft World"), and executed that plan to completion. It took a lot longer than expected, but given the information I had while taking the journey, I wouldn't have sped it up. If I had had the benefit of the document you're now reading I could have done it much faster.

So let me tell give you a summary of the transition steps for a single desktop computer whose data is on the hard disk (very small business like mine).

  1. Ban proprietary upgrades and new programs immediately
  2. Segregate your data from your apps and OS
  3. Make a transition plan
  4. Find dead ends and ways out
  5. Create a practice setup
  6. Get hardware ready to accept Linux
  7. Install Linux
  8. Do final windows backup
  9. Samba data across to the Linux box
  10. Test to verify a working setup
  11. Do a backup of your Linux data
  12. Rearrange directories to suit new environment
  13. Delete or rename DATA filenames with spaces
  14. Correct the case of DOS extensions
  15. Convert DOS format text files to UNIX format
  16. Back up
  17. Install Samba and VNC so you can use Windows programs for which there's no substitute
  18. Continue to seek substitutes for remaining Windows apps
And here is a possible process for a larger concern whose data is (or should be) kept on the network:
  1. Ban proprietary upgrades and new programs immediately
  2. Segregate your data from your apps and OS
  3. Begin moving data to the server immediately (multi-employee businesses)
  4. Add Samba servers as necessary to hold the new data.
  5. Or if you're transitioning away from Windows servers, add Linux NFS/NIS or Linux LDAP servers to hold the new data, and make that data available via Samba.
  6. Institute proper backup procedures for the new servers.
  7. Line up a team of technological savvy people as a steering committee and troubleshooting group
  8. Make a transition plan
  9. Make a list of apps for different groups
  10. Find dead ends and ways out
  11. Create a practice setup
  12. Give people final notice that their hard drives will be formatted, and to move their local data to the network
  13. Roll through with a basic kickstart install
  14. Install additional apps on an as-needed basis
You might wonder why I kept my data on the local disk instead of moving it to a Samba server first. My case is rather unusual. I have no Windows NT/2000 boxes, nor do I have any Windows or DOS clients except for the machine that was my main desktop box until a week ago. Samba is not an especially good choice with which to serve UNIX style machines like Linux.

Above all, make your plan, and stick to it. Don't let rabid Linux fanatics (you know, like I was until a couple months ago) pressure you into a premature transition. And don't let sniveling little Microsoft sycophants talk you into abandoning your transition. Take the time to do it right, and do it. After all, you're the one who owns your data.

Steve Litt is the main author of Samba Unleashed.  He can be reached at Steve Litt's email address.

This Concludes this article. Click here to resume the 4/2001 Troubleshooting Professional where you left off.