Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Google   


Admin Humor

Humor Chronicle RMS Linus Torvalds Larry Wall & Perl Top 10 Classic Unix Humor Softpanorama Humor Archive GPL
 C  C++ Assembler Perl Shell Java Debugging
Admin Algorithms  Networking Solaris Windows Linux Editors
skeptical humor OFM Humor   SE   vi Viruses Eric Raymond Outsourcing

See also Open Source Humor

Sysadmin songs

Todd's Humor Archive Burnout Prevention and Recovery

1. STOP DENYING. Listen to the wisdom of your body. Begin to freely admit the stresses and pressures which have manifested physically, mentally, or emotionally.

MSU VIEW: Work until the physical pain forces you into unconsciousness.

2. AVOID ISOLATION. Don't do everything alone! Develop or renew intimacies with friends and loved ones. Closeness not only brings new insights, but also is anathema to agitation and depression.

MSU VIEW: Shut your office door and lock it from the inside so no one will distract you. They're just trying to hurt your productivity.

3. CHANGE YOUR CIRCUMSTANCES. If your job, your relationship, a situation, or a person is dragging you under, try to alter your circumstance, or if necessary, leave.

MSU VIEW: If you feel something is dragging you down, suppress those thoughts. This is a weakness. Drink more coffee.

Todd's Humor Archive Computer Center Humor

Computing Center [n] In a University, that organization whose functions are 1) To impede wherever possible the development and usefulness of computing on the campus, 2) To gain the lion's share of funding, spend it largely on obsolete and otherwise inappropriate Solutions, and convince the campuse(s) wherever possible to expend their meager funds on the same, and 3) to oppose vigorously any new, useful and popular technology for ten years or more until nearly everyone on the campus(es) and elsewhere in the world is using it, then to adopt that technology and immediately attempt to gain complete and sole control of it [see MS-DOS, UNIX, ETHERNET, INTERNET].

NEW ELEMENT DISCOVERED!

The heaviest element known to science was recently discovered by university physicists. The new element was tentatively named Administratium. It has no protons and no electrons, and thus has an atomic number of 0. However, it does have one neutron, 15 assistant neutrons, 70 vice-neutrons, and 161 assistant vice-neutrons. This gives it an atomic mass of 247. These 247 particles are held together by a force that involves constant exchange of a special class of particle called morons.

Since it does not have electrons, Administratium is inert. However, it can be detected chemically as it impedes every reaction with which it comes into contact. According to the discoverers, a minute amount of Administratium added to one reaction caused it to take over four days to complete. Without Administratium, the reaction took less than one second.

Administratium has a half-life of approximately three years, after which it does not normally decay but instead undergoes a complex nuclear process called "Reorganization". In this little-understood process, assistant neutrons, vice-neutrons, and assistant vice-neutrons appear to exchange places. Early results indicate that atomic mass actually increases after each "Reorganization".

Unix Admin. Horror Story Summary, version 1.0 -- this is a classic paper by Anatoly Ivasyuk. should be read by any sysadmin.

Todd's Humor Archive Customer Support Lines (fwd)

They should just quit the charade of calling it Customer Support. I suggest:

Welcome! to the Cointelpro Technologies Music-On-Hold Appreciation Center. If you are using a touch-tone phone, please follow these instructions for faster service.

[April 10, 1999] The Sys Admin.  -- a nice tale about sysadmins

Todd's Humor Archive A Day in the Life of a System Administrator

8am: Your pager goes off and wakes you up. The message says it's the office, and it's a crisis. You roll out of bed moaning.

8:15am: You are now sufficiently awake to phone the office. Your pager has gone off three times already. You get through to the office and the receptionist is frantic. She says nobody in the entire office can print and they have a major proposal that has to be faxed out before 9am and if it isn't the company could lose a million dollars in new business. You try to get her to explain what's wrong, but she's incoherent.

8:30am: You're dressed in yesterday's dirty clothes (they were all you could find in time) and running out the door, sipping a Jolt cola and hailing a cab to the office.

Todd's Humor Archive Sysadmin Hints and Tips for Users

1. Do not ask your sysadmin "did you get my mail?". Your sysadmin receives more mail in an hour than you do in a week, and may well have already read and forgotten your mail. If he hasn't answered it could be that he has more important things to do, like restoring the passwd file on the main server.

2. Do not page the sysadmin at 1am to ask him simple shell programming questions. Your sysadmin has made the wonderful and enlightening set of UNIX man pages available to you to answer just that kind of question.

3. When in doubt, assume that it's your fault. It probably is.

4. If the networks' down and your sysadmin is laboring feverishly in the machine room, please do not pound on the machine room door to tell him that the network's down. He already knows.

5. Overly-general questions like "what's wrong with my computer?" or "what did you do the network?" do little except annoy the sysadmin and make him quiz you to find the actual symptoms that you are experiencing.

6. Accusing your sysadmin of favoritisim ("you won't fix my problem because you like the other engineers better") is infantile and ridiculous. Your sysadmin holds all users in equal disdain and is ignoring your problem because he has more important problems to deal with.

7. Do not, under any circumstances, walk into your sysadmin's cubicle and announce "I have no problem, I just wanted to tell you what a wonderful job you're doing" unless you want your sysadmin to drop dead from shock.

Todd's Humor Archive The Proper Answers to Support Questions

Results of Time Efficiency Study of Interdepartmental Communications - Development Responses to Support Questions. Please evaluate and implement.

In order to reduce the backlog of the Support Department (SPT), increase productivity, and decrease the time the Development Department (DEV) spends answering SPT questions, DEV will use the following list of numbered reasons to speed up answers in n-dimensional humanoid interface sessions, to user questions SPT is unable to answer and must pass along to DEV:

1. Bug. 2. Feature. 3. Upgrade. 4. Tell them "Don't do that." 5. Ow! 6. Huh-huh, huh-huh. 7. Check Quotas. 8. Wish List. 9. Fixed in the next release. 10. In a future release. 11. How's that again? 12. Cool! 13. We'll get back to you on that. 14. That's in the land between bug and they're doing it wrong. 15. You never asked us _that_. 16. Yes. 17. Not our product. 18. Not our product's fault. 19. Flat negation. 20. Need more info. 21. Why do they want to do that? 22. Outside the product parameters. 23. They don't get the point. 24. They're unclear on the concept. 25. Who said they can do that? 26. They lied. 27. Reevaluate their medication. 28. Reevaluate optometry. 29. They are mutants. 30. (Expletive deleted).

Bureau of Redundancy Department


Copyright © 1996-2007 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last updated: March 15, 2008