[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: [GNU-arch-dev] Re: [ANNOUNCEMENT] /Arch/ embrac

From: Jacob Gorm Hansen
Subject: Re: [Gnu-arch-users] Re: [GNU-arch-dev] Re: [ANNOUNCEMENT] /Arch/ embraces `git'
Date: Sun, 24 Apr 2005 21:15:58 -0700
User-agent: Mozilla Thunderbird 1.0 (X11/20050302)

Matthieu Moy wrote:
John A Meinel <address@hidden> writes:

However, I think 2^-160 * 2^-10 is a low enough probability of collision
that we don't have to worry about it. (Even if it is only 2^-80).

With 2^80 files the probability is 50%, as per the birthday paradox, but that is not the point. The point is that a) hash functions were not designed for this, so unless there is some clear strategy for handling collisions some users _will_ see silent corruption of their archives, and b) the whole git approach of storing full copies of everything and needing 160+-bit ids to index things is just gross, and in the end it buys you no extra functionality, it just wastes a lot of disk space for no apparent reason. Linus Torvalds needs to show the world that he was not an idiot for going with bk in the first place, git is his panicky 'solution', and right now it seems all the major free SCS's are bending over backwards just to get his attention.

> I guess the probability of collision is much lower than the
> probability of hardware failure (like a 0 turning into a 1 in the RAM
> of your computer).

That is a problem that can be fixed at the hardware-level, i.e. with error-correcting memory. For instance, IBM has been selling 'chipkill' memory with their top servers for several years. Using this argument to justify hash collisions is like trying to convince the cop who just pulled you over for speeding that he should go and chase some 'real criminals' instead.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]