3 ms·
I very strongly disagree with the author's complaint that "Xz is unreasonably extensible". The history of computers is littered by numbers and numbers of restr
by mrb 10y ago
I very strongly disagree with the author's complaint that "Xz is unreasonably extensible". The history of computers is littered by numbers and numbers of restrictive design choices that ended up biting us in the ass later. Let's design FAT12. Oops a 32MB file size limit is no longer sufficient? Let's make FAT16, err I mean FAT32, err no really NTFS... How about 7-bit ASCII, err 8-bit ISO-8859, err I mean 16-bit Unicode, err no I really mean 32-bit Unicode, now that should be sufficient, right?
So it was the right choice for the Xz format to use variable-length integer encoding. Not all integer fields will need to represent values up to 2^63, but it doesn't matter.
- TD-Linux 10y agoI don't think the variable-length encoding itself is the author's concern, it's adding additional filters later without an overall version number. Unlike long file names in FAT32, adding additional filters is not backwards compatible. With a version number, it's super clear what can decode a file. Without, your xz file is only decodeable if your decoder implements the same set of filters as the encoder, rather than the much simpler approach of gzip where any gzip decoder can decode any gzip file.