My name is Brian Root and this story began when my company was acquired by a larger outfit, and everyone gets a new login based on just the employee's family name -- which in my case is Root.

That should have been a non-issue with any other name, but when the administrators created my account, they apparently didn't think about the fact that root is the superuser account in our Unix systems.

Following the instructions provided in an email, I logged in and changed the password on my 'root' account. The next time I logged in, the password didn't work. I called the help desk for the new company and they reset my password -- and it worked until I logged off and tried to log back in.

After three days of this, I finally asked the second-level support tech if it was possible that my 'root' login was creating my issue, since there was already a root account and directory in Unix? And after several more days, I received an email with my new account name: broot. Problem solved. But I always imagined that each time I changed my password on the root account, systems were failing all over the world.

who | grep sleeping
who | grep awake
who | egrep 'bad|good'
for (goodness sake) {
be good
}

% ar m God
ar: God does not exist

% ^How did the sex change^ operation go?
Modifier failed.

% make love
Make: Don't know how to make love. Stop.

% sleep with me
bad character

% got a light?
No match.

% man: why did you get a divorce?
man: : Too many arguments.

% ^What is saccharine?
Bad substitute.

% man woman
No manual entry for woman.

% %blow
%blow: No such job.

% (-
(-: Command not found.

% sh $PATH=pretending! /usr/ucb/which sense
no sense in pretending!

$ drink matter
matter: cannot create

/earth is 98% full... please delete anyone you can.

Overflow on /dev/null, please empty the bit bucket.

The world is coming to an end. Please log off.

This login session: $13.99, but for you $11.88

[YOU MIGHT HAVE MAIL]

Your fault: core dumped

"SCCS, the source motel! Programs check in and never check out!"
- Ken Thompson

"Beware of bugs in the above code; I have only proved it correct, not tried it."
- Donald Knuth

How many hardware engineers does it take to change a light bulb?
None: "We'll fix it in software."

How many software engineers does it take to change a light bulb?
None: "We'll document it in the manual."

How many tech writers does it take to change a light bulb?
None: "The user can work it out."

Мораль сей басни такова: если Вы ничего и не поняли, то Вам остаётся только делать вид, что это смешно...

...full PL/1, with its growth characteristics of a dangerous tumor, could turn out to be a fatal disease.

Edsger W. Dijkstra, ACM Turing Lecture 1972, "The Humble Programmer" - http://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html

For references: http://dobbscodetalk.com/index.php?option=com_myblog&show=Catching-Minnows-in-a-Jar-with-PL-I.html&Itemid=29

Back In The Days of The 1971:

A small state had a central (shared) computer system. The Motor Vehicle system was the elephant sitting in the middle of the room.

The computer was and IBM 360/40 with:
256kb of core memory
That's kilo byte, not mega byte.
240mb of disk storage,
in an array of 40mb drives.
1gb 2321 Data Cell and
6 vacuum column tape drives.
124kb/sec read/write speed.

The 2321 was about the size of a washing machine tub. The storage was on 6x2 inch magnetic strips hanging in a circular array. The rental was $5,100/mo.

The system was backed up monthly. The backup was a 10 hr run. The transactions were written to journal tapes. When the system failed, it almost always did, it was restored from the previous month's backup, and the transactions applied from the journal tapes.

The back ups were started Friday evenings. The analyst pilot fish gets the call early Saturday morning, it's failed again. Roust the IBM Customer Engineer, (repair guy) out of bed, fixes it and the restore is started. 11:00 that evening, analyst gets call it's on the last tape. It's a nice Sunday evening and fish and operator are enjoying smokes out side. There is a brilliant flash and several seconds later a loud explosion. The power substation had blown up.

In horror and extreme dread, the fishes take a look at the 2321. Sure enough, the program had been running; It was restoring the VTOC, vol. table of contents, tape strip. The strip was a perfect according. 3 or 4 milliseconds later and it would have been a perfect run.

Since that that time the analyst has been a believer in the kingdom of Murphy, and Murphy sits on the left hand of god (or devil?).

Fish's boss bit the bullet and said the decision to bring all other processing to a halt and run it again was like the time he flew a glider across the Rine.
He knew they were coming down, hoping it wasn't into the trees.

For references: http://en.wikipedia.org/wiki/Murphys_law
http://www.columbia.edu/acis/history/datacell.html
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_2321.html
http://members.optushome.com.au/intaretro/2321DCD.htm
http://en.wikipedia.org/wiki/Early_IBM_disk_storage

Manager: Wally, what's the status on the RDP project?

Engineer: Am I working on that one?

Manager: You've been in charge of it for year.

Engineer: Oh. In that case, it's almost done.

Manager: Half of being a manager is living with a vague feeling of uneasiness.

For references: http://www.omega.com/dilbert