Troubleshooters.Com Presents

Troubleshooting Professional Magazine

 
Volume 10 Issue 4, Autumn, 2006
  Whoops!
Copyright (C) 2006 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 | Linux Productivity Magazine ]



 
If I had to live my life again, I'd make the same mistakes, only sooner. -- Tallulah Bankhead.

CONTENTS

Editor's Desk

By Steve Litt
A week or so ago I made a troubleshooting blunder. You know, the type I use as an example in my classes. The type made by fools without troubleshooting training. The type that's inexcusable for a person acknowledged as a world class leader in the field of system independent troubleshooting. During the Take Pride step of troubleshooting, I asked myself "How could a person with my knowledge and abilities have made that mistake. As an answer started to emerge, I knew it would be the subject of the Fall Troubleshooting Professional Magazine.

I'll discuss this mistake in one of this issue's articles, as well as several other mistakes. None of the mistakes discussed in this magazine are the super embarrassing personal type. Those aren't appropriate for a magazine. Some of the mistakes didn't occur during troubleshooting, but if you examine them closely, you'll see their explanations all can be pertinent to troubleshooting.

So kick back, relax, and read about my world class wonder blunders, and see if you can avoid fiascos of your own. And remember, if you're a Troubleshooter, this is your magazine.
Steve Litt is the author of Twenty Eight Tales of Troubleshooting.  You can email Steve here.

It Could Have Been a Five Minute Fix

By Steve Litt
It could have been a five minute fix, if only I'd followed the advice given in my books and courses. You know, the quadruple tradeoff.

The pressure was on. A family emergency required two weeks away from home -- too much time to let my business go without attention. I bought a laptop, installed Linux, rsync'ed my data to it, and tested, tested, tested.

The last step for taking my business on the road was creating a new IPCop box. An old computer and IPCop 1.4.10 did the trick, and all I had to do was test.

The test failed on the first number I tried, but subsequent numbers worked just fine. The final step was making sure it worked with Chicago Earthlink numbers, so I tried one and it failed. Then another failed. And another. No dialtone, no communication, just thirty seconds and then it went back to idle.

I went through all the settings in IPCop, over and over. No dialtone, no joy. Finally, I connected the phone line usually used for dialup to my handset telephone, and, by hand, on my handset telephone. No dialtone. So, using the same handset telephone, I called tech support.

If you're not rolling on the floor laughing right now, please go back and carefully read the last paragraph!

The "idiot" (later we'll identify the real idiot) on first level tech support didn't know anything about IPCop or Linux, so I asked to be escalated, which the first level guy did gladly.

The second level guy spoke calmly and professionally walked me through some diagnostic questions. Maintaining my last shred of The Attitude, I answered. The second level guy successfully logged into my account, on his end, and said he felt it was something with my phone line. I responded that, for this particular number, I couldn't get a dialtone, and asked he try it on a handset. Maintaining his professionality, he explained he didn't have a handset phone to do it on.

Then, speaking almost tenderly, he reminded me that the dialtone appears before the first digit of the number is dialed, and if I couldn't get dialtone on the Earthlink access number, I couldn't get dialtone on any number, including the one I used to phone tech support. The phone could not read my mind as to what number I intended to dial, and refuse dialtone if my intent was to dial the Earthlink access number.

I paused as it dawned on me who the real idiot was. I might as well have submitted a symptom of "my home theater system plays backwards, but only on FM". It was a clearly impossible symptom. I admitted I was wrong, apologized, and asked for further advice. He said it must be something about my phone line.

The Earthlink professional had calmed me down enough to force myself to adopt The Attitude. Going back through the IPCop settings, it became clear that it wasn't set to make the modem speaker active. With the modem speaker activated, the dialtone sounded, the number was dialed, but then there was a spoken error message to the effect that it needed permission to make the phone call. The same symptom happened with the handset phone connected to the line reserved for dialup.

Dead on my feet, stumped, I asked "How can I narrow this down just one more time?". The easiest test was a doubleswap, plug the handset phone into the dialup line, and plug the modem into the line usually used for voice. This time IPCop connected perfectly.

A puzzled look came to my face, followed by a disgusted groan as the true cause occurred to me. As a cost saving measure, my family had not enabled long distance on the line usually used for dialup. Without long distance access, there was no way to call a Chicago number, let alone log into a modem on it.

How Did This Happen?

How does a world-renown expert in his field suddenly start performing like a clueless amateur, a ditz, a moron? How does that happen?

It was an attitude violation. I just had to get the IPCop box running on a Chicago number before leaving town the next day. I also had to configure my notebook computer, pack, ship some books, make some sales calls. My todo list was long and oppressive, and I panicked.

Of all people, I know better than to panic. In the words of the Litt Takes the Nine Count article in the October 1997 Troubleshooting Professional Magazine:

And I learned The Attitude must be kept no matter what the challenge. Bosses can threaten termination, customers can threaten to take their business elsewhere, dead processes can shut down the business, but The Attitude must be retained. Because without The Attitude, all is lost.

The stress level was too much even for someone with my training, and panic set in. Not the wild panic of screaming, and throwing up of the hands, but the smaller symptoms of panic, like ignoring what's right in front of you, not reading screens thoroughly, and not taking the time to really examine a symptom.

Mistake #1 was not noticing that the checkbox enabling the modem speaker to make noise was not checked for the Chicago phone number. So of course I got no dial tone out of the modem -- it simply dialed in, got the error message (which of course couldn't be heard because the modem speaker was disabled in IPCop), and terminated the connection.

The next panic inspired mistake was not asking "how can I narrow this down one more time?" Instead, I went around in circles modifying the IPCop screen, even though that was very time consuming. A simple ten second swapping of my phone lines would have instantly pointed to the root cause, but panic obscured this ten second doubleswap.

Finally I got the excellent idea of dialing in on a handset phone. The only problem was that by this time panic had taken over to the extent that it really sounded to me like there was no dial tone :-)

