Troubleshooters.Com Presents

Troubleshooting Professional Magazine

 
Volume 6 Issue 5, May 2002
Talking About Troubleshooting: Part 2
Copyright (C) 2002 by Steve Litt. All rights reserved. Materials from guest authors copyrighted by them and licensed for perpetual use to Troubleshooting Professional Magazine. All rights reserved to the copyright holder, except for items specifically marked otherwise (certain free software source code, GNU/GPL, etc.). All material herein provided "As-Is". User assumes all risk and responsibility for any outcome.

[ Troubleshooters.Com | Back Issues ]


 
What is unsought will go undetected --  Sophocles

CONTENTS

Editor's Desk

By Steve Litt
The June 1998 Troubleshooting Professional Magazine was themed "Talking About Troubleshooting: Part 1", and promised an upcoming part 2. Years went past, and there was no 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.

Steve Litt is the author of "Troubleshooting Techniques of the Successful Technologist".  Steve can be reached at Steve Litt's email address .

It's About Process

By Steve Litt
Humans produce by following a process. It's how we work. It's how we avoid silly errors. It's how we efficiently use time and other resources. Almost any process is better than no process at all. Beyond that, the productivity of a process is determined by the process's optimization with respect to the task at hand.

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:

 
  • Confirm exact travel dates
  • Book the plane, rental car and hotel
  • List what you'll need to bring
    • Clothing
    • Personal/medicine
    • Keys/money/credit cards
    • Equipment for work
    • Phone numbers, addresses, and driving directions
  • Buy or procure what you need to bring with and don't yet have
  • List what needs to be done to the place where you're living
    • Cancel mail delivery
    • Set timed lights to come on
    • Find person to feed the cat
    • Give key to the person who will feed the cat
    • Make sure
      • All water faucets are turned off
      • Stove is turned off
      • All heaters and irons are unplugged
      • The door is locked
  • Find out when you need to reach the airport, and when you need to leave to get there at that time
  • Pack according to the list of what you need to bring
  • Pack your car or call a cab
  • Perform the tasks on your list of what needs to be done to the place where you're living
  • Go to the airport

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:

 
  • Find out
    • Scoring policies
    • Penalties for wrong guesses
    • How many questions
    • How much time
  • First answer the quick ones that you know
  • While looking at questions, find hints that will help you with other questions
  • Now answer the ones you can figure out in reasonable time
  • Now answer the ones on which you can take an educated guess
  • If no guessing penalty, guess on the rest
  • Finally, answer the extremely time consuming questions
  • Check all your answers once or twice

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?

Is there a process for troubleshooting?

Is there a process for troubleshooting? What does it cost you if:
  1. You don't prepare (attitude)?
  2. You don't make a damage control plan?
  3. You don't get a good symptom description?
  4. You don't reproduce the symptom?
  5. You don't do the general maintenance?
  6. You don't narrow with the process of elimination?
  7. You don't repair or replace the defective component?
  8. You don't test?
  9. You don't take pride?
  10. You don't prevent future occurrence?
This deserves an answer.
  1. On a tough problem, starting with an improper attitude, almost guarantees delay or failure by panic or anger.
  2. Failure to make a damage control plan increases the chance of costly mistakes or injury. If this step in the process is skipped with regularity, the result will be frequent costly mistakes, lost data, or injury on a regular basis.
  3. Failure to get a good symptom description leads to fixing the wrong problem or failure to reproduce the symptom.
  4. Failure to reproduce the symptom leads to fixing the wrong problem, failure to fix, inability to test the adequacy of your fix, and/or unfair but undefendable accusations that you made the problem worse or created new problems. Note that it's sometimes uneconomical to reproduce the symptom when faced with sparse intermittents, and in fact that's one reason why intermittents are so time consuming.
  5. Failure to do the general maintenance can make a simple fix into a long and arduous one. This is true of reproducible problems, and it's even more true of intermittents. Failure to do general maintenance can easily balloon repair time on an intermittent by a factor of 100. Note that in safety critical situations general maintenance is not appropriate, and in such cases the increased repair time is an acceptable price to pay for the safety of absolutely identifying the root cause.
  6. Failure to narrow leads to circular troubleshooting, which can be endless if the area containing the bad component is not checked. For maximum productivity, narrowing must be conducted in an efficient way:
  7. The result of failure to repair or replace the defective component are obvious.
  8. Failure to test after repair leads to non-fixes (symptom still present), unrepaired consequential damage (often the result of unrestored diagnostic strongarms), or side effect problems (the result of strongarming a symptom instead of fixing the root cause). These in turn lead to customer problems and possible investigation by agencies or the press.
  9. Failure to take pride tends to produce Troubleshooter burnout over time.
  10. Failure to prevent future occurrence increases the likelihood of future occurrence of the problem.
