Tip

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 (

Requires Free Membership to View

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).


Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 20-year veteran of the IT consulting industry.

This was first published in March 2005

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.