After Earthlink's second level level tech support guy pointed out the error of my ways (in the nicest possible way, considering that if our roles had been reversed I'd have been choked with laughter), I took 5 minutes to properly adjust my attitude. soon after that, I performed the doubleswap and solved the problem.

Two Possible Responses

As a reader, you can have two possible responses to this article:
  1. Litt must be an idiot to make such a mistake, I won't listen to anything he says.
  2. If a guy like Litt can have this happen, it can happen to anyone, so I'm going to be even more careful to avoid attitude violations in the future.
Response #1 is that of someone confident he can't make big mistakes. Often an arrogant person. I've dealt with many such people. When it comes their turn to make a mistake, they often lack the mental tools to back up and re-troubleshoot when inconsistent results are obtained. Some of the costliest blunders come from those certain they can't make a major mistake.

Response #2 is that of a Troubleshooter comfortable with the fact that he or she is human, understands the inherant weakness of humans, watches out for those weaknesses, avoids them when possible, and backs up and tries again when tripped up by those weaknesses.

One other comment. When it comes your turn to make a whopper of a mistake, and you know better, after you analyze what happened and how to prevent future occurrence, look at it with a sense of humor. There's no use beating yourself up.

What I did Right

This may have been a prodigiously stupid mistake, but discovery to solution was less than three hours, so I must have done something right.

Perhaps my smartest move was to understand I was at risk of a serious attitude violation, and guard against it. Several times I recited the Troubleshooter's Mantra, "how can I narrow it down just one more time?". True, my thinking wasn't rational enough to parlay that question into a phone line doubleswap, but it did keep me doing diagnostics. I also surrendered on a timely basis, and called Earthlink's tech support, which when all is said and done was the turning point in the troubleshoot, because the Earthlink second level support guy calmed me down and made me understand my voodoo thinking. And of course, I finally doubleswapped.

The attitude violation cut my productivity massively, but I never allowed it to avalanche. I didn't scream at the tech support guys. I didn't throw things around the room or break the machine.

It was a forest fire of stupidity, but at all times it remained a controlled burn. I credit that fact to my troubleshooting training.

Folklore

Every shop has its "defective customer" folklore. The guy who plugged his sound system speakers right into the wall, causing them to burst into flame. The secretary who rolled a floppy through a typewriter and then wondered why she couldn't read the floppy. The husband who put antifreeze in his wife's crankcase instead of her radiator, freezing the engine. In the world of troubleshooting, there's no shortage of abject, profound stupidity.

At Earthlink tech support, it will be handed down from senior tech to junior tech, generation after generation, the story of the guy who thought the number he intended to dial caused a lack of dialtone. And generations of junior techs will say "that guy must have been really stupid".