Perhaps now would be a good time to list the steps of the Universal Troubleshooting Process:
  1. Prepare
  2. Get a complete and accurate symptom description
  3. Make damage control plan
  4. Reproduce the symptom
  5. Do the appropriate general maintenance
  6. Narrow it down to the root cause
  7. Repair or replace the defective component
  8. Test
  9. Take pride in your solution
  10. Prevent future occurrence of this problem
Using the Universal Troubleshooting Process requires some attention and discipline, but it will skyrocket your productivity and rescue you from all sorts of potential problems.

Summary

By itself, knowledge of a subject is useless. Only when such knowledge is coupled with a process does productivity happen. Given a reasonable level of subject knowledge, the level of productivity depends on the process you follow, and how well that process is optimized to for the task at hand and the resources you have available.

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:

Luckily, process mastery is easy.

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!

Steve Litt is the author of " Troubleshooting Techniques of the Successful Technologist".  Steve can be reached at Steve Litt's email address .

Process Optimization

By Steve Litt
Almost any process is better than no process at all. Not following a process is mental anarchy and will certainly cause trouble over the long haul. But even with a process, there's still a productivity spectrum. The more your process is optimized for the task at hand and the resources you have available, the more productive you will be.

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:

 
  • List what you need to bring.
  • Pack what you need to bring.
  • Look up the driving directions.
  • Call the customer, friend or family member and let him know when to expect you.
  • Feed the dog and put him in the back yard.
  • Lock your door.
  • Start the car, check the gas gauge.
  • Drive.

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:

Almost any process is better than using no process at all. But using a process isn't enough. You must us a process that's optimized for the task at hand and the resources you have available.
Steve Litt is the author of Rapid Learning: Secret Weapon of the Successful Technologist . He can be reached at Steve Litt's email address .

The Origin of the Universal Troubleshooting Process

By Steve Litt
It started as a crutch. I had average intelligence, the attention span of a hummingbird, a memory like a sieve, and huge, clumsy hands. These are not the traits of a "natural born troubleshooter", and my productivity as an audio technician reflected that fact. So I developed a stereo repair methodology to give me a fighting chance against smarter, more focused, more agile techs with better powers of recollection.

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.

Steve Litt is the author of Rapid Learning: Secret Weapon of the Successful Technologist . He can be reached at Steve Litt's email address .

Factors of Production

By Steve Litt
When it comes to troubleshooting, there are four major factors of protection. Absolute lack of any one of them spells disaster. Beyond that, the one most deficient limits production. Here are those four factors, in no particular order: When trying to decide the most efficient way to upgrade troubleshooting productivity, the first step is to identify which of these four is the bottleneck. The most common situation is that the bottleneck is troubleshooting process:
Bottleneck analysis, tools, testpoints, tech knowledge, 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.

But don't employees learn troubleshooting process from the school of hard knocks?

Many folks, including those who are believers in "common sense", don't see a need for troubleshooting process training. After all, sooner or later everyone learns troubleshooting process in the "school of hard knocks".

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.

Steve Litt is the author of "Troubleshooting Techniques of the Successful Technologist".  Steve can be reached at Steve Litt's email address .

Process Bootstrapping and Mastery

By Steve Litt
Why would anyone not use a process to accomplish a task or activity? I see only two possible reasons:
  1. They don't understand the relationship between process and productivity
  2. They have never done this task or activity before.
