Jordan writes a nice piece of mail... If this was happening in -stable I'd be in total agreement. However, we're talking -current, and is not -current the integration area for new technologies, whether they be rough or round edged? This reminds me of the old development arguement: Don't do that, it hurts me. which has caused alot of good code to never see the light of day. -John ----- Jordan Hubbard's Original Message ----- > > 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 > 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 [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
