3 ms·
The time for complaining about xz has well and truly passed. One might infer that the problems with xz are related to the attitude of other developers... But I
by angry_octet 10y ago
The time for complaining about xz has well and truly passed. One might infer that the problems with xz are related to the attitude of other developers...
But I dogress. When you create archival packups you use must use error correcting systems. Par is a good place to start.
https://multipar.eu/ https://multipar.eu/
https://github.com/Parchive/par2cmdline https://github.com/Parchive/par2cmdline
- rincebrain 10y agoWhile I agree that you should use PAR-like error correction systems when doing archival, one of the points of the article is that xz has poor error detection and recovery, compared to any of the other formats available. If it offered none, and explicitly stated that, it would be one thing, but it offers some that functions quite poorly in practice, which is rather another.
- angry_octet 10y agoIt's only a problem if you are relying in it to detect and correct errors. I've got SHA checksums and FEC and ZFS and cascading backups for that, which are deliberately not relying on one code provider not having critical bugs. Also, I may have crypto, and I need error detection and FEC on the outside of that. So it seems like a storm in a teacup really. I think there is scope in xz to embed some FEC in the archive as a backwards compatible extension. Not such if the decoding scheme could be changed to reduce error cascades etc.