Kevin Ballard <kevin@xxxxxx> writes: > 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. >>> 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. > 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. > 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. > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
