Hacker News Reader

Comment by jpablo | Hacker News Reader

I wonder if Mike Goldman ever made a response after everything was published. I found very distasteful when he threatened to accuse Patrick of fraud.

He should have recognized that the rules where vaguely stated and at the very least offer an apology. Plain refusing to download all his files, when he had expressly accepted multiple files at being ok was kind of weird.

The google groups link in the page no longer works so I wonder if that's archived elsewhwere.

View on HN

> when he threatened to accuse Patrick of fraud

Exactly. He was the one committing the fraud.

To quote Mike Goldman (fta): "I cannot fathom that someone would read the comp.compression faq first and then want to participate after understanding the futility of the effort. On the other hand, some people just don't understand information theory too well."

He took $100 from this guy knowing he was frauding him! It was like watching a game of nerd 3-card monte.

Exactly, I consider Mike to be acting in bad faith here. Mike was willing to accept $100 (which in most of the world constitutes many hours of labor) not just once, but every time people wanted to play again. He was willing to accept real money for something that he believed was literally impossible. Mike didn't hint at the impossibility in any way. E.g. if he had said "Have you read the FAQ and you still sure you want to play?" I would view it in different light. But no, Mike seemed all to eager to accept the money.

So yes, then when a taker appears he's either not very bright (and therefore you shouldn't take advantage of him) or he's trying to out-hussle (and playing legalese with the terms is then fair game). After Mike got beaten at his own game he then continued to (a) weasel out of it (b) threaten legal action (c) attempt to deflect.

Not exactly a class act by Mike.

>The google groups link in the page no longer works so I wonder if that's archived elsewhwere.

Here you go: https://groups.google.com/d/msg/comp.compression/sSC04FEoAqE...

The rules weren't vague, but they relied on a rational (as opposed to legalistic) understanding of what it means to compress data.

He said he would accept multiple files; he did not however agree to change the rules of the game, which unambiguously required "a decompressor and a compressed file."

A compressed file, as in a single file, which has been compressed.

Patrick returned roughly 200 files, none of which were compressed. Thus, he did not complete the challenge, technically or legally.

EDIT: This is the crucial part: the files were not compressed by gzip. They were merely collected into a single archive (no compression), and some of the data from each file was moved into the file's name (no compression). IOW, the archive size of each chunk of data was the same as the filesystem size.

Your rejection based on the rule change makes no sense. Mike very clearly agreed to a change in the rules of the game. "can I send you a [de]compressor and several compressed files whose total file size is less than the original uncompressed file and from which I can regenerate the original uncompressed file." "Sure"

Also your rejection based on the files not being compressed is not going to work. I can get around it in only a few seconds of effort:

Let's say I have a theory that gzip works more efficiently when you don't have too many 1 bits in a row. I make a script to extract all the 0xFF bytes and compress each chunk (I might have to strip headers or use a compression algorithm that's better at dealing with random data without expansion, but that's not a huge hurdle.). Is this compression somehow not good enough? It's definitely a meaningful transform of the original data, with the chunks coming out wildly differently.

In fact allowing both a decompressor and a compressed file is a bad idea in the first place. If you get a sufficiently compact language and large file you can achieve compression on any file by the original wording. Split the data between the two files, this will give you n free bits based on where you split. Then make your decompressor, as part of some process subjectively qualifying as 'decompression', incorporate these extra bits.

Mike should have simply said "a .tar with the compressed file and decompressor, which is smaller than the original file".

Reply on news.ycombinator.com