A mantra for migration success

As your company evaluates migrating from Microsoft Windows to Linux, everyone in your IT shop may need to chant this mantra continually: Linux is not Windows. Forget these four simple words, and you may face some complex challenges. Your Windows skills aren't going to take you very far in the Linux world, but your budget will go a lot further.

Almost everything the Microsoft Certified Systems Engineer (MCSE) knows for sure about how to run applications on Windows is wrong on Linux. In this tip, I'll give some examples of how different things are between Windows and Linux.

A thoroughly different approach

First of all, the rack mount approach to symmetric multiprocessing (SMP) -- one application per server -- makes no sense for Linux or any Unix variant. Prior to Windows 2000, this approach was necessary with Windows; now it's a common and somewhat reasonable practice because having to shut down multiple applications while you restart, reinstall, or futz with Windows is annoying and wastes time. Besides, you still can't fully anticipate the interactions of the two or more sets of registry changes you get if you load two applications on one machine running Linux.

There is no registry in Linux, and it's perfectly safe to run two or more applications per box as long as they don't have the same peripheral dependencies -- like two video editors driving the same DVD.

In general, applications are started from scripts where you set environment variables that are local to the application. As a result, things like CLASSPATH, PSPRINT, or DATEFMT can have different meanings for each application without causing any conflicts.

With Linux, you usually do not reboot on failure, and a re-install is usually not the right answer. In most cases, rebooting will have no effect on an application failure. If it didn't install right the first time, re-installing it without making some other change first will just reproduce an identical result.

Most applications have options that set them to produce more or less complete operational logs. If you get mysterious failures, turn on logging to get a high level-look at the problem, and then decide what to do. Most of the time it will be a path or permission setting issue -- utterly frustrating when you don't know what's going on, but trivial to find and fix once you see a log entry like this one:

xrmenu starting on Homstat48A
No .xrconfig on Gardlink880
aborting

Not all logs, of course, are helpful. For example, I'd be grateful if someone could explain the fix for this one to me:

/usr/dt/bin/ttsession[13966]: starting
Killed
/usr/dt/bin/Xsession[749]: 13949 Hangup

Freedom from licensing fees

You do not buy a support contract for every installed copy of LInux. With Microsoft, you have to. Of course, some Linux distribution vendors might love to see people build on that example, but it's less than bright to do it.

Linux really is free; that fee a vendor wants for its basic first year subscription is for support, not the right to use Linux. Of course, you can also buy a distribution that has a lot of bells and whistles, but you don't have to spend a dime unless you want to.

Buy a 25-user Windows 2003/XP server license, and you can run it on one production machine. Buy a $20 Debian Linux CD, and you can load it on as many machines as you want to.

There's a quick bottom line here: If you're going to use an enterprise Linux distribution like Red Hat Enterprise or SuSE -- and there are lots of reasons to do that -- buy one copy for your sysadmin. Then, set up a procedure that says nothing runs in production until tested on the one supported system. Then download the free version, and run it on as many production machines as you like.

The list of necessary mindset differences goes on and on. The bottom line is the mantra: "Linux is not Windows." Do not assume that anything you know from managing or buying Windows is portable; it's usually not. That goes for everything from whether or not using two NICs makes sense (only on very low-end gear) to whether the sysadmin should login as root (only under very exceptional circumstances).