dumblob

`open()` calls: ``` strace open("/usr/lib/tls/x86_64/libm.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/libm.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/x86_64/libm.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No...

Nice! Why not? In the worst case we can change the logo any time if there is demand/proposal :wink:.

Right, bad mistake of mine - I got confused with `" 'Error' for 'Error' "` (the message should distinguish between _Error object_ type and _Error type_ type). By the way,...

I agree, that it's not needed at the moment and that the linked library is quite horrible. I'm though still convinced the algorithm should be built in the DaoVM reference...

>xxHash is only fast for large buffers. For small buffers or usage in a hash table FNV1 is still the fastest. Murmur 3 is also not really recommended. I'm certainly...

Well, the primary motivation for the switch was speed, but I do trust quite a lot the `smhasher` "benchmark" and mainly the quality classification whereas I would never accept any...

It seems you mean `FNV1a_YT` instead of `FNV1a`. Then if we'll ignore CRC-based hashes it's the fastest. But also one of the very few with the absolute worst quality 😉...

There is a new hash function [wyhash](https://github.com/wangyi-fudan/wyhash ), which seems to raise the bar of hashing (including PRNG) by a giant step. It's less complicated than xxHash, but more than...

>Where did you see this? https://github.com/rurban/smhasher/blob/master/doc/wyhash https://github.com/rurban/smhasher/blob/master/doc/wyhash32low >Please note speed is not the most important factor in choosing a hash function. Sure, that's why I noted "if there will be...

>In some networked applications (such as certain types of games), the clients and server are required to have deterministic and identical behavior, which cannot be guaranteed if endian-dependent hashes are...