Kevin Ballard <kevin@sb.org> writes:

quoted text
> On Jan 21, 2008, at 4:18 PM, Theodore Tso wrote:
>
>> Your faith in the HFS+ designers is touching.
>
> And your arrogance is troubling. Do you really believe you are so
> smart you can claim the HFS+ designers had no reason for this
> decision?

No reason?  Don't say where he says that.  No sane reason?  Certainly.
If the visibility of the upsides is not in the same order of magnitude
as that of the downsides (and your "I trust they must have had good
reason" is implicating exactly that), then yes, this appears like a
misdesign, however well-intended.  Because its cleverness hinges on an
what amounts to an arbitrary historic point of stability with only
fleeting convenience.

It reminds me of the self-defeatingproblem haunting the MIPS
(microprocessor without interlocked pipeline stages) architecture: for
pipelined processors, one has to add logic that prevents one command
from working before the results from other commands arrive.  Now the
ingenious idea of the MIPS architecture was to move that logic into the
compiler instead of the hardware.  But then the implications of that
idea got intermingled with binary compatibility and the result was that
the advantages lasted for one processor generation, and afterwards, the
m-stage pipelines needed logic that simulated the n-stage pipeline of
the first MIPS processor rather then a comparatively simple 1-stage
pipeline of a conceptual sequential processor.  Rendering the whole
original idea completely absurd and requiring rather more complicated
rather than simpler hardware as originally envisioned.

The road to hell is paved with good intentions.

quoted text
>>> The reason may not be valid anymore, but if it was valid back in
>>> 1998, then I can accept it without complaining.

There is no shortage in short-sighted decisions to repeat.  Some
political parties bank on it.

quoted text
> Again, I'm not saying that they necessarily did the "correct" thing,
> as I can't evaluate that without knowing their reason. I'm just saying
> there must have been a reason.

Jumping to blind faith-based conclusions is never a good move.  You
don't end up improving the work of your predecessors that way.

quoted text
> And why do you believe MacOS is going to adopt ZFS? Sure, they might,
> but assuming stuff about the future is just as bad as assuming stuff
> about the past. And git should "pervert" itself because of the simple
> fact that git has a problem on HFS+. Keeping your code "pure" is all
> well and good, except it's not particularly practical. If the git
> project has any interest in being a viable system on OS X, it really
> should behave properly.

If OS X has any interest in being a viable system, perios, it really
should behave properly.

quoted text
> How many times must I say I never suggested actually changing git's
> hashing algorithm? And if you want me to suggest a fix to git that
> works, first you have to wait for me to learn how git's internals
> work, and frankly, I have too much work on my plate right now to
> devote the time necessary to learning git's internals well enough to
> fix this problem.

Then please understand that you have too much work on your plate right
now to devote the time necessary to provide any constructive criticism.
A smart person in this situation would shut up until he has the time.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html