In the case of #1 the solution is trivial -- the person should read this issue of Troubleshooting Professional Magazine. If you know somebody who seems not to use process well, refer them to this TPM issue. If process is really their bottleneck, they might quickly triple their productivity.

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:

  1. Observe a phenomenon or several phenomena.
  2. Formulate a hypothesis to explain the phenomena.
  3. Use of the hypothesis to predict the existence of other phenomena, or to predict quantitatively the results of new observations.
  4. Test for the accuracy of the predictions in step 3 with properly performed experiments.
If the test in step 4 fails, reobserve, reformulate, repredict, and retest...

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.

Bootstrapping a Process

When faced with a task remotely unlike anything you've ever done before, the tendency is to bumble around trying this and trying that. And that's not so bad! Experimentation is a good thing. But even experimentation benefits from process.

So when faced with an alien task, why not try something like this:

  1. Prepare
  2. Assemble an inventory of known processes that might be useful in analysis
  3. Try repeatedly decomposing the task into subtasks and subsubtasks...
  4. For parts and the whole, look for commonalties between the task and something you've done before
  5. Get assistance from people, books, websites, mailing lists and newsgroups
  6. Think and experiment
  7. Devise a tentative process for the task or a part of the task
  8. Try the tentative process
  9. Constantly improve by looping back to step 1
A few notes on the preceding process. Step 1, prepare, primarily means prepare your attitude. Squelch anger and panic. And most of all, remind yourself of the importance of process, and what you have to gain by formulating a good process.

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.

The Tao of Process

The importance of process has been illustrated throughout this TPM issue. However, telling a person "use processes in your work" is useless if the person has no idea how to formulate a process. People are not born knowing how to formulate processes. As a matter of fact, most people in their early 20's are woefully unable to formulate a process. Many are even unable to follow a process formulated by others, because, not knowing the importance of process, they insert variation on the process, or worse yet, ignore it.

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.

Steve Litt is the creator of the Universal Troubleshooting Process.  Steve can be reached at Steve Litt's email address .
^^^ Troubleshooting and Process Information above ^^^

v v v  Linux and Open Source Information below  v v v

Life After Windows: Productivity at UMENU Speed

Life After Windows is a regular Troubleshooting Professional column, by Steve Litt, bringing you observations and tips subsequent to Troubleshooters.Com's Windows to Linux conversion.
By Steve Litt
The Linux menu system just wasn't cutting it, so I decided to adapt UMENU as my menuing interface. It was more work than I expected, and the result was better than expected.

Graphical Menu Problems

Even though my Icewm desktop manager provides a very keyboarder friendly interface to the menu system, it still wasn't quite as fast as I'd like. More importantly, the Menudrake menu configuration program is slow, quirky, and as far as I can tell doesn't even support cut and paste. The menu system that ships with Linux is usable -- I've been using it for a year. But it's not quite what I want.

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:

Microsoft propaganda

I actually had a DOS menuing system in the late 80's. I'd written it for a client. And when Windows 3.0 came out, I modified my menuing system to work in a multitasking environment, and for awhile that was my Win3x menuing system. But it was a hassle to go back to the dos prompt and use. And besides that, text menus weren't the "new way". The "Windows way". Modern technologists had to "change with the times". "Windows was better".

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.

Win9X menuing system "wasn't that bad"

Perhaps if I'd migrated directly from my DOS menu to the Win9x "Start Menu" I might have noticed a productivity drop. But having used the horrid Win3x program launching methods, Win9x seemed great. So there was little pressure to roll my own menu.

Difficulty of "rolling your own"

Which leads to the question -- why did I finally roll my own when I had Linux? Was Linux's menu that much worse than Microsoft's?

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.

UMENU Challenges

