Troubleshooters.Com Presents

Troubleshooting Professional Magazine

Volume 4, Issue 1, January 2000
The Revolution Spreads

Copyright (C) 1999-2000 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 ]


Contents

Editors Desk
Can you hear it in the wind?
If you're not part of the solution
Come the Revolution
Happy Y2K
The State of Troubleshooting Address
The State of Troubleshooting Professional Magazine
Linux Log
Auld Lang Syne
Letters to the Editor
How to Submit an Article
URLs Mentioned in this Issue

Editors Desk

By Steve Litt
Troubleshooting Professional Magazine turns three years old today. And we're proud that the Troubleshooting Revolution announced in our premier issue, January 1997, is pretty much a done deal. Era 2 intuitive Troubleshooting is going the way of the blacksmith. The dreaded question (troubleshooting what?) and the dreaded blank stare when you replied "anything", are quickly becoming a relic of a bygone age.

We go back a long way, you and I. Three years is a long time on the web. Maybe you are one of the original TPM readers who read the Troubleshooting zeal of the premier issue and rejoiced that finally somebody had discussed the strategy of system independent Troubleshooting. Or possibly you came in Troubleshooting Professional Magazine's dog days of late 1997 and voted for TPM to continue. Maybe your first acquaintence was one of the Open Source specific issues like May 1998, November 1998 or May and June 1999. You and I go back a long way, and you've seen Troubleshooting Professional change from pure Troubleshooting zeal to the dual audiences of Troubleshooting and Open Source. The greatest thing TPM could accomplish is to introduce these two audiences to each other.

This year's aniversary issue loudly proclaims that we will continue to serve both these fine audiences. Open Source provides a reliable platform for Era 4 Troubleshooting tools. Open Source software has the consistency necessary for systematic diagnosis. And Open Source development can benefit from the debugging advantages of conscious, consistent Troubleshooting Process.

So if you're a Troubleshooter, or if you're involved in Open Source software, this is, and will continue to be, your magazine. Enjoy.

Steve Litt can be reached at Steve Litt's email address.

Can you hear it in the wind?

By Steve Litt
It's deafening. You can't miss it. The Troubleshooting revolution has spread to twin powderkegs desktop and enterprise computing, and things will never be the same.

-----------

There was a time when the Troubleshooting revolution seemed like a local skirmish, with a few voices speaking seemingly into an empty, unlistening world. A little border dispute between the status quo believing in hit and miss Era 2 Troubleshooting, and a small band of guerillas advocating Troubleshooting as an Era 3 process. This sounds strange at the dawn of the millenium when the majority accepts Troubleshooting process as "common sense", but that's how it was when Troubleshooting Professional Magazine premiered in January 1997.

By 1999 the revolutionaries had won. But they didn't stop.

Early revolutionary Jim Roach led a large band of battle hardened veterans in the Era 4 Troubleshooting invasion. Some of todays automobile and military repairs are done with computer programs whose very foundation is Troubleshooting Process. It's an idea whose time has come, and Roach's team is bringing it on fast.

For you readers new to Troubleshooting Professional Magazine, Era 3 Troubleshooting is process based Troubleshooting, as opposed to the intuitive hit and miss Troubleshooting that preceded it. Era 4 Troubleshooting is Era 3 Troubleshooting enhanced  with automated tools, themselves built upon a valid Troubleshooting Process. Several Era 4 links appear in the URL's section of this issue of TPM.

Early revolutionary Steve Litt went a different direction, taking software giant Microsoft to task. The premise was simple: You can't fix junk. For the purpose of discussion, let's define junk as an operating system requiring daily reboots, reboots on configuration change, severely entangled components (.dll files), and generally perceived intermittent behavior. In May of 1998 Steve joined the GNU/Linux revolution, predicting the demise of Microsoft in a 5/1998 Troubleshooting Professional Magazine article called "Barbarians at the Gates". By the end of 1999 Linux had done the unthinkable -- created questions about Microsoft's survival potential in the general populace, resulting in the huge stock valuations for Linux startups in late 1999.

