Author: Whil Hentzen
My path to this decision didn’t follow the usual “choice, freedom, security” spiel that you hear from most people. To be sure, those reasons initially prompted me to look for alternatives. The big virus outbreaks of 2001 — Code Red, Nimda, and Klez — escalated the frustration that began with the usual complaints of blue screens, rising prices, and licensing requirements.
When I started looking at Linux in early 2002 and discovered OpenOffice.org, I realized that it was only a matter of time before Linux started making inroads on the desktop. And as more and more desktops began running Linux, those users would be needing custom database applications — just as they had asked for these on Windows over the last decade.
Combined with the lack of attention that Microsoft paid to my bread and butter, Visual FoxPro, the potential new market for developing custom software on Linux desktops spelled opportunity. That’s the real reason I started moving to Linux. I like growing markets, not shrinking ones, and the VFP market had been contracting for years. At the same time, I figured it was going to be several years before demand started showing up, and those years would be the head start I needed to get up to speed and comfortable with Linux.
Which comes first – the server or the desktop?
In most of the stories of migrations to Linux that I’ve read, the author starts out with the tip to move a server to Linux first, particularly if there’s a possibility of resistance from management. Migrating the boxes that run the business, but are invisible in terms of users, is an excellent way to sneak Linux in by the back door. Then, when management later asks about this “Linux thing,” you can proudly say, “Hey, been there, done that, and haven’t had any problems, have we?”
Well, that’s one approach. The problem with it is two-fold. First, it requires you to go behind management’s back, which doesn’t set well with some executive types. But even if you’re at a company where that behavior is tolerated (or encouraged), the second, and larger, problem is that this approach requires a fair amount of know-how. If you’re migrating a mission-critical server and you mess something up while coming up to speed, you can impact a lot of people in a terrible way.
A more reasonable approach for some organizations — and the one that I took — is to start at the desktop, moving the machines that people use during the day to Linux, and connecting them to the existing Windows server. Once they’re in place, use your newfound Linux expertise to start migrating servers.
This approach has several requirements of its own, of course. First, since your migration plan is immediately visible, you need explicit backing of management. Second, you need to make sure that you can find Linux equivalents for all the applications your users run under Windows. And, third, while you’re not supporting a mission-critical server conversion, you’ll still be supporting users who will have varying needs when presented with a new OS and associated applications.
Since I was the boss, I didn’t have problems convincing management. I handled the second requirement by being the guinea pig myself — converting my own desktop first, and seeing what problems I ran into, and making sure we could find equivalents on Linux for all of our Windows apps. Somewhat surprisingly, I was asked for a lot less support than I was expecting; once a user has learning how to move from Windows 3.1 to Windows 95 to Windows XP (and the associated versions of Office and other common applications), moving from Windows to Red Hat or SUSE and the related open source apps isn’t much more difficult.
The conversion process
After I got comfortable with one function under Linux, say, Web browsing, I started using my Linux client for a second function, such as email or word processing. I wasn’t in a big hurry to switch over, so I started with Red Hat 7.0 back in late 2002, and worked my way through 8.0 and 9.0, as well as the desktop successor, Fedora Core 1. I also experimented with a couple of other distributions, including SUSE and Debian. I found that I preferred the Red Hat product line — purely a matter of personal preference.
Except for a specialized database application I was running on a Windows computer that sat on my credenza, I had completely moved to Linux on my desktop by the spring of 2003, to the point that when I traveled, I brought only a Linux notebook with me. That signaled the turning point — I started migrating each of our users’ desktops to Linux as well. By the end of 2003, all of the users here were running either Red Hat 9.0, SUSE 8.0, or Fedora Core 1.
There were three specific technical tasks involved in the conversion of the desktops. First was to identify applications that individual users were running on their desktops. An office suite, an email client, graphics viewing and manipulation, Web browsing, and music CD playing and ripping turned out to be all of the important applications. A stock Fedora Core or SUSE distribution has one or more replacements for each of these.
Our users immediately picked up OpenOffice.org. They use Microsoft Office file formats when exchanging data with folks outside the company, but have begun using the openly defined OpenOffice.org file formats internally. Other applications that replaced their Windows counterparts include KMail and Evolution for email, The GIMP and GQView for graphics, Mozilla and Konqueror for Web browsing and file directory management, and XMMS and Grip for music CD functionality.
The second function was to identify internal data conversion requirements and potential problems. This turned out to be a breeze — much of our data was in openly documented file formats. Microsoft Office’s file formats, of course, are proprietary, but OpenOffice.org read and writes them rather well. Sure, there are occasional hiccups, but no worse than we’ve run into between various releases of Microsoft Office itself. Microsoft makes the export of Outlook files a nuisance, but I had been archiving our mail to a separate program for a couple of years, so our data was already in shape to be imported.
The other big headache was converting music files from the proprietary MP3 format to Ogg Vorbis’s file format, but that was easily accomplished by simply ripping the CDs again. All other data — graphics, Web pages, and the like — was already usable by open source tools.
The third function was to determine if we were going to get hung up with exchanging data with outside entities. As with internal data conversion, this step turned out to be a non-issue. OpenOffice.org reads Microsoft Office files with ease, although we’re finding more and more people are sending files in Adobe .PDF format, which is also readable by a variety of open source tools that come standard with popular distributions. And the graphical images that we exchange are also platform-independent.
I was a little surprised that things came so easily. You can hardly swing a mouse by its tail without hearing someone complain that Linux isn’t ready for the desktop, and I was expecting to spend more time looking for answers. I guess with a large enough population, there will always be a few situations that just won’t work, just as you’ll find the occasional lemon in an auto dealership. But between joining the local Linux user group and subscribing to a couple of mailing lists, such as Fedora Core and OpenOffice.org (and searching their archives on occasion), I was able to get answers to my occasional questions easier than when I was confronted with similar problems on the Windows platform.
The downside of being the boss and being responsible for the technical work behind migration was that there are only 25 hours in each day, so my projects don’t always get done on time. Our next project is to migrate our file server and domain management functions from an aging NT 4.0 box to a Linux server. I’ve done the heavy lifting in terms of building a test network with the new server and a test workstation; all that remains is deciding whether to use the server as a domain controller as well as a file server.
Conclusion
The Linux desktop is remarkably mature and extremely stable. There are still areas that need to be addressed; the occasional hardware driver or software application glitch still wastes an hour here and there. But in the big picture, the time investment spent on these single items compares favorably with the ongoing time requirements needed to maintain Windows installations, with continual patches and updates of the operating system, applications, and security tools. Functionality for mainstream tasks under Linux compares well with the capabilities of Windows systems. All in all, we’re well-positioned to run the company on Linux, and are now well prepared to investigate the development of custom software on Linux.
Whil Hentzen is the president of Hentzenwerke Corp., a custom applications development firm, and Hentzenwerke Publishing, a Milwaukee-based publisher that specializes in titles covering software development and, more recently, the migration of Windows developers and users to Linux.
Category:
- Open Source
