Proverbs, aphorisms, quotations (English) | by Linux fortune |
A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: "How long will it take to design this system if I assign five programmers to it?" "It will take one year," said the master promptly. "But we need this system immediately or even sooner! How long will it take it I assign ten programmers to it?" The master programmer frowned. "In that case, it will take two years." "And what if I assign a hundred programmers to it?" The master programmer shrugged. "Then the design will never be completed," he said. -- Geoffrey James, "The Tao of Programming" | |
I'm sure that VMS is completely documented, I just haven't found the right manual yet. I've been working my way through the manuals in the document library and I'm half way through the second cabinet, (3 shelves to go), so I should find what I'm looking for by mid May. I hope I can remember what it was by the time I find it. I had this idea for a new horror film, "VMS Manuals from Hell" or maybe "The Paper Chase : IBM vs. DEC". It's based on Hitchcock's "The Birds", except that it's centered around a programmer who is attacked by a swarm of binder pages with an index number and the single line "This page intentionally left blank." -- Alex Crain | |
If you ever want to have a lot of fun, I recommend that you go off and program an imbedded system. The salient characteristic of an imbedded system is that it cannot be allowed to get into a state from which only direct intervention will suffice to remove it. An imbedded system can't permanently trust anything it hears from the outside world. It must sniff around, adapt, consider, sniff around, and adapt again. I'm not talking about ordinary modular programming carefulness here. No. Programming an imbedded system calls for undiluted raging maniacal paranoia. For example, our ethernet front ends need to know what network number they are on so that they can address and route PUPs properly. How do you find out what your network number is? Easy, you ask a gateway. Gateways are required by definition to know their correct network numbers. Once you've got your network number, you start using it and before you can blink you've got it wired into fifteen different sockets spread all over creation. Now what happens when the panic-stricken operator realizes he was running the wrong version of the gateway which was giving out the wrong network number? Never supposed to happen. Tough. Supposing that your software discovers that the gateway is now giving out a different network number than before, what's it supposed to do about it? This is not discussed in the protocol document. Never supposed to happen. Tough. I think you get my drift. | |
The Gurus of Unix Meeting of Minds (GUMM) takes place Wednesday, April 1, 2076 (check THAT in your perpetual calendar program), 14 feet above the ground directly in front of the Milpitas Gumps. Members will grep each other by the hand (after intro), yacc a lot, smoke filtered chroots in pipes, chown with forks, use the wc (unless uuclean), fseek nice zombie processes, strip, and sleep, but not, we hope, od. Three days will be devoted to discussion of the ramifications of whodo. Two seconds have been allotted for a complete rundown of all the user- friendly features of Unix. Seminars include "Everything You Know is Wrong", led by Tom Kempson, "Batman or Cat:man?" led by Richie Dennis "cc C? Si! Si!" led by Kerwin Bernighan, and "Document Unix, Are You Kidding?" led by Jan Yeats. No Reader Service No. is necessary because all GUGUs (Gurus of Unix Group of Users) already know everything we could tell them. -- "Get GUMMed," Dr. Dobb's Journal, June '84 | |
Bierman's Laws of Contracts: (1) In any given document, you can't cover all the "what if's". (2) Lawyers stay in business resolving all the unresolved "what if's". (3) Every resolved "what if" creates two unresolved "what if's". | |
Consent decree: A document in which a hapless company consents never to commit in the future whatever heinous violations of Federal law it never admitted to in the first place. | |
Kaufman's Law: A policy is a restrictive document to prevent a recurrence of a single incident, in which that incident is never mentioned. | |
[ ] Safeguard this message - it is an important historical document. [ ] Delete after reading -- Subversive Literature. [ ] Ignore and go back to what you were doing. | |
Q: How many hardware engineers does it take to change a light bulb? A: None. We'll fix it in software. Q: How many system programmers does it take to change a light bulb? A: None. The application can work around it. Q: How many software engineers does it take to change a light bulb? A: None. We'll document it in the manual. Q: How many tech writers does it take to change a light bulb? A: None. The user can figure it out. | |
Q: How many IBM types does it take to change a light bulb? A: Fifteen. One to do it, and fourteen to write document number GC7500439-0001, Multitasking Incandescent Source System Facility, of which 10% of the pages state only "This page intentionally left blank", and 20% of the definitions are of the form "A:..... consists of sequences of non-blank characters separated by blanks". | |
Q: How many lawyers does it take to change a light bulb? A: Whereas the party of the first part, also known as "Lawyer", and the party of the second part, also known as "Light Bulb", do hereby and forthwith agree to a transaction wherein the party of the second part shall be removed from the current position as a result of failure to perform previously agreed upon duties, i.e., the lighting, elucidation, and otherwise illumination of the area ranging from the front (north) door, through the entryway, terminating at an area just inside the primary living area, demarcated by the beginning of the carpet, any spillover illumination being at the option of the party of the second part and not required by the aforementioned agreement between the parties. The aforementioned removal transaction shall include, but not be limited to, the following. The party of the first part shall, with or without elevation at his option, by means of a chair, stepstool, ladder or any other means of elevation, grasp the party of the second part and rotate the party of the second part in a counter-clockwise direction, this point being tendered non-negotiable. Upon reaching a point where the party of the second part becomes fully detached from the receptacle, the party of the first part shall have the option of disposing of the party of the second part in a manner consistent with all relevant and applicable local, state and federal statutes. Once separation and disposal have been achieved, the party of the first part shall have the option of beginning installation. Aforesaid installation shall occur in a manner consistent with the reverse of the procedures described in step one of this self-same document, being careful to note that the rotation should occur in a clockwise direction, this point also being non-negotiable. The above described steps may be performed, at the option of the party of the first part, by any or all agents authorized by him, the objective being to produce the most possible revenue for the Partnership. | |
Jargon Coiner (#3) An irregular feature that aims to give you advance warning of new jargon that we've just made up. * LILOSPLAININ': Arduous process of explaining why there's now a LILO boot prompt on the office computer. Example: "John had some lilosplainin' to do after his boss turned on the computer and the Windows splash screen didn't appear." * UPTIME DOWNER: Depression that strikes a Linux sysadmin after his uptime is ruined. Can be caused by an extended power outtage, a pet chewing through the power cord, a lightning bolt striking the power line, or an urgent need to reboot into Windows to read a stupid Word document. * OSTR (Off-Switch Total Recall): The sudden recollection of something terribly important you need to do online that occurs exactly 0.157 seconds after you've shut down your computer. | |
Linux World Domination: Not A Joke! WASHINGTON, D.C. -- Senator Fattecat (R-WA) is pushing for a ban on Finnish-produced software. His chief of staff, Ms. Dee Septive, has published a 200-page report revealing "the Helsinkian Underground", a Finnish world domination plot hatched in 1943. The Fattecat expose describes Finland's recent scheme involving free software. "Linux, originally called Freix (FREIX Retrieves Electronic Intelligence X), is a scheme to infiltrate the Western world with a 'free' operating system with nasty backdoors hidden within its obfuscated source code. IRC (Intelligence Relaying Code) is another Finnish innovation designed for spying purposes." Linus Torvalds plays a prominent role in the conspiracy. "That old story about Linus developing a Unix clone in his spare time while at University is a lark," the report states. "Indeed, the name Linux ("Line X") was coined because the kernel can extract any arbitrary line of intelligence from any document it has access to." | |
Brief History Of Linux (#1) Re-Inventing the Wheel Our journey through the history of Linux begins ca. 28000 B.C. when a large all-powerful company called MoogaSoft monopolized the wheel-making industry. As founder of the company, Billga Googagates (rumored to be the distant ancestor of Bill Gates) was the wealthiest man in the known world, owning several large rock huts, an extravagant collection of artwork (cave paintings), and a whole army of servants and soldiers. MoogaSoft's unfair business practices were irritating, but users were unable to do anything about them, lest they be clubbed to death by MoogaSoft's army. Nevertheless, one small group of hobbyists finally got fed up and starting hacking their own wheels out of solid rock. Their spirit of cooperation led to better and better wheels that eventually outperformed MoogaSoft offerings. MoogaSoft tried desperately to stop the hobbyists -- as shown by the recently unearthed "Ooga! Document" -- but failed. Ironically, Billga Googagates was killed shortly afterwards when one his own 900-pound wheels crushed him. | |
Clippit Charged With Attempted Murder Microsoft's Dancing Paper Clip turned violent last week and nearly killed a university student testing a new Windows-based human-computer interface. The victim is expected to make a full recovery, although psychiatrists warn that the incident may scar him emotionally for life. "You can bet this kid won't be using Windows or Office ever again," said one shrink. The victim had been alpha-testing CHUG (Computer-Human Unencumbered Groupware), a new interface in which the user controls the computer with force-feedback gloves and voice activation. "I was trying to write a term paper in Word," he said from his hospital bed. "But then that damned Dancing Paper Clip came up and started annoying me. I gave it the middle finger. It reacted by deleting my document, at which point I screamed at it and threatened to pull the power cord. I didn't get a chance; the force-feedback gloves started choking me." "We told Clippit it had the right to remain silent, and so on," said a campus police officer. "The paperclip responded, 'Hi, I'm Clippit, the Office Assistant. Would you like to create a letter?' I said, 'Look here, Mr. Paperclip. You're being charged with attempted murder.' At that point the computer bluescreened." | |
"And I doubt complaining to the author gets you anything but a free procmail rule." - Alan Cox on asking authors to document their code | |
* knghtbrd can already envision: "Subject: [INTENT TO PREPARE TO PROPOSE FILING OF BUG REPORT] Typos in the policy document" | |
> >I don't really regard bible-kjv-text as a technical document, > > but... :) > It's a manual -- for living. But it hasn't been updated in a long time, many would say that it's sadly out of date, and the upstream maintainer doesn't respond to his email. :-) -- Branden Robinson, Oliver Elphick, and Chris Waters in a message to debian-policy | |
"Since it's a foregone conclusion that Microsoft will be littering its XML with pointers to Win32-based components, the best that can be said about its adoption of XML is that it will make it easier for browsers and applications on non-Windows platforms to understand which parts of the document it must ignore." -- Nicholas Petreley, "Computerworld", 3 September, 2001 | |
If I don't document something, it's usually either for a good reason, or a bad reason. In this case it's a good reason. :-) -- Larry Wall in <1992Jan17.005405.16806@netlabs.com> |