UMENU 0.5.0 was completed in February 1999, but it wasn't suitable as the "Start Menu" for a power user GUI desktop. UMENU had two weaknesses that were non-issues when using it on a server, but were showstoppers in a heavily multitasking GUI environment:
  1. The Menu Definition Files were too cumbersome for use on a power-desktop menu capable of spawning over 100 commands from over 30 menus. Configurability via UMENU Menu Definition Files was as difficult as Menudrake or Windows Explorer.
  2. Then there's the challenge of getting the menu to the forground. If you need to hit repeated Alt+Tabs, or grab your mouse and click the menu application, what good is a keyboarder friendly menu? The purpose of the menu is to speed things up, not slow them down. So you must be able to get to the menu with a single keystroke.
I solved problem #1 by inventing EMDL (Easy Menu Definition Language), and creating an EMDL to UMENU MDF converter. EMDL is outline based, and is quickly editable with VimOutliner, making it MUCH quicker to configure than menus relying on Menudrake or Windows Explorer. With EMDL I was able to demonstrate that: The foreground focus problem was a little trickier. I quickly gave up the notion of having a single persistent menu and somehow keystroking it to the foreground. It's possible, but it requires some X programming I wasn't prepared to do. So instead I chose to associate the UMENU program with a single keystroke (such associations are possible on some desktop managers). Then the only remaining problem was avoiding a buildup of UMENU sessions. It was easy enough to add an argument to make UMENU terminate after spawning a program, but unfortunately in many cases the spawned program terminated right along with the menu. I gave up several times, but my fellow LEAP members kept sending ideas and encouragement. Finally, I used LEAPster Mark Alexander's parentless spawner code to reliably spawn programs that outlived the menu that spawned them. The result is that now the Ctrl+8 keystroke brings up UMENU, from which I can spawn a program just by pressing the key associated with it. A touch typist's dream -- straight from home position.

Linux Resources Used in Adapting UMENU

Linux offers some excellent resources to overcome the previously listed challenges. The resources are many, but they can be summed up with a single word -- confidence. With Linux, I was confident that I could adapt UMENU as a Linux "Start Menu", especially after asking around on the LEAP mailing list.

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:
 
Mark Alexander's Spawning Algorithm
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.

Expected UMENU Benefits

I expected two benefits: The speed and productivity are better, but not spectacularly so. The keyboarder speed is partially offset by the lack of icons. Icons make it quick to find the program you want out of a list of 10. Without icons, you find yourself taking valuable seconds searching the list. This is partially offset by familiarity, which allows your fingers to memorize the path to frequently used commands. Additionally, a keystroke menu is faster only if you don't need to drop the mouse and move to the keyboard. Bottom line, UMENU is faster than the Linux or Windows menus, but not hugely faster.

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...

Unexpected UMENU Benefits

Sometimes the best benefits are the unexpected ones. Here are some of UMENU's surprise gifts:

Less simultaneous programs

Within a few days after switching to UMENU I noticed the number of open programs had decreased. In the days of graphical menus, both in Windows and later in Linux, I'd kept 20 or more programs open in self defense. Navigating the menu took precious seconds, so it was easier to scan the taskbar for a copy of the program to be run, rather than navigate the menu. Of course this was somewhat self-limiting, because when the taskbar had over 15 items it became extremely hard to read.

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.

More keyboarding in my programs

I'm a touch typist. When dragged kicking and screaming into the Windows world in 1990, I took great pains to learn all the possible hotkeys. A touch typist can hit 10 keystrokes in the time required to reach for the mouse and move back to typing home position.

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.

Better retention of my menu system

Remember the old days of OS sponsored menus (or in Linux, window manager sponsored menus)? Every time you upgraded or reinstalled, your menus changed. And unless you were careful, your hand-crafted menu tweaks could be erased. Considering how often you needed to reinstall Windows, that was a problem.

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.

Menu portability

Remember the days of tweaking menus on your laptop, your home desktop, and your work desktop to keep the menus approximately the same? Was it a hassle? It sure was for me.

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:

Those are just a few examples. These can be set either at system boot, or if you have no control over that, on user login, or even by the script that starts UMENU.

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.

Makes various windows managers more useful

As a person who always has at least 5 apps open, I've often wondered why anyone would use a window manager whose menu requires you to click on the desktop. If you have many apps open, you can't see the desktop.

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:
 

