> The issue is one of seeding the device strongly. If all you care about
> is getting a different fortune when you boot then seeding with
> e.g. the system boot time would be enough, but obviously it doesnt
> make /dev/random cryptographically secure.

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

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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
          • ... Ed Hall
          • ... Doug Barton
          • ... Poul-Henning Kamp
          • ... Wesley Morgan
          • ... Poul-Henning Kamp
    • ... Kris Kennaway
      • ... Андрей Чернов
      • ... Terry Lambert
        • ... Mark Murray
  • ... Kris Kennaway
    • ... Jordan Hubbard
      • ... John W. De Boskey
        • ... David O'Brien

Reply via email to