Cool GNU/Linux commands

only problem with this is gnu tr is not multibyte aware so it will probably strip any valid utf8 sequence. but really at that point, you might as well use a tool that just randomly spits out unicode codepoint -> encoded as whatever.

What would you gain? How would you increase the entropy? 16 bytes of random data is ideally 128 bits of entropy (assuming your RNG isn't broken).
Sending the password as unicode instead of hex (which is really going to go over the wire as UTF-8 anyways) doesn't buy you anything, unless you actually increase the random data at the input, in which case you may as well just increase the number of bytes you're generating and converting to hex.

Plus you don't have to deal with broken servers that can't handle non-ASCII, you can type it on any keyboard without special chars, etc.

You can pack more entropy into the same length string.
I'm not sure what the actual entropy that UTF8 allows is (because of continuation bytes and shit), but the overall search space for an attacker who doesn't know anything about your password is a lot larger.
At this level, the required search time is already so ridiculous that it's probably not even worth discussing the difference between full ascii vs full unicode coverage, but just limiting yourself to lowercase hex (which md5sum produces) is just really stupid.

I think at this point you're going to just get stuck in a discussion of bytes vs characters.
You'll pass the heat death of the universe before you can brute force 2^128, regardless of how it's presented.
It'll take the same amount of time for "Ahw63Hl29Uw045gNxEX6bw==" or "e6e75da7659a581eaf08f42acb182eb9" or 8 characters of random UTF-8 (which may not even be valid), even if you know that one has a limited character set.

Pretty sure it's a random hex password generator. Try:
head -c20 /dev/urandom | base64

>I'd like to believe there's nobody dumb enough on Jow Forums
Oh you!

>You'll pass the heat death of the universe before you can brute force 2^128
With current technology*

>but why not malloc more than 10 at a time
Imagine being this brain dead

Documentation:
$ info

The less you malloc at a time, the greater the chance to exhaust the computer's memory completely. It's always possible that an amount of memory slightly less than what you request will remain free, and system still has a chance to be somewhat functional. With 10, at most 9 bytes can stay free, so you can hang the system completely.

Stop being condescending.