Slashdot Mirror
Linux Kernel Code Humor
An anonymous reader writes "This article points to some pretty funny comments and code in the Linux kernel. From colorful metaphors, to burning printers, to happy meals... A recursive search through the entire code base reveals some interesting language. Is all code like this?"
In the days when I was a die-harder coder (unlike the current easy life as a part time manager and part time developer) I used to keep my diary and calendar in code comments - those were, of course, the days without funky handhelds with funkier PIM systems :-) *sigh* The good old days....
-- Gaxx
A couple years ago the company I'm working for had sold the source to one of their business commerce systems to another company. The comments were sprinkled with some superlatives such as 'fuck' and 'son of a bitch' not to mention that there were a few other not-so-nice comments about other products like 'since this fucking windows bug' or what not heh. This other company was NOT very happy at all. It resulted in one person being let go when there were some small "budget" problems even though they just sold some software for over a million and this company wasn't very large (under 20). After he was let go they hired 3 new people. Lukly I just started about a week before this happened so I never got in trouble. Anyway, now the management scans the comments periodically to look for colorful words.
Ahh found the exact line:
/* linux, which is trying as desperately as the gnu folks can to be POSIXLY_CORRECT. I think I'm gonna hurl... */ -- *Hobbit*, taken from the netcat source
-sirket
In the VM subsystem for the Sun-3 kernel, about late 1986 I think, there appeared the following:
... /* You are not expected to understand this */
panic("Shannon and Bill say this can't happen");
One of the first mass market Unix boxes was sold through the now-defunct line of Tandy computer stores and contained a 68000 and a Z-80 as an I/O processor. They apparently had problems with the Z-80 going insane periodically. This would be noticed by the 68000 which would then...
panic("Beam us up Scotty, she's sucking mud again");
Of course the most famous of all is the comment in the task switching code of the original v6 Unix (Lyons commentary era) which said
I guess this is why Road Runner stuck me with one of these things.
They probably don't pay as much per unit as a decent chocolate bar.
It brings up an interesting use for having source though, even if you don't code. Before buying a particular bit of hardware it might be interesting to read the driver comments to see what the programer thought of the thing at the low level.
KFG
... (or maybe not) i usually find more funny comments in code from people who actually like coding (and are good at it) than from code monkeys .
While this comment is humorous, it's also very deep. It shows that the coder understood what he was doing well enough to know that the behavior wasn't as expected... and anyone else touching the same code should expect problems.
It's rare, thankfully, but it is possible for code to trigger obscure compiler or even CPU bugs. These can be virtually impossible to track down, esp. if your boss is (justifiably) skeptical of your claim that the problem has to be in the compiler. In these cases the best you can do is flag the code as something that's very flaky.
(BTW, I have some personal experience with such code. I just hit one with a PNG decoder - one mode had a rare decoder error that would flip one pixel, but the mode meant that the error was propagated across multiple scan lines. A very careful review of the code showed no error, and when I tested the code on different hardware (a PC, not an embedded device) it worked perfectly on the same images. Therefore it has to be the cross-compiler or hardware, and all I could do was document the problem.)
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
I remember reading this as part of a warning really. There was a mainframe app, and there was a constant, and it was called BDOLVB. Some maintenance programmers inherited the system, and saw the obove constant, and didn't know what the hell it was. They tried to look it up, figure out what the meaning was, and they couldn't figure it out. They could see what it was set to, 1770 Octal, but didnt know what it meant. They put looking into it on the back-burner - the system worked but they were stil curious about the meaning. Eventually, after months, they found oout what it meant.
1770 = BirthDate Of Lidwig Van Beethoven
Since they spun their wheels for a few days tracking this down, they weren't smiling all that much at the cleverness of this.
The thing to remember is that code is harder to read than to write. The author has context, information that the reader doesn't have and has to guess at. If you want to be funny, do so, but don't interfere with the ultimate goal of source, to make it easy for people to see and change your code.