The world's smallest self-replicating program

Did their naive decompression make the genome longer? If so, it probably didn't fit in the capsid. In our version, we had to provide one of the genes (gene F) in a plasmid in the host cell, in order to reduce the length of the decompressed genome to fit inside the capsid. See this section of our paper:

[The naive] decompression added 909 nucleotides to the wild-type genome. We next addressed practical constraints arising from the length of DNA that can be physically packaged within a øX174 capsid without impacts to reproductive fitness. Previous work has shown that the length of a øX174 genome, when packaged in vitro, must be kept within a few percent of the 5386 nucleotide wild-type length in order to avoid any significant fitness decrease ( Aoyama and Hayashi, 1985). Similar results were shown in vivo ( Russell and Muller, 1984). To reduce the decompressed genome length we removed the first 916 nucleotides of gene F, encoding the coat protein ( Air et al., 1978). We chose gene F because a plasmid containing a restriction fragment encoding wild-type gene F was able to complement two conditional gene F mutations ( Avoort et al., 1983). Additionally, the gene F coding sequence is greater than the total of the combined increases needed to implement the øX174.1 genome design. The truncated gene F version of the decompressed genome was named øX174.1f. To complement øX174.1f when transformed into host cells we designed a medium copy vector expressing gene F under control of a rhamnose-inducible promoter ( Fig. S1).

Gene overlap is extremely rare actually! When phiX174 was first discovered, some researchers wondered if such a complexly intertwined system could even have evolved naturally, or if it might suggest that the virus was hand-engineered: http://adsabs.harvard.edu/abs/1979Icar...38..148Y

I would think the opposite may be true, given that compressed information tends to be more sensitive to error, than uncompressed.

Interesting that this works at all. Perhaps it's special-cased?

No, without a shebang it is interpreted as a shell script.

No file on common unix platforms is interpreted directly as machine code. Machine code executables have headers which contain information on the environment needed, memory mappings, program entry points etc. Binary executables are not just immediately jumped into, they must be opened by a loader which will parse these headers and do the required work before continuing execution in the program itself.

A zero-length binary fed into either ld.so (a.out loader) or ld-linux.so (elf loader) will not produce a zero-length output, but a parsing error.

every self replicating entry in the competition is compiled with other binaries.

Done.

I'll be darned if I can find the URL to the story, but it is a brilliant application of giving the customer what they wanted.

The short of it is that when you dropped back to the command line, early versions of DOS didn't clear the memory. That meant that the program really just went into stasis, but in practice it meant restarting; see, the program ran off the floppy then, so to save or load to another disk was tricky. Because memory would be executed from the same address, you could insert this disk with an empty executable that would get DOS to send execution to that address, which happens to be the program already in memory.

This had the huge boon of allowing you to drop to the command line, do something, and the resume working! Apparently they sold the disks for like $5 (or pounds) each, and the customers were extremely pleased. And the programmer was got a kick out of having rather impressive return per byte written :)

I disagree. You are copying something exactly. Just because that something is empty does not mean it's not being copied. Using cp, by definition of the command, is copying something.

The empty set is a subset of the empty set.

Exactly, and that someone is the humble "Diogenes of Sinope"