Troubleshooters.Com Presents

Troubleshooting Professional Magazine

Volume 6 Issue 1, January 2002
Birth of a Book
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 ]

The real way to make money in Linux is not to create another distribution, but to use the existing Linux distributions in a value added model. -- Jon "maddog" Hall


Editor's Desk

By Steve Litt
December 16, 2001 marked the publication of my new book, "Troubleshooting Techniques of the Successful Technologist". It's by far the most comprehensive documentation of process oriented troubleshooting. It may sound trite, but I believe this book will revolutionize the practice of troubleshooting.

At 300+ pages and 117,000 words, it wasn't easy to write. Making the job even harder was the fact that I recently switched from the Windows operating system to the GNU/Linux operating system, so most of the tools I used to create "Rapid Learning: Secret Weapon of the Successful Technologist" were unavailable. And yet this book turned out to be the best produced book I've ever done, with more consistent styles, better typesetting, and for the first time in any Troubleshooters.Com book, an index. Excluding the staple bound cover, this book is aesthetically beautiful.

How did I manage such professional publishing using only Open Source software? Which tools did I use, and how did I use them? What challenges needed overcoming? And what does this say to those who claim you can't make money with Open Source?

The answers to these questions are contained in the articles of this issue. So kick back and relax as you read this issue. And remember, if you're a Troubleshooter, this is your magazine. Enjoy!

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

The Challenge

By Steve Litt
Failure *is* an option when it comes to writing a book. It's not easy. My first book, "Troubleshooting: Tools, Tips and Techniques", took a year and a half to write, and when it was done there were some fairly substantial problems, such as the lack of a single audience. "The Job Seeker's Guide", with a definite audience and hard hitting writing style, was written in a couple weeks in 1995. But at less than 50 pages, it couldn't really be called a "book".

I learned how to quickly write a full sized book while writing chapters for "Red Hat Linux 6 Unleashed" in 1999. A quick look at the tables of contents and chapter contents of several Unleashed books confirmed my suspicion that these books were written from outlines that went six levels deep (about as deep as you should ever go in a book). After finishing my Macmillan work I made a 940 headline outline, in MS Word, for a book to be called "Rapid Learning: Secret Weapon of the Successful Technologist", and wrote the book in 2.5 months. This book was twice the size of my first book, and took less than a fourth of the time. Full outline design prior to writing had proven its worth.

