On Jan 21, 2008, at 5:41 PM, Dmitry Potapov wrote:

quoted text
> On Mon, Jan 21, 2008 at 04:07:27PM -0500, Kevin Ballard wrote:
>>
>> Again, I've specified many times that I'm talking about canonical
>> equivalence.
>>
>> And yes, HFS+ does normalization, it just doesn't use NFD. It uses a
>> custom variant. I fail to see how this is a problem.
>
> If you think that HFS+ does normalization then you apparently have no
> idea of what the term "normalization" means. Have you? But if you
> don't know what is "normalization" then you cannot really know what
> canonical equivalence means.

I would go look up specifics to back me up, but my DNS is screwing up  
right now so I can't access most of the internet. In any case, there  
are 4 standard normalization forms - NFC, NFD, NFKC, NFKD. If there  
are others, they aren't notable enough to be listed in the resource I  
was reading. HFS+ uses a variant on NFD - it's a well-defined variant,  
and thus can safely be called its own normalization form. I fail to  
see how this means it's not "normalization".

quoted text
>>> I don't say they do that without *any* reason, but I suppose all
>>> Apple developers in the Copland project had some reasons for they
>>> did, but the outcome was not very good...
>>
>> Stupid engineers don't get to work on developing new filesystems.
>
> Assigning someone to work on a new filesystem does not make him
> suddenly smart. As to that stupid engineers don't get to work,
> it is like saying there is no stupid engineers at all. There are
> plenty evidence to contrary. And when management is disastrous
> then most idiots with big mouth and little capacity to produce
> any useful does get assignment to develop new features, while
> those who can actually solve problems are assigned to fix the
> next build, because the only thing that this management worries
> about how to survive another year or another months...

I'm not talking about assigning engineers, I'm saying developing a new  
filesystem, especially one that's proven itself to be usable and  
extendable for the last decade, is something that only smart engineers  
would be capable of doing.

quoted text
>> And
>> Copland didn't fail because of stupid engineers anyway. If I had to
>> blame someone, I'd blame management.
>
> But if the code was so good then why was most of that code thrown away
> later when management was changed? Still bad management?

Yes. Even the best of engineers will produce crap code when overworked  
and required to implement new features instead of fixing bugs and  
stabilizing the system. Copland is well-known to have suffered from  
featuritis, to the extent that it was practically impossible to test  
in any sane fashion. Bad management can kill any project regardless of  
how good the engineers are.

quoted text
>>>> The only information you lose when doing canonical normalization is
>>>> what the original byte sequence was.
>>>
>>> Not true. You lose the original sequence of *characters*.
>>
>> Which is only a problem if you care about the byte sequence, which is
>> kinda the whole point of my argument.
>
> Byte sequences are not an issue here. If the filesystem used UTF-16 to
> store filenames, that would NOT cause this problem, because characters
> would be the same even though bytes stored on the disk were different.
> So, what you actually lose here is the original sequence of  
> *characters*.

I've already talked about that, but you are apparently incapable of  
understanding.

-Kevin Ballard

-- 
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com