No one is actually dead until the ripples they cause in the world die away
There is a lot of code out there "on the wire".
If you follow Going Postal you will know the story of John Dearheart, a clacksman who was murdered. Like many who have died running the "clacks" (the discworld's version of a telegraph system) his name lives on. The message "GNU John Dearheart" continues. G means send on the message, N means not-logged, and U means return the message at the end of the line. This makes a datagram that continually bounces around the network.
IP as a protocol has a time-to-live (or hop-count) that stops a message going on forever, but for the names of those who should continue, we do not want a "time to live".
It seems that many systems and software around he world are finding GNU Terry Pratchett "on the wire".
Indeed, even the latest FireBrick alpha has a header, X-Clacks-Overhead: GNU Terry Pratchett in the software. His name will live on for a long time, buried in the code of the very Internet itself.
Rather than do this is a header in HTTP, which does add overhead, we have a different plan. It seems we had a slight issue with the code to handle small Ethernet packets (under 64 bytes) which ensures they are padded consistently (with NULL bytes). The internal operation of the FB2500/FB2700 was such that the last 4 bytes were not NULL. In practice this was not a leak of other buffers but an Ethernet checksum of an internal packet with a VLAN tag. However, the fix is to ensure the packets are sent with padding to 68 bytes before the VLAN tag is removed. OK, yes, this is technical.
However, padding can be anything, it does not have to be NULLs, so this is perhaps a far better place for this particular Easter Egg. On a zero payload IPv4 ICMP ping, we have 18 bytes to play with, which is one short for "GNU Terry Pratchett", but with one space removed, it aligns nicely on a packet dump as follows. In fact, ARP replies have exactly the same amount of space...
Now, yes, as one person has said, this is silly, but the actual content of the padding really does not matter at all, and can be anything. There is no harm, or waste in it being this string - so why not?
I'd like to get this in to an RFC http://www.me.uk/draft-kennard-padding.txt and I have emailed to the auditors of reality (I mean RFC editors) today (17th). P.S. I was considered but rejected, sorry.