Troubleshooters.Com Presents

Troubleshooting Professional Magazine

Volume 5 Issue 10, October 2001
Troubleshooting with the New Support Models
Copyright (C) 2001 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 ]

Everything comes to him who hustles while
  he waits -- Thomas Edison


Editor's Desk

By Steve Litt
"Your wait will be approximately eighteen minutes. Your call is important to us. Please have your credit card ready."

That kind of treatment never sat well with me. What's worse, after giving your credit card number, all too often you are confronted with someone no more knowledgeable than yourself. But all too often he thought he was more knowledgeable.

Now there are alternatives. For most techologies there are grassroots mailing lists and newsgroups. You can email a question, and often get an answer within 2 to 72 hours. You might even receive an answer or tip from the author of the software. Sure -- 72 hour support isn't realtime, but how often did supposedly realtime or 4 hour guaranteed support really solve the problem in less than 72 hours?

This month's Life After Windows article provides a compelling example of the new support models. This article speaks to a far wider audience than Open Source users and advocates. Please remember there's nothing stopping you from using those support models, usually associated with Open Source, for troubleshooting proprietary software.

This issue of Troubleshooting Professional explores the new world of troubleshooting with the new support models. You may find that using its information boosts your troubleshooting productivity considerably. So kick back, relax, and read this magazine. And remember, if you're a Troubleshooter or Technologist, this is your magazine. Enjoy!

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

Life After Windows: The Day I Almost Went Back to Windows

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.
Friday, August 31, 2001 was the day I almost went back to Windows. I had concluded I could not write books without Microsoft Word. The only thing that kept me from defecting was the rationale that compelled me to switch to Linux in the first place -- that now age old question, "who owns your data". I did not want to be in a position of needing to ask Bill Gates for permission to view my own data. But if there was no decent Linux software to write a book, what could I do? I needed to write my new book on troubleshooting, and LyX, the only software that could reasonably compete with MS Word in the book writing arena, had shown a fatal flaw.

The flaw was simple enough to describe. When printing a document containing a .eps graphic, all subsequent pages overprinted the first .eps graphic. It's not actually a LyX problem, because it occurred in Abiword, StarOffice, and any other file format into which I inserted a .eps graphic. But the fact that it wasn't a LyX problem was moot, because unlike Abiword and StarOffice, the only graphic format LyX could accept (so I thought) was .eps.

Buildup to a Crisis

To understand the happenings of 8/31/2001 through 9/2/2001 you need a little history on my Windows to Linux conversion. I had spent literally over a year researching the feasibility of converting my business to Linux. I had done an almost complete dead end analysis to reveal any potential showstoppers. I found Linux tools to do all my tasks except these:
  1. Outline processor (was MS Word)
  2. Graphic illustrating software (was Micrografx Windows Draw)
  3. Book writing software (was MS Word)
With a great deal of effort, I adapted the Vim editor to do outlining, eliminating potential showstopper #1. #2 was partially solved by learning dia and gimp. Without addressing #3, I transitioned to Linux.

Fast forward a few months, and I recognized the need to write a new book about troubleshooting. My 1990 classic, "Troubleshooting: Tools, Tips and Techniques" wasn't written well enough to carry the Universal Troubleshooting Process to the masses. After  a few days research my choices were obvious:

  1. Docbook
  2. LyX (front end to LaTeX)
  3. StarOffice
  4. MS Word
#1 would have been wonderful, but most of the front ends I could find forced the writer to type the codes, and they all included codes in the text. I use my entire brain to conceive words, phrases, and techniques when I write. If I stopped to write a DocBook code, I'd lose my train of thought. It could slow me by an order of magnitude. I could have used  Emacs as a front end, but I would have needed to learn Emacs, and the codes would have still been in the text. Have you ever tried to go back and figure the context of a sentence full of codes? DocBook wouldn't have been productive.

#2 showed promise. LyX neither requires the typing of codes, nor does it it place codes in the front end. In fact, the LyX front end to LaTeX strongly resembles the Netscape Composer front end, so it felt easy and familiar (90% of Troubleshooters.Com was penned in Netscape Composer). For me, the most compelling aspect of LyX is the fact that its native format is an extremely easy to parse set of codes, so if I ever decide to export it to a format for which Lyx itself doesn't provide an export facility, I can write a simple program to do it. LyX is a spectacularly safe vessel to hold my book. But adding and modifying styles in LyX is like performing open heart surgery. And LyX's built in styles are nowhere near adequate for the book I was writing.