Hey, I resemble that remark!
Steve Litt is the creator of the Universal Troubleshooting Process. You can email Steve here.

If I Can't Be a Bike Mechanic...

By Steve Litt
At the age of 23, I lived in the Cranden Park Woods in Miami (Key Biscayne, really), eating coconuts for breakfast, swimming in the Atlantic, and flirting with bakini clad beauties. It was an idillic life, but what I really wanted to do was work as a bicycle mechanic, the same as I had in Chicago the previous summer. Bicycles were my life. I believed in them. Bicycles would change the world.

Nobody would hire me as a bike mechanic because I didn't speak Spanish.

One day my buddy Rich came to my campsite. Five years older than me, Rich had a great job as a social worker. Rich made me an offer.

"Steve, you're just sitting here in the woods. You can do better. I can get you free training as a welder so you can get a really good job!"

I still cringe at my reply: "Rich, all I want to be is a bike mechanic, and if I can't be a bike mechanic, I'm not gonna work at all!"

Rich and I went on to talk of other things. Two months later I moved back to Chicago, and a month after that I was once again working as a bicycle mechanic.

The next summer, the price of eggs tripled. The following fall, the price of gasoline doubled, dragging almost all prices up with it. The bike mechanic's job barely paid my food and rent, leaving nothing for savings. The next three or four years featured the unholy combination of inflation and recession. I got a really crummy and exploitive white collar job to pay the bills.

During the worst of that recession, I ran into my old buddy Tim. Tim had been a counterman at a health food store back when I was a bike mechanic. Now Tim made $12.00 an hour as a welder. That's quadruple the best hourly I'd ever gotten as a bike mechanic, and almost double my white collar salary. Tim had gone to California, gotten free training, and returned to Chicago, a union town, to make the big bucks. I almost cried, realizing that if I'd said "yes" to Rich that day, I'd be on easy street just like Tim.

My mistake was thinking things would remain the same forever. If food, clothing and shelter had remained cheap, I'd have been a bike mechanic forever. $3.00/hour, $12.00/hour, it was all the same because it was more than I needed.

I'm not alone in ignoring change. America's technological job market has been decimated by change. Outsourcing, offshoring, downsizing, 80 hour weeks have changed our workplace, ability to get work, and ability to pay our bills with the work we do. How many of us postpone learning new techologies until tomorrow, thereby leaving ourselves unready to grab that job that would have improved our lot.

Change happens. Be ready.
Steve Litt is the author of the Universal Troubleshooting Process Courseware.  Steve can be reached at Steve Litt's email address.

Leading Curtis Cook

By Steve Litt
Somewhere someone has a picture showing me leading former world champions Curtis Cook and Ken Sutton in a rollerskating race. I know that picture exists, because I saw the flash go off.

It was the start of a 10K "bootleg race" in Southern California, magnet to the early 1980's speedskating world. I was feeling good that day, really good. When the starters pistol went off, it felt like a 426 Hemi engine in my legs. Effortlessly I shot out, leading everyone. Snapshots flashed, people cheered, and at least two world champions were drafting me.

Fast forward 500 meters, 1/10 of the race. My 426 hemi had become a 383, my pace had slowed, and someone behind me charged ahead, pulling the champions with him. I sprinted to keep the draft, but after another 100 meters I almost collapsed, and fell off the draft. A few minutes later the second pack passed me (I was normally a second pack skater), then the third pack, then the stragglers.

A half hour later, coughing, choking and stumbling, I crossed the finish line, my 426 hemi now a Yugo engine in need of a tuneup. Grandmothers had beaten me. Little kids had beaten me. People with gym shoe skates beat me. I was 6 minutes off my normal pace, 10 minutes off the winning pace.

I never heard whether Curtis Cook, Ken Sutton, or someone else won. I didn't care. Smog sickened, exhausted and depressed, I went home and slept away the rest of the day.

What the heck was I thinking? I was no champion, just a fairly good second pack skater. Tens of races with places between 15th and 30th had proven that. Instead of drafting the champs as long as possible, I ran out and expended all my energy in the first 1/10 of the race.

At the next bootleg race, I started out slowly, and as the first pack formed, I drafted. Lap after lap saw me still drafting the front pack, resting when possible, sprinting when necessary. Friends and groupies started cheering me as race's end approached with me still in the front pack. With 500 meters to go the front packers sprinted for the finish line, leaving me in the dust. But when the second pack crossed the finished line a couple minutes later, I was already cooling down and accepting congratulations.

