Problem solve Get help with specific problems with your technologies, process and projects.

Getting started on a Unix-to-Linux migration, part 2

In part two of a three-part series on Unix-to-Linux migration, expert Ken Milberg advises how to get your project off the ground.

In part one of this series, we began planning for a Unix-to-Linux migration. Now what? In this episode, I'll offer some tips on building your project team, working with code and setting up the administration of your new systems.

First, let's do a quick review. If you were engaged in a project and implemented the steps in part one, you'd have completed several tasks. First, you've done an assessment, and you know what resides on your Unix box(es), including details like version numbers. You've decided which applications you'd like to port over. Additionally, you checked with the business owners, and everyone has signed off on your project's content and timing. Now, you know -- we hope -- when your server or servers will be up and running in the new infrastructure. You have even installed a popular Linux variant on a PC.

Moving on the to next phase, the first thing you need to do is determine who will be doing what. Do you have a team, or are you the team? Are you going to bring in a vendor to help you support these initiatives, or are you going to do it all?

To answer the questions above, you probably have to know the answer to this question: What is your budget? Do you know the answer? If not, shame on you. Make sure the financial folks know what is going on and that you have the money you need for the migration. A tip: Your CFO will be friendlier to the project if you explain that, in the long term, Linux will save the company big bucks. (You'll probably have to be more specific than that.)

Now, for the sake of simplicity, I'm going to set up a basic migration scenario. This is a small shop, and you are the team. You may have some monies available to bring a vendor in to help, but you don't have a bundle. You're going to try to do as much as possible yourself.

Your next step is to start looking in detail at the code. The complexity of what you are trying to do is directly related to the amount of system-dependent code that you have. Does the application use standard binaries, or do they depend somewhat on the hardware platform you are running? Is your application based on Java or C++? Are there third-party dependencies relevant to the application that may not even be available on Linux? This is the level of detail that you must drill down to.

As you probably know, the great thing about Linux is that a lot of what you need -- like the OS and compilers --is free. (Are you listening, SCO?). With free software, you just need to do the work and provide the hardware.

If you have the luxury of a large development environment, you may want to continue to develop code in your existing environment, so that you can ease Linux in gradually.

In building your application, you'll probably want to use open source C (also known as GNU Compiler Collection or GCC). You may already have compiled code with GCC, which would put you one step ahead of the game. If you haven't yet compiled code with GCC, but only with your AIX C compiler using cc, you may want to recompile your code with GCC on your existing environment to ease the transition. There are versions of GCC available for AIX, Solaris and HP-UX that will let you recompile your C code very nicely. Here's a link for the AIX version. By the way, instead of make, you'll start using gmake.

If you don't want to go the route of recompiling everything on your existing box, you can try installing everything on the Linux box. You may already have all the compilers and build tools already pre-installed on your box. Get the source code over, as well as the makefiles, and start rebuilding. Again, look closely to make sure there is not hardware-specific code that will ruin your day. If there is, make those changes.

More than likely, you're going to have to make changes with your run-time APIs. There are a lot of things you must handle that may not be included in Linux: system calls, file system and logical volume management, streams, library support and more. Math libraries may not be supported, as well as your desktop environment. For example, do you use CDE (Common Desktop Environment)? If so, you'll have to give it up and choose now between KDE and GNOME.

You can't take many more steps without figuring out your systems administration functions. Though Linux is Unix-like, it is not Unix. There are differences all over the place, from process management to filesystem management to kernel tuning. So, dig in and learn more about the platform you are using. This guide compares Unix and Linux commands. One of the better quick-information resource guides on the Internet, it will get you up to speed on using Linux commands.

So, you have a lot of homework to do before you plunge ahead with your migration. Hit the books! In part three of this migration series, I'll try to bring it all together for you.

Kenneth Milberg is the resident Unix-to-Linux migration expert on and an independent contractor who has been working with Unix systems over 12 years. Ken has managed, configured and administered various Unix environments, most recently IBM SP Systems. He is also a board member of Unigroup of NY, the oldest Unix users group in NYC. Click here to ask him a question about migrating to Linux.

Dig Deeper on Linux servers

Running Linux on the bare metal, part 2 In your response to the person who asked you about running LINUX bare on a mainframe, it seemed to be that you politely understated the case. I know very little about Linux, but I thought running "bare" also included having to code all of your own interrupt handlers, IO drivers, etc. This alone would require almost as much effort as developing an operating system. Am I really off base here? Does Linux handle all of that stuff?

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.