Troubleshooting Professional Magazine
|
Troubleshooting with the New Support Models |
|
he waits -- Thomas Edison |
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!
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.
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:
#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...
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.
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.
But mailing lists operate very differently than paid phone support, and you need to know the difference to succeed with community email support...
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.
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.
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:
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."
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):