Migrating Once and For All
© Copyright Darrell Anderson.
(Reviewed and updated: October 31, 2006)
Introduction
People who visit this web site might think my primary operating system is Slackware/KDE. However, my primary operating system remains NT4 Workstation. I spend most of my computer time in NT4 and perform practically all of my productive work there. I have yet to fully migrate away from the proprietary world of software. Why?
A primary reason is my personal comfort zone. I have been using NT4 for many years. Officially supported or not by Microsoft is irrelevant to me when I remain productive and content with how that operating system (OS) supports my modest needs. The ancient and time-tested adage is, “If it ain’t broke then don’t fix it.” There is not a single animal species on this planet that fails to exhibit the eternal characteristic that individuals oppose unnecessary change. All living creatures tend to cling to the known when that environment provides predictability, stability, and comfort. I am no different. I challenge any reader to prove otherwise.
Although many people who visit here might find my claims challenging to believe, my NT4 Workstation setup is more stable and rock solid than any open source environment I have tried. I really do not care if people refuse to believe me. I am not a Microsoft fan-boy, but none of the native Windows products crash on my box. The only software on my NT4 system that crashes—and I add this tidbit specifically to tweak the noses of fan-boys—is Firefox (version 1.5.0.7 as of this writing). BSODs (blue screens of death) are a rare event on my box, but Firefox is the only software on my box that occasionally crashes hard enough to cause a BSOD. Firefox 1.5.0.7 does not crash as often as previous versions, but nonetheless crashes about once per week. I have considered using Opera, but for me that browser lacks a critical usability feature.
True, my stable and rock solid NT4 environment did not evolve overnight. There are several dozen, perhaps several hundred, applied tweaks through the many years that all contribute to this stability. Yet, that stability is a contributing reason why I have yet to commit psychologically to fully migrating to a free and open source software platform.
Although I am comfortable working at the command line level and do so regularly, I prefer point-and-click. I will not apologize for this attitude and preference and any fan-boy or developer who fails to grasp this simple observation about human nature does not belong in the business. Stability is important but another element in this process is usability.
Currently Slackware is the only distro that I remain comfortable with—but cautiously so. In my early days of investigating GNU/Linux I tested several distros, but I stumbled upon Slackware early enough in my efforts that I never experimented further. Unfortunately, Slackware is a two-headed beast. Low overhead and rare unapproved patching of software provides a crisp and fast operating system. However, Slackware is a bear to master because almost every configuration effort is performed at the command line or with a text editor. Additionally, the setup utility is user-hostile and not because of the ncurses design. That is the least of the problems. Nowhere in the setup process are users provided a means to correct mistakes before continuing. Lastly, automatic hardware recognition is poor at best. The setup process does little to help people configure X or basic hardware like a scroll mouse.
However, get past these obstacles and the underlying foundation of Slackware is notoriously stable. I dislike System V rc.d scripts, which Slackware does not use. After some persistent learning I more or less have matured past the two-headed monster phase. I now know my way around Slackware fairly well and I think my web site provides adequate testimony. If many people guess that I am comfortable with Slackware I would respond that they are correct. Comfortable but not in love. Nor am I a master or guru by any means. The next question then is why don’t I migrate?
Stability
First, is a confidence factor. Not with my skills—but with X and KDE. KDE simply is one cool desktop, but all of those X and KDE error messages appearing in the .xsession-errors file is a bit rattling to me. Many of the errors probably are not true errors but mere informational messages. Thus, they should not appear in a log file titled errors because that tends to disorient users. However, many of the messages probably are errors, and the volume of those messages in any one session causes me to squirm. The volume grows smaller with each release, but not sufficiently to win my confidence or eliminate my frustrations. Sadly, I notice that although old error messages tend to disappear with each release, they merely are exchanged for new and different error messages. The saga seems never-ending.
Are these errors causing my box to crash or destructive? Generally, I would say no, but on the other hand I don’t know. I’ve seen many more sigsegv errors than BSODs. Is the culprit X or KDE? I don’t know which, but the error messages lead me to believe both contribute to various instability issues.
The bottom line is I grow weary of continually having to tweak software and chase these error messages by spending hours surfing the net hoping to discover an obscure solution that resolves these immediate problems. I despise having to search bug reports, especially when until very recently I was stuck on dialup and anything I did on the web was slow.
I do not underestimate the complexity of modern software, operating systems, and desktop environments. I enjoy learning, exploring, and tinkering, but GNU/Linux is a moving target and KDE especially so. Although relatively stable, KDE developers seem generally to insist that working on the next obscure and seldom used feature is more important than fixing existing bugs. I’m not a programmer so fixing the bugs is out of my league. Currently I’m using KDE 3.5.4 and although speedier and more stable than any previous version of KDE that I have used, I still easily fill the .xsession-errors files with routine usage of KDE. Especially if I use K3B (a product I otherwise enjoy) or play various sound files. I no longer experience as many sigsegv crashes as with previous KDE versions and this is a significant step forward. However, I can create X BadWindow errors merely by starting and exiting KDE. This is discomforting.
I’m weary of the moving target analogy. When I use NT4 everything just works. That’s an observation that is challenging to overcome. Like many people, I use probably only 20% of the tools packaged with any distro. What I seek is stability with those foundational packages. True stability. I don’t care if the developers need to provide version 3.4.17 to quash bugs. I’m already using an operating system that is 10 years old but is stable as a rock. Age is meaningless to me.
Do I expect or demand perfection? No, but I expect an almost empty .xsession-errors log file at the end of the day. Many developers seem to act as though that they should stop providing patches and support after only two and occasionally three minor releases. This is nuts. Frankly, I do not need all of these new bells and whistles that seem to attract the attention of these developers.
I think part of this problem is the way the KDE maintainers package KDE. KDE is an all-or-nothing update routine. That approach is nonsense. All library files certainly will continue to improve and need updating, but they should remain backwards compatible with previous versions. However, end-users should be allowed the option to update only the specific packages or bug patches they want updated. If the Kicker is crashing then let people update only those files. And yes, prior to KDE 3.4.3, at least half the time when I exited KDE the Kicker crashed. Thankfully that nonsense now seems a distant memory. According to various reports, this Kicker-crashing problem had existed for several KDE versions. Such knowledge does not bode well to boost my confidence in KDE.
Some people suggest that I should use a different GUI. No, thank you. For me KDE is far and away the most useable GNU/Linux GUI available. All the stories about the Control Center being complex or the environment itself being bloated is hot air. KDE is the best GUI I have encountered. With other GUIs I am faced with the ancient geek-based challenge of configuring almost everything by hand. I won’t succumb to that mentality. I am not going to spend weeks and months learning obscure syntax merely to configure my desktop programs selection menu. I am not going to edit config files to produce a left-handed mouse. More importantly, I am not going down that road merely to satisfy some perverted sense of ego. I like KDE—I simply want the developers to realize that only a handful of people want the latest and greatest. Most users much more prefer stability and usability—bug patches.
Although now I possess a faster web connection, participating in the bug quashing process is futile for typical users unless one possesses the knowledge and debugging tools available to developers. Typical users possess only the ability to expose bugs. Stock distros do not include those developer options and tools, and learning how to use those tools and options for my personal satisfaction is beyond anything I want to do with computers right now. Perhaps a solution for the X and KDE people is to ask distro vendors to package their software with all the debugging tools and symbols such that at least some advanced users can learn to participate in this bug-quashing process.
Usability
Usability is just as important to me as stability. All open source software users are beta testers. I understand and accept this role, but I detest that often useful features are eliminated because of the personal whims of developers rather than listening to end-users. Historically, despite being the wonderful and lovable hacks they are, observation reveals that many software developers are not well-tuned into the concept of usability. Many developers are great at creating functional code, but not so great at creating the usable interface most typical users need. Thus, usability experts must continually nag developers into providing usable products.
A simple example is Konqueror. In browser mode I demand that the link context menu includes the option to both open a page in the foreground as the immediate active tab or in the background as an inactive tab (a direct selection opens the link in the current tab). This obvious usability feature at one time existed in Konqueror but now mysteriously is gone. No, I will not use the keyboard to augment my selection. No, I will not use the damned middle mouse button approach. The Opera developers seem to be the only browser developers who understand this simple usability option. The Firefox developers also refuse to provide this usability function. Firefox provides this same functionality but only through the wisdom of a developer providing a third party extension. The Konqueror developers (developer) refuse to restore this useful feature.
![[Image: Screen capture of the KDE Konqueror 3.1.3 context menu options.]](../images/context-menu-konq313.png)
(Konqueror 3.1.3 Context Menu)
Here’s an interesting factoid. The KDE documentation still includes a reference to the old 3.1.x context menu design! And just so the KDE people can’t send this tidbit down the Memory Hole, I have preserved the text from the current 3.5.4 Help Center. Then again, this should come as no surprise because the Konqueror Handbook was last revised September 22, 2002. Another usability issue—outdated documentation. (Yes, being a technical writer I probably could help with the sorry condition of KDE documentation, but there’s no pay and I do not possess the hardware or patience to run development versions of KDE. And with respect to the issue of pay, most if not all of the KDE developers have day jobs—don’t mix apples and oranges about “free” software.)
Consider another usability issue. Some KDE developer decided that I should be limited to only 10 files in Kate’s most recently used list. Who in blazes decided this for me? In KDE version 3.3.2 this was a user-definable option. What was wrong with the previous method of allowing users to decide this? Possibly this option remains but in a global nature. If so, then where?
![[Image: Screen capture of the KDE Kate 3.3.2 Settings options.]](../images/kate-mru-a.png)
(Kate 3.3.2)
![[Image: Screen capture of the KDE Kate 3.4.3 Settings options.]](../images/kate-mru-b.png)
(Kate 3.4.3)
Because I really do want to see KDE succeed, I’ll offer two more KDE usability issues. In KDE 3.4.3 or 3.5.4, minimize all open windows with the Show Desktop button. Then open Konqueror. Every single window opens despite being in a minimized condition. Destructive? Of course not. Distracting and frustrating? Absolutely.
Another non-destructive but completely frustrating bug is that the KFileDialog box insists upon forgetting that I have my kdeglobals configured for Detailed (list) view. Instead the dialog box routinely shows the Short View. There are additional usability bugs with 3.5.4. Who cares about the 3.5 or non-existent 4.0 versions of KDE? Just fix what already exists.
I haven’t yet begun to touch upon networking. I run a simple two-box peer-to-peer LAN and I have yet to get everything working properly. I use Samba.
I do not want to spend my time learning obscure config file options in Samba or NFS. I want to point-and-click to create and provide permanent shares and to connect. The KDE developers are catching on and providing some of these front-end tools, but typical users are left confused with all the existing terminology.
For example, in my simple two-box LAN, on one box I did not want Samba looking for any printers and I do not start the CUPS server on that box. Without starting CUPS, Samba complains with a nuisance error message to the system logs (Unable to connect to CUPS server localhost - Connection refused). How to stop those useless messages? The solution is a manual hand-tweak of the configuration file to point the printcap name option to /dev/null, but good luck if you find that documented anywhere obvious. I stumbled upon that info after a few hours of searching. From an end-user’s perspective, I don’t want to know how to hand-configure the printer output to a null device. A point-and-click interface would provide me a simple check box or radio button that would allow me to inform Samba the no printers exist. The underlying software interface should interpret that selection as assigning the printcap name to /dev/null.
While on the topic of Samba, how come all the documentation links in the Samba Web Administration Tool (SWAT) fail to open anything? Every link points to a non-existent file.
Why do I not migrate fully? Stability and usability.
A Usable Production Environment
I had hoped that after I finally reached a comfort zone with the underlying operating system environment of GNU/Linux that I then could configure a browser, email, and an office suite to complete my journey there. This has not happened.
Despite my rant about KDE, my primary challenge is the specific apps that I need personally to be productive with my computers. In Windows I use three significant programs: Firefox, Eudora, and Word 97.
Some people suggest I continue using these programs under WINE. In my journal I shared my experiences with configuring WINE, and I do not want to go down that road again. WINE is just nuts to any non-geek person. Additionally, WINE now supports only the 2.6 kernel and I remain content with the 2.4 kernel.
I thought I could resolve this dilemma by running Windows in a VNC environment, but I run NT4 at a 1280x1024 screen size and that high resolution noticeably slows VNC screen refreshes. At that resolution there is just too much data to move across the wires and VNC is too slow to be useful. And no, I’m not about to return to a lower screen resolution merely to reduce bandwidth. Besides, the native resolution of my LCD flat screen is 1280x1024.
I thought instead I could run a dual environment with a KVM switch. I have done this successfully for a while now, but continually using my primary three apps means I never migrate fully and never will. I experiment daily and continue to learn with my Slackware/KDE box, but for actual production I simply toggle to my NT4 box. Because everything there is stable and usable.
Browsers
Three primary browsers are available: Opera, Firefox, and Konqueror, none of which satisfies me as I shared elsewhere. Firefox comes the closest as far as providing me the features I desire, but only after I add more than two dozen extensions. Because I have been using Firefox in Windows for several years, I have focused on trying to maintain that same browser in GNU/Linux.
After installing Firefox in Slackware, initially I thought I had resolved all but one Firefox configuration challenge—how to share and synchronize the bookmarks file between two users on two different boxes. I’m really the only user on both boxes and naturally I want to use a common bookmarks file. There is a popular synchronizing extension available, but users must sync their bookmarks file with a master file housed at, of all things, an FTP server. That’s absurd overkill for me. I wish the extension allowed me to establish a master file on my local LAN.
I found another extension that provided what I needed. The extension installed fine in Windows and some quick testing showed the extension working, but the extension fails to install in Slackware. The installation there goes into some kind of loop and continuously replicates the firefox/extensions/tmp directory in a recursive manner.
A more significant problem remained, however. In Slackware, after installing all extensions globally—as any sensible person would do in a multi-user environment—I could get Firefox 1.07 to work only as root. I could not get Firefox to work as a normal user. Firefox remained belligerent with 1.5.0.7. Eventually I won the battle and solved the problem, but not without consuming a lot of my time. This is another prime usability example of why I never fully migrate. Chasing rabbits is not my idea of productive energy and my journal is filled with many such rabbits.
Yet even Firefox-Windows tasks me. That XUL interface continually tests my patience, even in NT4. I dislike the slow-responding XUL interface on my aging box. With several tabs open, merely trying to open the link context menu can take a full second or two instead of popping up immediately. Oh, I hear the response already—spend some money on a new box! No, thank you. My existing boxes are plenty fast enough for me and I doubt I ever will be able to type faster than these boxes respond. More importantly, the older technology means I can configure my primary box hardware to run silent. And my second box is quiet although not silent. I detest computers that sound like miniature airplanes all the time. My NT4 environment is plenty fast too. The problem is the XUL interface because all of my native Windows and KDE apps run very well. On my snappy NT4 box the Firefox XUL interface is lethargic, but the Firefox-GTK XUL interface is noticeably slower than Firefox-Windows. And why does the extensions interface box require several seconds to open, in either platform?
Firefox possesses great appeal, but I dislike GTK-based apps. GTK-based apps all are aesthetically unpleasing to me and whoever designed the common GTK file dialog boxes fails to understand usability. The KDE file dialog boxes are right on the mark. At one time there was talk of migrating Firefox to QT/KDE, but sadly, nothing happened after the initial proof-of-concept test. A Firefox that natively uses QT/KDE widgets would be a huge success. Possibly there are some unknown tweaks that will reduce my dislike for the slowness of XUL on GTK in KDE. I am willing to try if only I could find the information I need.
Because I prefer KDE as my GUI, Konqueror should be an obvious choice, but in browser mode Konqueror lacks several basic usability features that I demand. Konqueror is a wonderful file manager, but as a web browser, for me is a thorn in the side.
I have tried the newly released ad-free Opera. A nice browser that uses the QT libraries and a browser I could learn to enjoy, but as I mentioned, the browser is missing a critical usability feature that I demand in my browsing. I demand the ability to define the tab focus when I close a tab.
All of this means that with GNU/Linux I am stuck using broken browsers. No, thank you. I’ll merely using NT4 and tolerate the barely usable Firefox.
I have experimented with KMail, but one feature I demand that Eudora has provided me for many years is the ability to run from different configuration files and hence, to store the respective email in different directories. That option allows me to maintain mail in three separate directories. This is important to me because I help two other people with their email and I refuse to risk mixing my mail with their mail. I also do not want to risk sending an email for those people and I mistakenly forget to modify the default address which would be one of my personal addresses. Running from three different config files and directories avoids all of the potential mess. Yes, like Eudora I can customize KMail with several addresses and identities, but unlike Eudora all of those mails get stored in subdirectories within the same top-level directory. I won’t work that way. Three separate directories and three separate config files, please.
Yet, even if I discovered a way to configure KMail to my liking, I still have no usable browser. Thus, why would I want to power up one box to fetch my email and a different box to surf the web?
Sure, I probably could create two additional user accounts to provide me the separation I want, or possibly I could write a script to modify configuration files on the fly, but what a hassle just to check mail.
Yes, I hear the fan-boys shouting. Use Thunderbird! True, with T-Bird I can configure several profiles that would allow me to work much in the same manner I do with Eudora. I agree, but guess what? T-Bird is another XUL-based app. I know what that means. Slow. And being GTK-based, ugly. Themes can reduce some of that ugliness, but I detest GTK-based dialog boxes, especially when the KFileDialog box is so wonderfully configurable.
Without a browser that satisfies my needs and allows me to surf the way I want, I will continue the bulk of my web browsing from my NT4 box. Firefox-Windows meets those needs and desires—barely. However, without a preferred browser on my second box that satisfies my needs and desires, I possess little motivation to migrate my email from NT4. Even if I resolved my browser issues, I will not migrate my email unless I can run my email client with different config files and without the overhead of additional user accounts.
Writing
That brings me to OpenOffice. There is a lot of chest thumping going on from people involved in that project and from end-users too. I think for a good reason, but after many years of customizing my Word environment—including several templates and all of those associated macros—I never find the energy or determination to migrate. I’ve migrated word processors twice before and once professionally for a client, and such a project is a lot of work. Many users do not use templates, styles, and macros. They do not grasp the investment this means to other users. They think migrating is a piece of cake. Not true. Been there done that. That old human nature problem of appreciating my comfort zone hits me again.
This leads to the issue of productivity. I have been using Word 97 for many years, and Word 6 before that. As a technical writer I am one of those rare birds who routinely uses templates and styles. Through the years I have developed a core of templates and associated styles and macros that enhance my productivity with this one tool. I don’t have much desire to convert years of templates and macros, but I’m willing to consider the option. However, the only choice for such a migration is OpenOffice, the world’s slowest opening program and possibly the most bloated too.
I have superficially looked at KOffice to meet my needs. I admit, however, that I do not easily grasp the frame-based environment for writing. More importantly, however, the KDE developers boast that they do not provide a macro language for KOffice in order to avoid viruses. A pity. Such a disappointing excuse for not providing a macro language. As a technical writer I consider a macro language essential to producing and customizing a personal production environment.
I had OpenOffice installed on my NT4 box, thinking I could explore the software in that familiar environment. However, recently I uninstalled the software. I had tried to update to version 2.03, but the installer refuses to work on my box. So I surrendered and removed the entire bloated suite. I never did like the way in which the produce filled the registry. Yes, I can find a Slackware package of OpenOffice to install. However, I have little motivation to do so. I am happy and content with Word 97 and after years of developing my templates, and all the associated styles and macros, that product keeps me productive. If I explore OpenOffice, I will do so not out of any need, but mere curiosity. Of course, OpenOffice is notoriously slow and bloated, whereas Word 97 comparatively is compact and fast (I cannot and will not offer the same conclusion about subsequent versions of Word because I never have used them). I maintain many complicated documents in Word format, based upon those templates and styles. Frankly, through my own testing those documents do not convert well into OpenOffice 2.01. The so-called issue of the proprietary DOC file format is a non-issue for me because I can save documents using the long-existing open RTF file standard.
I depend upon Adobe Acrobat 4.0 to convert my Word files into PDF format. I don’t care that version 4.0 is considered “obsolete” by marketing shills. Rubbish. Acrobat 4.0 provides a Word template that is closed source—but works flawlessly for me. I realize that OpenOffice provides some PDF export functions, but I have not yet tested those features to see if that ability satisfies all that the Acrobat template already provides me. If not, then my recommendation to the OpenOffice developers is straightforward: evaluate how that template works and duplicate the features. No brain surgeons are required.
I want a word processor and OpenOffice Writer fits the definition, but one usability feature is dramatically missing from OpenOffice—the ability to work in text mode rather than page layout mode. In Word this is called Normal View. After I develop a template, styles, and macros, I don’t need to view my text in page layout mode because I know the page formatting foundations are already well tested. At that stage in the production process all I want to do is write. Word provides me that simple usability feature and unlike Page Layout View, Normal View is fast.
Another notable missing option is that OpenOffice uses the Single Document Interface (SDI). I prefer the Multiple Document Interface, which Word 97 provides.
Some Additional Quirks
I more or less have abandoned the idea that I soon will be using my second box in a full production environment. Of course, as a technical writer, my definition of production includes web surfing, email, and most obviously, writing.
A most unsettling problem is the sheer volume of xsession errors that appear during any KDE session. Yes, most of those errors appear to be non-destructive, but they are unsettling nonetheless and reduce my confidence in KDE. My data is too important.
Although I do not plan any time soon to use my second box as a web browsing or email platform, I still can use the box as a gateway and firewall. I have been doing this experimentally for a while now. Not that I need a separate firewall because the Kerio 2.15 firewall serves me very well in NT4. I must add here that the Kerio interface is far more easier to learn than writing crazy iptables scripts. Of course, I can continue learning more about basic networking functions using two boxes.
I intend to continue exploring and improving my administrative skills with respect to GNU/Linux, Slackware, and KDE, but I have no plans to use that environment in the same manner I now use my NT4 box. And there always is the pleasure of learning more about shell scripting, something that is so much more powerful and enjoyable than anything comparable found in Windows.
One area in which I have used KDE in a productive manner is with K3B, the CD/DVD utility. I use the tool only to burn data CDs, but the program works well and improves with each release. However, I am still waiting for the K3B developers to provide a front-end to burn bootable CDs. For example, I want to create my own stream-lined Slackware CD and then burn the bootable contents with K3B. Yes, I can learn obtuse command line syntax, but I prefer point-and-click, remember?
I hope to possibly migrate some of my HTML requirements to my second box. Quanta Plus seems like an enticing tool and Kate also provides an easy way to edit web pages. Now that I have basic networking functions between my two boxes, I can edit my web site HTML files while continuing to store the files on my NT4 box.
The KDE people also recently included (finally!) two important tools to help web development: KLinkStatus and KFileReplace. In Windows I had to continue using FrontPage 2000 (FP2K) to validate all of my links, but KLinkStatus now satisfies that need. Although originally I used FP2K to do my HTML work, I long ago stopped doing so, instead choosing to use a text editor that provides syntax highlighting. This link checking was the only reason I maintained FP2K on my box the past few years. I had hoped that now I could consider uninstalling FP2K. With KDE 3.4.3, KLinkStatus crashed on me repeatedly when checking one of my web sites, but this problem seems resolved in 3.5.4. So perhaps FP2K can be removed from my box.
For site-wide text replacements, in Windows I have been using a fine closed source product called PowerGREP, but now I should be able to use KFileReplace. However, I still need to experiment and test KFileReplace before I abandon the easy-to-use PowerGrep. My recommendation to the KFileReplace developers is the same I provided the OpenOffice developers: grab a copy of PowerGrep and duplicate the features. There is no need to reinvent the wheel.
An additional HTML challenge remains. I need the ability to validate code in a project or site-wide manner. In Windows I have been using an old version of CSE HTML Validator to validate all of my HTML code. Because currently I dabble only with HTML 4.01 Transitional, this old program continues to serve me well. Although Quanta Plus provides a Tidy interface to validate HTML code for a single page, I have not yet found a way to use Quanta Plus to validate the code in one pass for an entire project. Therefore, I wrote a short-and-sweet shell script to use Tidy to validate an entire site. Unfortunately, Tidy provides me results that conflict with CSE HTML Validator. I therefore still use CSE HTML Validator to second-check Tidy and vice-versa. Regardless, I’d like to see developed a KDE front-end to Tidy much in the same spirit as KLinkStatus and KFileReplace. That is, a front-end interface that allows me to validate an entire site/project without the overhead of opening Quanta Plus.
I’ll again raise the issue of writing. For my web site I write all of my text in Word 97 using my articles template. I then use another custom template to convert all of my text into clean HTML code. Word 97 is notoriously awful at converting text into HTML, which is why long ago I developed that additional conversion template. However, my initial research into OpenOffice Writer indicates that Writer is not so great at this conversion either. Odd, considering that the native file format is XML. Thus, I doubt I’ll be moving that aspect of my HTML work to my second box either.
Summary
I have been fiddling, toying, experimenting, and learning about GNU/Linux and KDE for more than three years. That environment continues to improve, but fails to satisfy my definition and perception of stability and usability. I have addressed additional specific stability and usability issues, such as in my wish list and my journal.
Yes, I would like to migrate. The philosophy behind free software compliments my personal philosophy about life. I actually like the way the GNU/Linux environment is designed. I do enjoy tinkering within that environment in a leisurely manner.
I admit that I am a creature of limited knowledge and that perhaps solutions exist for many of the challenges I have described. I am willing to learn, but I also have already exhausted an abnormal amount of time and personal energy surfing for solutions that I have not yet found. Therefore I think I possess standing to voice my concerns addressed here. I realize that many GNU/Linux users are command line advocates who bypass most the GUI-related issues described here, but I am unwilling to regress to the command line when my NT4 GUI is much easier to use, is rock solid stable, and is already customized to the way my mind thinks and works.
I’m frustrated. I want to migrate, but I am not going to sacrifice the ease-of-use and benign environment of NT4 Workstation. Everything there just works and is fast. I can tolerate and shrug over the modest degradation in speed I experience with KDE compared to my snappy NT4, but not usability and stability. I need a web browser that works the way I want. I need to migrate and configure my email in a manner that is usable to me. I need a way to help me migrate my Word 97 templates and macros—no small task. Perhaps I’m asking for too much. Perhaps my standards and expectations are too high.
Are any developers listening?
Finis.