It was the only time I was front pack all the way through a race, and perhaps the finest moment of my speedskating career. I'd learned from my silly burnout at the last race, and turned in a personal best performance this time.

-*-*-

What's this story doing in a troubleshooting magazine? As a Troubleshooter and Technologist, do you pace yourself? Or do you pull consecutive all nighters because you're young and feel good? Do you say "yes" to the boss even when any sane person knows burnout would be the result? We all need to pace ourselves. Pace yourself.
Steve Litt was a competitive outdoor speedskater from 1980 through the middle of 1984. He competed against, and lost to, champions like Tom Peterson, Curtis Cook, Ken Sutton, Sandy Dulaney, Julie Dulaney, Lynn Peterson, Fran McFate, Alphonso Kanno, and fellow Venice Speed Demon Jonathan Suetter, the former 24 hour world record holder. You can email Steve here.

What Twenty Dollars Would Have Bought

By Steve Litt
Two foot fins on two tons of rolling steel, my 1959 Plymouth was an 20 year old kid's dream. Its blue exterior showed all 10 slushy/salty Chicago winters it had survived. The interior was a hay ride festooned with strips of what had once been cloth apolstery. The inoperable drivers side door displayed a three foot peace sign in white house paint -- a source of constant police harrassment. All Mopar, from the days when Mopar was All American, it sported a flat head 6 whose tuneups were completed in 20 minutes with an adjustable wrench and a gapping tool. Its name: The South Side Special.

But the South Side Special was sick. Its crankshaft pulley had fallen off. A trip to a local garage indicated it would have cost twenty bucks to weld the pulley back on, and I was too cheap to do it. After all, the car had cost me only a hundred fifty. As summer breezes gave way to wet winds of fall, the South Side Special languished.

