Re: CFR: add widely accepted _ISOC99_SOURCE
On Mon, Mar 10, 2003 at 10:44:34 -0500, Mike Barcroft wrote: Andrey A. Chernov [EMAIL PROTECTED] writes: Many programs (from ports too) defines _ISOC99_SOURCE to get C99 functions, but we don't sense this define currently. Here is the fix for review: Cool. I didn't realize there was an existing precedence, or I would have used it. Just search Google about _ISOC99_SOURCE and see :-) This part isn't needed... #else /*- * Deal with _ANSI_SOURCE: @@ -378,7 +381,7 @@ #define__XSI_VISIBLE 0 #define__BSD_VISIBLE 0 #define__ISO_C_VISIBLE 1990 -#elif defined(_C99_SOURCE) /* Localism to specify strict C99 env. */ +#elif defined(_ISOC99_SOURCE) /* Strict C99 env. */ #define__POSIX_VISIBLE 0 #define__XSI_VISIBLE 0 #define__BSD_VISIBLE 0 ...since the next line here is: #define __ISO_C_VISIBLE 1999 Hm, I don't quite understand, which one part you mean? My patch handles 2 following cases: 1) Any _POSIX_C_SOURCE with _ISOC99_SOURCE. It is from real life example (ImageMagick). It wants lower POSIX level, *but* wants _ISOC99_SOURCE in the same time. 2) _ISOC99_SOURCE without any _POSIX_C_SOURCE. In that case it overrides _ANSI_SOURCE like old _C99_SOURCE does. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CFR: add widely accepted _ISOC99_SOURCE
On Tue, Mar 11, 2003 at 10:49:43 -0500, Mike Barcroft wrote: 1) Any _POSIX_C_SOURCE with _ISOC99_SOURCE. It is from real life example (ImageMagick). It wants lower POSIX level, *but* wants _ISOC99_SOURCE in the same time. I don't like this at all. The meaning of _ANSI_SOURCE is that the source is exclusively written in C89 with no BSD, POSIX, or XSI extentions. Similarly, I was intending _C99_SOURCE to be used without any POSIX. Programs looking for C99+POSIX functions should specify POSIX.1-2001, which incorporates both of these. What to do, if, say, C99 program want to use some POSIX functions from lower (and not from higher) POSIX standard? Currently we have problem with ImageMagick - undefined prototypes for vsnprintf() and other like, because it wants right that: magick/studio.h: ... #define _GNU_SOURCE 1 #define _ISOC99_SOURCE 1 #define _POSIX_C_SOURCE 199506L #define _XOPEN_SOURCE 500 #define _LARGEFILE64_SOURCE 1 -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
CFR: add widely accepted _ISOC99_SOURCE
Many programs (from ports too) defines _ISOC99_SOURCE to get C99 functions, but we don't sense this define currently. Here is the fix for review: --- cdefs.h.bak Wed Oct 23 05:04:06 2002 +++ cdefs.h Mon Mar 10 09:11:01 2003 @@ -360,6 +360,9 @@ #define__POSIX_VISIBLE 198808 #define__ISO_C_VISIBLE 0 #endif /* _POSIX_C_SOURCE */ +#ifdef _ISOC99_SOURCE +#define__ISO_C_VISIBLE 1999 +#endif #else /*- * Deal with _ANSI_SOURCE: @@ -378,7 +381,7 @@ #define__XSI_VISIBLE 0 #define__BSD_VISIBLE 0 #define__ISO_C_VISIBLE 1990 -#elif defined(_C99_SOURCE) /* Localism to specify strict C99 env. */ +#elif defined(_ISOC99_SOURCE) /* Strict C99 env. */ #define__POSIX_VISIBLE 0 #define__XSI_VISIBLE 0 #define__BSD_VISIBLE 0 -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
On Sun, Feb 16, 2003 at 22:08:10 -0800, Kris Kennaway wrote: when they should not. I've given examples of two of them, and there are probably lots of others I haven't noticed. For example, I just checked, and libICE appears to use rand() for cookie generation. This is completely bogus, and insecure. Usually applications we build (like awk, etc.) could be fixed by simple one line change: srand(something) - sranddev() It completely eliminates first value correlation problem. -- Andrey A. Chernov http://ache.pp.ru/ msg52685/pgp0.pgp Description: PGP signature
Re: cvs commit: src/lib/libc/stdlib rand.c
On Mon, Feb 17, 2003 at 17:39:55 +1100, Tim Robbins wrote: variant (which generates bad quality ones), the only problem remains is first value monotonically increased with the seed. Here's an interesting picture of that: http://people.freebsd.org/~tjr/rand.gif Nothing surprising here. It is common and know problem for all mod-type PRNGs. There is even good methods exists to eliminate this thing, see http://www.physik.uni-giessen.de:8081/PhysOfFinance/PoF09.pdf Shuffling Algorithm section for example. But all such methods will be incompatible with rand_r()... -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE breakage: backout patch for review
On Sun, Feb 16, 2003 at 11:01:43 +0100, Dag-Erling Smorgrav wrote: Andrey A. Chernov [EMAIL PROTECTED] writes: [...] Please disregard. Andrey does not know what he's talking about and ignores any attempt at explaining what the real issue is and what real users want. Unless you specify exact details of what I ignore, I'll be forced to treat your reply as NO REVIEW and commit this changes. P.S. It really des who ignore that simple fact that was localhost alias in OPIE for years before any evil PAM appearse. As you see, I am specific. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE breakage: backout patch for review
On Sun, Feb 16, 2003 at 13:27:38 +0300, Andrey A. Chernov wrote: Unless you specify exact details of what I ignore, I'll be forced to treat your reply as NO REVIEW and commit this changes. Well, after numerous exchanges of nonsense messages a bit of details comes from des, so I correct my explanation. Patch remains the same. As des describes in another thread, he tries to satisfy users who want to control localhost in the same way as other hosts. But... I found that the way he does it breaks existen OPIE behavor and configs. To be more specific, exact breakage after des is: Old non-PAMified OPIE variant: localhost allowed even there is no /etc/opieaccess at all. New variant from des: if there is no /etc/opieaccess, localhost is not allowed. Admins with no /etc/opieaccess AFFECTED! Please note that my patch not adds new functionality des and his users want, it only removes breakage. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE breakage: backout patch for review
On Sun, Feb 16, 2003 at 11:58:57 +0100, [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Andrey A. Chernov writes: On Sun, Feb 16, 2003 at 13:27:38 +0300, Andrey A. Chernov wrote: Unless you specify exact details of what I ignore, I'll be forced to treat your reply as NO REVIEW and commit this changes. Well, after numerous exchanges of nonsense messages [...] That is probably the most precise summary so far (NB: exchanges implies that the non-sense goes both ways). Yes, but nonsense from my side is more detailed. :-) But... Nonsense from my side happens only because 1) I see the breakage. 2) Seen breakage, I try to guess what des means, when he made it, having no information from des. 3) If I guess it (with no information) incorrectly, it not means that breakage not exist, it still there. Please take this to private email. I not see enough good will from des side for it. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE breakage: backout patch for review
On Sun, Feb 16, 2003 at 12:06:36 +0100, Dag-Erling Smorgrav wrote: Andrey A. Chernov [EMAIL PROTECTED] writes: Admins with no /etc/opieaccess AFFECTED! Admins with no /etc/opieaccess IDIOTS for not running mergemaster! First of all, there are many years of existen OPIE administration practice which every OPIE admin know, and this practice says that this file is not needed in many setups. In hypotetical case that FreeBSD deside to break this rule for some unknown reason, it must be well documented in both manpages and release notes. But, currently documented exact oppisite variant. Please read this quote from opieaccess(5), where OPIE authors explicetely state that this file can leads to security hole and always should be treated as optional. In any environment, it should be considered a transition tool and not a permanent fixture. When it is not being used as a transition tool, a version of OPIE that has been built without support for the opieaccess file should be built to prevent the possibility of an attacker using this file as a means to circumvent the OPIE software. Even some new admins read manpages and delete this file after reading that. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE breakage: backout patch for review
On Sun, Feb 16, 2003 at 11:21:15 +, Mark Murray wrote: Does the -as-localhost-alias break other PAM modules? No, it is local variable for that module. In what way does localhost or NULL break OPIE? Look into any pre-PAM code which use OPIE, like login code. Host (rhost) is only set to some name for non-local logins. Local logins set it to The comment in the OPIE accessfile.c confirms it too. If you set host to localhost or NULL, it not recognized as localhost inside OPIE code, i.e. in the accessfile.c, so some functionality (like always allowing localhost) will be lost. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE breakage: backout patch for review
On Sun, Feb 16, 2003 at 12:16:27 +0100, Dag-Erling Smorgrav wrote: My message [EMAIL PROTECTED] dated 2003-02-16 00:46:27 CET contained all the information you needed. If you mean that quote from it: This behaviour was very surprising to people who wanted to prevent OPIE users from using their passwords even locally. The answer was obvious - such people should read OPIE documentation to not be so surprised. I don't think that people who not read docs is information I need. Do you really think that your hysterical reaction, bombarding me with message upon incriminatory message and completely ignoring what I say I not bombarding you, I answer sequentally on each message and many of them comes when I write answer. About ignoring, I see situation, like you ignore me. BTW, do you ever think that bombarding and ignoring terms can't co-exist, they are oppisite? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE breakage: backout patch for review
On Sun, Feb 16, 2003 at 12:06:36 +0100, Dag-Erling Smorgrav wrote: Andrey A. Chernov [EMAIL PROTECTED] writes: Admins with no /etc/opieaccess AFFECTED! Admins with no /etc/opieaccess IDIOTS for not running mergemaster! Moreover, admins WITH old /etc/opieaccess (i.e. without your line) are affected too! Local logins becomes mysteriosly disabled for their users. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE breakage: backout patch for review
On Sun, Feb 16, 2003 at 19:11:49 +, Mark Murray wrote: In the case where an application is OPIEised and not PAMised, we need to figure out something; PAMizing such apps is not terribly hard. If any of them are in the base system, then this situation We are not in the situation to force users and admins to rewrite their OPIE apps under new PAM framework. I always believe that non-destructive for OPIE defaults (i.e. PAM only) solution is possible here, but not being PAM specialist, can't demonstrate it. Recent des commits solve problem correctly. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE breakage: backout patch for review
On Sun, Feb 16, 2003 at 15:39:51 -0600, Juli Mallett wrote: Can you explain how this stops purely opieized apps from working? I was under the impression the implicit case was still there, we just have a more explicit contract with the OPIE system. This is not pure situation but mix with opiezed and opiezed+pamified apps families contradiction. Each of the families will produce different behaviour in the variant was commited initially by des (now he fix things properly). If you tune opiezed+pamified apps to work as you need, pure opizeded stops working and vice versa. I mean localhost handling. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE breakage: backout patch for review
On Mon, Feb 17, 2003 at 01:51:20 +0300, Andrey A. Chernov wrote: properly). If you tune opiezed+pamified apps to work as you need, pure opized stops working and vice versa. In this phrase I mean documented OPIE tuning of OPIE config files (old way), without any new additions and requirements, basically I mean old setups working for years. F.e. if you delete /etc/opieaccess (which is legal from OPIE point of view), you will be not able to log in locally via opiezed+pamified apps, but able with opiezed. (Remember, we talk about initial variant from des, now he fix situation and people who want to shoot their foot needs to remove default PAM configuration option allow_local) -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE breakage: backout patch for review
On Sun, Feb 16, 2003 at 20:16:43 -0500, Garance A Drosihn wrote: to indicate localhost. Andrey provided a patch which allows OPIE to keep that standard (to OPIE) meaning. Could people try his patch and then explain why it does not solve the problem they are trying to solve? The problem already resolved, des commits acceptable for both parties solution (which use part of my patch too). -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
On Sun, Feb 16, 2003 at 20:57:29 -0800, Kris Kennaway wrote: On Sun, Feb 16, 2003 at 07:52:35PM -0800, Andrey A. Chernov wrote: So, monotonically increased seed-first value correlation problem remains... I think we should commit this patch (to -current) and fix all the problems that pop up. For example, it's used in awk (which started this set of changes), and in some of the XFree86 libraries. I agree. (diff is for old rand.c, but idea is clear in anycase). I have no fancy ideas how to fix correlation problem AND keep rand_r() compatibility at the same time. All linear mod-type generators share this problem with monotonic seeding and usual solution is shuffling array (more complex code than I use), but it will be incompatible with rand_r() again. If we back out most of changes and return to very first formulae with overflow, we 1) Make monotonic increasing for seed-first_value less visible. 2) Not fix seed-first_value correlation (taking some parts of bits will show repeated pattern). 3) Make distribution and lower bits bad. -- Andrey A. Chernov http://ache.pp.ru/ msg52528/pgp0.pgp Description: PGP signature
Re: cvs commit: src/lib/libc/stdlib rand.c
On Mon, Feb 17, 2003 at 16:40:48 +1100, Tim Robbins wrote: I don't think rand() needs a warning message like gets() c. because it's not as dangerous. Wait, what kind of warning __warn_references() produce? I was under impression that it is compile-time only. What I suggest instead is to remove the pathetic insults in rand(3) (bad random number generator, obsoleted) and add a BUGS section which describes the problem. I agree. It can be done not instead only but in addition to compile time warning. I'd much prefer that rand() generated higher quality numbers, though. Current formulae generates acceptable quality numbers. Unlike in old variant (which generates bad quality ones), the only problem remains is first value monotonically increased with the seed. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
OPIE breakage: backout patch for review
Background: recently des tries to fight problem that OPIE not sense localhost when called from PAM, but does it incorrectly. Moreover, he tries to fix OPIE config instead of fixing PAM bug: PAM not follows OPIE API. In non-PAM environment OPIE always sense localhost because its host variable always have value indicating localhost. Now PAM tries to break this, sending localhost string to OPIE instead of string. Because of that OPIE stop sense of localhost and des tries to fix OPIE config to add additional things here not needed by standard OPIE setup at all. Note that passing anything else than for localhost to OPIE is not supported by OPIE API and illegal. I mean NULL or localhost values now passed by PAM. Here is real fix for this problem for review. It includes backing out of /etc/opieaccess incorrect change. --- opieaccess.bak Sun Feb 16 04:25:20 2003 +++ opieaccess Sun Feb 16 04:27:04 2003 @@ -3,11 +3,10 @@ # This file controls whether UNIX passwords are to be permitted. Rules # are matched in order, and the search terminates when the first matching # rule has been found. Default action is deny. See opieaccess(5) for -# more information. +# more information. Local host is already permitted by default. # # Each rule has the form: # # permit address netmask # deny address netmask # -permit 127.0.0.1 255.255.255.255 --- pam_opieaccess.c.bakSun Feb 16 02:26:49 2003 +++ pam_opieaccess.cSun Feb 16 03:32:57 2003 @@ -42,6 +42,7 @@ #include sys/types.h #include opie.h #include pwd.h +#include strings.h #include unistd.h #include syslog.h @@ -73,8 +74,8 @@ r = pam_get_item(pamh, PAM_RHOST, (const void **)rhost); if (r != PAM_SUCCESS) return (r); - if (rhost == NULL) - rhost = localhost; + if (rhost == NULL || strcasecmp(rhost, localhost) == 0) + rhost = ; if (opieaccessfile(rhost) != 0 opiealways(pwent-pw_dir) != 0) return (PAM_SUCCESS); -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE breakage: backout patch for review
On Sun, Feb 16, 2003 at 04:41:58 +0300, Andrey A. Chernov wrote: des tries to fix OPIE config to add additional things here not needed by standard OPIE setup at all. To be more specific, exact breakage after des is: Old non-PAMified OPIE variant: localhost allowed even there is no /etc/opieaccess at all. New variant from des: if there is no /etc/opieaccess, localhost is not allowed. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wrong date for DEVFS entries
On Sat, Feb 08, 2003 at 09:01:20 +0100, [EMAIL PROTECTED] wrote: I see no solving way until kernel will understand fully and can handle timezone database format. It means timezone code should be integrated into kernel. And for which reason? Only to heal DEVFS timestamps? Mount workaround looks more light-weighted. Please re-read my earlier email on the topic. I wrote this after careful examination of your earlier email about taking zoneinfo information at boot time, i.e. about /boot/timezone.hint which must be in zoneinfo format to handle unlimited amount of machine up/down times. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wrong date for DEVFS entries
On Sat, Feb 08, 2003 at 16:52:28 +1100, Bruce Evans wrote: Obvious workaround: could DEVFS be mounted read-only initially and then re-mounted as read-write after adjkerntz started, in the same manner as / remounted read-write, i.e. with mount -u ? No. devfs silently ignores MNT_RDONLY and doesn't support MNT_UPDATE. I mean not right now situation, but it could fixed to handle them. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wrong date for DEVFS entries
On Thu, Feb 06, 2003 at 22:10:43 +1100, Bruce Evans wrote: More precisely: some are mounted, but they are mounted read-only (modulo the bug that adjkerntz is run a little after mounting filesystems read-write). Obvious workaround: could DEVFS be mounted read-only initially and then re-mounted as read-write after adjkerntz started, in the same manner as / remounted read-write, i.e. with mount -u ? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wrong date for DEVFS entries
On Sat, Feb 08, 2003 at 00:16:24 +0100, [EMAIL PROTECTED] wrote: Can we stop considering workarounds, and instead work on solving the problem please ? I see no solving way until kernel will understand fully and can handle timezone database format. It means timezone code should be integrated into kernel. And for which reason? Only to heal DEVFS timestamps? Mount workaround looks more light-weighted. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wrong date for DEVFS entries
On Thu, Feb 06, 2003 at 11:27:36 +0100, [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Bruce Evans writes: On Thu, 6 Feb 2003, Andrey A. Chernov wrote: On Wed, Feb 05, 2003 at 23:44:08 +0100, [EMAIL PROTECTED] wrote: 2) Feb 6 01:36 (boot time) 3) Feb 6 04:36 (+3 TZ future jump) These timestamps have been touched, and the clock has made a 3 hour jump either forward or backward at some point. The problem is the clock jump, not DEVFS. Clock jump happens as it supposed when adjkerntz(8) corrects machine clock back to GMT via various CPU_* sysctl's. Could touched DEVFS stamps be fixed back to something useful in the same sysctl code too? This should be well known to devfs users. devfs sets at least some of the times before adjkerntz can run, and nothing fixes them, so these times are wrong by the timezone difference. This is not any different from any other filesystem. No, it IS different - no real filesystems mounted at this point yet, so no real timestamps damaged. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wrong date for DEVFS entries
On Thu, Feb 06, 2003 at 11:44:29 +0100, [EMAIL PROTECTED] wrote: Think diskless NFS, think MD(4) based root, think... They are read-only at this rc stage, so something could be damaged are access times only. I avoid it entirely by using UTC time in my RTC, but this is not an option for machines which have to boot broken-as-designed OSs. Yes, the main reason not running BIOS clock at UTC is other OSes like M$ ones installed in the same machine. I don't know if modern bios's know about timezones and DST, I've seen some that has setup functions for it, but I don't know if there is any way to find the information they store and I don't think such features are widespread. I saw this too, but it is totally useless, even M$ can't handle such BIOSes. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Wrong date for DEVFS entries
Look at the snapshot below, taken right after boot time. Most entries are at Feb 5 22:34 which is boot time, but some other are Feb 6 01:34 which is in the future! It looks like TZ offset added for them by mistake. Please fix this bug. total 1 crw--- 1 root wheel 152, 0 Feb 5 22:34 acpi crw-rw-r-- 1 root operator 39, 0 Feb 5 22:34 apm crw--- 1 root wheel 0, 0 Feb 5 22:34 console crw--- 1 root wheel 12, 255 Feb 6 01:34 consolectl crw-rw-rw- 1 root wheel 1, 0 Feb 5 22:34 ctty crw-r- 1 root operator4, 1 Feb 5 22:34 da0 crw-r- 1 root operator4, 2 Feb 5 22:34 da0s1 crw-r- 1 root operator4, 3 Feb 6 01:34 da0s1a crw-r- 1 root operator4, 4 Feb 6 01:34 da0s1b crw-r- 1 root operator4, 5 Feb 5 22:34 da0s1c crw--- 1 root wheel 173, 0 Feb 5 22:34 devctl dr-xr-xr-x 2 root wheel 512 Feb 6 01:34 fd crw-r- 1 root operator9, 0 Feb 5 22:34 fd0 crw-r- 1 root operator4, 0 Feb 5 22:34 geom.ctl crw--- 1 root wheel 2, 14 Feb 5 22:34 io crw--- 1 root wheel 7, 0 Feb 5 22:34 klog crw-r- 1 root kmem2, 1 Feb 5 22:34 kmem lrwxr-xr-x 1 root wheel3 Feb 5 22:34 log - /var/run/log crw-r- 1 root kmem2, 0 Feb 5 22:34 mem dr-xr-xr-x 2 root wheel 512 Feb 6 01:34 net lrwxr-xr-x 1 root wheel4 Feb 6 01:34 net1 - net/de0 lrwxr-xr-x 1 root wheel4 Feb 6 01:34 net2 - net/lo0 crw--- 1 root wheel 165, 0 Feb 5 22:34 network crw-rw-rw- 1 root wheel 2, 2 Feb 5 22:37 null crw--- 1 root operator 31, 0 Feb 5 22:34 pass0 crw-r--r-- 1 root wheel 78, 0 Feb 5 22:34 pci crw-rw-rw- 1 root wheel 6, 0 Feb 5 22:40 ptyp0 crw-rw-rw- 1 root wheel 2, 3 Feb 6 01:34 random lrwxr-xr-x 1 root wheel6 Feb 6 01:34 stderr - fd/2 lrwxr-xr-x 1 root wheel5 Feb 6 01:34 stdin - fd/0 lrwxr-xr-x 1 root wheel6 Feb 6 01:34 stdout - fd/1 crw--- 1 root wheel 12, 128 Feb 5 22:34 sysmouse crw--w 1 ache tty 5, 0 Feb 5 22:40 ttyp0 crw--- 1 root wheel 12, 0 Feb 5 22:34 ttyv0 crw--- 1 root wheel 12, 1 Feb 5 22:34 ttyv1 crw--- 1 root wheel 12, 2 Feb 5 22:34 ttyv2 crw--- 1 root wheel 12, 3 Feb 5 22:34 ttyv3 crw--- 1 root wheel 12, 4 Feb 5 22:34 ttyv4 crw--- 1 root wheel 12, 5 Feb 5 22:34 ttyv5 crw--- 1 root wheel 12, 6 Feb 5 22:34 ttyv6 crw--- 1 root wheel 12, 7 Feb 5 22:34 ttyv7 crw--- 1 root wheel 12, 8 Feb 5 22:34 ttyv8 crw--- 1 root wheel 12, 9 Feb 5 22:34 ttyv9 crw--- 1 root wheel 12, 10 Feb 5 22:34 ttyva crw--- 1 root wheel 12, 11 Feb 5 22:34 ttyvb crw--- 1 root wheel 12, 12 Feb 5 22:34 ttyvc crw--- 1 root wheel 12, 13 Feb 5 22:34 ttyvd crw--- 1 root wheel 12, 14 Feb 5 22:34 ttyve crw--- 1 root wheel 12, 15 Feb 5 22:34 ttyvf lrwxr-xr-x 1 root wheel7 Feb 6 01:34 urandom - random lrwxr-xr-x 1 root wheel3 Feb 5 22:34 vga - ttyv0 crw--- 1 root operator 104, 0 Feb 5 22:34 xpt0 crw-rw-rw- 1 root wheel 2, 12 Feb 5 22:34 zero -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wrong date for DEVFS entries
On Wed, Feb 05, 2003 at 20:52:54 +0100, [EMAIL PROTECTED] wrote: My guess: Your RTC has the wrong time and ntpdate or similar stepped your clock to be correct. It is each boot repeated effect, not one time. I run local clock in BIOS and use adjkerntz(8) to correct kernel time to GMT, via standard /etc/wall_cmos_clock knob. It there any chance that DEVFS comes up in the middle? If yes, is there any ideas for workaround? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wrong date for DEVFS entries
On Wed, Feb 05, 2003 at 22:10:41 +0100, [EMAIL PROTECTED] wrote: You can try this patch instead. It has a different side effect: if you reset your clock the (untouched) timestamps will change. It not helps, see 00:48 - 03:48 future jump for some entries (00:48 is boot time): total 1 crw-r--r-- 1 root operator 117, 0 Feb 6 00:48 acd0 crw-r--r-- 1 root operator 117, 1 Feb 6 00:48 acd1 crw--- 1 root wheel 152, 0 Feb 6 00:48 acpi crw-r- 1 root operator4, 1 Feb 6 00:48 ad0 crw-r- 1 root operator4, 2 Feb 6 00:48 ad0s1 crw-r- 1 root operator4, 4 Feb 6 00:48 ad0s1a crw-r- 1 root operator4, 5 Feb 6 00:48 ad0s1b crw-r- 1 root operator4, 6 Feb 6 00:48 ad0s1c crw-r- 1 root operator4, 3 Feb 6 00:48 ad0s2 crw--- 1 root wheel 148, 0 Feb 6 00:48 agpgart crw-rw-r-- 1 root operator 39, 0 Feb 6 00:48 apm crw--- 1 root operator 159, 0 Feb 6 00:48 ata crw-rw-rw- 1 root wheel 21, 0 Feb 6 00:48 bpsm0 crw--- 1 root wheel 0, 0 Feb 6 00:48 console crw--- 1 root wheel 12, 255 Feb 6 00:48 consolectl crw-rw-rw- 1 root wheel 1, 0 Feb 6 00:48 ctty crw-rw 1 uucp dialer 28, 128 Feb 6 00:48 cuaa0 crw-rw 1 uucp dialer 28, 129 Feb 6 00:48 cuaa1 crw-rw 1 uucp dialer 28, 160 Feb 6 00:48 cuaia0 crw-rw 1 uucp dialer 28, 161 Feb 6 00:48 cuaia1 crw-rw 1 uucp dialer 28, 192 Feb 6 00:48 cuala0 crw-rw 1 uucp dialer 28, 193 Feb 6 00:48 cuala1 crw--- 1 root wheel 173, 0 Feb 6 00:48 devctl dr-xr-xr-x 2 root wheel 512 Feb 6 03:48 fd crw-r- 1 root operator9, 0 Feb 6 00:48 fd0 crw-r- 1 root operator4, 0 Feb 6 00:48 geom.ctl crw--- 1 root wheel 2, 14 Feb 6 00:48 io crw--- 1 root wheel 7, 0 Feb 6 00:48 klog crw-r- 1 root kmem2, 1 Feb 6 00:48 kmem lrwxr-xr-x 1 root wheel3 Feb 6 00:48 log - /var/run/log crw--- 1 root wheel 16, 0 Feb 6 00:48 lpt0 crw--- 1 root wheel 16, 128 Feb 6 00:48 lpt0.ctl crw-r- 1 root kmem2, 0 Feb 6 00:48 mem dr-xr-xr-x 2 root wheel 512 Feb 6 03:48 net lrwxr-xr-x 1 root wheel4 Feb 6 03:48 net1 - net/lo0 crw--- 1 root wheel 165, 0 Feb 6 00:48 network crw-rw-rw- 1 root wheel 2, 2 Feb 6 00:48 null crw-r--r-- 1 root wheel 78, 0 Feb 6 00:48 pci crw-rw-rw- 1 root wheel 21, 1 Feb 6 00:48 psm0 crw-rw-rw- 1 root wheel 2, 3 Feb 6 03:48 random crw--- 1 root wheel 26, 0 Feb 6 00:48 speaker lrwxr-xr-x 1 root wheel6 Feb 6 03:48 stderr - fd/2 lrwxr-xr-x 1 root wheel5 Feb 6 03:48 stdin - fd/0 lrwxr-xr-x 1 root wheel6 Feb 6 03:48 stdout - fd/1 crw--- 1 root wheel 12, 128 Feb 6 00:48 sysmouse crw--- 1 root wheel 28, 0 Feb 6 00:48 ttyd0 crw--- 1 root wheel 28, 1 Feb 6 00:48 ttyd1 crw--- 1 root wheel 28, 32 Feb 6 00:48 ttyid0 crw--- 1 root wheel 28, 33 Feb 6 00:48 ttyid1 crw--- 1 root wheel 28, 64 Feb 6 00:48 ttyld0 crw--- 1 root wheel 28, 65 Feb 6 00:48 ttyld1 crw--w 1 ache tty12, 0 Feb 6 00:49 ttyv0 crw--- 1 root wheel 12, 1 Feb 6 00:48 ttyv1 crw--- 1 root wheel 12, 2 Feb 6 00:48 ttyv2 crw--- 1 root wheel 12, 3 Feb 6 00:48 ttyv3 crw--- 1 root wheel 12, 4 Feb 6 00:48 ttyv4 crw--- 1 root wheel 12, 5 Feb 6 00:48 ttyv5 crw--- 1 root wheel 12, 6 Feb 6 00:48 ttyv6 crw--- 1 root wheel 12, 7 Feb 6 00:48 ttyv7 crw--- 1 root wheel 12, 8 Feb 6 00:48 ttyv8 crw--- 1 root wheel 12, 9 Feb 6 00:48 ttyv9 crw--- 1 root wheel 12, 10 Feb 6 00:48 ttyva crw--- 1 root wheel 12, 11 Feb 6 00:48 ttyvb crw--- 1 root wheel 12, 12 Feb 6 00:48 ttyvc crw--- 1 root wheel 12, 13 Feb 6 00:48 ttyvd crw--- 1 root wheel 12, 14 Feb 6 00:48 ttyve crw--- 1 root wheel 12, 15 Feb 6 00:48 ttyvf lrwxr-xr-x 1 root wheel7 Feb 6 03:48 urandom - random crw-rw 1 root operator 108, 255 Feb 6 00:48 usb crw-rw 1 root operator 108, 0 Feb 6 00:48 usb0 crw-rw 1 root operator 108, 1 Feb 6 00:48 usb1 crw-rw 1 root operator 108, 2 Feb 6 00:48 usb2 lrwxr-xr-x 1 root wheel3 Feb 6 00:48 vga - ttyv0 crw-rw-rw- 1 root wheel 2, 12 Feb 6 00:48 zero -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wrong date for DEVFS entries
On Wed, Feb 05, 2003 at 23:23:26 +0100, [EMAIL PROTECTED] wrote: Try to remove the three fix lines, and see what you get then. Very strange effect: 3 kinds of entries appearse: 1) Jan 1 1970 2) Feb 6 01:36 (boot time) 3) Feb 6 04:36 (+3 TZ future jump) total 1 crw-r--r-- 1 root operator 117, 0 Jan 1 1970 acd0 crw-r--r-- 1 root operator 117, 1 Jan 1 1970 acd1 crw--- 1 root wheel 152, 0 Jan 1 1970 acpi crw-r- 1 root operator4, 1 Jan 1 1970 ad0 crw-r- 1 root operator4, 2 Jan 1 1970 ad0s1 crw-r- 1 root operator4, 4 Jan 1 1970 ad0s1a crw-r- 1 root operator4, 5 Jan 1 1970 ad0s1b crw-r- 1 root operator4, 6 Jan 1 1970 ad0s1c crw-r- 1 root operator4, 3 Jan 1 1970 ad0s2 crw--- 1 root wheel 148, 0 Jan 1 1970 agpgart crw-rw-r-- 1 root operator 39, 0 Jan 1 1970 apm crw--- 1 root operator 159, 0 Jan 1 1970 ata crw-rw-rw- 1 root wheel 21, 0 Jan 1 1970 bpsm0 crw--- 1 root wheel 0, 0 Feb 6 01:36 console crw--- 1 root wheel 12, 255 Jan 1 1970 consolectl crw-rw-rw- 1 root wheel 1, 0 Jan 1 1970 ctty crw-rw 1 uucp dialer 28, 128 Jan 1 1970 cuaa0 crw-rw 1 uucp dialer 28, 129 Jan 1 1970 cuaa1 crw-rw 1 uucp dialer 28, 160 Jan 1 1970 cuaia0 crw-rw 1 uucp dialer 28, 161 Jan 1 1970 cuaia1 crw-rw 1 uucp dialer 28, 192 Jan 1 1970 cuala0 crw-rw 1 uucp dialer 28, 193 Jan 1 1970 cuala1 crw--- 1 root wheel 173, 0 Jan 1 1970 devctl dr-xr-xr-x 2 root wheel 512 Feb 6 04:36 fd crw-r- 1 root operator9, 0 Jan 1 1970 fd0 crw-r- 1 root operator4, 0 Jan 1 1970 geom.ctl crw--- 1 root wheel 2, 14 Jan 1 1970 io crw--- 1 root wheel 7, 0 Jan 1 1970 klog crw-r- 1 root kmem2, 1 Jan 1 1970 kmem lrwxr-xr-x 1 root wheel3 Feb 6 01:36 log - /var/run/log crw--- 1 root wheel 16, 0 Jan 1 1970 lpt0 crw--- 1 root wheel 16, 128 Jan 1 1970 lpt0.ctl crw-r- 1 root kmem2, 0 Jan 1 1970 mem dr-xr-xr-x 2 root wheel 512 Feb 6 04:36 net lrwxr-xr-x 1 root wheel4 Feb 6 04:36 net1 - net/lo0 crw--- 1 root wheel 165, 0 Jan 1 1970 network crw-rw-rw- 1 root wheel 2, 2 Feb 6 01:36 null crw-r--r-- 1 root wheel 78, 0 Jan 1 1970 pci crw-rw-rw- 1 root wheel 21, 1 Jan 1 1970 psm0 crw-rw-rw- 1 root wheel 2, 3 Feb 6 04:36 random crw--- 1 root wheel 26, 0 Jan 1 1970 speaker lrwxr-xr-x 1 root wheel6 Feb 6 04:36 stderr - fd/2 lrwxr-xr-x 1 root wheel5 Feb 6 04:36 stdin - fd/0 lrwxr-xr-x 1 root wheel6 Feb 6 04:36 stdout - fd/1 crw--- 1 root wheel 12, 128 Jan 1 1970 sysmouse crw--- 1 root wheel 28, 0 Jan 1 1970 ttyd0 crw--- 1 root wheel 28, 1 Jan 1 1970 ttyd1 crw--- 1 root wheel 28, 32 Jan 1 1970 ttyid0 crw--- 1 root wheel 28, 33 Jan 1 1970 ttyid1 crw--- 1 root wheel 28, 64 Jan 1 1970 ttyld0 crw--- 1 root wheel 28, 65 Jan 1 1970 ttyld1 crw--w 1 ache tty12, 0 Feb 6 01:36 ttyv0 crw--w 1 ache tty12, 1 Feb 6 01:37 ttyv1 crw--- 1 root wheel 12, 2 Feb 6 01:36 ttyv2 crw--- 1 root wheel 12, 3 Feb 6 01:36 ttyv3 crw--- 1 root wheel 12, 4 Feb 6 01:36 ttyv4 crw--- 1 root wheel 12, 5 Feb 6 01:36 ttyv5 crw--- 1 root wheel 12, 6 Feb 6 01:36 ttyv6 crw--- 1 root wheel 12, 7 Feb 6 01:36 ttyv7 crw--- 1 root wheel 12, 8 Jan 1 1970 ttyv8 crw--- 1 root wheel 12, 9 Jan 1 1970 ttyv9 crw--- 1 root wheel 12, 10 Jan 1 1970 ttyva crw--- 1 root wheel 12, 11 Jan 1 1970 ttyvb crw--- 1 root wheel 12, 12 Jan 1 1970 ttyvc crw--- 1 root wheel 12, 13 Jan 1 1970 ttyvd crw--- 1 root wheel 12, 14 Jan 1 1970 ttyve crw--- 1 root wheel 12, 15 Jan 1 1970 ttyvf lrwxr-xr-x 1 root wheel7 Feb 6 04:36 urandom - random crw-rw 1 root operator 108, 255 Jan 1 1970 usb crw-rw 1 root operator 108, 0 Jan 1 1970 usb0 crw-rw 1 root operator 108, 1 Jan 1 1970 usb1 crw-rw 1 root operator 108, 2 Jan 1 1970 usb2 lrwxr-xr-x 1 root wheel3 Feb 6 01:36 vga - ttyv0 crw-rw-rw- 1 root wheel 2, 12 Jan 1 1970 zero -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Wrong date for DEVFS entries
On Wed, Feb 05, 2003 at 23:44:08 +0100, [EMAIL PROTECTED] wrote: 2) Feb 6 01:36 (boot time) 3) Feb 6 04:36 (+3 TZ future jump) These timestamps have been touched, and the clock has made a 3 hour jump either forward or backward at some point. The problem is the clock jump, not DEVFS. Clock jump happens as it supposed when adjkerntz(8) corrects machine clock back to GMT via various CPU_* sysctl's. Could touched DEVFS stamps be fixed back to something useful in the same sysctl code too? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Mon, Feb 03, 2003 at 21:40:20 -0800, David Schultz wrote: followed by a 5 or 6. There is a similar pattern for 'e a 7'. I think this pretty much demonstrates that the algorithm isn't good enough to generate high-quality randomness with respect to different seed values. I'm not suggesting that it absolutely must be replaced, since most rand() implementations aren't very good in the first place, but I'm pointing out that to do a good job of fixing it once and for all is harder than you might think. I don't try to make rand() good for high-quality pseudo-randomness, because it can be done by price of speed and, more important, big state size. Due to rand_r() restriction state size can be one word only, so we can choose rand() algorithm only from those which pass this restrictions. So, if you define USE_WEAK_SEEDING and re-compile rand.c, you'll get even worse results from your test. It means current variant is better then previous. If you know even better algorithm wich pass restrictions above, just tell and we consider switching to it. Returning to current algorithm, I am interested in good NSHUFF value in the range 100-2000. Do you have any findings there? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Tue, Feb 04, 2003 at 12:46:59 +0300, Andrey A. Chernov wrote: Returning to current algorithm, I am interested in good NSHUFF value in the range 100-2000. Do you have any findings there? Apparently 100 is not enough too, I see repeated pattern in your program. I'll try other values... -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Tue, Feb 04, 2003 at 12:46:59 +0300, Andrey A. Chernov wrote: So, if you define USE_WEAK_SEEDING and re-compile rand.c, you'll get even worse results from your test. It means current variant is better then previous. If you know even better algorithm wich pass restrictions above, just tell and we consider switching to it. Here is result from your test for USE_WEAK_SEEDING, i.e. for old algorithm. As we can see, it even worse than current one. It means that returning to old algoritm as Kris means (maybe?) is not an option. 1 e b 8 5 2 f c 9 6 3 0 d a 7 4 1 e b 8 5 2 f c 9 6 3 0 d a 7 4 1 e b 8 5 2 f c 9 6 3 0 d a 7 4 1 e b 8 5 2 f c 9 6 3 0 d a 7 4 1 e b 8 5 2 f c 9 6 3 0 d a 7 4 1 e b 8 5 2 f c 9 6 3 0 d a 7 4 1 e b 8 5 2 f c 9 6 3 0 d a 7 4 1 e b 8 5 2 f c 9 6 3 0 d a 7 4 1 e b 8 5 2 f c 9 6 3 0 d a 7 4 1 e b 8 5 2 f c 9 6 3 0 d a 7 4 1 e b 8 5 2 f c 9 6 3 0 d a 7 4 1 e b 8 5 2 f c 9 6 3 0 d a 7 4 -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Tue, Feb 04, 2003 at 12:58:40 +0300, Andrey A. Chernov wrote: On Tue, Feb 04, 2003 at 12:46:59 +0300, Andrey A. Chernov wrote: Returning to current algorithm, I am interested in good NSHUFF value in the range 100-2000. Do you have any findings there? Apparently 100 is not enough too, I see repeated pattern in your program. I'll try other values... Well, I find that bigger values are not better, it means that algorithm limit is reached, so just 100 is good enough... -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Tue, Feb 04, 2003 at 03:52:37 -0800, David Schultz wrote: You can do better than the present generator with 32 bits of state. See the following page by Neal Wagner (not to be confused with David Wagner): http://www.cs.utsa.edu/~wagner/laws/rng.html The section on LCGs suggests that the multiplier FreeBSD uses (7^5) is not particularly good, and points out some better values suggested by Knuth. I can't find the original discussion in TAOCP vol. 2, but Thank for your pointer, I'll look at later. Well, if 0 doesn't work, and 10 doesn't work, and 100 doesn't work, then I'm not too hopeful about 2000. I appeal to Asimov's zero, one, infinity law. I found that f.e. 50 is worse than 100, but 200 isn't better. 100 is better than 0 because remove monotonically increased sequence. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Tue, Feb 04, 2003 at 15:07:30 +0300, Andrey A. Chernov wrote: On Tue, Feb 04, 2003 at 03:52:37 -0800, David Schultz wrote: You can do better than the present generator with 32 bits of state. See the following page by Neal Wagner (not to be confused with David Wagner): http://www.cs.utsa.edu/~wagner/laws/rng.html The section on LCGs suggests that the multiplier FreeBSD uses (7^5) is not particularly good, and points out some better values suggested by Knuth. I can't find the original discussion in TAOCP vol. 2, but Two variants looks interesting from that paper: m=2^31-1, k=48271 m=2^31-1, k=62089911 Do you know any comparison of them with what we currently have, i.e. m=2^31-1, k=16807 -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Tue, Feb 04, 2003 at 14:00:27 +0100, Dag-Erling Smorgrav wrote: David Schultz [EMAIL PROTECTED] writes: You can do better than the present generator with 32 bits of state. See the following page by Neal Wagner (not to be confused with David Wagner): http://www.cs.utsa.edu/~wagner/laws/rng.html The attached patch, based on one of the m/k pairs suggested on that page, results in the following: I just think about 62089911 and 48271 too :-) There is one bug in your patch: 0 is still illegal, so my fix required. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Tue, Feb 04, 2003 at 16:10:06 +0300, Andrey A. Chernov wrote: On Tue, Feb 04, 2003 at 14:00:27 +0100, Dag-Erling Smorgrav wrote: David Schultz [EMAIL PROTECTED] writes: You can do better than the present generator with 32 bits of state. See the following page by Neal Wagner (not to be confused with David Wagner): http://www.cs.utsa.edu/~wagner/laws/rng.html The attached patch, based on one of the m/k pairs suggested on that page, results in the following: I just think about 62089911 and 48271 too :-) There is one bug in your patch: 0 is still illegal, so my fix required. The next bug is that there is % RAND_MAX + 1, not % RAND_MAX. The next is not the bug but portability thing alowing different RAND_MAX: you need to assign *ctx first and return it % RAND_MAX + 1 next, not assign *ctx % RAND_MAX + 1 like you currently does. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Tue, Feb 04, 2003 at 16:17:48 +0300, Andrey A. Chernov wrote: On Tue, Feb 04, 2003 at 16:10:06 +0300, Andrey A. Chernov wrote: On Tue, Feb 04, 2003 at 14:00:27 +0100, Dag-Erling Smorgrav wrote: David Schultz [EMAIL PROTECTED] writes: You can do better than the present generator with 32 bits of state. See the following page by Neal Wagner (not to be confused with David Wagner): http://www.cs.utsa.edu/~wagner/laws/rng.html The attached patch, based on one of the m/k pairs suggested on that page, results in the following: I just think about 62089911 and 48271 too :-) There is one bug in your patch: 0 is still illegal, so my fix required. The next bug is that there is % RAND_MAX + 1, not % RAND_MAX. The next is not the bug but portability thing alowing different RAND_MAX: you need to assign *ctx first and return it % RAND_MAX + 1 next, not assign *ctx % RAND_MAX + 1 like you currently does. And the next bug is 32bit overflow there: tmp = *ctx * 62089911; must be tmp = (uint64_t) *ctx * 62089911; I'll produce working variant based on your patch... -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Tue, Feb 04, 2003 at 16:28:45 +0300, Andrey A. Chernov wrote:
I'll produce working variant based on your patch...
When all done correctly, there is repeated pattern still, so some NSHUFF
drop required too:
1 7 e 4 a 0 7 d 3 a 0 6
See attached patch based on -current sources.
--
Andrey A. Chernov
http://ache.pp.ru/
--- /usr/src/lib/libc/stdlib/rand.c Tue Feb 4 14:24:08 2003
+++ ./rand.cTue Feb 4 16:40:24 2003
@@ -51,10 +51,8 @@
#include stdio.h
#endif /* TEST */
-#define NSHUFF 100 /* to drop part of seed - 1st value correlation */
-
static int
-do_rand(unsigned long *ctx)
+do_rand(uint32_t *ctx)
{
#ifdef USE_WEAK_SEEDING
/*
@@ -65,24 +63,25 @@
return ((*ctx = *ctx * 1103515245 + 12345) % ((u_long)RAND_MAX + 1));
#else /* !USE_WEAK_SEEDING */
/*
- * Compute x = (7^5 * x) mod (2^31 - 1)
- * wihout overflowing 31 bits:
- * (2^31 - 1) = 127773 * (7^5) + 2836
- * From Random number generators: good ones are hard to find,
- * Park and Miller, Communications of the ACM, vol. 31, no. 10,
- * October 1988, p. 1195.
+ * New algorithm derived from
+ * The Laws of Cryptography: Pseudo-random Number Generation
+ * by Neal R. Wagner
+ * http://www.cs.utsa.edu/~wagner/laws/rng.html
+ * which itself is derived from work by Donald E. Knuth.
+ *
+ * This is a linear congruence generator using the equation
+ *
+ * x(n+1) = (k * x(n) + a) mod m
+ *
+ * where m is 2^31 - 1, k is 62089911 and a is 0.
*/
- long hi, lo, x;
+ uint64_t tmp;
/* Can't be initialized with 0, so use another value. */
if (*ctx == 0)
*ctx = 123459876;
- hi = *ctx / 127773;
- lo = *ctx % 127773;
- x = 16807 * lo - 2836 * hi;
- if (x 0)
- x += 0x7fff;
- return ((*ctx = x) % ((u_long)RAND_MAX + 1));
+ tmp = ((uint64_t)*ctx * 62089911) % 2147483647;
+ return ((*ctx = tmp) % ((uint32_t)RAND_MAX + 1));
#endif /* !USE_WEAK_SEEDING */
}
@@ -90,7 +89,7 @@
int
rand_r(unsigned int *ctx)
{
- u_long val = (u_long) *ctx;
+ uint32_t val = (uint32_t)*ctx;
int r = do_rand(val);
*ctx = (unsigned int) val;
@@ -98,7 +97,7 @@
}
-static u_long next = 1;
+static uint32_t next = 1;
int
rand()
@@ -110,11 +109,7 @@
srand(seed)
u_int seed;
{
- int i;
-
next = seed;
- for (i = 0; i NSHUFF; i++)
- (void)do_rand(next);
}
Re: rand() is broken
On Tue, Feb 04, 2003 at 14:43:57 +0100, Dag-Erling Smorgrav wrote: I believe that's a feature. All linear congruence generator have a fixed point. 0 is a far better fixed point than any other because it is more obviously unsuited (for some values of obviously) as a seed value. (but see below) It is implementation details. rand() manpage says nothing about linear congruence generator and not suppose special meaning of 0 which means that application stuck at this point. We should not relay on that. The next bug is that there is % RAND_MAX + 1, not % RAND_MAX. No, using modulo 0x8000 instead of modulo 0x7fff breaks the algorithm. (but see below) Yes, but manpage says about range from 0 to RAND_MAX inclusive. It means that RAND_MAX clipping must be not part of algorithm and be applied only at later stage. Changing RAND_MAX affects the algorithm in such a way that you should not do so without giving serious thought to revising the algorithm Changing RAND_MAX should NOT affect algorithm at all, because RAND_MAX is not part of it. All that being said, adding 1 to *ctx before returning it (see patch) adresses both of your objections: a seed of 0 will not cause the LCG to get stuck, and the result of rand() will range between 0 and RAND_MAX inclusive. Adding +1 you break algorithm formulae badly from math point of view, something else then given formulae not allowed here. You can change 'a' parameter to anything you want, but not add something at the end. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Tue, Feb 04, 2003 at 16:47:14 +0300, Andrey A. Chernov wrote: On Tue, Feb 04, 2003 at 16:28:45 +0300, Andrey A. Chernov wrote: I'll produce working variant based on your patch... When all done correctly, there is repeated pattern still, so some NSHUFF drop required too: 1 7 e 4 a 0 7 d 3 a 0 6 See attached patch based on -current sources. With NSHUFF 100 situation not changed much, so I beleive that stated problem is common for this type PRNGs, so we gains nothing changing formulae to Knuth-recommended values. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Tue, Feb 04, 2003 at 15:23:28 +0100, Dag-Erling Smorgrav wrote: Andrey A. Chernov [EMAIL PROTECTED] writes: On Tue, Feb 04, 2003 at 14:43:57 +0100, Dag-Erling Smorgrav wrote: All that being said, adding 1 to *ctx before returning it (see patch) adresses both of your objections: a seed of 0 will not cause the LCG to get stuck, and the result of rand() will range between 0 and RAND_MAX inclusive. Adding +1 you break algorithm formulae badly from math point of view, something else then given formulae not allowed here. You can change 'a' parameter to anything you want, but not add something at the end. Do the math - adding 1 after the modulo operation is equivalent to setting a == k. Repeated k may affect distribution. Better variant will be with a != k. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Tue, Feb 04, 2003 at 15:22:03 +0100, Dag-Erling Smorgrav wrote: Yes we do. We get a better sequence for any given seed, i.e. we get less correlation between n and x(n) for any given x(0). I don't think it changes much for long sequences, but we get a better distribution for short sequences (including short subsequences of long sequences). Maybe, I am not sure here, we need to ask expert. As for patterns in the lower bits, we should try with a != 0 and see how that affects the results. I believe the purpose of a in the LCG algorithm is to scramble the lower bits. a != 0 eliminates 0 stuck problem, no additional visible effects. Even with a != 0 values are monotonically increased, I try with a == 123459876 0: 123459876 1: 185549787 2: 247639698 3: 309729609 4: 371819520 5: 433909431 6: 495999342 7: 558089253 8: 620179164 9: 682269075 -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Tue, Feb 04, 2003 at 17:36:04 +0300, Andrey A. Chernov wrote: with a != 0 values are monotonically increased, I try with a == 123459876 With your a == 62089911 (i.e. +1) the same: 0: 62089911 1: 124179822 2: 186269733 3: 248359644 4: 310449555 5: 372539466 6: 434629377 7: 496719288 8: 558809199 9: 620899110 With a == 0 the same: 0: 0 1: 62089911 2: 124179822 3: 186269733 4: 248359644 5: 310449555 6: 372539466 7: 434629377 8: 496719288 9: 558809199 Where is improvement? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Sun, Feb 02, 2003 at 16:26:39 -0800, David Schultz wrote: The correlation is still present with your patch and NSHUFF set to 10. For instance, try seeding rand() with contiguous monotonically increasing integers, and observe the four lowest-order bits. Since you already have running framework for that, could you please test it with NSHUFF picked from 100-2000 range? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Final fix for 0 problem (was Re: rand() is broken)
On Mon, Feb 03, 2003 at 10:55:42 +, Mark Murray wrote: How do you _know_ that your newly chosen magic number isn't going to cause some kind of recurring (and too-short) sequence of numbers? I run simple test for it, it is not too short. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Final fix for 0 problem (was Re: rand() is broken)
On Mon, Feb 03, 2003 at 14:08:41 +0300, Andrey A. Chernov wrote: On Mon, Feb 03, 2003 at 10:55:42 +, Mark Murray wrote: How do you _know_ that your newly chosen magic number isn't going to cause some kind of recurring (and too-short) sequence of numbers? I run simple test for it, it is not too short. To be more specific - it never returns to 0 from this value at least in 2**31 iterations. You can test it by yourself, the code is obvious: srand(0) ... loop ... if (rand() == 0) print iteration number -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Final fix for 0 problem (was Re: rand() is broken)
On Mon, Feb 03, 2003 at 11:19:17 +, Mark Murray wrote: simple test? How long did you check for? See my another message with details. random() is documented to not repeat before some number of outputs; how do you know that this fix does not significantly shorten that? random(3) is not affected to to its hashing nature. We talk about rand(3). -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Final fix for 0 problem (was Re: rand() is broken)
On Mon, Feb 03, 2003 at 14:26:00 +0300, Andrey A. Chernov wrote: random(3) is not affected to to its hashing nature. We talk about rand(3). to to = due to -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Final fix for correlation problem (was Re: rand() is broken)
This is final fix for 1st value correlation problem. Somebody with
math statistic knowledge please run some test to be sure that NSHUFF is
good enough for this simple PRNG (i.e. not 100% good, but good for average
quality PRNG we have). My simple test shown that 100 is enough, but I
am not PRNG math expert. Maybe increasing NSHUFF up too 2000 required.
Similar patch is needed for random(3) TYPE_0 too, I'll produce it when we
find good NSHUFF.
--- stdlib/rand.c.bak Mon Feb 3 13:22:12 2003
+++ stdlib/rand.c Mon Feb 3 14:03:58 2003
@@ -51,6 +51,8 @@
#include stdio.h
#endif /* TEST */
+#define NSHUFF 100 /* to drop seed - 1st value correlation */
+
static int
do_rand(unsigned long *ctx)
{
@@ -108,7 +110,11 @@
srand(seed)
u_int seed;
{
+ int i;
+
next = seed;
+ for (i = 0; i NSHUFF; i++)
+ (void)do_rand(next);
}
@@ -137,7 +143,7 @@
unsigned long junk;
gettimeofday(tv, NULL);
- next = (getpid() 16) ^ tv.tv_sec ^ tv.tv_usec ^ junk;
+ srand((getpid() 16) ^ tv.tv_sec ^ tv.tv_usec ^ junk);
}
}
--
Andrey A. Chernov
http://ache.pp.ru/
msg51666/pgp0.pgp
Description: PGP signature
Re: Final fix for correlation problem (was Re: rand() is broken)
On Mon, Feb 03, 2003 at 07:01:50 -0500, Thomas David Rivers wrote: Please, oh please, don't change that behavior in srand()/rand(). This subject is not discussed (again). We already discuss it long time ago and agrees that changes are allowed especially when they fix bugs. Search mailing lists for exact arguments. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Sat, Feb 01, 2003 at 23:06:50 -0800, Kris Kennaway wrote:
FreeBSD's rand() implementation has been broken for the past 23
months, since the following commit:
i.e. the first value returned from rand() is correlated with the seed
given to srand(). This is a big problem unless your seed is randomly
chosen over its entire integer range. I noticed this because awk
exhibits the same problem, and the script seeds the generator with a
PID. The script works fine under 4.x since the rand() implementation
does not have this feature.
Yes, first value correlation is there, but old formulae have even worse
effect The random sequences do not vary much with the seed, as source
file comments and whole discussion about old RNG bad effects shown. I.e.
for different time+PID sequence, especially increased monotonically, like
in common practice, you'l got the same random sequence with old formulae
(which can't be called works fine because this fine work was the main
reason for change). So, returning to old formulae is not an option.
The real problem is not in formulae, but in srand() funclion. This simple
patch can fix first value correlation, and I plan to commit it, if we all
agree. I not find better value for NSHUFF right now, but think
that something like 10 will be enough to fight corellation completely.
Some generating picture tests needed.
--- stdlib/rand.c.bak Sat Jan 4 20:39:19 2003
+++ stdlib/rand.c Sun Feb 2 11:56:01 2003
@@ -51,6 +51,8 @@
#include stdio.h
#endif /* TEST */
+#define NSHUFF 3
+
static int
do_rand(unsigned long *ctx)
{
@@ -103,7 +105,11 @@
srand(seed)
u_int seed;
{
+ int i;
+
next = seed;
+ for (i = 0; i NSHUFF; i++)
+ (void)do_rand(next);
}
@@ -117,7 +123,7 @@
void
sranddev()
{
- int fd, done;
+ int fd, done, i;
done = 0;
fd = _open(/dev/random, O_RDONLY, 0);
@@ -133,6 +139,8 @@
gettimeofday(tv, NULL);
next = (getpid() 16) ^ tv.tv_sec ^ tv.tv_usec ^ junk;
+ for (i = 0; i NSHUFF; i++)
+ (void)do_rand(next);
}
}
--
Andrey A. Chernov
http://ache.pp.ru/
msg51491/pgp0.pgp
Description: PGP signature
Re: rand() is broken
On Sun, Feb 02, 2003 at 01:11:06 -0800, Kris Kennaway wrote: Another problem (noticed by tjr) is that once the sequence hits '0' it jumps to INT_MAX and stays there forever. For example, seeding with srand(0) produces nothing but INT_MAX from rand(). It looks like a lot more validation of this PRNG is needed. Don't have an idea about this thing yet, maybe some sign or variable size change fix required. BTW, note that new formulae also used in the kernel (by BSD developers) and taken from there - libkern/random.c - so all you say is true there too. -- Andrey A. Chernov http://ache.pp.ru/ msg51495/pgp0.pgp Description: PGP signature
Re: rand() is broken
On Sun, Feb 02, 2003 at 01:11:06 -0800, Kris Kennaway wrote: Another problem (noticed by tjr) is that once the sequence hits '0' it jumps to INT_MAX and stays there forever. For example, seeding with srand(0) produces nothing but INT_MAX from rand(). It looks like a lot more validation of this PRNG is needed. As I see searching through various sources, this is not simple overlook but fundamental feature of this formulae - it can't be initialized with zero and BSD developers try to deal with that fact by simple adding of INT_MAX in zero case (which is not in the original formulae), but gain nothing this way. Workaround I find so far is something like that #define MASK 123459876 seed ^= MASK; ... calculate value ... seed ^= MASK; Which just add another magick value, but fix zero. I am still searching... -- Andrey A. Chernov http://ache.pp.ru/ msg51498/pgp0.pgp Description: PGP signature
Re: rand() is broken
On Sun, Feb 02, 2003 at 03:48:17 -0800, David Schultz wrote: Specifically, rand() isn't very interesting in the lower-order bits, and it spectacularly fails nearly all of Marsaglia's It seems that you speak about old formulae, we use new one (which intended to fix low-ordered bits), see our rand.c source. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Sun, Feb 02, 2003 at 13:26:21 +0300, Andrey A. Chernov wrote:
Workaround I find so far is something like that
#define MASK 123459876
I found nothing better. Here is fix for 0 problem I plan to commit:
--- stdlib/rand.c.old Sat Jan 4 20:39:19 2003
+++ stdlib/rand.c Sun Feb 2 14:43:42 2003
@@ -70,14 +70,18 @@
* Park and Miller, Communications of the ACM, vol. 31, no. 10,
* October 1988, p. 1195.
*/
+#define SHIFT_MASK 123459876
long hi, lo, x;
- hi = *ctx / 127773;
- lo = *ctx % 127773;
+ /* Can't be initialized with 0, so use shifting mask. */
+ x = *ctx ^ SHIFT_MASK;
+ hi = x / 127773;
+ lo = x % 127773;
x = 16807 * lo - 2836 * hi;
- if (x = 0)
+ if (x 0)
x += 0x7fff;
- return ((*ctx = x) % ((u_long)RAND_MAX + 1));
+ *ctx = x ^ SHIFT_MASK;
+ return (x % ((u_long)RAND_MAX + 1));
#endif /* !USE_WEAK_SEEDING */
}
@@ -86,8 +90,10 @@
rand_r(unsigned int *ctx)
{
u_long val = (u_long) *ctx;
- *ctx = do_rand(val);
- return (int) *ctx;
+ int r = do_rand(val);
+
+ *ctx = (unsigned int) val;
+ return (r);
}
--- stdlib/random.c.old Sun Mar 24 23:42:48 2002
+++ stdlib/random.c Sun Feb 2 15:24:38 2003
@@ -142,6 +142,10 @@
*/
#defineMAX_TYPES 5 /* max number of types above */
+#ifndef USE_WEAK_SEEDING
+#define SHIFT_MASK 123459876
+#endif
+
static long degrees[MAX_TYPES] = { DEG_0, DEG_1, DEG_2, DEG_3, DEG_4 };
static long seps [MAX_TYPES] = { SEP_0, SEP_1, SEP_2, SEP_3, SEP_4 };
@@ -171,12 +175,12 @@
0x36413f93, 0xc622c298, 0xf5a42ab8, 0x8a88d77b, 0xf5ad9d0e, 0x8999220b,
0x27fb47b9,
#else /* !USE_WEAK_SEEDING */
- 0x991539b1, 0x16a5bce3, 0x6774a4cd, 0x3e01511e, 0x4e508aaa, 0x61048c05,
- 0xf5500617, 0x846b7115, 0x6a19892c, 0x896a97af, 0xdb48f936, 0x14898454,
- 0x37ffd106, 0xb58bff9c, 0x59e17104, 0xcf918a49, 0x09378c83, 0x52c7a471,
- 0x8d293ea9, 0x1f4fc301, 0xc3db71be, 0x39b44e1c, 0xf8a44ef9, 0x4c8b80b1,
- 0x19edc328, 0x87bf4bdd, 0xc9b240e5, 0xe9ee4b1b, 0x4382aee7, 0x535b6b41,
- 0xf3bec5da
+ 0x52a59789, 0x43164b1c, 0x7be52a82, 0x748ef343, 0x642a8923, 0x6ade1cd8,
+ 0x1ae76e27, 0x24b915ee, 0x2c42f326, 0x12ab3ee1, 0x4679af03, 0x876d19a0,
+ 0xe9e535ba, 0xad2471c8, 0x710262f8, 0xe1c16494, 0x29224bcc, 0x9710c348,
+ 0x7347f8e4, 0xe01ef1b4, 0x2030c33f, 0xd465e38, 0x925375aa, 0x6091d15d,
+ 0x467ee7d7, 0x92713312, 0x32346127, 0x8350e834, 0x3dadc6ea, 0x391364f2,
+ 0x8226561c,
#endif /* !USE_WEAK_SEEDING */
};
@@ -236,12 +240,14 @@
*/
long hi, lo;
+ /* Can't be initialized with 0, so use shifting mask. */
+ x ^= SHIFT_MASK;
hi = x / 127773;
lo = x % 127773;
x = 16807 * lo - 2836 * hi;
- if (x = 0)
+ if (x 0)
x += 0x7fff;
- return (x);
+ return (x ^ SHIFT_MASK); /* return state, not value */
#endif /* !USE_WEAK_SEEDING */
}
@@ -473,7 +479,12 @@
if (rand_type == TYPE_0) {
i = state[0];
- state[0] = i = (good_rand(i)) 0x7fff;
+ state[0] = good_rand(i);
+#ifndef USE_WEAK_SEEDING
+ i = state[0] ^ SHIFT_MASK;
+#else
+ i = state[0] 0x7fff;
+#endif
} else {
/*
* Use local variables rather than static variables for speed.
--
Andrey A. Chernov
http://ache.pp.ru/
msg51505/pgp0.pgp
Description: PGP signature
Re: rand() is broken
On Sun, Feb 02, 2003 at 04:38:53 -0800, Doug Barton wrote: I think it's worthwhile to wait till we get a chance to try arc4random(). This is libc's rand/random, it can't be fixed with arc4random() as designed. Also, have you run the code you're proposing through the tests in the post that David Schultz just made? This is fix form problem with 0, not for seed - 1st value correlation. I can't deal with two problems with same time, lets be sequental. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Mon, Feb 03, 2003 at 00:17:35 +1100, Tim Robbins wrote: I believe that this change just moves the bad seed to 123459876; after calling srand() with that seed, each call to rand() returns 0. Yes. Nothing better is possible for this formulae and this is documented in algorithm, some value must be excluded. Excluding 0 is bad only because srand(0) is commonly used and srand(123459876) is not. Ragarding to old formulae, the question is: what is worse, generate non-random lover bits everytime (old variant) or exclude one seed value (new variant)? Of course formulae can be changed to some another algorithm, but keep in mind that rand() must be simple and speedy. Now used variant is most simpler, others are much more complex. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Sun, Feb 02, 2003 at 16:42:25 +0300, Andrey A. Chernov wrote: On Mon, Feb 03, 2003 at 00:17:35 +1100, Tim Robbins wrote: I believe that this change just moves the bad seed to 123459876; after calling srand() with that seed, each call to rand() returns 0. Yes. Nothing better is possible for this formulae and this is documented in algorithm, some value must be excluded. Excluding 0 is bad only because srand(0) is commonly used and srand(123459876) is not. This workaround can be improved more, to make generator not stuck ever with 123459876 by simple way: if (seed == 123459876) seed = 123459877; It can be done even with original variant using more simpler patch: if (seed == 0) seed = 123459876; I'll produce and send it a bit later. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Sun, Feb 02, 2003 at 17:02:23 +0300, Andrey A. Chernov wrote:
I'll produce and send it a bit later.
Here it is.
--- stdlib/rand.c.old Sat Jan 4 20:39:19 2003
+++ stdlib/rand.c Sun Feb 2 17:06:08 2003
@@ -72,10 +72,13 @@
*/
long hi, lo, x;
+ /* Can't be initialized with 0, so use another value. */
+ if (*ctx == 0)
+ *ctx = 123459876;
hi = *ctx / 127773;
lo = *ctx % 127773;
x = 16807 * lo - 2836 * hi;
- if (x = 0)
+ if (x 0)
x += 0x7fff;
return ((*ctx = x) % ((u_long)RAND_MAX + 1));
#endif /* !USE_WEAK_SEEDING */
@@ -86,8 +89,10 @@
rand_r(unsigned int *ctx)
{
u_long val = (u_long) *ctx;
- *ctx = do_rand(val);
- return (int) *ctx;
+ int r = do_rand(val);
+
+ *ctx = (unsigned int) val;
+ return (r);
}
--- stdlib/random.c.old Sun Mar 24 23:42:48 2002
+++ stdlib/random.c Sun Feb 2 17:09:19 2003
@@ -236,10 +236,13 @@
*/
long hi, lo;
+ /* Can't be initialized with 0, so use another value. */
+ if (x == 0)
+ x = 123459876;
hi = x / 127773;
lo = x % 127773;
x = 16807 * lo - 2836 * hi;
- if (x = 0)
+ if (x 0)
x += 0x7fff;
return (x);
#endif /* !USE_WEAK_SEEDING */
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Final fix for 0 problem (was Re: rand() is broken)
So far, this is final variant for 0 problem fixing ready for committing. Any objections? --- stdlib/rand.c.old Sat Jan 4 20:39:19 2003 +++ stdlib/rand.c Sun Feb 2 17:34:34 2003 @@ -72,10 +72,13 @@ */ long hi, lo, x; + /* Can't be initialized with 0, so use another value. */ + if (*ctx == 0) + *ctx = 123459876; hi = *ctx / 127773; lo = *ctx % 127773; x = 16807 * lo - 2836 * hi; - if (x = 0) + if (x 0) x += 0x7fff; return ((*ctx = x) % ((u_long)RAND_MAX + 1)); #endif /* !USE_WEAK_SEEDING */ --- stdlib/random.c.old Sun Mar 24 23:42:48 2002 +++ stdlib/random.c Sun Feb 2 17:09:19 2003 @@ -236,10 +236,13 @@ */ long hi, lo; + /* Can't be initialized with 0, so use another value. */ + if (x == 0) + x = 123459876; hi = x / 127773; lo = x % 127773; x = 16807 * lo - 2836 * hi; - if (x = 0) + if (x 0) x += 0x7fff; return (x); #endif /* !USE_WEAK_SEEDING */ -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Sun, Feb 02, 2003 at 15:32:32 +, Mark Murray wrote: Jeroen C. van Gelderen writes: Wouldn't it be a good idea to change the name at the same time? Or should it be retained for compatibility reasons with other BSDs? Currently the name needlessly exposes implementation detail. Callers expect good, cheap, non-blocking randomness but don't give a hoot if that is actually provided trough use of RC4 or not. I see no reason why the implementation could be changed if the contract is maintained. Good point. We can re-implement random() internally with arc4rand(). Objections? We can't, simple because sequence must be repeated for the same seed across the calls. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote: Why not? Arc4 is a) deterministic and b) good for all bits. If you mean arc4random() function - not, because it use true randomness, if you mean RC4 algorithm, probably yes, but we should compare its distribution with our current variant and be sure that speed is acceptable. What form RC4 distribution have? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Sun, Feb 02, 2003 at 17:34:19 +, Mark Murray wrote: Andrey A. Chernov writes: Objections? We can't, simple because sequence must be repeated for the same seed across the calls. RC4 is repeatable. It seems we mean different things saying arc4random(), see my answer in the thread. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Sun, Feb 02, 2003 at 21:20:09 +0300, Andrey A. Chernov wrote: On Sun, Feb 02, 2003 at 17:30:48 +, Mark Murray wrote: Why not? Arc4 is a) deterministic and b) good for all bits. If you mean arc4random() function - not, because it use true randomness, if you mean RC4 algorithm, probably yes, but we should compare its distribution with our current variant and be sure that speed is acceptable. What form RC4 distribution have? BTW, if we ever think about replacing our current variant with such complex and unknown (at least to me) thing as RC4-based PseudoRNG, I simpatize more to Knuth variant mentioned by David Schultz: http://www-cs-faculty.stanford.edu/~knuth/programs/rng.c RC4 is good for hashing existen randomness, but is it good as PseudoRNG? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Sun, Feb 02, 2003 at 19:32:50 +0100, [EMAIL PROTECTED] wrote: Anyway, last time we discussed this, I think we stuck with the rand() we had because we feared that people were using it's repeatable well documented sequence of random numbers in regression testing. As documented, it must be repeatable across the calls for same seed, that is all. It not means repeatable accross platforms or across different OS versions. In fact it is already not repeatable across different OS'es, so regression is limited. Also, regression must not stop bugs fixing progress in anycase. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Sun, Feb 02, 2003 at 19:43:44 +0100, [EMAIL PROTECTED] wrote: Please surf the mail-archives to find the discussion, it contained a lot of good arguments from both sides, arguments which should be thought about before changing rand(). I remember well that we decide to allow it be changed in that discussion, moreover we already change it once. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Sun, Feb 02, 2003 at 19:47:12 +0100, [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Mark Murray wr ites: We have most of this, and RC4 can deliver. RC4's licence is fine. Call it ArCFour and there is no problem. The code is small, fast and repeatable, and meets conditions 1-4 above. There are some concerns about RC4's strength and predictability. Yes. That why I say we need to run some tests to compare RC4 distribution and other vital parameters with our current variant. The worst case will be if we replace good PRNG with bad. F.e. Knuth variant I already mention already proven as better than what we currently have, so don't have such problem as RC4-based PRNG probably have. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Sun, Feb 02, 2003 at 20:05:29 +, David Malone wrote: I presume it also produces reasonably uniform output for most seeds too. Yes. Modulo the requirement to burn a bit of output after a reseed. I guess the crypto guys would have junked it otherwise ;-) Notice that it will happens _each_ time for rand() due to rand_r() requirement 1) to output the same sequence as rand() and to 2) to store one word seed value each time. I.e. it will be reseed on each call. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Sun, Feb 02, 2003 at 12:39:50 -0800, Bakul Shah wrote: Note that it is rand() that is broken, not random() as can be seen by modifying Kris Kennaways' test so I don't see why Mark Murray was talking about changing it in the first place. About correlation bug: it is srand() which is broken, not rand(). It is common practice for this type of PRNGs to throw out N values after seeding to remove correlation and srand() not follow this. My first patch fix this. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Final fix for 0 problem (was Re: rand() is broken)
On Sun, Feb 02, 2003 at 13:12:55 -0800, Doug Barton wrote: If I had to guess, I'd say that you're eager to fix the mistake you made, and I suppose that's commendable. However, it's been broken for two years, it can wait another couple days for a more thorough fix. If you talk about 0 problem, this mistake is not mine, but inherited from BSD developers who made it in the first place in the kernel. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Final fix for 0 problem (was Re: rand() is broken)
On Sun, Feb 02, 2003 at 13:06:08 -0800, Kris Kennaway wrote: On Sun, Feb 02, 2003 at 06:10:49PM +0300, Andrey A. Chernov wrote: So far, this is final variant for 0 problem fixing ready for committing. Any objections? What tests have you run on this code to ensure it doesn't still have strange problems? Uhm, I don't understand you well here. Any code can have strange problems, nobody can be sure. Lets concentrate to this particular problem which I call 0 problem. 0 seed is illegal by algorithm desing and BSD developers try to made workaround, but their attempt was unsuccessful with result you describe. Now successfull attempt comes. It not add any new bugs, because value 0 simple mapped to another value (which could be any, but I choose to not touch lower ones), which make generator non-stick at 0 again. -- Andrey A. Chernov http://ache.pp.ru/ msg51597/pgp0.pgp Description: PGP signature
Re: rand() is broken
On Sun, Feb 02, 2003 at 21:23:43 +, Mark Murray wrote: That was random(9). KERNEL random(). KERNEL random() can be easily implemented (better - replaced) with arc4random(), there is no objections. But... 1) Implementing random(3) with RC4 is not needed, its algorithm is already equal or better. 2) Implementing rand(3) with RC4 can be possible only if seed (i.e. state) can be stored in single word (due to rand_r()) restrictions. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Final fix for 0 problem (was Re: rand() is broken)
On Sun, Feb 02, 2003 at 14:21:02 -0800, Kris Kennaway wrote: If I understand correctly, this still doesn't solve the problem, because any PRNG sequence that hits the magic value will still get stuck there forever. It was true for the first patch I post which just move problem to another place (this is commonly spreaded method for this PRNG). It is false for the last patch I post which not stuck with any given seed. -- Andrey A. Chernov http://ache.pp.ru/ msg51605/pgp0.pgp Description: PGP signature
Re: rand() is broken
On Sun, Feb 02, 2003 at 22:19:33 +, Mark Murray wrote: 1) Implementing random(3) with RC4 is not needed, its algorithm is already equal or better. Rubbish. :-) RC4's internal state is 256 bytes. In theory, its cycle-of-repetition is 2^(8*256) bits. This is comparable with random() TYPE4 which internal state is 252 bytes. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rand() is broken
On Sun, Feb 02, 2003 at 22:35:54 +, Mark Murray wrote: I stand (somewhat) corrected. The random() code is _nasty_ complexity-wise. Its not obvious how it works. RC4 is 10-20 lines and clean with no magic numbers. That's why randomness tests + mathematician to interpretate their results are needed to compare what we have now in random(3) with RC4. Easy and understandable code not always mean better results. We can't switch algorithms blindly, i.e. when their comparative quality remains unknown. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM disklabel
On Sat, Jan 25, 2003 at 10:17:39 +0100, [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Michael Reifenberger writes: On Fri, 24 Jan 2003 [EMAIL PROTECTED] wrote: ... Don't use the '-r' option, it gets confused because geom::BSD does not lie to it. Yes, that seems to work... Time to say good bye for '-r' ? Well, we still need it for writing the first disklabel on an otherwise empty disk, but I think it could be implied in that case. -B implies -r too. Currenty this check prevents my bootblocks from writting. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAWS ack-on-ack loop avoided
On Mon, Dec 23, 2002 at 10:55:05 -0800, Matthew Dillon wrote: That's very odd. I see them on my development box too which is just talking FreeBSD-FreeBSD. We should not be seeing them at all. I found that big source of them is Windows machines when Selective acknowledgement is turned on on their side. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAWS ack-on-ack loop avoided
On Mon, Dec 23, 2002 at 10:55:05 -0800, Matthew Dillon wrote: That's very odd. I see them on my development box too which is just talking FreeBSD-FreeBSD. We should not be seeing them at all. I got about 200 of them per 6 hours. Nothing unusual, small webserver + SMTP. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
GEOM prevents bootblocks writing
Now I can't update my bootblocks to new ones using 'disklabel -B da0s1', checklabel() disklabel function return error preventing actual write with following diagnostic: partition b: partition extends past end of unit partition c: partition extends past end of unit Warning, partition c doesn't start at 0! Warning, An incorrect partition c may cause problems for standard system utilities Warning, partition d: size 0, but offset 32 Warning, partition e: size 0, but offset 32 Warning, partition f: size 0, but offset 32 Warning, partition g: size 0, but offset 32 Warning, partition h: size 0, but offset 32 In fact, this is exact the same diagnostic as from 'disklabel -r da0s1': # /dev/da0s1c: type: SCSI disk: da0s1 label: flags: bytes/sector: 512 sectors/track: 32 tracks/cylinder: 64 sectors/cylinder: 2048 cylinders: 17500 sectors/unit: 35842016 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 34611200 324.2BSD 2048 1638464 # (Cyl.0*- 16900) b: 1230816 34611232 swap# (Cyl. 16900*- 17500*) c: 35842016 32unused0 0 # (Cyl.0*- 17500*) partition b: partition extends past end of unit partition c: partition extends past end of unit Warning, partition c doesn't start at 0! Warning, An incorrect partition c may cause problems for standard system utilities Warning, partition d: size 0, but offset 32 Warning, partition e: size 0, but offset 32 Warning, partition f: size 0, but offset 32 Warning, partition g: size 0, but offset 32 Warning, partition h: size 0, but offset 32 For comparison see just 'disklabel da0s1' output which indicate no errors and no mysterious offset 32 in the data: # /dev/da0s1c: type: SCSI disk: da0s1 label: flags: bytes/sector: 512 sectors/track: 32 tracks/cylinder: 64 sectors/cylinder: 2048 cylinders: 17500 sectors/unit: 35842016 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 3461120004.2BSD 2048 1638464 # (Cyl.0 - 16899) b: 1230816 34611200 swap# (Cyl. 16900 - 17500*) c: 358420160unused0 0 # (Cyl.0 - 17500*) Please fix this GEOM bug, to allow to update bootblocks at least. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
New AWK bug with collating
Since both operands are unsigned, result can't be negative, but supposed to be. Here is the fix: --- b.c.bak Fri Dec 13 14:54:12 2002 +++ b.c Fri Dec 13 15:20:15 2002 @@ -292,7 +292,7 @@ s[0][0] = a; s[1][0] = b; if ((r = strcoll(s[0], s[1])) == 0) - r = (uschar)a - (uschar)b; + r = (int)((uschar)a) - (int)((uschar)b); return r; } -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: New AWK bug with collating
On Fri, Dec 13, 2002 at 14:32:40 +0200, Ruslan Ermilov wrote:
Pardon my ignorance here, but the following fragment
returns -1, doesn't it?
#include stdio.h
void
main(void)
{
int i;
i = (unsigned char)1 - (unsigned char)2;
printf(%d\n, i);
}
It very depends on compiler, i.e. does it implements value preseving or
unsigned preserving for 'char' type conversions. Or ANSI C vs. common C
mode. Better be safe for both.
Read 6.10.1.1 section here:
http://wwwrsphysse.anu.edu.au/doc/DUhelp/AQTLTBTE/DOCU_067.HTM
--
Andrey A. Chernov
http://ache.pp.ru/
msg48645/pgp0.pgp
Description: PGP signature
Re: New AWK bug with collating
On Fri, Dec 13, 2002 at 17:09:42 +0200, Ruslan Ermilov wrote:
:
: * Integer types `unsigned short' and `unsigned char' promote to
: `unsigned int'.
With -traditional, the code I quoted still produces -1.
Probably because of machine-specific overflow handling or printf overflow.
Use this safe example instead (with -traditional):
main()
{
long long l;
unsigned char a = 1;
unsigned char b = 2;
l = a - b;
printf(%04x %04x\n, (int)((l 32) 0x), (int)(l 0x));
l = -1;
printf(%04x %04x\n, (int)((l 32) 0x), (int)(l 0x));
}
In any case, this section doesn't apply to this case because
no conversion described in section 6.10 is ever done here,
since both operands are of the same type, unsigned char.
No, any char type converted to int (or to unsigned int with -traditional)
prior to any operation with it.
--
Andrey A. Chernov
http://ache.pp.ru/
msg48647/pgp0.pgp
Description: PGP signature
Re: awk(1) is locale unaware (was: Re: buildworld breakage during make depend at usr.bin/kdump)
On Wed, Nov 20, 2002 at 14:54:12 +0200, Ruslan Ermilov wrote: Index: b.c === RCS file: /home/ncvs/src/contrib/one-true-awk/b.c,v retrieving revision 1.1.1.2 diff -u -p -r1.1.1.2 b.c David, this variant is nice enough. Please, commit. -- Andrey A. Chernov http://ache.pp.ru/ msg48017/pgp0.pgp Description: PGP signature
Re: awk(1) is locale unaware (was: Re: buildworld breakage during make depend at usr.bin/kdump)
On Tue, Nov 19, 2002 at 14:52:02 +0200, Ruslan Ermilov wrote: It seems that this patch has never been committed. This is a critical bug that should be fixed before 5.0-RELEASE is out. I agree. There is no locale yet and I never see that patch. -- Andrey A. Chernov http://ache.pp.ru/ msg46960/pgp0.pgp Description: PGP signature
Re: awk(1) is locale unaware (was: Re: buildworld breakage during make depend at usr.bin/kdump)
On Wed, Nov 20, 2002 at 14:27:53 +1100, Tim Robbins wrote: On Wed, Nov 20, 2002 at 04:38:38AM +0300, Andrey A. Chernov wrote: On Tue, Nov 19, 2002 at 14:52:02 +0200, Ruslan Ermilov wrote: It seems that this patch has never been committed. This is a critical bug that should be fixed before 5.0-RELEASE is out. I agree. There is no locale yet and I never see that patch. This patch seems to work, I used the logic from regcomp.c in libc. Long lines make it ugly, but it was like that when I got here ;) Looks good, but it is not enough. Please look in b.c to see how weird character classes, i.e. [:alpha:] are implemented there, this stuff must be rewritted too. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sshd: double Last login: bugfix spammed again
On Tue, Nov 12, 2002 at 12:37:13 +0100, Dag-Erling Smorgrav wrote: Andrey A. Chernov [EMAIL PROTECTED] writes: Old bugfix for double Last login: was spammed in 3rd time, causing following printout: I can't reproduce this here. Look at session.c, one Last login comes from print_pam_messages(); and second one comes just few lines below under if (options.print_lastlog ... condition. Now look at the times: Last login: Tue Nov 12 15:44:54 from xxx.yyy.zzz Last login: Tue Nov 12 15:38:01 2002 xxx.yyy.zzz The first time from print_pam_messages() is wrong in anycase, it is JUST login time, not LAST one! It clearly indicates that something wrong with print_pam_messages(). We have two ways of fix: 1) Just disable print_pam_messages() ignoring what is wrong there. 2) Fix print_pam_messages() to print right time and remove second print from sshd. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sshd: double Last login: bugfix spammed again
On Tue, Nov 12, 2002 at 14:26:58 +0100, Dag-Erling Smorgrav wrote:
pam.d is not relevant, sshd_config is.
I sent it to you privately.
des@des ~% ssh localhost
Last login: Tue Nov 12 14:25:39 2002 from :0.0
It is Last login with right time comes from sshd itself (second in my
case). It means that print_pam_messages() remains silent in your case but
be verbose form my case for unknown reason. Is there some way to debug
print_pam_messages() deeply I can turn on?
BTW, double-testes options.print_lastlog looks suspiciuos. For what
print_pam_messages() used here? It is unclear to me.
#ifdef USE_PAM
if (options.print_lastlog !is_pam_password_change_required())
print_pam_messages();
#endif /* USE_PAM */
...
#ifndef NO_SSH_LASTLOG
if (options.print_lastlog s-last_login_time != 0) {
...
printf(Last login: %s from %s\r\n, time_string,
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: sshd: double Last login: bugfix spammed again
On Tue, Nov 12, 2002 at 14:47:51 +0100, Dag-Erling Smorgrav wrote: Andrey A. Chernov [EMAIL PROTECTED] writes: BTW, double-testes options.print_lastlog looks suspiciuos. For what print_pam_messages() used here? It is unclear to me. I think the idea is that we should define NO_SSH_LASTLOG in config.h. It physically eliminates Last loging comes from sshd, but not fix wrong _time_ printed by print_pam_messages() in my case (first prompt), as I already write, there is JUST time, not LAST time. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sshd: double Last login: bugfix spammed again
On Tue, Nov 12, 2002 at 15:11:04 +0100, Dag-Erling Smorgrav wrote: Dag-Erling Smorgrav [EMAIL PROTECTED] writes: I think the idea is that we should define NO_SSH_LASTLOG in config.h. Actually, I think the problem is that DISABLE_LASTLOG should imply NO_SSH_LASTLOG but doesn't. There was USE_LASTLOG on the way, which is currently on and checked before DISABLE_LASTLOG, so DISABLE_LASTLOG does nothing. See loginrec.c -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sshd: double Last login: bugfix spammed again
On Tue, Nov 12, 2002 at 15:28:41 +0100, Dag-Erling Smorgrav wrote: Andrey A. Chernov [EMAIL PROTECTED] writes: There was USE_LASTLOG on the way, which is currently on and checked before DISABLE_LASTLOG, so DISABLE_LASTLOG does nothing. See loginrec.c No, USE_LASTLOG is not defined if DISABLE_LASTLOG is defined. See defines.h. Yes. Sorry, false alarm. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sshd: double Last login: bugfix spammed again
Old bugfix for double Last login: was spammed in 3rd time, causing following printout: zzz@xxx's password: Last login: Wed Nov 6 17:12:40 from Last login: Wed Nov 6 17:10:08 2002 from Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 ... -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM gets whole disk geometry for slice (instead of slice geometry)
On Sun, Oct 27, 2002 at 03:37:47 +0300, Andrey A. Chernov wrote: I have disk shared between FreeBSD and M$ Win, two slices, and got incorrect disklabel with GEOM kernel. Namely cylinders and sectors/unit fields are from _whole_ disk, not from just requested slice. Just found more brokeness: 'disklabel -r ad0s1' and 'disklabel ad0s1' shows different results, for -r case 63 added to offset field of all a, b and c partitions. BTW, is there is a way to turn GEOM off, something like NOGEOM kernel option? I want my old good disklabel back. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
GEOM gets whole disk geometry for slice (instead of slice geometry)
I have disk shared between FreeBSD and M$ Win, two slices, and got incorrect disklabel with GEOM kernel. Namely cylinders and sectors/unit fields are from _whole_ disk, not from just requested slice. It invalidates previously correct 'c' BSD partition too, 'disklabel' outputs several warnings about it. I am not familiar with GEOM. In which place it senses cylinders and secs/unit? Does anyone saw the same problem too? Specific info attached below. Look at the wrong fields in disklabel. They even can't be corrected using 'disklabel -e'. -- fdisk: can't get disk parameters on /dev/ad0; supplying dummy ones *** Working on device /dev/ad0 *** parameters extracted from in-core disklabel are: cylinders=89355 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=89355 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 12514572 (6110 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 778/ head 254/ sector 63 The data for partition 2 is: sysid 7 (0x07),(OS/2 HPFS, NTFS, QNX-2 (16 bit) or Advanced UNIX) start 12514698, size 77545692 (37864 Meg), flag 0 beg: cyl 779/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED -- # /dev/ad0s1c: type: ESDI disk: ad0s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 5606 ^^^ must be 778 (or 779?) sectors/unit: 90069840 ^^^ must be 12514572 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 11900172 6144004.2BSD 2048 1638464 # (Cyl. 38*- 778*) b: 6144000 swap# (Cyl.0 - 38*) c: 125145720unused0 0 # (Cyl.0 - 778*) -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Forgotten locale dirs in etc/mtree/BSD.usr.dist
On Wed, Oct 23, 2002 at 19:44:33 +0300, Adrian Penisoara wrote: Hi, Someone (ache it seems) forgot to add the sr_YU.ISO8859-[25] directories in /usr/share/locale to the BSD.usr.dist mtree file. Please check your BSD.usr.dist is not obsoleted. They are there from v1.266 -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Forgotten locale dirs in etc/mtree/BSD.usr.dist
On Wed, Oct 23, 2002 at 19:58:00 +0300, Adrian Penisoara wrote: There is something strange going on here: these directories do appear in etc/mtree/BSD.usr.dist, but somehow they haven't been created neither by 'mergemaster -p', nor at the beginning of make installworld. I had to re-run make installworld about three times and make two directiories (sr_YU.ISO8859-x) before it could complete without complaining about the missing directories. Could someone please clarify this ? make hierarchy should make all needed directories, but I don't know any deeper details, i.e. about make hierarchy and 'mergemaster -p' or 'make installworld' interaction. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATTN: people who were getting CVSup crashes under -current
On Wed, Oct 09, 2002 at 20:37:39 -0700, John Polstra wrote: understand why those changes mattered. My theory is that the changes would matter to the old pm3 port, but not to the newer ezm3 port. If you experienced the crashes, please check which Modula-3 version you have using pkg_info and let me know. According to my test, signal 6 crashes happened with _both_ old pm3 port and new ezpm port (first thing I try to do seeing them - upgrade to latest cvsup, with ezpm, and see exact the same crashes as with old pm3 cvsup). -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Reason: releng4 comp. hack, machdep.c 1.539 (was: cvsupd death (signal 6))
On Thu, Oct 03, 2002 at 08:11:10 +0400, Andrey A. Chernov wrote: On Wed, Oct 02, 2002 at 20:51:40 -0700, Julian Elischer wrote: Please back it out or do it properly! this IS the backout.. it's now how it was before, including in 4.x I mean - back out this backout - it damage 5.0 FP binaries. Note that cvsup(d) _not_ use threads (-lc_r). It means that newly committed compatibility hack just breaks floating point subsystem alone. I suppose FP exceptions. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
