I think there's a more general point being made here - if we're not seeding /dev/random effectively at startup, fortune is the least of our worries since all the other startup services will be unrandom as well.

This situation I see with /dev/random is kind of disturbing since I think we're running the danger of falling into the following all-too-common scenario in engineering:

1) Person X falls in love with a new algorithm or technique and implements it in a fairly key service with quite a few rough edges.

2) The users fail to embrace this new technology all that fervently since those same rough edges make it a promising but annoying or downright non-functional implementation.

3) Person X vigorously defends himself and/or the algorithm since he knows it's really a much better thing in the long run and simply needs "tweaking" to make it fully work.

4) The users see this as an attempt to cram broken bits down their throats and just as vigorously fight back against what they see as someone's fancy solution in search of a problem to solve.

5) Constructive dialog breaks down and it all turns into an exchange of increasingly irritated words as each side feels the other isn't hearing what it's trying to say or appreciating the bigger pictures.

Let's try not to go there with /dev/random, please. :)

- Jordan

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message