So as the main author of "Samba Unleashed" in 1999, my first step was to spend an entire month outlining the book. The outline turned out to be 2800 lines long. Was it worth it? I believe so. Once the outlining was done, the writing process took between 3 and 4 months for this 1200 page book. I wrote over half the book myself. And if you look at the reviews of "Samba Unleashed" (see URL's section), it's obvious that everyone liked the content, structure and organization of the finished product. Outlining had proven itself.

After switching to Linux in March of 2001, outlining became a challenge. Unable to use MS Word or even anything half as good for outlining , I put off writing another book. But as the months rolled on it became obvious that the aging "Troubleshooting: Tools, Tips and Techniques" needed replacement. I created a series of configuration files and scripts to make the Vim editor into an outliner, and made a 900+ line outline for my new troubleshooting book, "Troubleshooting Techniques of the Successful Technologist". The outline challenge had been solved.

Styles based editing

I've believed in styles based editing since the dawn of time. My 1990 "Troubleshooting: Tools, Tips and Techniques" was authored in WordPerfect 5.1, with styles for emphasis, heavy emphasis, warnings, chapters, end of chapter questions, and almost everything else. Same with my subsequent books, which were written in heavily stylized MS Word.

But now I was in Linux, where MS Word is unavailable. After Corel's partial sellout to Microsoft I had a serious "who owns your data" problem with any Corel product, so WordPerfect for Linux was out. Most Linux word processors weren't up to the task. The main possibilities were Docbook and LyX, neither of which were as simple as WordPerfect 5.1 or MS Word.

LyX Challenges

LyX is a killer app for publishing books. At first it would seem a no brainer top choice. But styles were a problem. Rolling your own style in MS Word is a 3 minute task. It's probably 10 minutes in WordPerfect 5.1. It can take a couple days in LyX, especially if you aren't thoroughly familiar with the LaTeX language. When evaluating LyX, it can appear impossible to create certain styles.

The Decision

By Steve Litt
The initial elimination decision of book authoring tools was quick. StarOffice was too shaky to rely on. Abiword was not even close -- it was more in the category of MS WordPad. The same was true of KWord.

I'd pretty much narrowed it down to Docbook and LyX. LyX provided quick content entry and good looking output, but its facilities for style creation and modification seemed grossly inadequate. Also, LyX seemed to export only to LaTeX, PDF, HTML, Postscript, and DVI. This was a serious "who owns your data" problem. Docbook seemed the way to go.

But Docbook had its own problems. I could have used Emacs to front end my Docbook, but I don't know Emacs and have had trouble trying to learn it. LyX can front end only the SGML version of Docbook, and I wanted to use the XML Docbook representation, so a LyX front end for Docbook was unsuitable for me. Most other Docbook front ends required tag coding, which is a productivity killer for a writer.  The moment you switch your focus to coding a tag, you forget the idea about which you were writing. Ughhh!

The decision came when I looked at a LyX document in VI. The LyX native file format is simple, easily understandable and parsable, and you can recover all styles. It would be trivial to write an app to convert LyX code to XML.

The decision made, it was now necessary to evaluate LyX to make sure it would do everything needed. Nobody wants to be half way through a book when they discover their authoring software won't do the essentials.

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

The LyX Evaluation

By Steve Litt
The evaluation took the form of a dead end analysis. The most obvious dead end was the extreme difficulty of adding or modifying styles. When I started the evaluation, style adds and mods were a mythology I'd read on the LyX email list. People said they were doing it, but I could find no documentation showing the complete code necessary for any style. The Rapid Learning Process began.

Already knowing most of the terminology, I started by seeking a "Hello World" environment (LyX paragraph styles are called "Environments"). It's NOT the slightest bit obvious. I finally learned to create a new environment (call it MyStyle) by placing a file called MyStyle.layout in the .lyx directory under my home directory, and then in LyX choosing Edit->Reconfigure from the menu, and then restarting LyX. If you're interested in what goes in that file you can see my "Writing Books with Lyx" page at

I found out the layout file could be placed in the same directory as the document, and then place a symlink of the same name in the .lyx directory under my home directory. In this way I kept everything contributing to my book in one directory.

Soon I learned to modify not only the appearance in LyX, but also by using LaTeX I could modify the appearance in Postscript and other outputs. Now Paragraph styles were within my reach, although throughout the writing of this book style mods and adds remained difficult.

The evaluation uncovered the true nature of LyX. It's a front end to the LaTeX typesetting language. LyX markup and LaTeX markup look remarkably similar, which would haunt me throughout the writing of this book, and indeed haunts many people. If I do one thing for the LyX community, it will be to correctly and simply document when you use LyX markup, and when you use LaTeX.

LyX has no built in outlining ability -- at least none that would help an author design the structure of a book. I therefore created a script to convert my VimOutliner created outline into LyX headings. It worked superbly!

I tested graphics, and they appeared to work perfectly as long as they were in Encapsulated Postscript format. I neglected to test graphics in a long document, and that fact came back to haunt me on a day I call "Black Friday". But for the time being, my research indicated that LyX would be able to carry me through to a finished book. I already had my outline and a way to convert it to LyX. On August 26, 2001, I quit evaluating and began to write.

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 Obstacles Overcome

By Steve Litt
Before I'd written 1000 words it was necessary to make environments (remember that "Environment" is LyXese for "paragraph style") for Notes, Warnings and Tips. Ideally they should have been 5% indented on each side, shaded 5% dark, surrounded by a border, and headed by the word NOTE, WARNING or TIP as appropriate. A day's work showed me that if that exact appearance was possible, it was far beyond my current LaTeX capabilities. Confident that some day making the necessary appearance would become obvious, I temporarily left the three styles indented, surrounded top and bottom with lines, and the appropriate heading.

Then I wrote actual content. Unfortunately, a problem with a Chapter 1 graphic stopped me dead in my tracks.

Black Friday

On Friday, August 31, 2001, it became clear that all subsequent pages overwrite the first LyX page containing an .eps graphic. This made writing the book completely impossible. I worked all day Friday trying to find a cure, and when a cure proved impossible, a workaround. The workaround I found was so ugly it wasn't practical for the long term. I considered backing out of LyX and moving to something else -- maybe even MS Word!

Saturday, September 1, LEAPster Bryan Coyle solved the dilemma by telling me that this problem was a well known defect of Mandrake 8.0's CUPS implementation, and I could fix it with an update. I fixed it and began to slam out content in earnest.

The 10 days til the next crisis saw huge productivity, with several chapters written at a rate of over 4000 words per day.

September 11

A bunch of fools collapsed the World Trade Center, and I spent the next 2 weeks in a fog of anger and revenge fantasies. Even when I got back to work, my productivity wasn't the same. From what I hear, everyone else was having similar productivity problems in mid September.

But we all got back to work, and I was no exception. Slowly but surely, progress continued and the book took shape.

Character styles

The book was over 25% done when I belatedly discovered that LyX has no true character styles. LyX aficionados might point to the emphasize and noun "styles", but in the native LyX file they become nothing more than bold and small caps, respectively. They're not styles.

Two character styles were needed -- one for the book's chapter names within the text, and one for the names of Universal Troubleshooting Process steps. I probably could have used noun style, but if kludges like that were acceptable why not write the book in Notepad?

I asked about character styles on the LyX mailing list. Some of the developers mentioned that such styles would be in a future LyX release. That didn't help much, because unless I could find a way to identify such styles now, there would be no reasonable method of finding applicable text and applying the new character style. It looked bad.

Then a LyX list participant named Dekel Tsur sent an ingenious workaround. Dekel had a way to have text of certain colors attain the appearance of choice in the final rendered document. The beauty of this workaround is that when real character styles become available, a simple search/replace can be used to convert the colors to character styles. After assigning magenta to chapter names and blue to UTP step names, and coding the layout file so they both print slanted sans-serif, progress continued quickly.

The Documentation Hole

The preceding challenges reared their ugly heads at specific times, but the documentation hole teased me throughout the project.

Here's the problem. There is plenty of documentation for the LyX newbie, and plenty for the guru, but little in between. Newbie documentation is available from the LyX program's Help menu. This introductory documentation is quite sufficient for anyone satisfied with the default appearance of his chosen document class. If you meet someone who says LyX is easy to learn, he's satisfied with the defaults.

At the other end of the spectrum is voluminous documentation for the LaTeX expert (remember that LyX is simply a front end for LaTeX). The entire /usr/share/texmf tree contains documentation a LaTeX expert can use to create the exact appearance of his desire. But these documents have no LyX context. They say what codes to put in, but not what file to place them in, or where in the file, or how they relate to LyX markup (remember that LaTeX and LyX markup look similar, but are completely distinct).

These documents contain few examples. The LyX website has similar problems -- all the LaTeX you'd ever want at, but little context, and insufficient examples for the person not intimately familiar with both LyX and LaTeX. The content isn't organized for easy access, and there's no search facility. It has some very useful information, but not until you've used it enough to know how to find things.

The LyX mailing list itself is excellent, but suffers some of the same problems. The people on the list are so skilled in LaTeX that they answer a question with two lines of LaTeX, never realizing that the person asking has no idea where to put those lines, or how to integrate them into his LyX layout file. Repeated queries with lots of experimentation are often required for the newbie wanting to use LyX to its fullest. Nevertheless, the mailing list is the best intermediate source of LyX information. Its archives are searchable, and if you keep asking you'll get enough info to solve your problem.

I overcame the documentation hole challenge by learning more LaTeX, by learning to find answers using reverse engineering (as discussed in the December 2001 Troubleshooting Professional), and by searching code in the /usr/share/texmf tree using grep. Also, there are some websites devoted to intermediate LyX (see URL's section).

The Copyright Page

I tried and tried to identify a way to put the copyright page on the back of the title page. In the end it just fell there -- a non-challenge.


The mailing list had many messages about creating a bibliography, but ultimately the answer was to go through the Bibliography exercise in the LyX tutorial. (Help->Tutorial in the LyX menu).


Creating an index is the most distasteful part of book production. It's tedious, and seems to go on forever. Nor is it simple -- there's an art to making a useful index. No wonder Macmillan had special employees to do the indexing.

I learned how to index from the "Extended LyX Features" (Help->Extended Features from the LyX menu), and /usr/share/texmf/doc/makeindex/makeindex.dvi. If you want detailed and challenging indexing information (IMHO overkill for a simple book), see /usr/share/texmf/doc/makeindex/ind.dvi.

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

The End Game

By Steve Litt
The book's cover was a challenge. Until now, the covers of all my books had been created with Micrografx Windows Draw. But Windows Draw is now an unsupported orphan owned by some  little-known company, yet its source code is still proprietary. There's a significant "who owns your data" problem with Windows Draw, so I evaluated several Open Source design tools: Killustrator, xpaint and dia flunked miserably for various reasons. That left Gimp, a pixel painter seemingly without Micrografx Windows Draw's vector graphic advantages. However, Gimp implements layers, which, when used right, can simulate many vector graphic techniques. Gimp offers several methods of drawing just the right rounded rectangle around the cover. Gimp's ruler lines and the ability to make construction lines gives it an accuracy better than that of most vector graphic programs. When all was said and done, I was as productive with the Gimp program I've used for a few months as I had been with the Micrografx Windows Draw I'd used for 11 years. The cover turned out beautifully.

Proofreading was accomplished by LEAP members Aaron Morrison and Max Lang. Both were given the assignment of finding and marking confusing sentences. They found quite a few, and I fixed them.

The next step in the end game was printing. For the time being I'm printing them on my HP Laserjet 4050. That keeps my inventory low, costs reasonable, and print quality excellent. When sales rise to the point where it's practical to print in lots of 100 I'll use a professional print shop. When sales rise to the point where runs of 5000 are practical, I'll have them done by a short run book printing outfit.

The final step, and the one I haven't done yet, is publicity for the book. Even the greatest book won't sell if it isn't known. Within the next few months you'll see this book reviewed in various newsletters and websites.

Steve Litt is the main author of Samba Unleashed. He can be reached at Steve Litt's email address.

The Final Product

By Steve Litt
So what does this book, authored entirely in Open Source software, look like? Is it good? Is it better than books authored in Windows?

On the content front, "Troubleshooting Techniques of the Successful Technologist" is by far the most complete and authoritative documentation of process oriented troubleshooting. Part I covers the basics of problem solving, including the theory and practice of solving intermittents. Part II is a complete documentation of the ten steps of the Universal Troubleshooting Process. Part III covers advanced topics including The Attitude, observation optimization, career integration, throughput maximization, and customizing the UTP. Part IV applies the theory of the first three parts to specific technological situations such as computers, networks, software, and source code debugging.

At 117,000 words and over 300 pages, it's not a small book. The table of contents is three levels deep (part, chapter and section), and the book's index is quite complete. This is my first book with an index. I just didn't have the heart to create indexes in WordPerfect 5.1 or MS Word. LyX made it easier.

In spite of the book's size, the rigorous use of styles facilitated by the LyX software yields visual consistency throughout the book. Because LyX is a front end to the LaTeX typesetting language, the typesetting of the book is exquisite. This is a very aesthetic and readable book.

This is my first book authored with Open Source tools, and it's my best book ever, in terms of both content and format.

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

The State of Troubleshooting Address

By Steve Litt
This is a Troubleshooting Professional Magazine anniversary issue. TPM turns five years old today. Our original goal was to define good troubleshooting in the hope of preventing carpetbaggers from trashing the principles of valid troubleshooting process. So how have we done?

In one sense we succeeded. The use of rigorous troubleshooting process continues to spread. The hit and miss troubleshooting that ruled the land five years ago is very much on the run. And in no small part because of Troubleshooters.Com, most troubleshooting process being used is valid -- not consultant drivel.

In another sense we failed. The hyperpolitical pronouncements on correct troubleshooting lasted just a few months. TPM is now known more for its Linux content than for its troubleshooting content. But given the intermittence and irreparability of much of Microsoft's software, Open Source advocacy might be one of the most pro-troubleshooting acts we can perform.

I've heard that Windows XP is less intermittent than previous "user" versions of Windows. If that's true it's great news for Troubleshooters. However, I heard similar pronouncements early in the lives of Windows 95, Windows 98, and Windows NT, and those products all turned out to be horrendously intermittent once the OS had been hammered on for awhile.


I've never used XP, and refuse to use it for business reasons having little to do with troubleshooting. The business reasons are discussed in the Editor's Desk article of the April 2001 Troubleshooting Professional Magazine.

The news gets even better because of the wide adoption of GNU/Linux and other Open Source software in the corporate world. Linux is rock solid, seldomly exhibiting intermittence. Its text configuration files are a breath of fresh air for the Troubleshooter accustomed to sneaking around in the Windows Registry. Linux and Open Source relieve the Troubleshooter from the licensing worries so common in the Windows world.

All in all, software troubleshooting has become saner thanks to the wide use of Open Source.

2001 was a great year for Troubleshooters.Com customers. Our troubleshooting course was vastly improved. And late in the year I published "Troubleshooting Techniques of the Successful Technologist". This book is by far the most authoritative documentation of troubleshooting process available anywhere for any price. Any technologist failing to read this book does so at the peril of his career. The early readers of this book will have a huge advantage in the career marketplace.

Era 4 troubleshooting (use of automated tools based on a troubleshooting process) did not take over the world. In fact, Era 4 troubleshooting is beginning to look like a niche rather than evolution. In hindsight it's obvious that the cost of Era 4 script authoring is just too expensive for many industries. Era 4 might have better have been named "Automation Assisted Troubleshooting Process" (AATP). I have no doubt that Troubleshooting as a whole will evolve some day, but that evolution might not involve AATP. That being said, AATP continues to make inroads in the military, the automotive industry, and other uses. If you have the skills to author AATP skills, your future is bright.

As a matter of fact, no matter what kind of troubleshooting you do, your future is once again bright. The recession predicted in the January 2001 TPM issue is weighing heavily upon us, and portable skills now make the difference between a paycheck and the unemployment line. The technologist who can correctly use troubleshooting process positions himself as one of the few indispensable "go to guys" who are costly to lay off.

The troubleshooting expert with security expertise is at a premium in these uncertain times. This is an excellent time to brush up on your computer networking and security skills.

The job market stinks, but you can shine by continuing to hone your use of troubleshooting process, while at the same time being flexible in your job title, and the exact type of troubleshooting and technology you practice.

I've heard predictions that 2002 will be the year we come out of this recession. Use your troubleshooting process expertise to remain continuously employed. That way when things get good again, you'll be first in line for the great jobs 2002 is scheduled to bring us.

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

Auld Lang Syne

By Steve Litt
A record-breaking three people voted in this year's best TPM issue/article award, but one ballot was rejected as unreadable (no issue or article named). Both remaining voters named the best issue as November 2001, "Linux Outlawed!". The best article was split evenly between November's SSSCA and April's "The Conversion of Troubleshooters.Com".

And once again I will name my favorite issue and top 5 favorite articles :-).

To me, the one-two punch of the March and April issues rose head and shoulders above the others, earning them a tie for best issue. March was a soup to nuts XML tutorial with which anyone could learn XML in a day. The April issue provided a tested and detailed blueprint for moving your business to the Linux desktop.

The March and April issues were also the most visited, although the May (Working With Auto Mechanics), October (Troubleshooting with the New Support Models) and November (Linux Outlawed!) issues were also heavily visited.

2001 was a year of big issues and little articles. Most articles were dependent on other articles. But some articles managed to rise to the top, including what I consider to be the top five:
Article What It's About
1 Simplified Explanation of the DOM API
(March 2001) 
This crystal clear tutorial on the sometimes murky subject of XML claims top honors for 2001.
2  Editors Desk
(April 2001)
The one irrefutable reason to switch to Linux, hammered home by a simple phrase.
3 Tales of Mechanics Good and Bad
(May 2001)
A series of car repair stories, each illustrating a point vital to the consumer.
4 Distinctions
(December 2001) 
How to make breakthroughs in troubleshooting and life using distinctions.
5 Linux Log: Open Source as Consumer Revolt
(October 2001) 
A Jurassic Park analogy to the rise of Linux.

And because this is the five year anniversary of Troubleshooting Professional Magazine, I'll list my ten favorite articles of the past five years:
Article What It's About
1 Gavin Gray
(November 97)
This troubleshooting short story about a late-blooming baby boomer is still by far my favorite TPM article.
2 Simplified Explanation of the DOM API
(March 2001)
A top-notch tutorial for an absolutely fascinating technology.
3 The Man Who Banned General Maintenance
(February 1998)
A Troubleshooting short story encompassing three generations, over 30 years, plots, intrigue, corporate takeover, and sweet victory.
4 Problem Solving Principles
(December 2000)
This article gives a remarkably thorough treatment of general problem solving principles.
5 The Loser
(February 2000)
The ultimate rebuttal to those asserting that troubleshooting cannot be taught or learned.
6 Editors Desk
(April 2001)
The one irrefutable reason to switch to Linux, hammered home by a simple phrase.
7 Barbarians At the Gates
(May 1998)
An early prediction of Microsoft's Demise
8 The Woods
(March 2000)
A compelling explanation for Step 9: Take Pride.
9 Linux Log: Where Have All the Heros Gone?
(May 1999)
A short but inspiring article about Open Source.
10 If you're not part of the solution
(January 1998)
A horror theme and a snappy ending punctuate this essay on troubleshooting process.

A warm thank you for a job well done goes out to this year's sole guest author, Phil Barnett, for his July 2001 article, "LEAP-CF Linuxizes Central Florida at CTS Orlando".

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

Life After Windows: XML 2001

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
Do trade shows have any relevance to us Open Source types?

Especially guys like me, who buy no proprietary software. It's not because of the price. If you read the April 2001 Troubleshooting Professional, you know that my reason for avoiding proprietary software is the "who owns your data" factor.

As a free software kind of guy, I didn't expect much from XML2001. After all, Bill Gates has managed to portray XML as a Microsoft technology. Expecting a bunch of proprietorists hawking expensive software with narrow vertical appeal, I walked in the door, and at first glance it looked exactly as expected. But then I began finding diamonds...


The first diamond was Ontopia -- who offer some free-beer closed source software you can use to learn and understand topic maps. Topic maps are free form structures allowing incorporation and lookup of almost any type of information. I believe they might be helpful in Era 4 Troubleshooting, in a manner described by Marc-Henri Poget's July 1999 Troubleshooting Professional article, "Using Semantic Nets to Model Troubleshooting's Knowledge, part 1". Basically, you use an editor like VI to make the topic map's XML, and use their Omnigator product to navigate it. If Ontopia later stops offering Omnigator without cost, you'll know enough to either switch to or create another topic map navigator, if you don't want to pay for Omnigator.

If you enjoy thinking, Ontopia's The TAO white paper is a must read (URL in URL's section). It describes the structure and power of topic maps in as simple a manner as something this general and powerful can be described. You can then use Omnigator to learn topic maps, which will almost certainly improve your mental abilities.


