Xz format inadequate for long-term archiving (2016)

Re:Xz format inadequate for long-term archiving (2016) by gwern on Wednesday June 05, 2019 @06:00PM (#20109602)

You move them, then you verify the integrity of the new copy, then you can get rid of the old one. You don't need to build integrity checks and extra FEC at every level of the system redundantly.

Just like in the end-to-end principle when applied to networking: you have a single strong integrity check at the very furthest endpoint possible, and then you don't build in integrity & ECC at every level of the stack, you devote those resources to higher performance, and just do retransmission from the other endpoint when a file occasionally gets corrupted and the integrity check catches it.

[ Parent | on HN ]

Re:Xz format inadequate for long-term archiving (2016) by mixmastamyk on Thursday June 06, 2019 @11:28AM (#20115458)

Appealing to "more manual work" is not very compelling to be honest.

[ Parent | on HN ]

Re:Xz format inadequate for long-term archiving (2016) by gwern on Friday June 07, 2019 @07:16PM (#20129477)

-_- I never appealed to 'more manual work', nor did I say that. If you refuse to understand my point and want to make up things I did not say, so be it.

[ Parent | on HN ]

Re:Xz format inadequate for long-term archiving (2016) by mixmastamyk on Sunday June 09, 2019 @03:43AM (#20137808)

> you verify the integrity

[ Parent | on HN ]

Re:Xz format inadequate for long-term archiving (2016) by gwern on Thursday June 13, 2019 @10:15AM (#20175044)

Don't be a moron. You knew perfectly well what I meant. (Did I also mean that 'you', a human, should be checking hashsums and FEC by hand for every network packet...?)

[ Parent | on HN ]