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.
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:
- Litt must be an idiot to make such a mistake, I won't listen to anything he says.
- 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!
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.
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:
- Never put keys down inside a trunk.
- 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.
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.
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.
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