ActiveState and I go back a long way, to the days when ActiveState Perl enabled me to create components for the timesheet program used at one of the country's top 10 law firms. So I stopped in.

ActiveState developer Eric Promislow began describing their Komodo tool, which he demonstrated as a realtime XSL debugger. At first I wasn't too interested because Komodo is proprietary software, even though version 1.1 is free for "non-commercial use",  meaning "in a teaching or learning environment only" according to their website.

Note: You can also purchase  a non-commercial license for their Komodo version 1.2 for $29.50.

As Eric demonstrated how each line of the XML in the input file window is processed by the code in the XSL window, producing the (in Eric's demo) HTML code in the output window, it suddenly was clear what a tremendous learning tool Komodo is. Apply my Rapid Learning techniques using Komodo as a tool, and XSL mastery is only a few days away. Within a minute of that realization came the idea to make the February 2002 Troubleshooting Professional Magazine an XSL tutorial. Tutorials are always popular issues, and this one would be widely topical. Attending this trade show had given me the tools for a high traffic February TPM issue.

As far as I can see, there's no who owns your data risk using proprietary Komodo.  Your data is in industry standard XML and XSL languages, so even if Microsoft were to buy ActiveState and try to put a hammerlock on your data, you could simply switch to another development environment and go merrily on your way. So there's no risk or downside using Komodo as a learning tool. And if you decide to use it as a development tool, the only downside is the $295/year/developer cost, which depending on what you're developing could be insignificant. You can learn more about Komodo at their web page (see our URL's section).

