On Sun, Mar 19, 2017 at 10:58 PM, Michael Steuer
<Michael.Steuer@xxxxxxxxxxxxxxxxx> wrote:
>
> On 20/03/2017 16:21, Jason Hennessey wrote:
>>
>> On Wed, 8 Mar 2017, Johannes Schindelin wrote:
>>>>
>>>> Linus Torvalds writes ("Re: RFC: Another proposed hash function
>>>> transition plan"): > > Of course, having written that, I now realize how it
>>>> would cause
>>>>>
>>>>> problems for the usual shit-for-brains case-insensitive
>>>
>>> filesystems. > > So I guess base64 encoding doesn't work well for that
>>> reason.
>>> Given that the idea was to encode the new hash in base64 or base85, we
>>> *are* talking about an encoding. In that respect, yes, it can be whatever
>>> encoding we like, and Linus just made a good point (with unnecessary foul
>>> language) of explaining why base64/base85 is not that encoding.
>>
>> Since the hash format is switching anyway, how about using base32
>> instead of hex?
>>
>> Still get a 20% space savings over hex (minus a little for padding), and
>> it's guaranteed to be a single case.
>> Jason
>>
>
> If base32 is being considered, I'd suggest the "base32hex" variant, which
> uses the same amount of space.
I don't see the benefit of adding characters like 0 and 1 which
conflict with some of the letters? Since there's no need for a human
to decode the base32 output, it's easier to use the one that's less
likely to get screwed up when typing if that ever happens. It's not
like we actually need to know what value each character represents.
(sure the program does, but the human does not).
Thanks,
Jake