Defining Integration

If you think of interop as simply getting Windows and Linux to talk to each other, then you're missing the true potential of both technologies.

• By Emmett Dulaney
• 06/12/2006

To a second group of administrators, integration implies the ability for the two operating systems to communicate in a limited capacity. An example of this was the focus of the first column -- Linux clients can print to Windows-shared printers and/or Windows clients can print to Linux-shared printers. Aside from this limited interaction, the two are kept apart.

In a third group, there are administrators trying to find a platform to standardize upon. They may have both operating systems running because they need to move/migrate from one to the other. An example of this would be when Novell decided to bet the farm on Linux; not only did they purchase SuSE, but they made a mandate that all internal operations would migrate from Windows to Linux. For a while, both operating systems were running while they mapped out their migration and then implemented their plan.

All three of these do represent legitimate computing environments in which you can operate, but they all miss the true beauty of integration. The real advantage of integration only enters the picture when you realize that the us-versus-them mentality solves nothing. When you accept the fact that there are some things that Windows does better than Linux, and some things than Linux does better than Windows, then you can begin to build a computing world around both operating systems: Each doing those functions that it does best.

With the exception of this article -- which addresses solutions for administrators in the other three camps -- all Integration Station columns will be written with the intent of focusing on how to best integrate the functions of the two operating systems for optimal, long-term, performance. While I wish I could take the credit for this stance, recognition really is due to Moskowitz and Thomas Boutell's book “Windows & Linux Integration: Hands-On Solutions for a Mixed Environment.” This was the first book I am aware of to come right out and state that the center of attention should be on harmony, not a holy war, and I strongly encourage you to add it to your bookshelf.

In addition to the monthly Integration Station column, Redmond has also started a forum called Win/*Nix Interop that can be found here. The purpose of this forum is to provide a place where you can share your questions and insights as they pertain to integration. While I will try to answer questions when possible, it is my hope that many others who have been in similar situations will chime in and we can build a community around this too-often-overlooked topic.

With that out of the way, the following sections address the three groups of administrators not looking for full integration and offer some advice to each of them.

Running Separate Operating Systems
Thanks to the default networking protocol in most operating systems being TCP/IP, there is nothing particularly tricky or confusing about having multiple operating systems sharing the same networking cable. If you are doing this without intending for any level of integration, though, my only question is why?

There may be legitimate situations where they scenario is used -- such as it is necessary to segment a LAN, you must maintain a legacy system, etc. -- but for the most part there is not a great deal to be gained from this unless you fall into one of those select categories. If you are afraid to try integration for fear of it not working, I suggest you add a workstation running the minority operating system (Linux in a Windows environment, or vice-versa) and begin experimenting with it. Once you experience what can be done, it is quite likely you'll want to go further.

If you are trying to maintain a legacy system, there are a number of other ways you should consider approaching this. One method is to use VMware Workstation to run multiple operating systems on the same machine. This saves you from needing to have multiple machines when you can get by with only one and offers a great deal of benefit in the ability to use their tools to interact with -- and between -- the multiple sessions. If you are daring, and wanting to experiment a bit, you can use WINE to run Windows on top of X and Unix. Yet another approach is to use coLinux to run Linux on Windows.

Partially Integrating Windows and Linux
While integration is the focus of the Integration Station articles to come, I strongly encourage you to spend a small amount of time studying Samba – this is the service that makes integration possible. You can find documentation on the Web, but if you want something tactile in your hands, start with "The Official Samba 3 HOWTO and Reference Guide, Second Edition" edited by John H. Terpstra and Jelmer Vernooij and round it out with Samba-3 by Example, Second Edition by John H. Terpstra. Both books are in the Bruce Perens' Open Source Series and are necessary references to keep within arm's reach of your desktop.

I also recommend the Linux Hacks books from O'Reilly as they cut through the meaningless garble and get directly to the heart of the matter -- telling you how to do a task quickly. In addition to any others that might be out there, the three worth checking out are Linux Desktop Hacks and Linux Server Hacks, Volume One and Linux Server Hacks, Volume Two.

Preparing for Migration
Regardless of whether you are migrating from Windows to *Nix or *Nix to Windows, rest assured that the process will be much more complex that you first anticipated. In order for the migration to take place, you must come to understand both operating systems intimately and then run multiple test migrations to identify and minimize what will become lost or damaged.

You can find countless resources telling you that one operating system is cheaper than another, more powerful, more scalable, etc. What you need more than that, though, is an honest diatribe on what works and what does not. I wish I could point you to a single source for this, but can only encourage you to do your research and talk with others who have taken a similar path.

When you migrate from one operating system to another, you often give up the tools and utilities you have become accustomed to in one setting and have to learn the syntax of a new set. Thankfully, there are a number of ways to get around this in the *Nix/Windows world. In addition to some tools being included with SFU (mentioned in the section above), you can find a virtual glut of *Nix-inspired tools that run on Windows in two sources:

• MKS Toolkit comes in a number of flavors (for developers, system administrators, etc.), and offers a suite of utilities that will make your head spin. You can find almost every utility you loved in the *nix world and have it run in the Windows world in a similar way. The latest version of the Toolkit (9.0) works on both the 32-bit and 64-bit platforms and offers native support for multibyte/Unicode character sets.
• Cygwin offers most of what you can find in MKS if you are only looking for the suite of *Nix-like tools, but without the expense. It is a GNU project, meaning open source and essentially free of charge.

Both of these can help ease the transition from one platform to another and stave off operating system homesickness.

Coming in July...
Next month, the focus will be on Services for Unix (SFU) and why you should become familiar with this suite of tools. This set of utilities and applications is overlooked in the marketplace and holds great possibilities regardless of the level of integration you are striving for, or the type of administrator you may be.