Tractor4973

5 ms·

1.
by Tractor4973 12y ago
Yes it is
2.
by Tractor4973 12y ago
Actually, the test code and the benchmark suite are present within the FSE project (linked from the article)
3.
by Tractor4973 12y ago
Yeah, it could be that both discovered the vulnerability independently. It's just that, from a timing perspective, Ludwig found it first, and provided explanations which where accessible and readable to all on the public board. It does
4.
by Tractor4973 12y ago
Current kernel users : zRam, SquashFS, BTRFS, BootLoader First 3 use small block sizes, KB range. Last one used the LZ4 file format, which limits blocks to 8 MB. Yes, there is no kernel program at risk right now, but it's nonetheless g
5.
by Tractor4973 12y ago
Of course, this argument is totally nuts. 2^64 of RAM is not accessible, period. It's ludicrous to pretend that a code delivered today should take into consideration a potential issue that might happen in 30 years from now. Frankly, yo
6.
by Tractor4973 12y ago
btw : http://fastcompression.blogspot.fr/2014/06/lets-move-on.html
7.
by Tractor4973 12y ago
The LZ4 Memory corruption was already fully described at the LZ4 issue board, and accepted by the LZ4 author. What is this article supposed to learn us ?
8.
by Tractor4973 13y ago
Golomb is way too static, it doesn't compress as well as Huffman, let alone FSE.
9.
by Tractor4973 13y ago
Same of Q-Coder : "The Q-Coder is a new form of adaptive binary arithmetic coding"
10.
by Tractor4973 13y ago
The Howard-Vitter coder only works for binary alphabet (0/1).
11.
by Tractor4973 14y ago
This reminds me of this game for HP48. It had some pretty graphics for the time, using 4-grey colors with LCD timing tricks. Unfortunately, it also meant the game was heavy (40KB!). And even more unfortunately, some HP48 emulators (most imp