Now we know that victory is not over the next hill or even the mountain beyond it. The conflict is global, involving Troubleshooting, Quality, Learning, Ethics, and even Social Issues. The war is long and bloody, and just beginning. Our opponents are human resistance to change, and still-powerful vestiges of the mightiest software empire in history. We're ragged and dusty, but we're tough as nails.

Can you feel it? You see it in the trade mags and business journals. Listen carefully and you hear it in the wind. We're winning.

Steve Litt editor of Troubleshooting Professional Magazine, the documentor of the Universal Troubleshooting Process, and author of four chapters in Red Hat Linux 6 Unleashed (DNS, Samba, Python, and tcl/tk). He can be reached at Steve Litt's email address.

If you're not part of the solution

By Steve Litt
If you're not part of the solution, you're part of the problem. That 60's slogan has never been truer than it is today. It's more than a problem. It's a crisis. The Troubleshooting Crisis. Discussed in Troubleshooting Professional for three years running, it's getting worse. How can that be, when Era 3 Troubleshooting is now an accepted practice in many companies, and Era 4 Troubleshooting is making inroads?

Complexity.

Some complexity, like that in modern automobiles, brings safety and convenience. Other complexity, like that in the Windows operating system, brings instability and irreparibility.

Be part of the solution. Don't purchase, accept or work with irreparable junk. If your software requires prophylactic reboots, or requires reboots to implement a minor configuration change, or crashes on an ongoing basis, or acts intermittent, be part of the solution -- throw it out. Get good software. There's tons of it available as Open Source. It's widely documented, very supportable via email, and wide open for source code perusal.

If you're a decision maker, plan your exodus from Windows now. It needn't be a cold turkey switch. The first step is a declaration that there shall be no new Windows servers. Any new file servers are Samba on Linux, Unix or BSD. Web servers are Apache on Linux, Unix or BSD. Use Zope or PHP for quick, quality web app development. As Windows server apps obsolete, replace them with Open Source server apps.

The desktop transition can be slow. The first step is a policy *not* to upgrade proprietary apps. This is vitally important now that the state of Virginia has put the evil UCITA legislation on the fast track to passage. UCITA bans reverse engineering, thereby cutting off your escape path from proprietary data formats.

The next step is to decide on the desktop window manager and OS brand of your choice. As of this writing, I personally prefer Caldera with KDE, but that can change. GNOME on Caldera or Red Hat is also good, and there are probably other excellent choices. Pay particular attention to ease of cut and paste, a traditional weak point of Linux desktop systems. Also pay attention to bundled applets' ability to open and save files.

The next step is authoring tools. Word Processors include Star Office, Applix, Wordperfect. They're all proprietary to a greater or lesser degree, so we need to trust them not to exploit the evils of UCITA. As far as static page web authoring, Netscape Composer is excellent -- Troubleshooters.Com has used Composer since 1/1/97. Graphic authoring is accomplished with Gimp, a package often compared to Photoshop in power. Unfortunately, Gimp is very unintuitive. Someone should really write some good documentation on Gimp.

Finally, get Internet connectivity and faxing working on the Linux client. Now you have a legitimate, high productivity desktop machine that does not rely on Windows.

Now make two trusted and verified backups, and  switch over. *Do not* reformat the Windows. Keep them around for a couple months just in case you need to grab some files or revert. For Windows-created ascii files and scripts on a Samba server, you'll need to convert from Windows' crlf to Unix lf line endings after making a complete backup of the Samba share. This simple script incorporating this command will do the conversion:

#!/bin/sh

cat $1 | tr -d "\r" > $1

DO NOT run the preceding script on binary or other non-text files! You may wish to modify the script so it creates a backup of the original.

If you're like me, you see Windows as a dead-end with a long and arduous escape path, especially in light of the possible passage of UCITA in several states. It's likely Windows will soon be a career killer. Get out now while it's easy. If you're not part of today's solution, you'll be part of tommorrow's problem. And make no mistake about it -- you'll own that problem.

Steve Litt can be reached at Steve Litt's email address.

