Ok, yes, there were some algorithms in the past which had problems with carrying input biases to their output and sometimes even getting totally broken with cer

Ok, yes, there were some algorithms in the past which had problems with carrying input biases to their output and sometimes even getting totally broken with certain seeds/keys. Nowadays, this isn't the case, and the view is that such issues are fundamental weaknesses rather than mere errata to be worked around. However, the quality of a modern CSPRNG doesn't save you from a low-entropy seed. A couple biased bits in a 128-bit seed may not be a serious issue (but why take the chance?!), however good entropy estimation is a difficult task which is best left to the operating system. Modern operating systems will ingest sources of hardware randomness and seed their system-level CSPRNGs, which should then be used directly by application software (for key material) or as seeds to local CSPRNGs (for less security-sensitive but more performance-sensitive needs). Do not play around with seed entropy just to be clever. In the absence of a full-fledged operating system, then things like high-precision boot timers can be used for seeds, but only because there's nothing better available. The lack of good randomness is a real problem in resource-constrained environments, though usually there are easier-to-exploit vulnerabilities that get hit first.