On Sunday 24 Jul 2011 22:56:06 Rob Davies wrote:
On 24 July 2011 20:45, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
On 24 July 2011 20:18, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
El 24/07/11 14:37, Rob Davies escribió: To do what you suggest you need exactly what the daemon itself already does, monitor the entropy amount of the system, if it goes lower than a
El 24/07/11 15:31, Rob Davies escribió: limit it starts working.
Saying "it should" be done by kernel doesn't help, when Linux 3.0 doesn't and that's what we've got. Can you really see many installs having those USB keys? (I can't, I just think, you'll get some users saying openSUSE's slow.).
On demand daemon starting is an issue for 12.1, if you do it for CUPS why not something that provides entropy if it's generally not useful to most installs? It's just events, print job submitted, low water mark hit.
I have not seen what the objections were to having the daemon started by default, and I pointed out that the changelog misrepresented the discussion in the bug, which was about lack of information in the release notes. Very likely that's the simplest practical solution.
Far from "telling that we add another level of complexity", I just pointed out a possible alternative, rather than just blocking ignoring or reporting a problem, the system activates something to ameliorate it when it seems useful. I DO NOT care that would be ineffiecient, it is far more efficient than a call to a sysadmin. I don't understand why you think reacting to such an issue is too complicated, because good sysadmins end up writing scripts to do that kind of maintenance rather often, and there were objections to the non-obvious inclusion in Installer. Overloading the choice of run level 3 rather than 5, seems rather indirect and fragile to me; install time can be very different from real usage so dislike of that alternative is understandable.
Rob
Agreed. In any case, from having haveged running on my 11.4 box, its footprint seems to be very small, around 6Kb and it simply sits there idling; if I dd /dev/random into /dev/null then it starts consuming CPU cycles but does not increase memory consumption. I could completely understand disabling this if you were running SUSE on some embedded system where memory was incredibly tight to the point that you were compiling your own stripped-down kernel to accommodate for the fact - in all other instances, haveged is just going to sit there and do nothing if the system always has sufficient entropy. So the cost-benefit analysis is that either you cost everyone who doesn't know that they don't need haveged a few Kb of memory to have it running at all times to ensure people on entropy starved machines don't ever run into issues with applications that rely on /dev/random or you decide to save a few Kb at the cost of causing hassle for people with insufficient system entropy. the only other possibility I can think of is to have the installation environment (or some post-install runonce) attempt to empty out /dev/random and see how quickly it replenishes and use that to make a decision as to whether or not to enable haveged for that particular system, given that haveged will give you roughly 1.7MB/s of entropy. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org