Come the Revolution

"We won't get fooled again". In their song of that name, The Who describe the futility of revolution. Futile because once the fighting is over, self-serving hacks replace the zealots and the new regime becomes as bad as the old. The plot of films and Twilight Zone adventures, it's true enough to have become part of our collective consciousness.

Remember how we rejoiced when revolutionaries Gates and Allen overthrew monopolist IBM in the early 80's? Not two decades later, we struggle to free ourselves from the yoke of Gates's empire. Meet the new boss, same as the old boss.

Microsoft is on its way out, and we'll celebrate when they've been rendered just another software company. But let's not get fooled again.

LinuxExpo in Raliegh, NC hosted many proprietarist vendors hawking costly "solutions". The Red Hat and VALinux IPO's made overnight millionaires capable of being the next boss. But where are RMS, Linus, Guido, Larry, Andrew? In the grand tradition of revolution, many revolutionaries are being bypassed. We have exactly one thing going for us -- the GNU General Public License penned by revolutionary Richard Stallman so many years ago. At least this time, if a bad guy takes over or a good guy turns bad, we can grab the source and run with it. But we must remain constantly vigilant. Power corrupts, and absolute power corrupts absolutly.

Watch Your Back

Era 4 Troubleshooting is only too easy to corrupt. It bears an uncanny resemblance to that ancient snake oil, the "expert system". Remember when expert systems were going to make technicians obsolete ?:-) They're still out there, making their little sales pitches and trapping the unwary. Learn to recognize a legitimate Era 4 product:
 
Legitimate Era 4 Troubleshooting Tool Snake Oil "Expert System"
Software incorporates valid Troubleshooting Process No Troubleshooting Process
Troubleshooting Process proudly displayed as a feature Troubleshooting Process swept under the rug
Sold as a tool, not a solution "Buy our product and your support problems are solved"
Claims to enhance the productivity of good technologists Claims to replace technologists with clerks
Used correctly, enables huge productivity gains Costly program of the month, stuck with it for years

Soon enough, the phrase "Era 4" will reach the general lexicon. And when it does, be assured snake oil salesmen will claim it as their own. Evaluate their products with the table above, and if found lacking, laugh them out of your office.

It's Not Nice to Fool Revolutionaries

As long as I'm in charge, Troubleshooters.Com will represent good process and good technology. It can't be bought, threatened or fooled into becoming a tool of dictatorships. Troubleshooters.Com will always serve as a beacon. Multiply me by thousands of revolutionaries contributing to better Troubleshooting and better software. Bogus process, products, and software cannot long stand up to us. Successions of new bosses will become old bosses, but support for the truth is immortal.

We won't get fooled again. They never fooled us in the first place.

Steve Litt became one of the first to document Era 3 Troubleshooting Process with the publication of his book "Troubleshooting: Tools, Tips and Techniques" in 1990.  His opinions and advice are actively sought by Era 4 pioneers. He can be reached at Steve Litt's email address.

Happy Y2K

By Steve Litt
In a few days we'll know. The century and milleneum change will result in one of the following:
  1. A huge sigh of relief, with Wall Street up 35% and renewed economic expansion, or
  2. A couple weeks of hassles, or
  3. Serious problems and start of a nasty recession, or
  4. Infrastructure collapse causing the worst depression in history, complete with starvation, disease, war in the streets, and a massive decline in population.
In most of the developed countries it looks like either #1 or #2, thank goodness. But we really won't know until maybe the second week of January. Even then all the data won't be in. Reciept of January statements, probably in early February, will indicate the degree of Y2K disruption or lack thereof.

Troubleshooters.Com has stayed clear of all Y2K issues because of the legal implications. It seems like everyone's trying to find someone to blame and someone to sue, instead of just owning the problem and fixing it. It's troubling when society's producers work doubletime and spend huge amounts to fix the problem, and the zero sum crowd (led by the lawyers) take the money. That is not a formula for productivity.

