Programming in Plato’s Cave 185...The third time that Berkeley released a version of make with the same
bug present, the hackers at BBN gave up. Instead of fixing the bug in Ber-
keley make, they went through all of their Makefiles, found the lines that
began with spaces, and turned the spaces into tabs. After all, BBN was pay-
ing them to write new programs, not to fix the same old bugs over and over
again.
(According to legend, Stu Feldman didn’t fix make’s syntax, after he real-
ized that the syntax was broken, because he already had 10 users.)
The Source Is the Documentation. Oh, Great!
If it was hard to write, it should be hard to understand.—A Unix programmerBack in the documentation chapter, we said that Unix programmers believe
that the operating system’s source code is the ultimate documentation.
“After all,” says one noted Unix historian, “the source is the documentation
that the operating system itself looks to when it tries to figure out what to
do next.”
But trying to understand Unix by reading its source code is like trying to
drive Ken Thompson’s proverbial Unix car (the one with a single “?” on its
dashboard) cross country.
The Unix kernel sources (in particular, the Berkeley Network Tape 2
sources available from ftp.uu.net) are mostly uncommented, do not skip
any lines between “paragraphs” of code, use plenty of goto’s, and gener-
ally try very hard to be unfriendly to people trying to understand them. As
one hacker put it, “Reading the Unix kernel source is like walking down a
dark alley. I suddenly stop and think ‘Oh no, I’m about to be mugged.’ ”
Of course, the kernel sources have their own version of the warning light.
Sprinkled throughout are little comments that look like this:
/* XXX */These mean that something is wrong. You should be able to figure out
exactly what it is that’s wrong in each case.