ServersEnterprise Unix Roundup: Unix Exiles in a Windows World

Enterprise Unix Roundup: Unix Exiles in a Windows World

ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.




Last month, we briefly considered Sun’s Java Desktop System, a Linux-based desktop operating system with all the open source trimmings. At the time, we offered this forecast: “We suspect there will be much squawking and tooth-pulling before Linux desktops are widespread in many
enterprises beyond the engineer and geek pools.”

Sun hopes to bite off a chunk of Microsoft’s desktop monopoly with its Java Desktop System and StarOffice. Its success will not be about whether these products are enterprise-ready, but rather the difficulty of application and data migration. For Unix admins currently in the Windows trenches, we provide a pocket-size toolkit to make it easier to be a Unix person in a Windows world.

“The desktop” is a contentious topic. Writing about it in an “enterprise Unix” column is fraught with peril because “enterprise” is often construed to mean “server.” Something, however, has to interact with those servers, and that’s typically desktops. So we’ll give the subject a few inches to justify our comments; then we’ll drop it like hot plutonium until some time next
year.

At the core of Sun’s JDS value proposition is StarOffice, an office suite that’s been on Unix desktops for several years. Sun bought the software a few years ago, released the source code for it to the OpenOffice project, and announced it would put some
marketing and technical muscle behind it to help in the mission to push Microsoft Office off the desktop.

StarOffice/OpenOffice are good products. They’re quite good at importing and exporting Word and Excel files with all but the most involved features intact. We’ve seen OpenOffice users interact successfully with professional publishing houses, which demand the ability to tap quite a few Word features as part of their day-to-day
production flow. But as good as those suites are (and they’re practically the same product), they’re missing enough of the critical features to make them a tough proposition for organizations entrenched in Microsoft Office.

When not keeping an eye on the Unix world in plain old HTML, one ServerWatch writer spends some time providing volunteer technical support at a women’s crisis line that’s heavily invested in a reasonably current Windows setup.

When someone calls up with a problem, it’s usually an issue of a computer or program’s behavior going from “routine” to “unexpected.” Some time is spent fixing misconfigurations or correcting user error, and sometimes, something is unexplicably broken, and person on the end of the phone does his or her best to fix it. Recently, one staffer took a misbehaving Microsoft Word macro home to poke it back to working order.

The macro itself was simple enough: It parsed a document for some style
issues that the owner, a grant writer, needed to fix on a routine
basis. It handled a few dozen common changes and corrections, and it
had been written by someone who wasn’t a particularly dab hand at
macro writing. The grant writer, it should go without saying, had nothing to do with writing it. Some other friendly volunteer, much like those on the hotline, had done that for her before moving on to greener pastures.

We have a few machines running on our own private network, including a Mac, a Linux server, and a Windows desktop, and we’ve become big fans of OpenOffice during the past year, since it allows all of the systems to share files among themselves. So when the broken macro was brought to us, our first thought was to open it up in the OpenOffice word processor and test it out.

Which was, of course, flatly impossible: Even a simple Visual Basic for Apps
snippet, like a macro generated by Word, isn’t something with which OpenOffice can
cope. It can identify the macro so a simple file conversion doesn’t destroy the macro outright, but it cannot run it.

Frustrated, we complained to a friend and fellow Unix enthusiast about the
whole experience:

“How,” we wondered, “are people supposed to make
a move to a whole new office suite when their working lives are spent
dealing with ad-hoc solutions they’ve cobbled together or inherited
from someone else? We deal with this Windows stuff, and we’re completely
adrift! How do they cope? How do we get them to change?”

Our friend was entertained by the question, since it had a heavy
element of speck-noticing and sty-ignoring.

“Yeah,” he offered, “it’s not like Unix involves
a bunch of one-purpose programs designed to be tied together into
quick, ad-hoc solutions that won’t ever survive outside the Unix
ecosystem.”

Touché.

