Hi Nia, I think you are mixing a few issues here into one discussion - which might make sense from a user perspective, but does not help us to get forward.
>From my POV the interacting-but-need-to-be-solved-individually issues are: - The libc or kernel<->userland API. This is what the core decision was about. The API is well (enough) defined, same on multiple OSes, and provides all the flexibility we need. - Making entropy available "early enough" during the boot process. This is a hard problem on *many* machines, but no big deal at all on modern x86 and a few modern aarch64. For me this is looks like still work in progress with no "good enough" solution yet. I understood Taylor would like to improve this next. I personally would define "early enough" as "during rc.d" and this makes the problem relatively easily solvable for "real installations" (see below) by just manually (or "someway") seeding the individual installations entropy file. IIUC Taylor would like to also enhance/add kernel parts providing entropy. - Related to above: how to deal with one-off setups like first boots of install images or clones of virtual machines. This will be solvable (probably by a combination of better scripting and/or documented "best practices") once the point above is more or less settled. - Finaly the grey area of "which variant of our API should applications use" (and even more complex: libraries). This needs individual answers on a case by case basis and might need some upstream battle - but we should be able to give good guidance and clear rules once the items above are cleared. Martin