On the other, you have HN's 'tveita, saying that urandom "isn't guaranteed to be random enough for cryptographic keys".
I could continue the argument, but since the whole post you're commenting on is that argument, I'd be repeating myself. So instead, I'll just ask: what specific assertion in that post do you disagree with?
> the bug that is Linux's willingness to give you output from an unseeded RNG
So there you have it. But don't worry, no one uses this "Linux" thing, certainly not in embedded systems.
When you're writing a program for generic use, you can't trust the underlying system to be set up above and beyond a stock install. If you want to use seeding as a workaround, it should be done from every program that requires secure randomness. That doesn't seem to be what you're advocating. And if you're just generating a key, why not read it directly from random instead?
You can pretend that urandom gives good randomness and be surprised when you get key collisions. Just like you can pretend that strncpy null-terminates strings and be surprised when you get a buffer overflow vulnerability. That makes you a menace.
For what's it's worth, I agree that an adequately seeded CSPRNG should never 'run out' of entropy, and I wouldn't mind if Linux got a BSD-style shared random/urandom. But as it stands, urandom is not guaranteed to be adequately seeded, and I have no idea why you would advocate taking that risk.
urandom simply isn't guaranteed to be random enough for cryptographic keys. Misusing it for this causes real-world problems.
You are telling people to write insecure software. That it could be secure if Linux worked differently from how it actually works is completely irrelevant and bordering on denialism.
If you want to fix Linux to be more like the other systems, great! Then /dev/random will be non-blocking and everyone can use that. Meanwhile, I'd much rather block than find myself sharing prime factors with random strangers.