similar to: [PATCH v2 nbdkit] common: Improve pseudo-random number generation.

Currently we use non-cryptographically secure random numbers in two places, the error filter (to inject errors at random) and the random plugin. For this we have used either random_r or a home-brew-ish Linear Congruential Generator. Use of random_r is problematic on BSDs because it doesn't exist there. Use of the LCG is simply a bad choice. Replace both uses with a better quality and

On 12/28/18 2:55 PM, Richard W.M. Jones wrote: > Currently we use non-cryptographically secure random numbers in two > places, the error filter (to inject errors at random) and the random > plugin. For this we have used either random_r or a home-brew-ish > Linear Congruential Generator. Use of random_r is problematic on BSDs > because it doesn't exist there. Use of the LCG is

Currently we use non-cryptographically secure random numbers in two places, the error filter (to inject errors at random) and the random plugin. For this we have used either random_r or a home-brew-ish Linear Congruential Generator. Use of random_r is problematic on BSDs because it doesn't exist there. Use of the LCG is simply a bad choice. Replace both uses with a better quality and

Should we use attribute((nonnull)) at all? There's a very interesting history of this in libvirt -- try looking at commit eefb881 plus the commits referencing eefb881 -- but it does seem to work for me using recent GCC and Clang. I only did a few functions because annotating them gets old quickly... Rich.

v1 was here: https://www.redhat.com/archives/libguestfs/2019-January/msg00008.html In v2 I have provided two patches: The first patch extends attribute((nonnull)) to most internal functions, but not to the external API. The second patch uses a macro so that attribute((format)) is only used in the public API on GCC or Clang. At least in theory these headers could be used by a C compiler which

I do have a question about whether patch 2 is right, or whether I've exposed a bigger problem in the truncate (and possibly other) filter, but the rest seem fairly straightforward. Eric Blake (4): server: Check for pthread lock failures truncate: Factor out reading real_size under mutex plugins: Check for mutex failures filters: Check for mutex failures filters/cache/cache.c

On Aug 28, 2013, at 1:50 PM, Paul Robinson <pogo.work at gmail.com> wrote: > On Mon, Aug 26, 2013 at 9:14 PM, Todd Jackson <quantum.skyline at gmail.com>wrote: > >> Personally, I think it is necessary to go for the strongest random number >> generator possible. Cryptographically secure pseudorandom number >> generators have good properties that make them

On Mon, Aug 26, 2013 at 9:14 PM, Todd Jackson <quantum.skyline at gmail.com>wrote: > > > We would also include a secure random number generator which links >> > against OpenSSL. This would of course be an optional module disabled >> > by default, but is necessary so the randomization is cryptographically >> > secure and useful in security applications.

> > We would also include a secure random number generator which links > > against OpenSSL. This would of course be an optional module disabled > > by default, but is necessary so the randomization is cryptographically > > secure and useful in security applications. > > I am not sure why you need this feature. You can provide LLVM with a > SEED value that can be

Hi, I failed to search for R package providing random number generator of "Park and Miller". Anyone know any R package supporting this kind of function? Thanks, Grace -- View this message in context: http://www.nabble.com/Random-Number-Generator-of-Park-and-Miller-tf3636501.html#a10154554 Sent from the R help mailing list archive at Nabble.com.

Commit 975dab14 argued that for simple lock/unlock sequences, it was easier to avoid the cleanup.h macros. But since that time, we added additional sanity checking to the macros, at which point the boilerplate of inlining that sanity checking is outweighed compared to just using the macros in more places. Signed-off-by: Eric Blake <eblake@redhat.com> --- filters/cache/cache.c | 23

In order to avoid high-frequency cpu migration, vcpus may in fact be scheduled slightly out-of-order. Account for this situation properly. Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com> credit2: Fix erronous ASSERT In order to avoid high-frequency cpu migration, vcpus may in fact be scheduled slightly out-of-order. Account for this situation properly. v2: - Update comment

Address some credit2 issues. This patch series, along with the recent changes to the cpupools interface, should address some of the strange credit2 instability. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hello I have a data set with fixed and random effects, therefore I am using the lme function: lm(y ~ xfixed, random=~1|xrandom, data) After this I want to get the F-values for both the fixed and random predictors. I can easily get the F-value and df for the xfixed predictors (anova()), but how to get the F-value for the xrandom predictors? Thanks in advance. /R

Annotate some function parameters with attribute((nonnull)). Only do this for internal headers where we are sure that we will be using sufficiently recent GCC or Clang. For the public header files (ie. include/nbdkit-*.h) it may be that people building out of tree plugins are using old GCC which had problems, or even other compilers that don't support this extension at all. Libvirt has an

I want to post this but mainly for discussion and early review. It's not safe for these patches to all go upstream yet (because not all filters have been checked/adjusted), but if any patches were to go upstream then probably 1 & 2 only are safe. File, VDDK, memory and data plugins all work, although I have only done minimal testing on them. The current tests, such as they are, all

Add a xen command-line parameter, sched_credit_tslice_ms, to set the timeslice of the credit1 scheduler. Signed-off-by: George Dunlap <george.dunlap@eu.citrix.com> diff -r 4a4882df5649 -r 782284c5b1bc xen/common/sched_credit.c --- a/xen/common/sched_credit.c Wed Aug 31 15:23:49 2011 +0100 +++ b/xen/common/sched_credit.c Thu Sep 01 16:29:50 2011 +0100 @@ -41,15 +41,9 @@ */ #define

Hello all, I tried OpenSSH versions 2.1.1p4, 2.2.0p1 and the latest snapshot briefly on 64-bit Irix 6.5.7f an 6.5.9m. Both times, no matter what I do, I'll get 'PRNG initialization failed -- exiting'. This happens with ssh-keygen (the keys aren't even generated yet, ssh binary etc.) It's clear that Irix etc. don't have a proper entropy pool like *BSD and Linux do, but

Just for peace of mind, can someone who knows the openssh code better than I do, confirm that openssh doesn't use (in any circumstances) the openssl prng (since the code in versions prior to 0.9.6b is rather weak). My understanding is that it doesn't (using either /dev/random, egd, prngd or the builtin code), but I may have missed some other use of the openssl prng elsewhere... -- Jon

Greetings. I'm wondering if OpenSSH automatically falls back to the internal PRNG (such as used on Solaris) when it can't use a better alternative. The reason I ask is this: the machine I am compiling OpenSSH on has the /dev/random patch for Solaris 8. I'd like OpenSSH to use /dev/random whenever possible, if it exists. However, I'd prefer NOT to have to compile a separate