I will be off the net for about 36 hours starting early new years eve and extending until afternoon 1/1/2000 (assuming I have reliable electrical power and phone at that point). I'll neither receive nor answer email, nor change any web pages. I'm backing up to CD using PKWare's PKZip, and also backing up to my Linux box with smbtar. My Windows box will be powered down for the switch. I have not yet decided whether to leave my Linux boxes running, or power them down also. If my computers don't come up, I'll buy and install new motherboards. I have deferred hardware purchases specifically so I could buy them in early 2000. If for some reason I can't access my backup data, I'll backdate my computer and work with it that way, after which I'll Samba transfer it to a Y2K compliant computer.

I don't expect any of the preceding to happen. Several  months ago I forward dated my 1997 Pentium 300mhz II with Abit LX6 motherboard, and it worked perfectly, including Microsoft Word. I just want you to know Troubleshooters.Com is in for the long haul.

I have not asked Troubleshooters.Com's web host, Pacificnet in Southern California, whether they are ready for Y2K. First of all, they're a top quality outfit so I imagine they are. Nevertheless, it's theoretically possible that Troubleshooters.Com will be off the air for a few days, so please be patient. If for some reason Pacificnet cannot resolve a problem (I expect no problems), I will switch DNS for the domain and FTP Troubleshooters.Com to a different provider.

Nobody knows for sure, but Troubleshooters.Com is betting that the worst of Y2K is already behind us.

From Troubleshooting Professional Magazine to all you readers, both the original Troubleshooting Process crowd and the newer Open Source crowd, thanks for a great three years. Have a good new year. If you drink, do it in moderation and don't drive. Have lots of fun. HAPPY NEW YEAR!

Steve Litt became one of the first to document Era 3 Troubleshooting Process with the publication of his book "Troubleshooting: Tools, Tips and Techniques" in 1990.  His opinions and advice are actively sought by Era 4 pioneers. He can be reached at Steve Litt's email address.

The State of Troubleshooting Address

By Steve Litt
2000's state of Troubleshooting could be described as "the good, the bad and the ugly".

The Bad

I'm disappointed that Troubleshooting is not yet considered a profession. There are no job ads for "Troubleshooter". I've never met a person whose job title is "Troubleshooter". I find this surprising.

But perhaps I was was wrong to expect it. Troubleshooting is much more universally applicable than I believed when Troubleshooting Professional Magazine started. It's a fundimental part of the design process. Not only must all designs be debugged, but systems must be designed for reasonably easy Troubleshooting and repair. Good engineers must be good Troubleshooters, regardless of job title. As explained in my newest book, "Rapid Learning: Secret Weapon of the Successful Technologist", Troubleshooting is a fundimental component of learning. Technologists of all job titles must keep up with rapidly changing technology, and Troubleshooting is a big part.

As the millenium begins, Troubleshooting effectiveness still fails to enhance one's ability to procure a job. But of course the job market is such that technologists don't need much help in that regard. Troubleshooting's real career enhancement comes from the fact that an excellent Troubleshooter will be percieved as an excellent engineer, software developer, network administrator, or any one of thousands of other "high tech" job titles. Excellent Troubleshooters are more effective on the job, and get the more lucrative promotions.

The Ugly

It's called UCITA, and it's ugly as it gets. UCITA is a proposed uniform state law which does the following:
 
  1. Allow "Self help" for software vendors. Software vendors will legally be able to remotely shut down a client's software if the vendor believes the customer has violated the shrink-wrapped license. Imagine negociating with Microsoft for a better deal when you know they have the legal right to shut down your mission critical operations for any percieved breach of contract.
  2. No "pass alongs". You cannot sell or give away the shrink-wrapped software you buy without the software vendor's permission (oh sure they'll give you permission). Planning a merger? Remember you might need to buy all new copies of MS Office and other proprietary programs for every desktop.
  3. Gives shrink wrapped licenses a legal status. Now they're automatically enforced in court. Including limitations on the customer's ability to speak or write about the product. Did someone say First Amendment?
  4. Allows vendors to disclaim warrantees. Now we get into legalized fraud. Simply demonstrate great software, promise great software, and sell a bug-infested mess with an in-the-box license stating there's no warrantee. Bate and switch. As I read UCITA, UCITA makes this behavior legal.
  5. Outlaws reverse engineering. Once UCITA becomes law, your data can be, in effect, held hostage by the software vendor. This creates a financial incentive for Microsoft, the day UCITA is passed, to create a new .doc definition. Only now other vendors will not be able to reverse engineer it to import it. If that document is important to you, you must keep Microsoft Word forever. At any price. With any bugs. Microsoft Word is just one example -- this is true of all proprietary software.