#3 would have been decent. It's very easy to make your own styles, and it's very much like Microsoft Word. Which is also its downfall. From what I understand, it's not truly Open Source or free software. Instead, it exists in a licensing netherworld of free beer software, with Sun reserving all rights. Combine that with the fact that its native format is binary, and it's no better a vessel for my valuable book than MS Word.


I've heard there will be a new version of StarOffice called "Open Office" that will be free software, and will have an XML native format. If that had been available in a stable version when I made my choice I probably would have chosen it.

But now I'm getting very fond of LyX...

#4 was a fallback position, business as usual. I've written books in MS Word before. The 300+ page "Rapid Learning: Secret Weapon of the Successful Technologist" was written in MS Word, and it turned out well. But MS Word is a proprietary program whose native format is binary. If dealing with Microsoft became impossible, how could I migrate my books to something else?

I took a solid month to evaluate LyX, and concluded though it would be difficult, and though I'd need to trade quite a bit of writing time in order to learn how to make LyX styles appropriate for my book, LyX's typesetting and stylistic consistency, combined with the easily parsable and manipulable native format, carried the day. Let me repeat:

Evaluating LyX consumed a month!

I did a complete dead end analyisis of LyX, and could find no showstoppers, including using .eps graphics. But I had not placed graphics in large documents...

Black Friday

On Friday, August 31, 2001, somewhere between 7:00 am and 8:30 am am Eastern time, I discovered that all subsequent pages overwrite the page containing the first .eps graphic. I rounded up all the usual suspects, trying different .eps files made with different graphics programs, and verifying that the problem occurred even in Abiword, as long as the graphics were in .eps format.

Not having another printer, I temporily assumed that it was a problem with my HP 4050's postscript implementation. At 9:02 am I wrote to the LEAP (Linux Enthusiasts and Professionals) mailing list asking how to use ghostscript to print to non-postscript printers. My idea was to print the book as HP-PGL instead of postscript.

I spent the rest of the day working on the problem, and became increasingly bleak. There seemed to be no answer. Nobody on the LyX mailing list had experienced this, or had any real idea of what caused it. My troubleshooting efforts were slow and non-productive. I had put out a message on LEAP asking others to try to print it on their non-postscript printers, but it was a workday and nobody had responded.

This was one of the worst workdays of my life. I was increasingly convinced that I'd need to back out of LyX, transfer my book to another program, learn that other program (or go back to license-challenged MS Word). Any way you looked at it, I was about to lose 2 months of work. To understand the feeling, imagine if you got fired and spent 2 months out of work, and couldn't collect unemployment. I was not pleasant to be around.

As the day wore on I began to contemplate returning to Windows. I couldn't stay with an OS that could cost me 2 months work. If Linux were that hard to work with, why did I leave Windows. But underneath, a calmer voice told me why. "Who owns your data?", it whispered. If I went back to Windows, I'd need to continue paying Bill Gates' ever increasing ransoms to see my data, and when I could no longer afford it, I'd need to either go out of business or convert to Linux all over again. I continued troubleshooting.

At 8:12 pm I found a workaround. I could print to .pdf format instead of postscript, and print the .pdf. Breathing a sigh of relief, I hugged my wife and said I think it was going to be OK. But at 10 pm I discovered that the .pdf files were so big that the printer slowed down to the point where the engine went off every page, further slowing the printer and likely taking years off the printer's life, if I did massive book printings that way.

The time from 10 pm until 1 am were spent trying to reduce the bandwidth of the .pdf. I met with some success (cut the size in half) using pdflatex instead of plain pdf. But pdflatex format errored out on .eps files, so I needed to switch the graphics to .png, which doesn't show format in the LyX front end environment. I went to bed at 1 am knowing I had serious problems, but at least for the purposes of this book I could complete the book and print it. And I had enough experience in Linux to know that sooner or later every problem gets solved.

I was in a funk when I drove to the LEAP Installfest at 9 am on 9/1. A 15 hour troubleshoot with no clear progress can do that to you. When LEAPster Brian Coyle got to the Installfest a few hours later, he asked me "did you get my email message?".

"What message?" I asked.

