Troubleshooting Professional Magazine
|
Talking About Troubleshooting: Part 2 |
|
|
Convincing people that they'll truly benefit from Troubleshooting Process is no easy matter. The suggestions in the June 1998 TPM were well laid out and logically consistent, but I don't think they were particularly persuasive. In fact, it's taken almost 4 years to think of something more persuasive. So this month's issue once again tackles the problem of truly convincing Troubleshooters, Managers, Executives, and yes, even Trainers that Troubleshooting Process is more than a program of the month or yet another self-help topic.
This issue demonstrates process as a necessity for human activity, first by demonstrating several common human activities presumed to be dependent on subject matter expertise, but which are actually dependent on the process used to energize that subject matter expertise. Once it's accepted that process is necessary, it's much easier to teach troubleshooting process.
If you're any type of technical worker, whether it's in automotives, software, computers, networking, or electronics -- read this magazine to protect and enhance your career. If you're a manager, this is a must read magazine, because this information can skyrocket your department's productivity. And if you're a trainer, what you read in this magazine can eliminate the perception that your course is merely a good source of coffee, donuts and relaxation.
Think about what you read here, and think how to verbally pass this information on to others. Your reward will be increased effectiveness personally and in those around you.
Do you believe the preceding paragraph, or does it sound like a motivational speech? Do you need more evidence? Then consider some of the tasks you've performed in your own life.
Is there a process for going on a trip? What does it cost you if you wait til the last minute to reserve the plane? What does it cost you if you forget to bring necessary prescription medicine or the piece of equipment you will be selling? What does it cost you if you forget to have someone come in and feed the cat while you're gone? Can a process help you avoid these things? Consider the following abbreviated example:
|
Do you think that using a process like the preceding might make trips go much more smoothly, profitably, and in a more relaxed manner?
On to another subject...
Is there a process for taking a test? From first grade until the we graduate college, we're evaluated and advanced by such tests. Even in the workplace our progress often depends on such tests. Have you met people who know the material cold but do poorly on tests? Could it be that all they're missing is a process for test taking? Have you met people whose test scores are much higher than their everyday performance would indicate? Could it be that they follow a process for taking a test?
When taking a test, what does it cost you if you refuse to skip an early question that counts for 1/50 of your score? What does it cost you if you refuse to guess, even when you've eliminated two of the four choices? What does it cost you if you guess permiscously, even though every wrong answer cancels a right one? What does it cost if you fail to take advantage of the fact that you can often deduce the answer to one question from the phrasing of another? Can a process help you avoid these things? Consider this abbreviated example:
|
Might a process like the preceding boost your score? Who would score better -- a person who knows the material well but doesn't follow the right process, or the person who vaguely knows the material but follows the process efficiently?
Is there a process for flying a plane? What does it cost if the pilot forgets a checklist step? Why do airlines and regulatory agencies insist that pilots go through a checklist, in spite of the fact that pilots are the most knowledgeable experts on planes and flying? Could it be to give the pilot a process by which to use his knowledge and skills?
There's a word for system expertise without process expertise. It's called "book learning". "90 day wonder". "Paper MCSE". "He's smart but has no common sense". When you hear a person described with any of these phrases, you can bet that the person is simply missing a process.
For a technologist, unleashing the potential of his knowledge requires mastery of one or more processes:
When it comes to Troubleshooting, system expertise is useless without reasonable knowledge of troubleshooting process. This is why so many supposed system experts fail so miserably at troubleshooting. This is why there's a troubleshooting crisis today. This is why car repair, appliance repair, and tech support are so fraught with errors. Troubleshooters and their bosses don't realize that the only thing holding them back is a lack of troubleshooting process knowledge. Instead, they believe the current troubleshooting crisis to represent the human condition, and have surrendered to mediocrity.
You can do better!
For instance, when taking a one day car trip, you would not follow the process described in the preceding article. Following the previously described process would take hours, and would be wholly unnecessary for a one day car trip. The process for a 1 day car trip would look more like this:
|
This process is optimized for a one day car trip. The process described in the previous article was optimized for a week long plane trip. Using the week's process for a day trip would delay you by an hour or more. Using the day process for a week's trip would likely result in errors that could ruin the trip.
In much the same way, various Troubleshooting Processes are optimized:
It worked! Within 6 months of my first experimentations with this new methodology I'd moved from the bottom 20% to the top 20% of the company's techs. Three months later I broke a regional production record.
A couple months after that I used the same methodology to repair my television, even though I'd had no training on televisions. I simply used a Sams Photofact book on TV repair to gain subject matter expertise (called the Mental Model in the UTP), and my stereo repair methodology to diagnose. Now I knew my methodology worked on any equipment.
So it was just natural that when I became a computer programmer a few years later, I used the same troubleshooting methodology. The result was predictable -- although just an apprentice programmer, I became the company's best troubleshooter. When the hardware guy with 10 years experience and the programmer with 20 years experience couldn't fix the problem, they sent me in and I fixed the problem.
As time went on, co-workers consulted me on troubleshooting. Then my techniques rubbed off on them. It was gratifying to see them succeed using the exact same techniques as me. As time progressed, my co-workers went on to critique their own troubleshooting moves using my principles, and even critique my troubleshooting moves. This was proof positive that this methodology worked universally.
So in 1990 I wrote "Troubleshooting: Tools, Tips and Techniques" and began to teach the Universal Troubleshooting Process.
Access to tools and access to test points are somewhat maleable. For instance, an expert in both troubleshooting process and system/technology can usually devise diagnostic tests compatible with whatever tools he possesses, and whatever test points are available. Unless something's truly a black box, such an expert can usually work with whatever tools and test points are available.
In practice, tools are almost never a problem. Tools are cheap compared to labor, so management typically gets the necessary tools and then some.
In practice, test point access is often a minor problem but rarely a major one. Almost invariably tools exist to make obscure testpoints easy to read. And even when such a tool isn't available, the troubleshooting process expert can usually make an appropriate tool, or else find other testpoints that will substitute for the missing ones.
In practice, system and technology expertise is rarely a problem, but is USUALLY blamed for problems in diagnosis and troubleshooting. That's because most people (even bosses and Troubleshooters) tend to lump all knowledge into the category of system and technology expertise. Few people realize that knowledge of the process of troubleshooting is totally separate (orthogonal) from knowledge of the system and technology. Therefore, most employers send their employees to yet another system and technology "advanced class" at the first sign of troubleshooting inefficiency. The bottom line is that most employees have much more than enough system and technology expertise to fix any problem.
The preceding three paragraphs describe why the troubleshooting performance bottleneck is seldom testpoints, tools, or system and technology expertise. That leaves knowledge of the process of troubleshooting, which is usually the bottleneck. It's not surprising. Gather 100 technologists and ask how many have been trained in the process of troubleshooting, and in 2002 it's likely five will raise their hands. Of the remaining 95, 50% typically have never given a thought to the process of troubleshooting.
The most obvious counterargument is to ask "how much does it cost for your junior employees to be needlessly underproductive in troubleshooting?" Whether or not these new employees will eventually learn troubleshooting process is immaterial. The fact is, for the next year or so they will underperform for lack of a 2 day course.
Furthermore, the assertion that employees will eventually learn the process of troubleshooting at work is a half truth. Some will learn it sufficiently, and some won't. And among those who do, they will learn it in varying degrees, from those who are barely able to profitably solve technical problems to those who are ninjas.
If you step back and observe your workforce, you'll see that the percentage who thoroughly learn troubleshooting process is small indeed. All for lack of a two day class.
Learning troubleshooting process in "the school of hard knocks" is a specious argument. Great basketball players don't learn in "the school of hard knocks". They have coaches from the moment they display skill. Great programmers don't learn the process of design in the school of hard knocks -- they take college courses and training courses on design process. Greatness comes not from discovering everything yourself, but from standing on the shoulders of those before you, and moving up from there.
In a world without coaches, Michael Jordan would have been the greatest, but his performance would have been that of today's typical coached college player. And uncoached Michael Jordan would have been lucky to make it to the NBA in a world of coached players.
In our current world of mostly uncoached Troubleshooters, your company's workforce can be superstars by taking a two day course in the process of troubleshooting.
Case #2 is a little tougher. How can you define a process for something you've never done? When Edison repeatedly attempted to build a lightbulb, how could he use a process when he had never successfully built a lightbulb?
Edison already had many processes to guide his way, starting with the looping 4 step process called the scientific method:
I'm sure Edison had processes for caring for his workspace, directing the work of his employees, and assembling prototypes. When Edison finally tried tungston as a filament, most of the actual assembly was probably a rote task.
So when faced with an alien task, why not try something like this:
Step 5 is actually a fairly complex process in and of itself.
Actually, all the steps are processes, but most are familiar enough and simple enough that you needn't learn them before starting.
If someone is nice enough to give you a process to use, use it. Once you're proficient at the process and understand its intricacies and reasons (the reasons are very important), you might be able to improve the process by changing a step or 2. But first work with the process until you can do it with your eyes closed.
Those of you in your 40's or above can skip the rest of this article. You know the material. You learned it the hard way. If you read this you'll be angry that nobody told you this information when you were 20. Heck, I'm angry nobody told me when I was 20. So from this point I assume I'm talking with somebody young.
Right this instant, understand that your accomplishments in every aspect of your life depend on your formulation and/or use of processes. Sports, dating, school, work, hobbies -- they all go better with process. You might not believe me. That's natural -- you have little experience with process. But I want you to believe me when I tell you process is vastly important. If you don't believe me, try this experiment. Humor me and suspend your disbelief for 1 week. During that week, try out the suggestions in this article. If your life hasn't improved at least a little in that week, call me a fraud and forget the whole thing. But just in case I'm right, give it a week.
Now that you understand the importance of process, become an observer of process. Notice the processes your coworkers use in their jobs, or your fellow students use in their studies. Ask your parents about processes they use (hint -- they may not be conscious of those processes -- some probing might be necessary). Look back on your life, and try to reconstruct the processes you used when things went right. Try to use those processes again.
Try to notice processes that are similar. For instance, you might notice that both computer programming and task planning involve decomposition. You might notice similarities between sales processes and processes used to socialize with the opposite sex.
Next, take an activity you're already fairly good at (but not excellent at), and see if you can devise a process for that activity. Because this is a first step, it's important that this process not involve other people (influencing others is a complex and challenging activity). Once the process is devised, write it down and consciously follow it. See how much your performance of the activity improves. See if you can "tweek" the process to gain extra performance.
If you've gotten this far, you've seen a concrete example of the power of process in your own life. It has probably taken a little less than a week. Now it's time to begin your studies in earnest...
Processes are like languages. The more you know, the easier it is to learn another one. So learn some easy processes. I recommend the Rapid Learning Process as the first one. The URL's section of this magazine contains a link to that process. Learn it, use it, and think about it. Then learn the Universal Troubleshooting Process. Once again, the URL is in the URL's section of this magazine. From there, go on to learn some other processes. Sales processes, design processes, perhaps even self-improvement processes. Now that you understand processes you'll be more able to discern the legitimate from the bullfeathers.
Next, do a lot of thinking about processes. You know several, you've used several. What do they have in common? What differentiates them? Which ones are more efficient? Can you improve any of them? How?
Now start formulating processes for your various tasks and activities. Write them down. Observe the increased performance, and adjust the processes for maximum performance. Enjoy your successes in athletics, business, socializing and school. And graciously accept compliments as people tell you how smart and able you are. You earned it. The easy way.
Of course that could have been said for the Win9x menu system too. That system was as slow as the Linux menu system, and although its configuration program (Windows Explorer) was a quicker and easier than Menudrake, it was no great shakes either. So why was it that in the 11 years I used Windows, I didn't replace the built-in menuing system? I see three reasons:
I believed the propaganda. We all did back in the early 1990's.
So when Win3x became Win9x, I gratefully migrated to the new "Start Menu", which seemed ultra productive. After all, it had been 4 years since I used a real, keyboarder friendly menu.
Not at all. I rolled my own because I could.
Perhaps that's too strong a statement. Knowing what I know today I could probably adapt UMENU for Windows. But the operant word is "knowing what I know today". Writing system interface software in Windows always seemed daunting. Batch files were crude, VB was crude and difficult. Perl was a good resource all too seldom used -- not enough mindshare (note -- Activestate is changing that). Worst, without open API's and the like, interfacing to the operating system was daunting.
Your mileage may vary, but in the Linux world I've found that almost any project you start can be successfully finished. I never had that feeling in the Windows world.
LEAP stands for Linux Enthusiasts And Professionals. It's the LUG serving the metro Orlando area. At last count we have 168 people on our mailing list, and our meetings usually draw 35-45 people. In other words, LEAP is a huge knowledge source.
My first question on the LEAP mailing list was how to pull a specific program to the foreground with a keystroke. The idea was to run a single persistent copy of UMENU and return to it at will. The answers came back -- it appeared that the only way to do that was to do some fairly sophisticated X programming. Given my limited time, that probably wouldn't have happened.
So I asked how to run a program with a single keystroke. The idea here was that the user hit the keystroke, operate UMENU, and after the program is spawned UMENU terminates, leaving only the spawned program. This would require an easy modification to the UMENU code. The modifications were made and the code tested.
A LEAPster told me how to associate a keystroke with the UMENU script, and I made the UMENU modification and tested the code. It worked!
Most of the time.
But sometimes, the program would not run. Testing with a sleep command indicated that when UMENU terminated, the program it spawned would terminate. This happened even if the command had an ampersand (&) at the end, putting it in the background. Putting something in the background so you can use the terminal session for something else is very different from making the program survive termination of the terminal session that spawned it.
To investigate further I removed UMENU as a variable, simply opening a terminal session, running a program (konqueror is a good example) in the background by ending with an ampersand, and then killing the spawning terminal. The instant the terminal ended, the spawned konqueror would end also. Further investigation showed that while GUI apps, such as konqueror, would tie up a terminal if run without an ampersand, some GUI apps, such as gvim, would return control to the command prompt after spawning. Apps that returned control to the command prompt always survived termination of the spawning terminal session. This later became the basis for the solution.
LEAPster Hale Pringle recommended using the nohup command.
This solved the problem with many spawned programs, but some still terminated.
One that still terminated was LyX, my one and only book authoring environment.
So for really stubborn cases like that, I let UMENU spawn gvim, which had
no problems surviving terminal termination, and had gvim spawn the intended
program. The following is the command to do this:
gvim -c "! lyx rl_recession.lyx &" -c "q"Gvim is called to spawn Lyx, after which gvim terminates ( -c "q"), leaving LyX all alone.
At that point LEAPster Mark Alexander pointed out that gvim used an algorithm that he had already posted as a solution to my problem:
|
|
use POSIX qw(setsid);
sub launch {
my(@args) = @_;
unless (fork) {
setsid; # set child process to new session
unless (fork) { # Create a grandchild
close STDIN; # close std files
close STDOUT;
close STDERR;
exec @args; # exec the x program
}
}
}
|
In Mark Alexander's own words, here's the explanation for the preceding algorithm:
| "The child that's forked first is still associated with the xterm session.
`setsid` sets it to a new session group which will also detach subsequent
children from the parent (xterm) session.
The grandchild then becomes a member of the new session and exec's the desired program. Because the grandchild outlives it's father, it will get reparented to init and will no longer be associated with the xterm process at all. So `launch('konqueror')` will launch a konqueror that survives after umenu or the xterm."f |
Once I incorporated this code into UMENU, it worked beautifully and everything fell into place.
In summary, the availablility of a Linux User Group, and Linux's availability of good programming languages, a good API, and well documented process methods, gave me the confidence to pursue and ultimately perfect this use of UMENU.
UMENU's ease of configuration is an order of magnitude better than that of any menu system I've used before, because of EMDL. My menus are structured the way I work -- not the way Bill Gates or the folks from Mandrake think I work. For the first time in my life, the majority of my daily work is easily and quickly accessible off my menu system. This ALONE made it worth the switch.
So UMENU performed exceedingly well relative to the two expected benefits! But wait -- there's more...
Now that opening a program is a two second matter I'm more willing to close programs, rather than keep them around "in case I need them". The result is less desktop clutter, and, even on my monster 2xCeleron450 with 512Meg and 100G at 7200rpm, better performance.
But as time went on I did more mousing around and less keyboarding. The problem was that the system menu kept my hands on the mouse so much that it was often easier just to acquiesce to mousery.
The opposite effect greeted me after switching to UMENU. After starting Kmail from the keyboard, it made no sense to use the mouse to check mail or reply to a message. So I learned that Ctrl+L checks mail, R replies, and Ctrl+Enter sends the message you composed. This happened in almost every app, further speeding production.
No more! UMENU makes the menu completely separate from the operating system. Using EMDL, your entire menu is a single file kept in your data tree. When you back up that file, you're backing up your menu hierarchy.
Contrast that with UMENU. To reproduce my menu system on my experimental Installfest computer, I simply copied the EMDL file, compiled to UMENU MDF, and bang -- an exact duplicate of my main computer's menu.
But perhaps the directory structure is different on the several computers. What then?
This is when environment variables come in handy. Consider the portability gains if you use the following environment variables in your EMDL file:
No discussion of menu portability is complete without mentioning roaming profiles. As you know, in the Windows world roaming profiles can enable an identical menu anywhere on the network. Isn't that better than sneakernetting an EMDL file and compiling?
Yes and no. Obviously it's better. But if the two computers are not on the same network (you're visiting the Bankok office), roaming profiles do you no good, whereas an EMDL copy and compile gets you up and running quickly. And if you're on the network, it wouldn't be hard to make a script to compile your master EMDL file for use on a given workstation. Perhaps a future UMENU will operate directly on EMDL, in which case even the compile will be unnecessary.
And yet, there's something to be said for using all the monitor square centimeters you paid for, without giving some away to a taskbar. Take the Sawfish window manager, for instance. It opens with no taskbar, no desktop icons, and no other cute geegaws. A maximized window covers the entire monitor and covers nothing. But how do you invoke a menu if you can't click the desktop?
With a keystroke of course. Most window managers allow you to associate
a hotkey with the system menu. A few go one further and allow you to associate
a hotkey with an arbitrary shell command. By making that shell command
a script that runs a non-persistent UMENU session, you can use UMENU as
your start menu. Easy menu access and full screen apps -- the best of both
worlds. So far I've discovered how to link a hotkey to an arbitrary shell
command for five window managers:
Before describing how to integrate UMENU into these five window managers, here's a script called mm_startmenu (keep it on the path -- maybe /usr/local/bin) to run UMENU in a non-persistent way such that it will terminate after the user chooses a menu item:
#!/bin/bash cd ~/umenu/program ./umenu.pl --terminate s |
The following table explains how to set each of the preceding window managers to run the mm_startmenu script in an rxvt terminal when Ctrl+F8 is pressed:
| Window
manager |
Features | How to enable UMENU |
| Icewm | Lightly featured, seriously
configurable. Menus accessible through a start button on the task bar, which can be invoked by a keystroke. All menus and window lists are extremely keyboard friendly. In my opinion this is the most keyboard friendly window manager around. |
key "Ctrl+8" rxvt -fg yellow -e /d/bats/mm_startmenu where mm_startmenu starts UMENU in terminate-on-select mode. |
| Sawfish | Sawfish is a minimalist,
"empty screen" window manager whose windows still manage to look good and have all the features. Menus are invoked by middle-clicking on the desktop. Menus and window lists can also be invoked with keystrokes that you configure, but such menus are not as keyboard friendly as you might like. |
|
| Gnome | Gnome is a huge and
capable desktop environment. That means it is a window manager and more. In fact, most modern implementations of Gnome use Sawfish for the Window manager duties. So the same process UMENU enables both Sawfish and Gnome. Gnome has incredible
|
Same as Sawfish
|
| Enlightenment | This is a very feature-filled
window manager, with audio help and good hotkey configuration. It seems faster than Gnome and KDE. Menus accessible through clicking on desktop. |
|
| fvwm2 | An old, lightweight window
manager that has improved greatly over the years. |
The following is the high level plan for enabling UMENU:
|
| Window
Manager |
User
interface type |
Taskbar
adornments |
Desktop
adornments |
Resource
usage |
UMENU-
ready? |
Aesthetics | Comment |
| KDE | Taskbar &
Startmenu |
Numerous | Numerous | Heavy | ? | Pretty &
crowded |
Most common.
Windows-like interface. Heavily featured. |
| Gnome | Taskbar &
Startmenu |
Numerous | Numerous | Heavy | Yes | Pretty &
crowded |
Heavily featured.
Gnome Object model. |
| Enlightenment | Click
Desktop |
n/a | Numerous | Light to
Moderate |
Yes | Good looking | Heavily featured.
Well integrated sound. |
| Sawfish | Click
Desktop |
n/a | None | Light | Yes | Tastefully
simple |
Clean and simple interface. |
| Icewm | Taskbar &
Startmenu |
CPU and
network usage monitors |
None | Light | Yes | Gaudy | Windows-like interface.
Very keyboard friendly. CPU & Net monitors on taskbar. Highly productive. |
| BlackBox | Toolbar,
Click Desktop for menus |
n/a | Toolbar | Light | ? | Tastefully
simple to the point of elegance |
Very well liked. |
| WindowMaker | Click
Desktop |
n/a | Paper clip,
desktop app icons |
Light | ? | Tastefully
simple, clean and good looking |
An entirely different user interface.
Excellent aesthetics. Good productivity for those not opening lots of windows. |
| XFce | Menubar
Cannot click desktop |
n/a | None | Light | ? | Gaudy | An acquired taste. |
| twm | Click
Desktop |
n/a | None | Light | ? | Barebones | A barebones window manager. |
| fvwm2 | Click
Desktop |
n/a | Configurable | Light | Yes | Configurable | An old friend from
the days of Red Hat 5x. Very configurable. Keyboard friendly days. |
Looking at the preceding chart, it's obvious that each window manager has its good and bad points, and that none has a distinct advantage. That doesn't stop most Linux users from passionately embracing their favorite.
KDE and Gnome have every feature you can imagine, and quite a few that you can't. Does that mean they're the best window managers? For some, yes. But not for me. Gnome and KDE were, in my opinion, designed to lure the Windows user. And they're great at that. Many Windows users have seen KDE or Gnome and switched to Linux. I used KDE for a long time. But eventually, some folks come to believe that "point and click" is a nonproductive paradigm invented by marketing types to lure people away from DOS, and that there are more efficient ways to work.
Additionally, KDE and Gnome are some serious resource consumers. My dual 450 Celeron with 512MB and 80GB run them just fine, but on my Celeron 333 with 512MB and 8GB they're slow, and on my son's 150 Pentium with 96MB and a couple GB at 5400 RPM, Gnome or KDE takes several minutes to load, and slows down the machine even after initial loading.
And even on the snappiest of machines, things are snappier when you use a lightweight window manager. Unless you really need the features, why tie a ball and chain to your computer.
You might think that all the light window managers are roughly equivalent. That's not necessarily true -- they all have different features.
In my case, another way to narrow it down is by UMENU compatibility. My research indicates that 4 of the lightweight window managers can use UMENU as a start menu:
The CPU monitor is IceWM's answer to that silly Windows hour glass. The hour glass was never accurate because it required the application programmer to set the cursor type, and somehow the programmers never did it right. The hourglass always popped up at confusingly unexpected moments, and failed to pop up when an app was silently processing, leading you to wonder whether the computer had "hung". With the CPU monitor, you glance right after clicking something, and you can instantly see whether the computer "heard your request". As you gain more experience you can interpret various monitor signatures as an ordinary invocation of a specific program, and you begin to know the symptoms of a hung process or a blown load. Because the CPU monitor is right on the taskbar, there's no need to move it around, and it's never buried under an app. The taskbar-mounted CPU monitor is far superior to the hourglass, and it's an IceWM exclusive.
The taskbar-mounted network monitor is equally valuable when moving files around the network, or when surfing the net through a network connection to IPCop or any other firewall. You can interpret it just like you used to interpret those little green modem lights on your Windows 9x box. You know, the modem lights that were no longer available when you switched to connecting via LAN to a firewall.
If you've used Windows 9x or greater, you'll instantly understand IceWM's user interface. It's a taskbar with start button, just like Windows (and KDE and Gnome). IceWM has many "themes". Most are gaudy and bizarre -- the kind of interface you wouldn't want your clients seeing you use. But in private, just for fun I sometimes switch to the "ultracute" theme, which looks like something designed by a style-challenged 10 year old science fiction fan. Or "E15", which would fit right in with a 1950's cafe. But mostly I use either "William3", or "Win95". Both have an Windows-like interface (and lets face it, Windows had a pleasing interface), and both also have large title bar buttons for easy sizing or closing.
Sometimes I use the "Blue Plastic" theme, perhaps the most aesthetically pleasing, but it has small round titlebar buttons that are harder to click. A funny story. The first time I saw Windows XT, I said "hey, that's the IceWM Blue Plastic theme". But I don't think the Blue Plastic makers "knocked off" Windows XT, because I was using Blue Plastic long before XT came to market.
The bottom line is that IceWM makes Linux much quicker, easier, and more pleasant. I wouldn't want to use Linux without IceWM.
On a minor note, most IceWM themes are gaudy and do not project a professional image. Even the most professional themes, Win95, William3, and BluePlastic, are not up to the same aesthetic standards as Gnome and Windows, and certainly not as elegant as KDE. But aesthetics are minor -- good enough is good enough.
The only real problems with IceWM are difficulty of icon managment and a focus bug. Many programs appear with the generic red X on the taskbar, and it's difficult to change this. This is less of a problem with newer versions of IceWM. The focus bug manifests itself as an inability to type onto the window with focus after alt-tabbing to that window. To type onto the window you need to click its taskbar icon twice, after which you can type onto the window. This is an intermittent bug, and it occurs less with the newer versions (it's rare with the IceWM version 1.0.9-2 that's bundled with Mandrake 8.2).
Gnome, Sawfish, IceWM, Enlightenment and fvwm2 can associate hotkeys with arbitrary shell commands, and thus are UMENU compatible. Windowmaker, Sawfish, Blackbox, Xfce, Twm, IceWM and fvwm2 are light weight, and can be used on old, underpowered machines.
Any article submitted to Troubleshooting Professional Magazine must be licensed with the Open Publication License, which you can view at http://opencontent.org/openpub/. At your option you may elect the option to prohibit substantive modifications. However, in order to publish your article in Troubleshooting Professional Magazine, you must decline the option to prohibit commercial use, because Troubleshooting Professional Magazine is a commercial publication.
Obviously, you must be the copyright holder and must be legally able to so license the article. We do not currently pay for articles.
Troubleshooters.Com reserves the right to edit any submission for clarity or brevity, within the scope of the Open Publication License. If you elect to prohibit substantive modifications, we may elect to place editors notes outside of your material, or reject the submission, or send it back for modification. Any published article will include a two sentence description of the author, a hypertext link to his or her email, and a phone number if desired. Upon request, we will include a hypertext link, at the end of the magazine issue, to the author's website, providing that website meets the Troubleshooters.Com criteria for links and that the author's website first links to Troubleshooters.Com. Authors: please understand we can't place hyperlinks inside articles. If we did, only the first article would be read, and we can't place every article first.
Submissions should be emailed to Steve Litt's email address, with subject line Article Submission. The first paragraph of your message should read as follows (unless other arrangements are previously made in writing):
Copyright (c) 2001 by <your name>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, version Draft v1.0, 8 June 1999 (Available at http://www.troubleshooters.com/openpub04.txt/ (wordwrapped for readability at http://www.troubleshooters.com/openpub04_wrapped.txt). The latest version is presently available at http://www.opencontent.org/openpub/).
Open Publication License Option A [ is | is not] elected, so this document [may | may not] be modified. Option B is not elected, so this material may be published for commercial purposes.
After that paragraph, write the title, text of the article, and a two sentence description of the author.