#1 reminds me of the movie "repo man". #2 has incredible accounting implications. Do I have an asset, or don't I. Imagine deciding to change the name of your company, only to discover that you'll need to re-purchase all your software. #3 enforces a contract not signed, read, or agreed to by one party. I'm no lawyer, but it looks to me to contradict the last few hundred years of contract law. #4 legalizes fraud, plain and simple. It's likely to conflict with other law, and I'm betting the courts will throw it out. But that will take a few years, and life will be ugly until that time.

The real threat is #5. Without it UCITA would be ineffective. Here's why:

Who in their right mind would allow self help, relinquish their right to sell what they bought, agree to a contract they've never seen, or pre-agree to fraud *if they had a choice*?. The first four provisions would simply drive consumers right into the hands of Open Source vendors. So they ban reverse engineering to eliminate the alternative to repo man, empty assets, stealth contracts and fraud. Once reverse engineering is illegal, they change the data format and presto, they can hold your data for ransom. At any price. Absolute power corrupts absolutely.

The solution is clear. Do not upgrade proprietary apps. Make sure all your data stays in pre-UCITA format. That way you can import it into Open Source software any time you're ready. Make no mistake about it. If you upgrade and place your data in a post-UCITA format, the software vendor owns your company.

UCITA is the last refuge of incompetant software vendors. They couldn't win on quality. They couldn't win on "innovation", in spite of their propaganda based on the word. They couldn't win on price. They cannot win in a free and open marketplace. So they go running to the government for protection. The proprietarists, especially Microsoft, are on their way out. Can you feel it? Can you hear it in the wind? They're incapable of making reliable software, and their world is crumbling.

Don't let your world crumble with them. Get out while the getting was good. Troubleshooters.Com was a well known Windows Troubleshooting site in 1996 through 1998. But increasingly in 1999, I've responded to requests for Windows help with "I'm sorry, I can't help you". It's a Troubleshooting principle. My 1990 book "Troubleshooting: Tools, Tips and Techniques" cautions the reader "don't do dogs", and defines dogs as follows:

A dog is a machine that's difficult or impossible to repair for a reasonable price.

In that book, the causes of "dogism" are listed as:

Defective design

Because Windows is a closed source product, we cannot directly view its design. Instead we must infer its design from its performance. At the turn of the milleneum, that performance is widely percieved to be crash prone and intermittent. Some visible parts of the design are obviously defective. That huge black box called the registry, allowing every component to see and touch every other component, is a troubleshooting nightmare. Mix in .dll's from different vendors, in different directories, sometimes even on different servers, each of which can crash or more subtly effect each other, and it's a recipe for disaster. Windows' design is obviously one of monolithic entanglement.

One of a kind type unit

A major component of swift solutions is having seen the same problem, on the same system, before. The state of every Windows box is determined by its history since the last *fresh* installation. What service packs have been installed? What utilities and applications have been installed. Note that deinstallation often does not place the box in preinstallation state. Every Windows box is a one of a kind type unit.

Of course, this is true for every computer. But not to the same degree. Linux applications tend to be standalone, with minimal and well defined changes to specific text configuration files. There's no registry.

Modified unit

Few Windows computers over 2 months old are "as sold". They have gained an installation history, and many modified "preferences". They almost certainly now have .dll files that did not come with the original Windows installation diskette, and possibly some dribbleware "updates".

Once again this could be said of all systems. But once again, most systems are modular enough that addition of an app does not effect the OS itself.

The Good