Excited with thoughts of a hugely popular XSL tutorial in a future Troubleshooting Professional Magazine issue, I left the ActiveState booth wearing a big smile. Life doesn't get any better than this.

But it got better...

Isogen International

The place to have been at 3pm on 12/11/2001 was the Isogen International booth at  XML 2001. Trainer extraordinaire Don Smith gave a short presentation on what Isogen calls "The XML Learning Framework, which is a group of 7 categories of XML knowledge, each of which has several defined levels of knowledge. He then showed how to map an employee's job requirements onto this category/level matrix, and how to map that result into XML courseware for that employee. There's no need to describe this presentation further, because it's available on Isogen's website (url in URL's section of this magazine). Suffice it to say half way through Don's presentation I realized this mapping method could be used for ANY area of knowledge. Perhaps I'll soon compose a "Troubleshooting Learning Framework".

Don's 3pm presentation seemed impossible to beat, but his 5pm presentation on XML Schema was twice as good. Don started by listing the two distinctions vital to understanding schema:

  1. Schemas are a type hierarchy.
  2. Schemas are scoped documents
He explained that trying to learn schemas from books or the specification, without understanding the significance of the preceding two points, leads to frustration and the conclusion that schemas are impossibly difficult.

From there he demonstrated the use of the Built-in Datatype Hierarchy diagram from the XML Schema specification (url in URL's section), and how various types are derived from other types.

He then taught us the four derivation types, and the fact that extensions and restrictions were the two most important of the four. He discussed the rules of schema scoping, pointing out potential landmines

From there he plunged into the details. I left believing I can write a schema, and decided that the February 2002 Troubleshooting Professional would be a tutorial on XML Schema, thereby pushing my intended XSL tutorial back to March.


My education has featured over 100 teachers ranging from bad to great, but only two were spectacular. At Santa Monica College there was my advanced Cobol teacher, Mr. Little, who seemed to have a Cat5 cable connected between his head and mine. As fast as he spoke, that's how fast I learned. One might surmise that I learned so well because I was the class's top student, but in fact all the students agreed Mr. Little was the best teacher they'd ever seen.

And then there was Dr. Armington at IIT. Another Cat5 direct connection, but he taught the extremely difficult subject of transmission lines (with Smith charts -- ughh), and in that class I was one of the worst students. But even I learned everything he taught, got high 90's on all the tests, and aced the course. With a teacher like Dr. Armington the only necessity is listening.

Don Smith's 5pm presentation was comparable with the teaching performance of Mr. Little and Dr. Armington. The Cat5 brain to brain connection was definitely there. So after the presentation I asked Don how he did it. The answer was surprising.

Don felt the quality of his presentation was due more to his courseware than to his teaching techniques. He mentioned that he had recently spent nine months completing courseware for an XML course.


Do you think that courseware might be pretty good? And the beautiful thing is, assuming the power is in the courseware, any Isogen trainer can use that courseware to duplicate Don's results. Don is Isogen's Manager of Core Technologies Training, and my impression is that he writes most of the courseware and educates Isogen trainers on delivery and the underlying XML technology.

And based on Don's 5pm presentation, I think I know his courseware principles. He seems to start by showing the audience the landmines, and then gives them the lay of the land -- a kind of course map, if you will. This goes far beyond "tell em what you'll tell them, then tell them, then tell em what you told them". At every point, Don makes sure the audience understands the context in which they're learning, and frequently asks questions like "this isn't so difficult, is it?", or asks a question whose material he had just thoroughly covered.

  1. Show landmines
  2. High level map of the materials
  3. Teach
  4. "This isn't that hard, is it?"
  5. Go back to step 1

Listening to Don's Schema presentation, Don didn't seem like a genius. After all, I seemed to know the answers to every question he asked before he asked the question, even though I had no prior experience with the material. *I* seemed like the smart one. Of course, most of the rest of the audience was having an equally easy time keeping up. A REALLY smart professor would be so far beyond the audience that he'd confuse them. Right? Maybe the material was just easy.

A few hours later I bought and looked through an XML Schema book written by an XML Schema expert. It was complex, confusing, and almost unfathomable. But I already knew the material in the first few chapters. From Don's 1/2 hour presentation! The material wasn't simple at all. The reason I had known everything before Don said it was because of the bandwidth of his trainer to student connection.

Don is VERY technically gifted, and could make great money as a developer. But great developers are a dime a dozen. People who can establish a Cat5 teaching connection are ever so much rarer. But somebody who can write courseware to reproduce and scale that Cat5 connection to other trainers -- I don't think I ever met one before.

In most cases I recommend learning through the methods in my book, "Rapid Learning: Secret Weapon of the Successful Technologist" (URL in URL's section). But if what you need to learn is XML or SGML related, and you need to learn it extremely fast, and you have the money for training, immediately enroll in Isogen courses. Their URL is in the URL's section of this TPM issue.

Trade Shows After Windows

XML2001 was exceptionally well run, with lots of happy and enthusiastic people, and XML tech discussions breaking out in every hallway. During the excellent lunch I spoke to some of the IDEAlliance people who ran the show (I don't think they had a clue who I was). They were nice, friendly, down to earth people. They seemed busy, but not harried. They had time to talk to that ordinary looking guy who sat down at their lunch table. Everything was well organized. XML2001 was fun, and I'd recommend it to everyone, including Open Source people.

But in these busy days you need more than fun to justify spending time at a trade show. You must gain something.

In the six hours spent at XML2001, I found inspiration for two high traffic Troubleshooting Professional tutorial issues, and learned some training techniques that can be used to improve my Universal Troubleshooting Process courseware.

Are there trade shows after Windows? You'd better believe it!

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: The Natural Resource View of Open Source Profit

By Steve Litt
Executive Summary

You don't make money selling Open Source -- you make money using it.

Most explanations of "Open Source business models" have been proposed as ways to subvert the laws of supply and demand, which are based on scarcity. Most such models have failed because of the flawed assumption that Open Source is a scarce commodity, or can somehow be made scarce.

In fact Open Source more resembles an abundant, self renewing natural resource. Imagine it as a fast growing weed. You don't make money by selling abundant weeds -- you make money using them.

The one remaining question is how these abundant Open Source resources renew themselves, when the programmers creating them are not paid to do so (in most cases). The answer is that the programmers create or contribute to Open Source projects because they need the resulting functionalities more than they need the time they spend coding those functionalities.

One might ask why a programmer doesn't sell his creation. The answer is simple enough -- he couldn't make a penny. Only Microsoft and a handful of other huge companies can make money selling software. The small programmer makes his creation Open Source so at least it won't be kidnapped, changed and monopolized by a megacorporation. By making it Open Source, he knows it will be available to him forever. And if he's lucky, others may help him code it.

So the future supply of Open Source is assured. A profit motive is not necessary to assure it. There's plenty of incentive without profit. The intelligent businessperson makes money using Open Source, not trying to sell it.

"You can't make money selling free software".

Oft repeated, it's so true, yet so misleading.

The truth: Obviously there's little profit potential selling a product whose very license makes every customer your competitor in the sale of the product.

The mislead: the assumption that selling a product is the only way to profit from the product. It is not. You can make great money using the product to make something you can sell.

The Standard Propaganda

Would-be "realists" rush to display their wisdom with trite utterances like "you can't sell what you give away", and "sooner or later you have to sell something" (another true but misleading statement -- it assumes the thing you sell must be software). In the aftermath of the dot com bust, the computer trades are full of such profound pronouncements. IT journalists don't want to look gullible.

More on the evil side, certain entrenched interests with their own agendas work to perpetuate the misleading statement that you can't make money with free software. The proclamations of Microsoft's Jim Allchin and Craig Mundie are perfect examples (see URL's section of this magazine). Such proclamations operate on the deliberate and cynical belief that the public is too gullible to realize that they can profit from using a free product (possibly as a substitute for Microsoft's offerings).

Scarcity and Abundance

Some things are abundant and some are scarce. Abundance occurs when there's enough of something to go around. Scarcity happens when there's not. By definition, some people must go without the scarce thing.

Who gets the scarce items is determined by economy. In a dictatorship most of the scarce resource goes to the leader and his supporters. In communism, theoretically the scarce resource goes to those who "need it", but in practice it goes to the leader and his supporters. In capitalism it goes to those willing and able to pay the price, and sometimes to the leaders and their supporters. The point is, economics is a tool for the distribution of scarce resources. No such tool is needed for abundant resources.

It's obvious that life is better with abundance than scarcity. It would be wonderful if everyone had a nice house in a nice neighborhood, nice clothes, a quality education, quality health care, and a nice car. Certainly a quick look at poorer nations confirms that given a choice between scarcity and abundance, abundance is best.


Obviously the preceding paragraph is somewhat oversimplified. If we had absolutely everything we needed, we would stagnate intellectually and physically. If gasoline were a penny a gallon we'd quickly pollute the earth. But such obvious laziness and gluttony aside, for the individual needing the resource, abundance is preferable to scarcity.

Note also that abundance depends to a large degree on the economic system involved. Capitalism with restrictions on monopolism usually produces a high degree of abundance.

Not all resources are consumed directly. Some are used in the production of other goods and services. Obviously, cheap factors of production make for more profit or lower consumer prices, or a little of both. Let's take a closer look at abundance and scarcity.

Would we make less money without air?

Air is certainly abundant. We all breath it, and we don't pay a cent. Our cars use oxygen from the air as a power source. Almost every factory uses air in one way or another, and doesn't pay a cent for it (except for costs complying with the EPA).

Imagine if air became scarce. It would be unaffordable to run the gasoline engine in your car. Electric cars wouldn't fare much better, because coal powered electricity, which is about 50% of our electricity, would cease for lack of oxygen. The hugely increased costs of electricity would seriously damage the profits of metal plating plants, manufacturing plants of all kinds, and large server farms.

Our gross domestic product would plummet if air became scarce. The difference between that reduced GDP and the one we enjoy with abundant air is the amount of money we make from air -- an abundant resource with no cost.

We definitely make money with air -- but nobody can make money by selling air, because its price is zero.

What if electricity cost a penny a MEGAwatt hour

Electricity costs somewhere between 4 and 10 cents a kilowatt hour, depending on use and location. The power companies make a good living selling this somewhat scarce resource. But what would happen if someone discovered a generation method costing only a penny a megawatt (that's about 4000 times cheaper than current prices). It would be bad news for the power companies and their stockholders, but what would happen to the economy in general?

Expenses at factories would plummet, dramatically increasing profits. In a non-monopolistic capitalist economy, much of that profit would be passed to the customer in lower prices, which would increase sales. A good portion of farmers' expenses are energy related -- more money for the farmers and cheaper produce for American families. Server farms, huge users of electricity, would send the savings straight to the customers and the bottom line.

So abundant electricity would decrease the profit of those selling it, but would increase the profit on the whole.

What if salt were the price of gold?

McDonalds' Big Mac sandwich currently costs $2.23. It contains 1090mg grams of sodium, and because only 11/28 of salt's weight is the sodium content, that means the Big Mac contains 2775mg of salt, or 2.775 grams. Imagine that salt became as scarce as gold, so the price of salt rose to match that of gold ($275/oz, or $9.70/gram). In such a case the salt content of a Big Mac would cost $26.92. Do you think that might reduce the sale of Big Macs a bit?

Luckily, salt is dirt cheap. My local Publix store sells two 26 oz boxes of Mortons Salt for 79 cents. That's 18.658 grams per penny. At that price, McDonalds must make 6.7 Big Macs to use a penny's worth of salt.

Only a few companies make a living selling salt -- Mortons is one. But every restaurant makes money using this abundant resource, which for all practical purposes is free, to attract customers with tastier food.

What if software were free?

Do you use software in your business? If software were free, would you use more of it? Are there some nice software utilities, tools or systems that you'd like to use, but they're just too expensive?

When I switched to Open Source software, all sorts of opportunities opened up to me. Perhaps the best example is LyX -- a true book publishing program (and much more). I would have had to spend hundreds of dollars for a commercial program to do what LyX does, and with no "try before you buy", it's very likely I would have purchased an inferior product. So I made due with Microsoft Word -- a program not intended or suitable for writing books. Only after switching to Open Source was I able to get true book publishing software.

Real vs. contrived scarcity

No consumer wants scarcity. All consumers want abundance. Imagine life if we all had a nice house in a nice neighborhood, nice clothes, a quality education, quality health care, and a nice car, without working 90 hours per week to get it. The United States appears to have recently won a potentially very difficult war due to the abundance of its wealth and weapons. Abundance is good, and for society as a whole abundance is always better than scarcity.

Capitalism is the best way of dealing with real scarcity. Land is scarce -- they're not making any more -- especially near the cities. Titanium is scarce -- if it were abundant every car would have a titanium frame. But because there's not enough titanium for such uses, in a capitalistic society titanium's price rises to meet its demand, so that it ends up used on aircraft and a few bicycle components rather than entire car frames. Under normal circumstances, capitalism does a pretty good job of taking from each what he can, and to each what he needs. The individual does what he can to fulfill what he believes to be his needs. Capitalism makes scarcity more bearable, but abundance is always better than scarcity.

Well, almost always. The only exception is for those holding a large quantity of the scarce commodity. They can then trade the scarce commodity for lots of money, which they can trade for lots of other scarce commodities, or even favors from the government. That brings us to the subject of contrived scarcity.

Contrived scarcity

Earlier you read the description of titanium as a scarce commodity. There's not enough readily available to fill all its potential uses. The scarcity of titanium is real.

But some scarcity is created. Consider the scarcity of word processing software. In 1986 you could choose word processing software from Microsoft, WordPerfect Corporation, Corel, Lotus, Adobe, Microrim, and many others. Today Microsoft is the only game in town, except for the forward looking StarOffice users and WordPerfect stalwarts. Microsoft put the rest out of business using the practices of illegal monopolism (Judge Jackson's and the appeals court's words, not mine).

In fact there are three primary methods of creating scarcity: monopolism, collusion and government interference. Microsoft has managed to bankrupt almost all competitors, so Microsoft now holds almost all proprietary software, making it scarce. This is monopolism. In 1973 the OPEC countries voted to simultaneously reduce oil production, thus doubling the cost of gasoline in a few weeks. This is an example of collusion. The US government has created a doctor shortage by making entry into the profession costly and difficult, and with immigration rules making it difficult for foreign medical students to set up a practice in the US. The extremely long US patent period gives drug companies monopolies on their drugs for 17 years or more. It's my belief that with less interference from the government, ordinary citizens could pay for most of their medical care without insurance, HMO's would be a thing of the past, and most people would be getting better medical care.

Have you ever known an unemployed doctor?

The point is this: Given human nature, holders of commodities will try to artificially make those commodities scarce. And holders of scarce commodities will try to have the government restrict sale of abundant substitutes for those commodities. Hence the posturing of Allchin, Ballmer, Mundie. Their worst nightmare is Open Source software, because it eliminates software scarcity.

As a matter of fact, money DOES grow on trees

Open source is an abundant, renewing resource. It grows like weeds. It grows to meet demand. Although Open Source has been known to the general populace for less than a decade, it offers tools to solve almost any business problem or opportunity. And every year it catches up to, and in some cases overtakes, similar proprietary software.

But who will write Open Source if it costs nothing?

This question is at the core of every prediction of Open Source's demise. The theory goes something like this: "nobody in their right mind will put all that work into something they can't sell". It's just common sense.

And yet this common sense is being proved wrong. Open Source projects like Samba, Apache and GNU/Linux have existed for years, and are stronger than ever. Andrew Tridgell, Jeremy Allison, Linus Torvalds and the people comprising the Apache Software Foundation haven't gotten obscenely rich, but it's obvious that their Open Source participation has been good for their careers.

At this point a skeptic would mention that the people in the preceding paragraphs were the Generals of Open Source, and that the foot soldiers didn't make a penny. As a proud foot soldier of Open Source, I'll clarify that point. I'm the author of three GNU GPL licensed apps: UMENU, Htmlslides and VimOutliner. I never made a penny selling them. Nobody ever offered me a job, contract, speaking opportunity or board of directors position based on my Open Source authorship. And yet I'm sure I'll author more Open Source apps. Here's why...

I needed these programs, and couldn't find or buy satisfactory equivalents. My last 10 or so presentations have been given with Htmlslides. VimOutliner is my most crucial app. All my time and resource planning is done with VimOutliner. Every day more of my business is conducted with VimOutliner. The entire structure of my new book was created with VimOutliner. Almost 1000 headings! I've made a lot of money with VimOutliner -- much more than I could have made trying to sell it. So I put a GNU-GPL license on it to preserve its availability forever, and now you too can profit by using it.

But what if there are no more programmers? What if the lack of software sales potential ends the need for programmers?

Programmers will always be needed to adapt software -- either proprietary or Open Source, to businesses. And as long as the supply of programmers is assured, so is the supply of Open Source.

Open Source is here to stay, and is getting more abundant every day. The future belongs to those who use it.


Open Source is not a scarce commodity, but instead is an abundant and renewing resource. It's abundant because programmers find it worthwhile to create Open Source to solve their own problems. They have no incentive to proprietorize the software, because only megacorporations can make money selling software. The days of making a million from a $39 Pascal compiler sold out of your garage is long gone.

You don't make money trying to sell an abundant resource. You make money using it.

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 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 (wordwrapped for readability at The latest version is presently available at

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.


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

URLs Mentioned in this Issue