A BIG VOTE OF CONFIDENCE goes out to those five window managers for enabling hotkeys to run arbitrary commands. That ability makes any window manager much more productive.

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.
  • Place the following in ~/.icewm/keys:

  • key "Ctrl+8" rxvt -fg yellow -e /d/bats/mm_startmenu
    where mm_startmenu starts UMENU in terminate-on-select mode.
  • Restart IceWM by logging out and in, or by clicking the restart button in IcePref
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.
  • Center click the desktop
  • Choose Customize
  • Choose Bindings, and the "Sawfish configurator" window appears
  • On the Context list, choose "Global"
  • Click the "Add" button, and the "Edit Binding" window appears
  • Click the "Grab" button, and press the Ctrl+8 key combination
  • From the "Commands" list, choose "Run shell command"
  • Notice that a field opens up for the command to run
  • Into the command field type rxvt -fg yellow -e /d/bats/mm_startmenu
  • Click the OK button on the "Edit Binding" window
  • Click the OK button on the "Sawfish configurator window
  • Ctrl+8 will now run UMENU
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
capabilities, but they come
at the price of resources.
Using Gnome on a small
memory machine, or a 
machine with a slow
processor, will slow you
down.
 

Same as Sawfish
 
  • Center click the desktop
  • Choose Customize
  • Choose Bindings, and the "Sawfish configurator" window appears
  • On the Context list, choose "Global"
  • Click the "Add" button, and the "Edit Binding" window appears
  • Click the "Grab" button, and press the Ctrl+8 key combination
  • From the "Commands" list, choose "Run shell command"
  • Notice that a field opens up for the command to run
  • Into the command field type rxvt -fg yellow -e /d/bats/mm_startmenu
  • Click the OK button on the "Key Binding" window
  • Click the OK button on the "Sawfish configurator window
  • Ctrl+8 will now run UMENU
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.
  • Right click on the desktop
  • Choose "Legacy E-Conf Tool..." from the dropdown menu
  • From the list, choose "shortcuts"
  • Click the "New" button
  • Click the "Change" button and press the "8" key
  • Choose "Ctrl" from the modifier popup list
  • Choose "Run Command" from the "Action to perform" list
  • Type rxvt -fg yellow -e /d/bats/mm_startmenu in the "options for action" field
  • Click the OK button to enable your new hotkey
fvwm2 An old, lightweight window
manager that has improved
greatly over the years.
The following is the high level plan for enabling UMENU:
  • Create ~/.fvwm/.fvwm2rc if necessary
  • Edit ~/.fvwm/.fvwm2rc to run UMENU on Ctrl+8
  • Restart fvwm2
And the following are the specifics:
  • Create ~/.fvwm/.fvwm2rc if necessary
    • CAUTION: This procedure will overwrite your existing rc file.
    • Leftclick->Setup
    • Click desired check boxes (or none at all)
    • Click "Copy Config File(s)" button
    • Click the "Restart fvwm" button
  • Edit ~/.fvwm/.fvwm2rc to run UMENU on Ctrl+8
    • Find the "some simple default key bindings:" section
    • Add the following line:
      • Key 8     A       C       exec rxvt -fg yellow -e mm_startmenu
    • Find the "AddToFunc StartFunction" section followed by lines starting with plus signs
    • Add one more plus sign line like this:
      • + I FuncFvwmFocusPolicyChange ClickToFocus
      • This line changes focus from following the mouse to clicking to focus,
      • which is necessary to use UMENU as a start menu.
    • Save and exit
  • Restart fvwm2
    • Leftclick->Exit Fvwm->Restart

The Bottom Line

Some aspects of life after Windows, such as my switch to UMENU, appear a considerable time after cutover. The more time one has in Linux, the more confidence and knowledge he or she has, and the easier it becomes to mold his or her Linux experience to meet his needs, instead of the Windows habit of suppressing needs to conform to the Windows experience.
Steve Litt is the author of the course on the Universal Troubleshooting Process.  He can be reached at Steve Litt's email address .

Linux Log: Great Computing Starts with a Great Choice of Window Managers