For the third year running, the career outlook for Troubleshooters is rosy. Although there's still no job called "Troubleshooter", most of use who troubleshoot effectively perform well above expectation and get the perks, promotions and raises. At the tail end of the Windows era, we still have plenty of Windows related diagnostic work. Better yet, the emergence of Linux gives us a consistent system to troubleshoot, setting us process oriented people apart from those having nothing but a great memory for symptoms and workarounds. A stable OS will promote an automation explosion far beyond what we've seen so far. Anyone who can troubleshoot and has a minimal amount of self-promotion ability will find his or her paycheck bountiful.

Some Advice to Those in Tech Support

Tech support, especially first line tech support, pays abyssimally. First line tech support should be nothing but a quick (less than a year) stepping stone. If your company will not promote you to second line or to some other technology position, get a job elsewhere. There are plenty of them.

You can already troubleshoot. Simply add some design skills (that topic is discussed to some degree on Troubleshooters.Com), and maybe some business and interpersonal skills. You should be making double or triple your first line tech support pay in a very short period.

So Over All, Things Are Great

UCITA, Microsoft and the lack of a profession called "Troubleshooting" cannot begin to darken the bright prospects of Troubleshooting in the next few years. Troubleshooting is intimately involved with repair, learning, design and quality, and greatly enhances the percieved value of the technologist. Look for 2000 to be our best year ever.
Steve Litt can be reached at Steve Litt's email address.

The State of Troubleshooting Professional Magazine

By Steve Litt
Troubleshooting Professional serves two audiences, the Open Source audience and its original but smaller audience, Troubleshooting Process advocates. Classic marketing theory dictates that rather than diluting my message, I should drop my smaller audience, the Troubleshooters.

But that's not my style. TPM will continue to serve both audiences, and do it well.

1999 was a banner year for TPM. The May 1999 issue drew 21,000 readers, becoming Troubleshooters.Com's most viewed page (ahead of its home page) from 5/7/1999 through the end of May. The other TPM issues were in the top 10% of Troubleshooters.Com's pages. Email was voluminous and almost uniformly positive (except for my omission of Tim Berners-Lee, Ken Thompson, Brian Kernighan and Dennis Ritchie from the May "Heroes" issue).

Troubleshooting Professional is well in the black. It brought in writing business, including four chapters (Samba, DNS, Python and tcl/tk) in each of two books ("Red Hat Linux 6 Unleashed" and "Linux Unleashed, 4th Edition"), and lead authorship in the upcoming "Samba Unleashed". TPM was the vehicle for the successful  rollout of my new book, "Rapid Learning: Secret Weapon of the Successful Technologist), published by Troubleshooters.Com. Six more Troubleshooters.Com published books are slated for 2000. Troubleshooting Professional Magazine is now a core component of the business strategy.

You may have noticed the last four issues of 1999 were a little lean. That's a temporary condition, not a trend. In September, 1999 I began work as the main author on the book "Samba Unleashed" for MacMillan press (Sams). At present, Samba Unleashed is due out in mid April. The release date is only an estimate at this point, but there's a link in this issue's URL's section to a page giving the up to the moment release data. You can expect TPM to return to its normal content very shortly.

Troubleshooting Professional had some tense moments in late 1997, complete with a vote on whether to keep it alive. Those days are gone. TPM plans no major changes for 2000. We will continue to serve both Troubleshooting Process and Open Source audiences. Troubleshooting Professional is strong, and we're betting TPM will outlive the Windows operating system.

Steve Litt can be reached at Steve Litt's email address.

Linux Log: Linux and Troubleshooting

Linux Line is now a regular column in Troubleshooting Professional Magazine, authored by Steve Litt. Each month we'll explore a facet of Linux as it relates to that month's theme.
Think of what you've accomplished in 1999 (and in years gone by). Along with millions of other GNU/Linux users and advocates, you've given the world a stable, reliable computing alternative. That in itself is cause for celebration.