There’s much to be said about whether the Windows or Unix paradigm is “better” or worse. Windows, when the debate is confined to where to take an organization, has the benefit of being heavily established everywhere. In terms of competing desktop ecosystems, Unix users who’d like to operate within a predominately Windows world may as well be methane breathers: It’s possible for them to exist and even interact with the natives, but the process will involve a clumsy suit and moderate discomfort.

Bad science fiction metaphors aside, we’re not convinced any IS organization has the iron will and perseverance needed to look all of its users dead in the eye and tell them they’re going to have to review and rewrite or reinvent every little time-saving, ad-hoc solution they’ve come up with over the years.

For a while now, the “desktop debate” has raged around whether what the Unix world can put forward is good enough to suit Windows people. With the sorts of advances in Unix clients we’ve seen in the past few years, from the GNOME and KDE desktops, to apps like OpenOffice, to software like Ximian’s Evolution, the answer is
clearly that yes, the Unix desktop is ready for the enterprise. It’s stable, solid, usable, and relatively inexpensive. But that’s not the issue.

The issue is whether the transition will be perceived as worth it once the little things start being taken into account.

In Other News

  • Last week we reported that Sun and Fujitsu may be in talks to
    merge production of SPARC-based servers in a move that would give
    the companies control of more than 40 percent of the Unix server market.
    Since then, Fujitsu has denied any such plans.

  • SCO has once again asserted that the GNU GPL, the license
    under which Linux and much of its related software are licensed, is
    unenforceable and probably in conflict with U.S. copyright law.
    Readers will probably be relieved to note that “same
    stuff, different month”
    seems to apply here, which will
    spare them any further musing from us about the apparent paradox of a
    license grounded in established copyright law somehow violating it
    at the same time. The company has also decided to offer a free Unix
    IP license to users of its Caldera and SCO Linux products, including
    OpenLinux, eDesktop, or eServer. Finally, the company has
    reportedly announced that it will hold UnitedLinux users
    who bought the product from SCO harmless. How generous.
  • Sun
    and Symantec have partnered
    to create a new intrusion detection
    system (IDS). The 1U rack units are Sun Fire V60x’s running Solaris
    x86 and Symantec’s “ManHunt 3.0.”

Security Roundup

Tips of the Trade

Since the predicament of being a Unix person in a Windows world is our centerpiece this week, we’ll turn briefly to a few tools that make the situation easier. In particular, Cygwin, Emacs, and a little program that brings some familiar keybindings back to the desktop for Emacs fans.

Cygwin is a set of tools that provide the GNU development environment on the Windows platform. Everything from the bash shell to a working X Window environment with Window Maker are included, and it’s all
packaged up in a handy downloader/installer that handles dependencies, too. If you’re running Windows and wish you could have a taste of Unix without using ssh to get at a real Unix machine, Cygwin might fit the bill.

We’re also big fans of Emacs, and run the Win32 port daily for most of our basic HTML editing and a few other tasks. The Emacs for Win32 FAQ handles many of the questions that arise from dealing with Emacs outside of its original Unix environment. One thing it doesn’t handle, though, is the issue of how to get at Cygwin programs (like wc, which, for one thing, is handy for counting how many words we’ve gone over for the week’s column) when running Emacs. So we were excited to find a page by an Emacs devotee that details the use of an Emacs lisp that allows Emacs to recognize Cygwin paths and use its applications.

Finally, we’d like to highlight a piece of software from Japan called xkeymacs, which might be one of the happiest inventions a Unix exile on Planet Windows ever will ever find. If you’re hooked on the Emacs keybindings that run throughout much of the Unix world (and even on
Cocoa applications in OS X), xkeymacs provides them in any Windows application, including Word, Internet Explorer, or anywhere else that simple keyboard navigation takes place. There are a few issues about how it all interacts, since the total number of Emacs keys that xkeymacs emulates run into the dozens and inevitably collide with
shortcuts for some of the more complex Windows applications; however, with
a little fine-tuning it works fairly well.

Get the Free Newsletter!

Subscribe to Daily Tech Insider for top news, trends & analysis

Latest Posts

Related Stories