"There's a fix for your .eps printing problem. It's a known problem with the CUPS printing system that came with Mandrake 7.2 and Mandrake 8.0. Update to the latest CUPS and it should fix your problem."

Then LEAPster Phil Barnett mentioned that the Mandrake updates he gave me a couple weeks before contained the .rpm for the updated CUPS.

Dreading more disappointment, yet filled with hope, the day brightened. After Installfest we all went to dinner, and getting home around 7 pm on 9/1/2001,  I installed the CUPS upgrade .rpm that Phil had given me. My .eps printing problem immediately vanished. It was a known problem, and once I installed the known solution it vanished.

The Moral of the Story

This was truly an oddball problem. I could have spent a month troubleshooting it. I think it unlikely that a tech support person at the vendor would have heard of it. But I'm fortunate to have lots of technical friends in LEAP and elsewhere, and one of them remembered hearing of an update that cured a symptom exactly like the one I described.

LyX has proven very productive. Even though I was too angry to work the week starting September 11, I still have over 68,000 words in the book. That's over half of the 300+ page book.

This is the power of the new support model.

Steve Litt is the creator of the Universal Troubleshooting Process Course. He can be reached at Steve Litt's email address.

The Power of the Mailing List

By Steve Litt
In the time you spend on hold for the vendor's phone support person, you can and should send out the symptom description and a request for help to several mailing lists. That way, if the phone support people can't help you (and doesn't it seem like they're less and less helpful as time goes on?), you're likely to get some outside help.

But mailing lists operate very differently than paid phone support, and you need to know the difference to succeed with community email support...

Mailing List Rules of the Road

If you keep the preceding in mind, you'll receive excellent help from mailing lists.

Him Who Hustles While He Waits

Typically mailing list help has a 2 hour to 3 day latency. That's not a problem if the question to be answered is not on your critical path. Make sure that it's not on your critical path. Ask the question the instant you realize you have a problem, then work on other things so that when you finally get an answer, those things won't slow you down. What you want to avoid at all costs is sitting still spinning your wheels waiting for an email.

Note the different mindset from phone support. In phone support, you expect the matter to be settled during the phone call. Often it doesn't work out that way, but it's your expectation. So it frees you from the need to find alternate work do to while information comes to you.

When you look for email support, don't just sit around waiting. Hustle while you wait.

Steve Litt is the documenter of the Universal Troubleshooting Process.  He can be reached at Steve Litt's email address.

The Power of the User Group

By Steve Litt
My CUPS/.eps problem was solved by a member of my Linux user group, LEAP.  Not by someone on the LyX mailing list, or any other mailing list. It wasn't obvious from search engine searches. If I hadn't been a LEAP member I'd have been in trouble.

User groups are great because people have actually met each other and formed friendships. That bestows a greater desire to help, even when the questioner is not somebody the answerer knows. A user group is a community. That's a lot of committment.

I answer many questions, and provide much information, on the LEAP mailing list. So it's only natural that when I need help (and that's a daily occurrence :-), fellow LEAPsters try to help me. There are over 150 people on the LEAP mailing list. Many are lurkers, but even so there are over 20 who regularly answer questions. That's a lot of brainpower.

Committment plus brainpower spells fast and accurate answers. Always join user groups for any technology in which you work.

Steve Litt is the creator of the Universal Troubleshooting Process Course. He can be reached at Steve Litt's email address.

Proactive Troubleshooting

By Steve Litt
If you subscribe to bug lists, you'll proactively eliminate problems. If I had subscribed to the right bug lists, I never would have encountered the day-wrecking CUPS/.eps bug.
Steve Litt is the author of Rapid Learning: Secret Weapon of the Successful Technologist. He can be reached at Steve Litt's email address.

Linux Log: Open Source as Consumer Revolt

By Steve Litt
In the 1993 movie "Jurassic Park", Dr. Ian Malcolm (Jeff Goldblum) says "Life will not be contained. Life breaks free, expands to new territories, and it crashes through barriers, painfully, maybe even dangerously."

Indeed, introduce a new antibiotic, and a few years down the line germs are resistant to that antibiotic. 65 million years ago, the same cataclismic climate changes making life impossible for the dinosaurs propelled mammals to the forefront, eventually culminating in man. Had there not been the climate changes, mammals might have been a mere footnote in history.

