- 1 Manipulating Azure Storage Accounts Using Storage PowerShell cmdlets
- 2 Vapor IO Brings OpenDCRE to General Availability
- 3 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 4 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 5 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
Enterprise Unix Roundup: Unix Exiles in a Windows World
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.”
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.”
- Sendmail has been found to suffer from a buffer overrun that could allow attackers to run arbitrary code on affected versions.
- Fetchmail, the most venerable of mail downloading programs under Unix, appears to suffer from a vulnerability that could allow for remote denial of service attacks.
- iwconfig, a common tool for configuring wireless networks under Linux, has a bug that could allow local users to escalate their privileges.
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.