|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
|May the source be with you, but remember the KISS principle ;-)|
|Computer Humor Collection||Manifest of the Softpanorama IT Slacker Society||Ten Commandments of the IT Slackers Society||Classic Computer Humor||"Linux Sucks" Humor Collection||Best Russian Programmer Humor||Interview with a hacker|
|ARE YOU A BBS ADDICT?||Object oriented programmers of all nations -- encapsulate||BSD Logo Story||The Cuckoo's Egg||The Evolution of a Programmer, from High School to CEO||The Perl Purity Test||THE TOP 25 THINGS PROGRAMMERS SAY|
Please note that so called "hacker dictionary" is The Jargon File spoiled by Eric Raymond :-) -- earlier versions of jargon file are better than the latest hacker dictionary...
There are four major species of Unix sysad:
The Technical Thug.
Usually a systems programmer who has been forced into system administration; writes scripts in a polyglot of the Bourne shell, sed, C, awk, perl, and APL.
- The Administrative Fascist.
Usually a retentive drone (or rarely, a harridan ex-secretary) who has been forced into system administration.
- The Maniac.
Usually an aging cracker who discovered that neither the Mossad nor Cuba are willing to pay a living wage for computer espionage. Fell into system administration; occasionally approaches major competitors with indesp schemes.
- The Idiot.
Usually a cretin, morphodite, or old COBOL programmer selected to be the system administrator by a committee of cretins, morphodites, and old COBOL programmers.
---------------- SITUATION: Root disk fails. ----------------
- TECHNICAL THUG:
Repairs drive. Usually is able to repair filesystem from boot monitor. Failing that, front-panel toggles microkernel in and starts script on neighboring machine to load binary boot code into broken machine, reformat and reinstall OS. Lets it run over the weekend while he goes mountain climbing.
- ADMINISTRATIVE FASCIST:
- Begins investigation to determine who broke the drive. Refuses to fix system until culprit is identified and charged for the equipment.
- MANIAC, LARGE SYSTEM:
- Rips drive from system, uses sledgehammer to smash same to flinders. Calls manufacturer, threatens pets. Abuses field engineer while they put in a new drive and reinstall the OS.
- MANIAC, SMALL SYSTEM:
- Rips drive from system, uses ball-peen hammer to smash same to flinders. Calls Requisitions, threatens pets. Abuses bystanders while putting in new drive and reinstalling OS.
- Doesn't notice anything wrong.
---------------- SITUATION: Poor network response. ----------------
- TECHNICAL THUG:
- Writes scripts to monitor network, then rewires entire machine room, improving response time by 2%. Shrugs shoulders, says, "I've done all I can do," and goes mountain climbing.
- ADMINISTRATIVE FASCIST:
- Puts network usage policy in motd. Calls up Berkeley and AT&T, badgers whoever answers for network quotas. Tries to get xtrek freaks fired.
- Every two hours, pulls ethernet cable from wall and waits for connections to time out.
- # compress -f /dev/en0
---------------- SITUATION: User questions. ----------------
- TECHNICAL THUG:
Hacks the code of emacs' doctor-mode to answer new users questions. Doesn't bother to tell people how to start the new "guru-mode", or for that matter, emacs.
- ADMINISTRATIVE FASCIST:
- Puts user support policy in motd. Maintains queue of questions. Answers them when he gets a chance, often within two weeks of receipt of the proper form.
- Screams at users until they go away. Sometimes barters knowledge for powerful drink and/or sycophantic adulation. <
- Answers all questions to best of his knowledge until the user realizes few UNIX systems support punched cards or JCL.
Last week I walked into a local "home style cookin' restaurant/watering hole" to pick up a take out order. I spoke briefly to the waitress behind the counter, who told me my order would be done in a few minutes.
So, while I was busy gazing at the farm implements hanging on the walls, I was approached by two, uh, um... well, let's call them "natives".
These guys might just be the original Texas rednecks -- complete with ten-gallon hats, snakeskin boots and the pervasive odor of cheap beer and whiskey.
"Pardon us, ma'am. Mind of we ask you a question?"
Well, people keep telling me that Texans are real friendly, so I nodded.
"Are you a Satanist?"
- It Has To Work.
- No matter how hard you push and no matter what the priority, you can't increase the speed of light. (2a) (corollary). No matter how hard you try, you can't make a baby in much less than 9 months. Trying to speed this up *might* make it slower, but it won't make it happen any quicker.
- With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead.
- Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.
- It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.
- It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it. (6a) (corollary). It is always possible to add another level of indirection.
- It is always something (7a) (corollary). Good, Fast, Cheap: Pick any two (you can't have all three).
- It is more complicated than you think.
- For all resources, whatever it is, you need more. (9a) (corollary) Every networking problem always takes longer to solve than it seems like it should.
- One size never fits all.
- Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works. (11a) (corollary). See rule 6a.
- In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.
- Nothing is as easy as it looks.
- Everything takes longer than you think.
- Anything that can go wrong will go wrong.
- If there is a possibility of several things going wrong, the one that will cause the most damage will be the one to go wrong. Corollary: If there is a worse time for something to go wrong, it will happen then.
- If anything simply cannot go wrong, it will anyway.
- If you perceive that there are four possible ways in which a procedure can go wrong, and circumvent these, then a fifth way, unprepared for, will promptly develop.
- Left to themselves, things tend to go from bad to worse.
- If everything seems to be going well, you have obviously overlooked something.
- Nature always sides with the hidden flaw.
- Mother nature is a bitch.
- It is impossible to make anything foolproof because fools are so ingenious.
- Whenever you set out to do something, something else must be done first.
- Every solution breeds new problems.
OO experienced a Road To Damascus situation the moment objects first crossed her mind. From that moment on everything in her life became object oriented and the project never looked back. Or forwards.
Instead, it kept sending messages to itself asking it what direction it was facing in and would it mind having a look around and send me a message telling me what was there...
OO thinks in Smalltalk and talks to you in Eiffel or Modula-3; unfortunately she's filled the disk with the compilers for them and instead of getting any real work done she's busy writing papers on holes in the type systems and, like all OOs, is designing her own perfect language.
The most dangerous OOs are OODB hackers; they inevitably demand a powerful workstation with local disk onto which they'll put a couple of hundred megabytes of unstructured, incoherent pointers all of which point to the number 42; any attempt to read or write it usually results in the network being down for a week at least.
"When you have learned to snatch the error code from the trap frame, it will be time for you to leave."
If the Tao is great, then the operating system is great. If the operating system is great, then the compiler is great. If the compiler is greater, then the applications is great. The user is pleased and there is harmony in the world.
Real Programmers don't write specs -- users should consider themselves lucky to get any programs at all, and take what they get.
Real Programmers don't comment their code. If it was hard to write, it should be hard to understand.
Real Programmers don't write application programs, they program right down on the bare metal. Application programming is for feebs who can't do system programming.
... ... ...
Real Programmers aren't scared of GOTOs... but they really prefer branches to absolute locations.
[ A letter to the editor of Datamation, volume 29 number 7, July 1983. Ed Post Tektronix, Inc. P.O. Box 1000 m/s 63-205 Wilsonville, OR 97070 Copyright (c) 1982]
Back in the good old days-- the "Golden Era" of computers-- it was easy to separate the men from the boys (sometimes called "Real Men" and "Quiche Eaters" in the literature). During this period, the Real Men were the ones who understood computer programming, and the Quiche Eaters were the ones who didn't. A real computer programmer said things like "DO 10 I=1,10" and "ABEND" (they actually talked in capital letters, you understand), and the rest of the world said things like "computers are too complicated for me" and "I can't relate to computers-- they're so impersonal". (A previous work  points out that Real Men don't "relate" to anything, and aren't afraid of being impersonal.)
But, as usual, times change. We are faced today with a world in which little old ladies can get computers in their microwave ovens, 12 year old kids can blow Real Men out of the water playing Asteroids and Pac-Man, and anyone can buy and even understand their very own personal Computer. The Real Programmer is in danger of becoming extinct, of being replaced by high school students with TRASH-80s.
There is a clear need to point out the differences between the typical high school junior Pac-Man player and a Real Programmer. If this difference is made clear, it will give these kids something to aspire to -- a role model, a Father Figure. It will also help explain to the employers of Real Programmers why it would be a mistake to replace the Real Programmers on their staff with 12 year old Pac-Man players (at a considerable salary savings).
... ... ... ... ... ... ... ... ...
In a dark dim machine room
Cool A/C in my hair
Warm smell of silicon
Rising up through the air
Up ahead in the distance
I saw a Solaris light
My kernel grew heavy, and my disk grew slim
I had to halt(8) for the night
The backup spun in the tape drive
I heard a terminal bell
And I was thinking to myself
This could be BSD or USL
Then they started a lawsuit
And they showed me the way
There were salesmen down the corridor
I thought I heard them say
... ... ... ... ... ... ...
All those backups seemed a waste of pay.
Now my database has gone away.
Oh I believe in yesterday.
There's not half the files there used to be,
And there's a milestone hanging over me
The system crashed so suddenly.
I pushed something wrong
What it was I could not say.
Now all my data's gone
and I long for yesterday-ay-ay-ay.
The need for back-ups seemed so far away.
I knew my data was all here to stay,
Now I believe in yesterday.
Notes from some recent archeological findings on the birth of the UNIX cult on Sol 3 are presented. Recently discovered electronic records have shed considerable light on the beginnings of the cult. A sketchy history of the cult is attempted.
This article was written in 1984 and was published in various UNIX newsletters across the world. I thought that it should be revived to mark the first 25 years of UNIX. If you like this, then you might also like The UNIX Cult.
,,, ,,, ,,,
"VisTech is your one-stop source for Internet and Intranet open source development, as well as open source software support and collaborative development" said Smuda, adjusting the toupee he has worn since age 23. "We are a full-service company that can evaluate and integrate multi-platform open source solutions, including Linux, Solaris, Aix and HP-UX"
"Remember, no job is too small for the professionals at VisTech," added the spouseless, childless man, who is destined to die alone and unloved. "And no job is too big, either."
By R. Lawrence Clark*
From DATAMATION, December, 1973
Nearly six years after publication of Dijkstra's now-famous letter,  the subject of GOTO-less programming still stirs considerable controversy. Dijkstra and his supporters claim that the GOTO statement leads to difficulty in debugging, modifying, understanding and proving programs. GOTO advocates argues that this statement, used correctly, need not lead to problems, and that it provides a natural straightforward solution to common programming procedures.
Numerous solutions have been advanced in an attempt to resolve this debate. Nevertheless, despite the efforts of some of the foremost computer scientists, the battle continues to rage.
The author has developed a new language construct on which, he believes, both the pro- and the anti-GOTO factions can agree. This construct is called the COME FROM statement. Although usage of the COME FROM statement is independent of the linguistic environment, its use will be illustrated within the FORTRAN language.
AT YOUR LAST JOB INTERVIEW, YOU EXHIBITED:
B. Mild Wariness
C. Tried to overcome headache. I was really tied
D. Controlled Hostility
2. DESCRIBE YOUR WORKPLACE:
A. An enterprising, dynamic group of individuals laying the groundwork for tomorrow's economy.
B. A bunch of geeks with questionable social skills.
C. An anxiety-ridden, with long hours and a lot of stress because of backbiting bunch of finger-pointers.
D. Jerks and PHB
3. DESCRIBE YOUR HOME:
A. Small, but efficient.
B. Shared and dormlike.
C. Rubble-strewn and fetid.
D. I have a personal network at my home with three or more connected computers and permanent connection to the Internet
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".
Horror Stories www.lbl.gov Dr. Bombay: Where to Find the `Any' Key and other stories
December 23, 1999
- Thou shalt not worry about bugs. Bugs in your software are actually special features.
- Thou shalt not fix abort conditions. Your user has a better chance of winning state lottery than getting the same abort again.
- Thou shalt not handle errors. Error handing was meant for error prone people, neither you or your users are error prone.
- Thou shalt not restrict users. Don't do any editing, let the user input anything, anywhere, anytime. That is being very user friendly.
- Thou shalt not optimize. Your user are very thankful to get the information, they don't worry about speed and efficiency.
- Thou shalt not provide help. If your users can not figure out themselves how to use your software than they are too dumb to deserve the benefits of your software any way.
- Thou shalt not document. Documentation only comes in handy for making future modifications. You made the software perfect the first time, it will never need mods.
- Thou shalt not hurry. Only the cute and the mighty should get the program by deadline.
- Thou shalt not revise. Your interpretation of specs was right, you know the users' requirements better than them.
- Thou shalt not share. If other programmers needed some of your code, they should have written it themselves.
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) 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.
Created June 1, 1998; Last modified: September 12, 2017