Does the decompressor have to be wholly hosted locally? Could it just be a shim that pulls a more complex program from the net?
There are grey areas here. Does a decompressor that depends on linked libraries count? Do things like libc count towards the total decompressor size?
I know this was written 14 years ago, but we had the net then, and shared libraries aren't exactly a new thing. Where do you draw the line? Can any decompression code call an external dependency and not be disqualified in the same way?
I'd say that using the filesystem to "hide" bytes is the least of the possible loop-holes with this challenge, if you were being pedantic about the rules.
> Does the decompressor have to be wholly hosted locally? Could it just be a shim that pulls a more complex program from the net?
The judge can disconnect his computer from the Internet, attempt to run the submitted decompressor and file, and declare failure when it doesn't work. Nothing in the challenge guarantees Internet connectivity on the machine.
> Does a decompressor that depends on linked libraries count? Do things like libc count towards the total decompressor size?
Nope. In the email exchange, Mike said that just a script that called out to gunzip would be fine, and that he'd only count the size of the script as the decompressor size
> Where do you draw the line? Can any decompression code call an external dependency and not be disqualified in the same way?
Yup, as long as the dependency is already on the machine I suppose.
That's what's so enlightening about this challenge. Even a tiny, tiny script that calls to other programs still can't compress a "pathologically" random file by more than a few bytes.
>Yup, as long as the dependency is already on the machine I suppose.
That's exactly what I was getting at.
If gzip was allowed, then any common decompression utility should be allowed.
If that's the case, and said utility relies on an external library, should that library be included as part of the size of the decompression utility?
It's arguable that the "fabric" over which the data is delivered shouldn't matter. If shouldn't really matter if the linked library comes from the same SSD as the executable, or from a server on the other side of the world.
We currently define "the machine" as the internals of a box. Would this count if you were running the executable from a removable drive? If not, why does "network storage" trigger the disqualification, and not "USB storage"?
I understand the original premise of Mike's challenge, but considering a loophole is being discussed here, I'd like to know where people see that the boundaries of similar loopholes lie.
There are grey areas here. Does a decompressor that depends on linked libraries count? Do things like libc count towards the total decompressor size?
I know this was written 14 years ago, but we had the net then, and shared libraries aren't exactly a new thing. Where do you draw the line? Can any decompression code call an external dependency and not be disqualified in the same way?
I'd say that using the filesystem to "hide" bytes is the least of the possible loop-holes with this challenge, if you were being pedantic about the rules.