When one visits the Hancom web page, there is the opportunity to download the entire suite or any application from it or combination thereof. I selected the whole shebang. In due course it had arrived, a tarball that when opened rendered several directories -- one containing rpms for each of the applications, of the files common to the applications, and of TrueType typefaces; one containing libraries, one containing internationalization stuff, one ominously labeled /lib.bak, and one containing the bitmap graphics used in the splash screens and so on, all of which were .bmp format. In the toplevel directory there are an install script that points to an install binary also there and a readme file that deals mostly with the installation of additional typefaces.

The install binary, which at a little under a meg chiefly allows the user to select the destination directory, but also allows one to select which applications are to be installed, must be run as root. So I sued root and ran it, to learn that I needed to go back and add localhost to the xhost list. Which I did, went back to root, and tried again.

The installation was quick and trouble-free and even added a KMenu item that when clicked opened a little bar of icons, reminiscent of the one that Applixware puts on the desktop. And the installation also generated an uninstall script (has UnWise been WINE ported to Linux, too?) in the directory containing the opened archive.

I took a little look around the apps, noting the problem with the paint program, yawning at the spreadsheet and presentation program, and sighing at the word processor. I imported a few files into it -- HTML and Winword -- and they came through okay, but they were uncomplicated. I typed a little in it, changed typefaces and sizes, stretched the window unsuccessfully hoping to find a way to make the screen fonts palatable.

Thinking that I would return to it later, I closed it after an hour or so. I was overdue in my weekly build of the KDE2 CVS tree, to see what new and amazing things had come to pass in the preceding week. Imagine my chagrin when the very first package, kdesupport, would not make it through configure because, it told me, I did not have qt-2.2.2 or better installed. In that I've been using qt-2.2.3 since the day it was released, this surprised me.

I wish that I could say that I responded with cool scientific calm and conducted a thorough autopsy before undertaking what turned out to be 24 hours of system rebuilding. And I might have but for the second thing that happened.

When I build a new KDE, I build kdesupport, the first package, in a Konsole window, dumping out of X for make install and for construction of the other packages. So I was still in X, and one of the XScreenSaver kicked in. I had only days before somehow managed to get GL to work really quickly there, with the smoothest animation I'd ever seen. It was now back to about four frames per second in the GL gears screensaver module. Ugh.

That would have to be tended to later. I dumped out of X, went to my qt-2.2.3 directory, typed make clean, and started a rebuild. I build openGL support into qt; I know it's not necessary, but I have heard no good reason not to. The build blew up because the GL libs were looking for glibc-2.0. I have glibc-2.2. Now what?

I looked at the Hancom lib directory. It had brought its own libGL along with it, as well as its own libqt.so.2. (At this point I should have looked at /etc/ld.so.conf to see what atrocities had been committed there, but I didn't. The installation shell script tells me that it dumped new GL libs into /lib and ran /sbin/ldconfig with the output to /dev/null. The GL situation is already bad enough without new players joining the game. So I nuked everything GL or Mesa from the entire machine and then rebuilt XFree86-4.02 and installed it. Now qt-2.2.3 would build. But I got the same error from kdesupport.

Having just about had it, I ran the Hancom uninstall script which uninstalled, among other things, itself, so I cannot look back now to see whether it was its qt-so.1 or its qt-so.2 that it threw in front of my qt. (Had HancomOffice been worth the trouble, free, or both, it would probably have been easy to change some things in ld.so.conf so as to produce peaceful coexistence. But it met none of those criteria in my estimation, and didn't meet two of the three in anybody's estimation.)

Now kdesupport, and the rest of the KDE CVS tree, built. My beloved GL screensavers were faster than even their designers could have imagined they'd be.

Before I rip into the Hancom people for acting as if they're the designers of cheap sailboat simulators for 1980s DOS (which I plan to get around to doing), it's to be noted that this isn't the first time we've encountered this kind of problem. Does anyone here remember glibc-2.07 and StarOffice 4.0? For those who don't, there was a period about three years ago when there were a dozen different glibc-2.07s out there, all incompatible, there being no official glibc-2.07. Red Hat shipped one with its distribution 5.1, and StarOffice built 4.0 against another one. When the two collided, there was trouble. Some distributions built elaborate and sometimes but not always successful wrappers around StarOffice and its glibc, insulating it from the rest of Linux and vice versa. But it was a messy time, though the only think I know of that StarOffice broke was StarOffice.

Commercial applications (and some freeware that employs libraries not likely to be used by anything else) often statically compile their binaries. To oversimplify, this means that the libraries are compiled right into the applications themselves -- no need to go to dynamically loaded libraries, often called shared libraries (and in Windows called dlls). Shared libraries are often used by multiple applications, which matters on a multitasking operating system in that they only have to be stored once and often only have to be loaded once into memory. If you are using libraries that are shared by your desktop, say, then both loading and execution will be faster. Apparently the Hancom people decided to share libraries among their respective, freestanding applications. But this is at best only a half-fast solution. Here's why: like the developers of that miserable little sailboat program, they failed to take into account the possibility that potential users are doing anything else with their computers; in the Hancom case, that those users have KDE as their desktops. This is a very foolish assumption when you're building Linux applications.

It would have been a simple thing to have their little install application look first to see if qt-2.2.x was already installed (likewise the GL libraries; it's beyond me why an office suite needs 3-D rendering anyway), and if the needed libs were found, to forget overwriting them or dumping something else in front of them in the pecking order. Nor in the case of QT is this breaking new ground: it's already well documented that KDE-1.x applications, that require qt-1.x, can be made to work with KDE2, which uses qt-2.2 or better. At this very moment I have qt-1.44 installed along with qt-2.2.3, and nothing complains. A programmer who cannot pull off this simple task does not inspire confidence in more complicated areas.

I'm in no way philosophically opposed to commercial software. I have bought-and-paid-for WordPerfect and Applix on my machine, and when it's released I expect to pay for Opera. But I'm very much opposed to lousy software, commercial or free, and I'm sad to say that HancomOffice 1.0 at present falls into that category. I certainly would not pay $100 for it, though there was a time I would have paid $100 to have my machine restored to its pre-Hancom condition.

« Back: First, Do No Harm