Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide
Andrew Shadura wrote:
Why haven't you just fixed dd_rescue instead of creating one more tool?
I wrote ddrescue instead of fixing dd_rescue because the algorithm of
ddrescue is orders of magnitude more complex than the simple linear read
performed by dd_rescue. Treating failing drives gently is a difficult
The fact is that the algorithm of dd_rescue seems designed to break
failing drives instead of recovering data from them.
"Other programs [dd_rescue] read the data sequentially but switch to
small size reads when they find errors. This is a bad idea because it
means spending more time at error areas, damaging the surface, the heads
and the drive mechanics, instead of getting out of them as fast as
possible. This behavior reduces the chances of rescuing the remaining
I am very sorry that the creation of ddrescue inconvenienced you, and am
genuinely interested in knowing why you think that dd_rescue is better.
(No sarcasm intended. I'm open to any ideas that can make ddrescue better).
Same with XZ vs LZIP, why haven't you talked to XZ people instead of
creating Just One More LZMA-based compressor?
I talked to LZMA-utils people (xz didn't exist then), but they refused
to listen and finally released the monster container format that is xz.
The cases of dd_rescue/ddrescue and xz/lzip are almost identical except
in the time scale. When dd_rescue breaks your CD drive, it breaks it
fast (it broke mine, that is why I started ddrescue). But xz can take
years or decades to lose your data. (Or you to notice it). This is why
the dd_rescue/ddrescue situation evolved much faster than the xz/lzip
But, wait a moment. When I wrote lzip there existed a number of lzma
tools (LZMA-utils, lzma from Pavlov's SDK, lzmatools, easylzma), all of
them using the same substandard lzma-alone format. I was the first one
who wrote a LZMA tool with a decent format. Then, why are you angry
against me? Why don't you ask Lasse why he wrote xz instead of
contributing to lzip?