But you've done a lot more. Consider that the "The State of Troubleshooting Address" article in the January 1998 issue of Troubleshooting Professional warned of Troubleshooting difficulties caused by Windows' non-modular entanglement, especially the .dll files. This was a full three months before TPM began addressing Open Source issues. By overthrowing Microsoft, you've solved some thorny Troubleshooting problems.

Consider the economics of what you've done. Until Linux took over, more and more time was spent rebooting Windows. Windows problems were often simply lived with, because they were too difficult to fix. The cost to productivity was immense. GNU/Linux and other Open Source software enables people to quit rebooting and get to work.

Linus Torvalds, Tim Berners-Lee, Larry Wall, Guido van Rossum, Andrew, Jeremy and the gang at Samba, the Zope gang, and Richard Stallman, whose GNU General Public License made our world possible. These are some of the heroes of our age. They deserve our thanks. And while you're in a thanking mood, don't forget that guy you see in the mirror every morning. He built our world brick by brick.

More accurately, line by line.

Steve Litt can be reached at Steve Litt's email address.

Auld Lang Syne

Troubleshooting Professional has a rich history of "best story" elections being decided by a single vote, and we've once again carried on that tradition. One person voted, so by unanimous decision, this was the best story of the year:

February 1999 Troubleshooting Professional Magazine: Escalation Procedures

That same voter pegged the best TPM issue as:

April 1999 issue, The Education Revolution

Others have their own opinions. Based on reader statistics, the May 1999 issue was the most popular ever, with over 21,000 readers. Network Magazine liked the February 1999 article, When the Going Gets Tough, enough to reprint it (with my permission) in their May 1999 issue. And, as in previous years, I have my own top five favorites.

This was an interesting year, with no full length Troubleshooting short stories like 1997 winner "Gavin Gray", or 1998 winner "The Man Who Banned General Maintenance". This year the top two were pure, 100% technology, with each addressing both generic Troubleshooting with an Open Source flavor. So without further adeau, the top five (as I see them) TPM stories for 1999:
 
Article What It's About
1 The CGI Troubleshooting Toolkit
(July  1999)
A combination Troubleshooting, Open Source and application development place this 100% technical article at the top of the heap.
2 Using Semantic Nets to Model Troubleshooting's
Knowledge, part 1
(July 1999)
Marc-Henri Poget's article demonstrates how to create Semantic Nets as a preliminary step in authoring Era 4 Troubleshooting scripts.
3 Code Readability Throughout the Ages
(August 1999)
The history of application development on the road to readable code.
4 Stick Shifts and Command Lines
(March 1999)
The ulitimate use of analogy to answer Microsoft GUI propaganda.
5 Gary's Revenge
(June 1999)
Any story starting with the sentence "Gary Kildall has reached out of the grave and grabbed Bill Gates' ankle." deserves a place in the top five.

A warm thank you for a tough job well done goes out to this year's sole guest author, Marc-Henri Poget for his July 1999 article, "Using Semantic Nets to Model Troubleshooting's Knowledge, part 1".


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.

By submitting content, you give Troubleshooters.Com the non-exclusive, perpetual right to publish it on Troubleshooters.Com or any A3B3 website. Other than that, you retain the copyright and sole right to sell or give it away elsewhere. Troubleshooters.Com will acknowledge you as the author and, if you request, will display your copyright notice and/or a "reprinted by permission of author" notice. Obviously, you must be the copyright holder and must be legally able to grant us this perpetual right. We do not currently pay for articles.

Troubleshooters.Com reserves the right to edit any submission for clarity or brevity. 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):

I (your name), am submitting this article for possible publication in Troubleshooters.Com. I understand that by submitting this article I am giving the publisher, Steve Litt, perpetual license to publish this article on Troubleshooters.Com or any other A3B3 website. Other than the preceding sentence, I understand that I retain the copyright and full, complete and exclusive right to sell or give away this article. I acknowledge that Steve Litt reserves the right to edit my submission for clarity or brevity. I certify that I wrote this submission and no part of it is owned by, written by or copyrighted by others.
After that paragraph, write the title, text of the article, and a two sentence description of the author.

URLs Mentioned in this Issue