By Steve Litt
Which is better, KDE or Gnome? Spark of flame wars, this question is asked continuously. The very question is misleading because it implies there are only two choices. In fact, there are several Linux window managers. Here are a few of them:
 
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:

Of those four, IceWM is by far more keyboarder friendly than Sawfish and Enlightenment, and it's a little more keyboarder friendly than fvwm2. And indeed, IceWM is by far my favorite window manager. But for reasons that go far beyond what I've mentioned so far.

IceWM Benefits

From my perspective, IceWM has so many benefits that it leaves all the others in the dust. Here they are: If you're a touch typist, the only time you'll need to touch the mouse is when an app requires it. The IceWM interface can link hotkeys to any action you're likely to take, including arbitrary shell commands. Better yet, when you bring up a menu or list, you can navigate that menu or list by typing the first letter of your choice. If multiple choices have that letter, type the letter multiple times to circulate between same-lettered choices.

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.

IceWM Disadvantages

No product is perfect. IceWM has some disadvantages, some of which are simply the other side of the coin from its advantages. The taskbar that makes the CPU monitor and process icons constantly visible also subtracts screen real estate. The lightweight resource usage means that you don't have the voluminous features of KDE or Gnome (although IceWM can run all KDE and Gnome apps if you install KDE and Gnome libraries).

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).

The Other Window Managers are Also Great

All the window managers are great. Each has strengths, weaknesses and passionate followers. KDE is hugely powerful and by far the easiest for a recent convert from Windows. Gnome is also hugely powerful, includes the Gnome object model. Aesthetically, Windowmaker is a work of art, and many find it highly productive. Sawfish is elegant, clean and light, and it's extensible using a Lisp-like scripting language. Enlightenment has a remarkable feature set for a lightweight window manager. Blackbox is pure functionality, but still manages to be aesthetically pleasing. Xfce is built from the bottom up to be light, and has many adherants. Twm is your basic, generic window manager -- light and simple. fvwm2 has stood the test of time and still stands tall, with the bugs worked out, a great feature set, light resource usage, and great configurability.

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.

Gnome, or KDE?

For me, imagining life without IceWM is bleak. IceWM's keyboard friendliness, UMENU capability, CPU/Network monitors, and fast performance make it a must have. Other people feel equally passionate about their favorite window managers. So the next time somebody asks you whether you prefer KDE or Gnome, remember there are many other choices.
Steve Litt is president of Linux Enthusiasts and Professionals of Central Florida (LEAP-CF). He can be reached at Steve Litt's email address .

Letters to the Editor

All letters become the property of the publisher (Steve Litt), and may be edited for clarity or brevity. We especially welcome additions, clarifications, corrections or flames from vendors whose products have been reviewed in this magazine. We reserve the right to not publish letters we deem in bad taste (bad language, obscenity, hate, lewd, violence, etc.).
Submit letters to the editor to Steve Litt's email address, and be sure the subject reads "Letter to the Editor". We regret that we cannot return your letter, so please make a copy of it for future reference.

How to Submit an Article

We anticipate two to five articles per issue, with issues coming out monthly. We look for articles that pertain to the Troubleshooting Process, or articles on tools, equipment or systems with a Troubleshooting slant. This can be done as an essay, with humor, with a case study, or some other literary device. A Troubleshooting poem would be nice. Submissions may mention a specific product, but must be useful without the purchase of that product. Content must greatly overpower advertising. Submissions should be between 250 and 2000 words long.

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.

Why not Draft v1.0, 8 June 1999 OR LATER

The Open Publication License recommends using the word "or later" to describe the version of the license. That is unacceptable for Troubleshooting Professional Magazine because we do not know the provisions of that newer version, so it makes no sense to commit to it. We all hope later versions will be better, but there's always a chance that leadership will change. We cannot take the chance that the disclaimer of warranty will be dropped in a later version.
 

Trademarks

All trademarks are the property of their respective owners. Troubleshooters.Com (R) is a registered trademark of Steve Litt.
 

URLs Mentioned in this Issue