My buddy Jeff and I wanted to go to Madison, Wisconsin, 200 miles northwest of Chicago. Jeff said he could fix the South Side Special -- he used duct tape (no, I'm not kidding). He taped the flywheel back on, and congratulating ourselves on all the girls we were going to meet in Madison, we hit the road.

After 10 freeway miles, the pulley fell off (surprise, surprise). Within 5 more miles, steam was blowing out the hood. I pulled off in Evanston, Illinois, where the car died in a mushroom cloud of smoke visible throughout Evanston. It wouldn't start -- the head gasket was gone, the heads were warped, the South Side Special was finished.

Wanting to avoid disposal charges, I begged a car dealer to buy it. Finally the car dealer said he'd take it for free, but I had to put a dime in the parking meter. Jeff and I took a bus to Madison.

What was I thinking? For twenty dollars I could have had driven my car who knows how much longer. Twenty lousy bucks. Yeah, I know that back in 1969 twenty bucks could have bought you two weeks of groceries if you were frugal, but still, twenty lousy bucks! What did I think, maintenance is unnecessary?

Our combined bus tickets to and from Madison cost darned near twenty dollars. These days, when my mechanic says it will cost seven hundred to replace my worn shocks, I say "great, do it!"
Steve Litt teaches courses on troubleshooting. You can email Steve here.

The "Key" to Productivity

By Steve Litt
Twenty job interviews in four days and two cities. Job hunting all day, roller skating and socializing all night. Good times!

It was spring of 1980. Sick of Chicago, I vowed to move to California. But which would it be -- Los Angeles or San Francisco? A week's vacation, flights from Chicago to Los Angeles to San Francisco, and job interviews stacked four and five per day went into the decision.

So here I was, enjoying myself at a park in San Francisco on a Saturday after a brutal week of job interviews. After putting my skates in the trunk and closing it, I realized I'd locked my keys in the trunk. Frantic calls to all sorts of locksmiths resulted in the trunk being opened two hours later, at a cost of $175.00. Two hours of precious vacation time gone.

That's OK. In the 26 years since that incident, I never locked my keys in the trunk again, because of two new habits developed to prevent future occurrence:
  1. Never put keys down inside a trunk.
  2. Always check my pockets for keys before closing a trunk.
These two habits have generalized to rooms of all sorts, the result being I seldom get locked out of anything. Who knows how many business fiascos those habits have prevented. Who knows how extra much money I've earned because of those two habits.

Mistakes are bad, but if you learn from them and create policies and habits to prevent future occurrence, it's all good.
Steve Litt is the author of Manager's Guide to Technical Troubleshooting. You can email Steve here.

Out of Scope

By Steve Litt
This is a computer programming story almost identical to The "Key" to Productivity. A nasty intermittent caused one of my programs, installed at my client's client's site, to crash once or twice a day -- naturally never with me there.

The turns out the problem was caused by code similar to the following:

#include <stdio.h>
#include <string.h>

char * double_string(const char * string_in)
{
char buffer[2000]; /* way big enough */
strcpy(buffer, string_in);
strcpy(buffer + strlen(string_in), string_in);
return buffer;
}

int main(int argc, char * argv[])
{
char * newstring = double_string("the quick, sly fox");
printf("%s\n", newstring);
return 0;
}

No fair compiling it in gcc. gcc issues a warning for what I did wrong. My code was compiled with Borland Turbo C for DOS, a less sophisticated compiler in which I generally ignored warnings. Also, forget the fact that I used strcpy() instead of strncpy(). I made the buffer much bigger than any string it would ever encounter.

Do you see the problem?

Notice that by the time the main routine gets around to using newstring, the buffer comprising it is already out of scope, being declared locally to subroutine double_string(). And yet that buffer was still on the stack, and unless a succeeding local variable grabbed a lot of memory, that buffer would remain undisturbed, and the code would work. Until the successor record was extremely long, at which time newstring would magically change as its stack area was overwritten.

I prepended the word static in front of the declaration of  buffer, and the problem went away forever, as the variable stayed in scope after the subroutine exited.

That mistake caused me a lot of trouble and made me look like a dork. I paid attention, and never again passed an automatic local string as a function return. Once again, I bungled, I pondered, I made a new policy, I never repeated the bungle.
Steve Litt is the author of four books on the subject of troubleshooting. You can email Steve here.

For Three Dollars More

By Steve Litt
It was a tremendous opportunity. A different department at one of my clients was courting me. They invited me to go to lunch with them, and from the discussion it was obvious they were evaluating the way I'd fit into their department, and it was obvious things were going well. Lunch finished, the check came, we divvied up, and I put in what I thought was my share. I really thought that was my share. The total was a little light and one of my hosts put in an extra buck or two, with the other one asking "do you have enough, Fred?"

It was awkward for me. I didn't want to pay too much, but paying too little wasn't right either. Fred said everything was fine, but on the walk back to the office I felt awkward about the check. I was never invited into their department. If I'd pitched in three dollars, I'd probably have gotten thousands of dollars of business.

Stupid!

Perhaps the hardest thing was telling my wife I'd lost a great opportunity by being three dollars cheap. Heaven knows, we really needed more money, and the extra business would have made life much easier. I had to tell my wife we'd need to do without because of a stupid mistake on my part. We discussed it, and how when it comes to business, its better to pitch in too much than just enough.

Roll the camera forward five years, the night before teaching a troubleshooting course. My client's people were all there, chowing down on Pizza. They offered me a piece, and I took it. I left to go back to my room, and just then remembered the lunch five years ago and what it had cost me. I thought of how, for the rest of my time with that old client, every time I saw those two people, the only thing I could think of, the only thing I could envision, was my short payment on that check. I imagined the class tomorrow, looking out at all my clients' people, able to think only of how I'd taken free pizza and not paid. I marched right back into the room, whipped out a ten, and paid for my portion of the pizza. Ten dollars for a single slice of pizza was cheap insurance that I wouldn't be thinking about unpaid pizza when I should have been thinking about teaching them troubleshooting.

The manager of the client's department said "Steve, take your ten back, it's expensed back to the company anyway -- none of us are paying for it. But thanks for the thought, that's nice of you."

The class was extremely successful, with my mind only on teaching, not on extraneous subjects like whether I'd paid enough. I'd learned my lesson.

The moral of this story is sometimes the most expensive thing you can do is to be cheap. If a restaraunt isn't within your budget and then some, the time to discuss that is before a place is decided. If you're in a situation like mine (one income, five people, owning your own business) you might not be comfortable at $20.00 a plate dinners, or golf outings. Fine, don't go to such events. But whatever you do, if you go to them, pay your share.

Once a long time ago, a headhunter called me and invited me to lunch, making it clear that it was his treat. I liked this headhunter, and intended for him to find me a better job. The headhunter chose a restaraunt way above my budget, but hey, he was paying. When the check came, he suggested we split it. After a minute of surprise, I said "sure", and paid half the bill and half the tip. The headhunter saved about ten bucks by having me split it. From that moment on, every time that headhunter called me, I told him I was busy. He blew his commission for lack of ten bucks. I got a better job without him.

If it's a business situation, pay more than your share. That way, when you talk business, your mind will be on business, not on whether you paid enough.
Steve Litt is the author of Troubleshooting Techniques of the Successful Technologist.  You can email Steve here.

The Role of Mistakes

By Steve Litt
Everyone makes mistakes. They're embarrassing. They're costly. And they're how we learn.

Stories abound of subordinates making million dollar mistakes. They beg their boss not to fire them, and the boss assures them that now that he's spent a million dollars training them not to make that mistake, the last thing he's going to do is fire them and throw away the million dollars of training. These stories usually end with the boss warning the subordinate that he expects them to learn, and they better never make the same mistake again, or they will get fired, because now it's not lack of knowledge, it's carelessness, sloppiness, and laziness.

In most of the stories in this month's Troubleshooting Professional, I learned. I'll be even more careful maintaining The Attitude when troubleshooting and in other activities. Setting keys in the trunk or returning a soon to be out of scope character array are two things I never did again. In social situations I try to get separate checks, and in business situations, if I go to eat at all, I pay more than my share (unless the invitation specifically stated the other person is paying). I pace myself, in athletics and everything else. I understand that when buying older cars, one must budget some serious money for auto maintenance, and don't give up a car because of a minor expense.

Everyone's capable of being an idiot. What separates temporary idiocy from the chronic variety is the ability to examine the mistake, determine how it happened, create policies to prevent future occurrence, and change habits to implement those policies.
Steve Litt is the author of Twenty Eight Tales of Troubleshooting. You can email Steve here.

Troubleshooting Professional Needs Theme Ideas

By Steve Litt
This is the tenth year I've published Troubleshooting Professional Magazine, and I'm running out of theme ideas. I've written about the UTP, The Attitude, intermittence, bottleneck analysis, toolsmanship, and generic problem solving. I've written short stories, dense and dry treatises, and humor. I can't think of what else to write.

Which is why I need your help. Please email me with topics you'd like to see covered in future Troubleshooting Professional Magazine issues.
Steve Litt is the author of Samba Unleashed. You can email Steve here.

Letters to the Editor

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

How to Submit an Article

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

Any article submitted to Troubleshooting Professional Magazine must be licensed with the Open Publication License, which you can view at http://opencontent.org/openpub/. At your option you may elect the option to prohibit substantive modifications. However, in order to publish your article in Troubleshooting Professional Magazine, you must decline the option to prohibit commercial use, because Troubleshooting Professional Magazine is a commercial publication.

Obviously, you must be the copyright holder and must be legally able to so license the article. We do not currently pay for articles.

Troubleshooters.Com reserves the right to edit any submission for clarity or brevity, within the scope of the Open Publication License. If you elect to prohibit substantive modifications, we may elect to place editors notes outside of your material, or reject the submission, or send it back for modification. Any published article will include a two sentence description of the author, a hypertext link to his or her email, and a phone number if desired. Upon request, we will include a hypertext link, at the end of the magazine issue, to the author's website, providing that website meets the Troubleshooters.Com criteria for links and that the author's website first links to Troubleshooters.Com. Authors: please understand we can't place hyperlinks inside articles. If we did, only the first article would be read, and we can't place every article first.

Submissions should be emailed to Steve Litt's email address, with subject line Article Submission. The first paragraph of your message should read as follows (unless other arrangements are previously made in writing):

Copyright (c) 2001 by <your name>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, version  Draft v1.0, 8 June 1999 (Available at http://www.troubleshooters.com/openpub04.txt/ (wordwrapped for readability at http://www.troubleshooters.com/openpub04_wrapped.txt). The latest version is presently available at  http://www.opencontent.org/openpub/).

Open Publication License Option A [ is | is not] elected, so this document [may | may not] be modified. Option B is not elected, so this material may be published for commercial purposes.

After that paragraph, write the title, text of the article, and a two sentence description of the author.

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

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

Trademarks

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

URLs Mentioned in this Issue