Topic: Programming/Coder humor (Read 247,422 times)
From Novice to Master, and Back Again
In 1985, I was a freshman at St. Olaf College in Minnesota. The college had a VAX 11/780 running 4.2BSD and a PDP-11/70 running v7 with some Berkeley and local code hacked in. It was my first experience with multi-user systems other than dialing into an MS-DOS BBS or two.
The college’s Academic Computing Center had printouts of the 4.2BSD manuals, plus some home-grown documentation, available for sale so students could learn how to use UNIX. One week I sat in the Science Center terminal room and started going through the alphabetical list of the commands available on the VAX, trying each one and reading its man page to learn what it did.
Eventually I got to “su”. “Become the super-user”? What’s that? Does it involve wearing a cape? Sounds interesting, so I tried it. To my disappointment, it just asked for a password, and wouldn’t do anything.
Shortly thereafter, someone came running into the room and asked, “Are you David MacKenzie? Did you just run ‘su’?” “Yeah… what does it do?” “Uh, don’t do that.” My failed “su” attempt had been logged on the system console and one of the sysadmins was worried about an attempted breakin.
Within a year, I did have root access on the VAX, as I learned enough to be hired as a student system programmer. I contributed to upgrading the machine to 4.3BSD when that was released.
Recently I was working on a CentOS Linux virtual machine and needed to look up the command-line options to “su”. I had worked for the past several years mostly on Macs where “sudo” is preferred, so my “su” skills were rusty. I ran “man su” and got the information I needed. Then at the bottom of the screen I sheepishly read “Written by David MacKenzie.”
In the 1990s, while filling in gaps in the GNU toolset, I wrote the GNU “su”, and I had forgotten about it. It’s still what Red Hat and other distributions are shipping.
At least I know what it does now.
(see attachment in previous post)
public static DateTime
getYesterdaysDate() {
DateTime yesterday = DateTime.Now;
Thread.Sleep(24*60*60*1000);
return yesterday;
}
This is my favorite bit of prank code. On non-microchannel machines running OS/2 you could hang the machine using debug in a Dos window to create this program.
cli
jmp $
I think they finally virtualized the Dos interrupt flags in OS/2 2.1 which eliminated the hang. On microchannel a non maskable interrupt would fire after so many milliseconds if the interrupt flag was not reset.
This is my favorite bit of prank code. On non-microchannel machines running OS/2 you could hang the machine using debug in a Dos window to create this program.
cli
jmp $
I think they finally virtualized the Dos interrupt flags in OS/2 2.1 which eliminated the hang. On microchannel a non maskable interrupt would fire after so many milliseconds if the interrupt flag was not reset.
I know it's old and retro, but I think I remember from one summer camp (maybe?? heh! ) That you wreck the hardware of a BBC Micro with some bunch of commands that could even start a fire!
^
That belongs in the code humour thread!
Q: How do you tell an introverted computer scientist from an extroverted computer scientist?
A: An extroverted computer scientist looks at your shoes when he talks to you.
[ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo *Click*
I was telling my friends a TCP joke the other day; I had to keep repeating it slower and slower until they got it.
QuoteI was telling my friends a TCP joke the other day; I had to keep repeating it slower and slower until they got it.
Network Working Group R. Callon, Editor
Request for Comments: 1925 IOOF
Category: Informational 1 April 1996
The Twelve Networking Truths
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This memo documents the fundamental truths of networking for the
Internet community. This memo does not specify a standard, except in
the sense that all standards must implicitly follow the fundamental
truths.
Acknowledgements
The truths described in this memo result from extensive study over an
extended period of time by many people, some of whom did not intend
to contribute to this work. The editor merely has collected these
truths, and would like to thank the networking community for
originally illuminating these truths.
1. Introduction
This Request for Comments (RFC) provides information about the
fundamental truths underlying all networking. These truths apply to
networking in general, and are not limited to TCP/IP, the Internet,
or any other subset of the networking community.
2. The Fundamental Truths
(1) It Has To Work.
(2) 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.
Callon Informational [Page 1]
RFC 1925 Fundamental Truths of Networking 1 April 1996
(3) 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.
(4) 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.
(5) It is always possible to aglutenate multiple separate problems
into a single complex interdependent solution. In most cases
this is a bad idea.
(6) 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.
(7) It is always something
(7a) (corollary). Good, Fast, Cheap: Pick any two (you can't
have all three).
(8) It is more complicated than you think.
(9) 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.
(10) One size never fits all.
(11) 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.
(12) In protocol design, perfection has been reached not when there
is nothing left to add, but when there is nothing left to take
away.
Callon Informational [Page 2]
RFC 1925 Fundamental Truths of Networking 1 April 1996
Security Considerations
This RFC raises no security issues. However, security protocols are
subject to the fundamental networking truths.
References
The references have been deleted in order to protect the guilty and
avoid enriching the lawyers.
Author's Address
Ross Callon
Internet Order of Old Farts
c/o Bay Networks
3 Federal Street
Billerica, MA 01821
Phone: 508-436-3936
EMail: rcallon@baynetworks.com
Callon Informational [Page 3]
Original address: https://www.donationcoder.com/forum/index.php?topic=35756.0