In software also, life will not be contained. Microsoft's monopolism has killed off countless software companies. The way I see it, all remaining proprietary software companies are parasites and symbiants of Microsoft, eating its leavings. Microsoft can, and regularly does, kill these  remaining software companies with a flick of its gigantic tail. An integrated browser here, a deliberate interface booby trap there, and another software company is dead. Microsoft aims to be the sole technology company, and is accomplishing that by getting bigger and killing other technology companies. 2001 is a truly hostile environment for any software company other than Microsoft.

But life will not be contained. Open Source and free software are immune to the revenue starvation techniques Microsoft uses to kill software companies. They have their roots in the early 70's, but remained insignificant until Microsoft commandeered the technology ecology in the early 90's. All the consumers who would have chosen from several word processors (Wordstar, WordPerfect, Ami Pro, MS Word, PFS Professional Write, IBM DisplayWrite, Volkswriter, Officewriter, MultiMate, XyWrite, WriteNow) now had two choices -- proprietary MS Word, and free software. All the programmers who would have made good money writing several word processors now had the choice of Microsoft or free software. Had it not been for Microsoft's commandeering the technology ecology, free software and Open Source would likely have remained mere footnotes in history.

But Microsoft's revenue starvation tactics do not kill free software, so free software flourishes in today's hostile and poisoned software development environment.

And consumers revolt. Every time Microsoft creates an even more disgusting licensing provision, more consumers move to free software. Increasingly, consumers see free software as guaranteed perpetual access to their data. They see free software as a less expensive alternative. Free software has been selected by software evolution to challenge Microsoft. For the first time Microsoft cannot use revenue starvation to kill a rival.

So Microsoft itself evolves. One might think their evolution would be toward better products and saner licensing provisions. But that's not their style. Instead, they petition the government to outlaw free software. The most obvious petition was Allchin's February 2001 whine. When congress didn't instantly ban free software Microsoft went to plan B -- laws ostensibly banning tools of copyright violation. The DMCA says it's illegal to create a technical workaround for encrypted content, even if that workaround is only for the purpose of playing legally obtained content on your Linux box. Now the other shoe is dropping, a draconian law called SSSCA.

SSSCA stands for "Security Systems Standards and Certification Act". It has nothing to do with security -- it's copy protection like the copy protection that made our lives so miserable in the late 80's. But now, they want to force everyone's PC (and cellphones and virtually all other technology) to include copy protection to "protect" encrypted copyrighted material from getting copied. Understand, it's not protecting the computer program. It prevents the use of the computer from unprotecting other protected matter, such as movies and music.

You will not be able to manufacture or import PC's or software lacking these protection routines. And if you disable them on your personal PC, you're subject to imprisonment for a felony.

But so what? If people won't respect copyright and licensing, shouldn't they be forced to?

Maybe, but not at the expense of those who do respect copyright and licensing. Watch carefully as you see the cause and effect chain by which the SSSCA kills Linux and gives Microsoft a legally enforced monopoly:

  1. All software must have components to prevent the computer from being used as a tool to unprotect copy protected content.
  2. Algorithms for those components are patented, and available only under license totally incompatible with free software.
  3. Free software cannot reverse engineer the algorithms because of the patents
  4. Free software therefore cannot be manufactured or imported into the United States.
  5. Microsoft is now the only game in town, at least in the United States.
  6. The brain drain experienced by the United States in the last decade accelerates, as the only career option for a U.S. computer programmer is working with technologically inferior Microsoft products. India, Ireland, Russia and Australia lead the technological world, while the United States fades into technological obscurity.
Yes, the U.S. Congress might kill Linux. No matter what operating system you use, if you find the legislated lack of an alternative a bit scary, you might want to sign petitions and write your congressman and senators. URL's for these letters are included in the URL's section of this issue of TPM. To learn more about SSSCA, simply place that acronym in the Google search engine, and you'll get enough information to scare the daylights out of you.

I'm sure Microsoft is rubbing their hands in glee. Depending on how many votes they, the RIAA, and Disney can buy, Linux might be outlawed in the U.S. But Microsoft should note that a look at the United States during alcohol prohibition shows that when you outlaw something wanted by the public, the cure is often worse than the disease. Or, in the words of Dr. Ian Malcolm,

"Life will not be contained. Life breaks free, expands to new territories, and it crashes through barriers, painfully,

maybe even dangerously."

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.

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.


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

URLs Mentioned in this Issue