Mersenne Digest Monday, April 17 2000 Volume 01 : Number 719 ---------------------------------------------------------------------- Date: Sat, 15 Apr 2000 14:51:10 +0200 (CEST) From: Henrik Olsen <[EMAIL PROTECTED]> Subject: Re: Mersenne: V20 beta #3 On Sat, 15 Apr 2000, Brian J. Beesley wrote: > On 15 Apr 00, at 4:22, Henrik Olsen wrote: > > > I just tried downloading 20.3, both mprime and sprime, as well as tried > > with mprime 19.0.2 . None of them where able to detect the network as > > being available on a machine running Mandrake Linux, kernel version > > 2.2.14-15mdksecure, probably due to /proc/net not being readable by > > non-root on such a system, which is a bit of a bummer, as I as I don't > > want to have to run it as root. :( > > > > Does a solution exist for running mprime on such a system or will I have > > to use this one as well for SNFS sieving instead of GIMPS? > > Could I suggest three things to try: > > 1) Install mprime with suid privelege. This should enable mprime to > read /proc/net as though it were running under root even though it's > actually running under an unpriveleged user. With all the respect due to George, I haven't seen anything to indicate that mprime was written with suid in mind, with in any security concient person would raise big red flags when contemplating this solution. Actually, if I setuid it, I might as well run it as root, which is what I wanted to avoid in the first place. > 2) Get out your hacker's hat and fix the problem in the source code. > I'd guess that all you need to change is the code which creates the > /proc pseudofilesystem at boot time. As you've probably found, you > don't seem to be able to change the permissions on "files" in the > /proc tree on a running system - even if you _are_ root. There isn't one piece of code generating the /proc fs, it's done dynamically by linking in inodes with relevant callback functions for the operations on them, one call passing one struct per inode, so it can happen everywhere and tracking down the call/struct for a specific inode is a real pain. > 3) Is Mandrake really linux, or just a linux clone? I think the > latter. If I'm right, then perhaps switching to a genuine linux (Red > Hat, or SuSe) might be a sensible thing to do. Though the official > Red Hat distribution retail package is expensive, you can get just > the CD for about $2, or download the distribution FoC (not > reccomended unless you have fast internet access!) Mandrake is really Linux (whatever that means), it's essentially RedHat with the security holes fixed, and all rpm's compiled for the Pentium. (as for my connection it's only 2Mb/s) > Regards > Brian Beesley > - -- Henrik Olsen, Dawn Solutions I/S URL=http://www.iaeste.dk/~henrik/ Should we throw another human wave of structural engineers at stabilizing the Leaning Tower of Pisa, or should we just let the damn thing fall over and build a tower that doesn't suck? Neal Stephenson about cruft, In The Beginning... Was The Command Line _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 15 Apr 2000 11:41:52 -0000 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Re: Mersenne: V20 beta #3 On 15 Apr 00, at 4:22, Henrik Olsen wrote: > I just tried downloading 20.3, both mprime and sprime, as well as tried > with mprime 19.0.2 . None of them where able to detect the network as > being available on a machine running Mandrake Linux, kernel version > 2.2.14-15mdksecure, probably due to /proc/net not being readable by > non-root on such a system, which is a bit of a bummer, as I as I don't > want to have to run it as root. :( > > Does a solution exist for running mprime on such a system or will I have > to use this one as well for SNFS sieving instead of GIMPS? Could I suggest three things to try: 1) Install mprime with suid privelege. This should enable mprime to read /proc/net as though it were running under root even though it's actually running under an unpriveleged user. 2) Get out your hacker's hat and fix the problem in the source code. I'd guess that all you need to change is the code which creates the /proc pseudofilesystem at boot time. As you've probably found, you don't seem to be able to change the permissions on "files" in the /proc tree on a running system - even if you _are_ root. 3) Is Mandrake really linux, or just a linux clone? I think the latter. If I'm right, then perhaps switching to a genuine linux (Red Hat, or SuSe) might be a sensible thing to do. Though the official Red Hat distribution retail package is expensive, you can get just the CD for about $2, or download the distribution FoC (not reccomended unless you have fast internet access!) Regards Brian Beesley _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 15 Apr 2000 10:56:27 -0700 From: Will Edgington <[EMAIL PROTECTED]> Subject: Re: Mersenne: V20 beta #3 Brian J. Beesley writes: On 15 Apr 00, at 4:22, Henrik Olsen wrote: > I just tried downloading 20.3, both mprime and sprime, as well as tried > with mprime 19.0.2 . None of them where able to detect the network as > being available on a machine running Mandrake Linux, kernel version > 2.2.14-15mdksecure, probably due to /proc/net not being readable by > non-root on such a system, which is a bit of a bummer, as I as I don't > want to have to run it as root. :( 1) Install mprime with suid privelege. This should enable mprime to read /proc/net as though it were running under root even though it's actually running under an unpriveleged user. As Henrik later points out, this is _not_ a good idea. I'm sure we all trust George - or we wouldn't be running his binaries - but he is not a Linux security expert, and even I wouldn't do this and I've not only read the source code, I've worked with UNIX security since 1980 and I see nothing wrong with the code in the security sense. Besides, there are other solutions. Which is, by the way, the first "test" that setuid should not be used: it should only be used as a last resort, after just about everything else has been tried. 2) Get out your hacker's hat and fix the problem in the source code. The first time I read this, I thought you meant the Prime95 source code. That's certainly where I'd look first. I'd guess that all you need to change is the code which creates the /proc pseudofilesystem at boot time. As you've probably found, you don't seem to be able to change the permissions on "files" in the /proc tree on a running system - even if you _are_ root. I would guess that there are good reasons that the authors wrote it this way. In any case, it's much easier to fix this in Prime95. 3) Is Mandrake really linux, or just a linux clone? I think the latter. If I'm right, then perhaps switching to a genuine linux (Red Hat, or SuSe) might be a sensible thing to do. Though the official Red Hat distribution retail package is expensive, you can get just the CD for about $2, or download the distribution FoC (not reccomended unless you have fast internet access!) This also would be a lot of work and may not even be an option for many people. So: 4. Look at the Prime95 source code (well, for version 19.1 anyway, which is the one I've got unpacked on my system presently) near line 761 of linux/primenet.c, where there's an fopen("/proc/net/route", "r") inside an #ifdef __linux__. Look lower down, after the #endif, and note that __FreeBSD__ doesn't have a similar check; it simply always returns TRUE. Looks to me like it would be very simple to add a check for the fopen() failing due to permissions or whatever under Linux and return TRUE (i.e., that the system is connected to the network), perhaps based on a new flag in one of the .ini files. In fact, always returning TRUE from that function is not that big a deal; if TRUE is returned when FALSE is correct, all that will happen is that the later call to connect() - to actually try to connect to Primenet - will fail and Prime95 will complain to the log file and screen. I see such complaints all the time on my Win98 machines and my new Debian Linux machine (which is running the unmodified RedHat Linux mprime binary just fine, as far as I can tell). Will _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 15 Apr 2000 19:42:49 +0200 From: Martijn Kruithof <[EMAIL PROTECTED]> Subject: Re: Mersenne: V20 beta #3 Henrik Olsen wrote: > > On Sat, 15 Apr 2000, Brian J. Beesley wrote: > > On 15 Apr 00, at 4:22, Henrik Olsen wrote: > > > > > I just tried downloading 20.3, both mprime and sprime, as well as tried > > > with mprime 19.0.2 . None of them where able to detect the network as > > > being available on a machine running Mandrake Linux, kernel version > > > 2.2.14-15mdksecure, probably due to /proc/net not being readable by > > > non-root on such a system, which is a bit of a bummer, as I as I don't > > > want to have to run it as root. :( > > > > > > Does a solution exist for running mprime on such a system or will I have > > > to use this one as well for SNFS sieving instead of GIMPS? > > Hello, I actually was pretty annoyed by the mkdsec kernel. With the security patch applied I actually compiled a new kernel in which /proc is readable by everyone (More programs suffered from /proc not being readable). This even is the default for the security patch! (Most important is the buffer overflow protection) Kind Regards, Martijn - -- http://jkf.penguinpowered.com Linux distributies voor maar Fl 10 per CD, inclusief verzendkosten! _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 15 Apr 2000 15:42:43 -0400 From: George Woltman <[EMAIL PROTECTED]> Subject: Re: Mersenne: V20 beta #3 Hi, At 10:56 AM 4/15/00 -0700, Will Edgington wrote: >near line >761 of linux/primenet.c, where there's an fopen("/proc/net/route", >"r") inside an #ifdef __linux__. Look lower down, after the #endif, >and note that __FreeBSD__ doesn't have a similar check; it simply >always returns TRUE. Looks to me like it would be very simple to add >a check for the fopen() failing due to permissions or whatever under >Linux and return TRUE (i.e., that the system is connected to the >network), perhaps based on a new flag in one of the .ini files. This is a good fix. The next v20 release will return TRUE if /proc/net/route is not readable. You can keep the current behavior by setting "RouteRequired=1" in primenet.ini. A question to all you linux users with modems: I assume that the /proc/net/route file exists when you are not connected. Let me know if this is not the case (I'll need to change the default setting of RouteRequired above). Regards, George _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sat, 15 Apr 2000 22:27:50 +0200 From: Martijn Kruithof <[EMAIL PROTECTED]> Subject: Re: Mersenne: V20 beta #3 George Woltman wrote: > > Hi, > > At 10:56 AM 4/15/00 -0700, Will Edgington wrote: > >near line > >761 of linux/primenet.c, where there's an fopen("/proc/net/route", > >"r") inside an #ifdef __linux__. Look lower down, after the #endif, > >and note that __FreeBSD__ doesn't have a similar check; it simply > >always returns TRUE. Looks to me like it would be very simple to add > >a check for the fopen() failing due to permissions or whatever under > >Linux and return TRUE (i.e., that the system is connected to the > >network), perhaps based on a new flag in one of the .ini files. > > This is a good fix. The next v20 release will return TRUE if /proc/net/route > is not readable. You can keep the current behavior by setting > "RouteRequired=1" in primenet.ini. > > A question to all you linux users with modems: I assume that the > /proc/net/route file exists when you are not connected. Let me know > if this is not the case (I'll need to change the default setting of > RouteRequired above). > > Regards, > George > >From memory, it should still exist, as the loopback device will always be present, and thus there will always be a loopback route. Kind Regards, Martijn - -- http://jkf.penguinpowered.com Linux distributies voor maar Fl 10 per CD, inclusief verzendkosten! _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 16 Apr 2000 00:06:10 +0200 From: Harald Tveit Alvestrand <[EMAIL PROTECTED]> Subject: Re: Mersenne: V20 beta #3 At 14:51 15.04.2000 +0200, Henrik Olsen wrote: >On Sat, 15 Apr 2000, Brian J. Beesley wrote: > > On 15 Apr 00, at 4:22, Henrik Olsen wrote: > > > > > I just tried downloading 20.3, both mprime and sprime, as well as tried > > > with mprime 19.0.2 . None of them where able to detect the network as > > > being available on a machine running Mandrake Linux, kernel version > > > 2.2.14-15mdksecure, probably due to /proc/net not being readable by > > > non-root on such a system, which is a bit of a bummer, as I as I don't > > > want to have to run it as root. :( > > > > > > Does a solution exist for running mprime on such a system or will I have > > > to use this one as well for SNFS sieving instead of GIMPS? Check /etc/fstab. There's a line there that says something like none /proc proc something 0 0 If you change "something" (whatever that is) to "defaults", and umount and mount /proc, everyone can probably read it. No idea why Mandrake would choose not to make it world readable.... Harald - -- Harald Tveit Alvestrand, EDB Maxware, Norway [EMAIL PROTECTED] _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 16 Apr 2000 00:35:28 +0200 (CEST) From: Henrik Olsen <[EMAIL PROTECTED]> Subject: Re: Mersenne: V20 beta #3 On Sun, 16 Apr 2000, Harald Tveit Alvestrand wrote: > At 14:51 15.04.2000 +0200, Henrik Olsen wrote: > >On Sat, 15 Apr 2000, Brian J. Beesley wrote: > > > On 15 Apr 00, at 4:22, Henrik Olsen wrote: > > > > > > > I just tried downloading 20.3, both mprime and sprime, as well as tried > > > > with mprime 19.0.2 . None of them where able to detect the network as > > > > being available on a machine running Mandrake Linux, kernel version > > > > 2.2.14-15mdksecure, probably due to /proc/net not being readable by > > > > non-root on such a system, which is a bit of a bummer, as I as I don't > > > > want to have to run it as root. :( > > > > > > > > Does a solution exist for running mprime on such a system or will I have > > > > to use this one as well for SNFS sieving instead of GIMPS? > > Check /etc/fstab. > There's a line there that says something like > > none /proc proc something 0 0 > > If you change "something" (whatever that is) to "defaults", and umount and > mount /proc, everyone can probably read it. It's already none /proc proc defaults 0 0 in /etc/fstab, the 550 permissions for /proc/net isn't due to a mount option, but looks like it's modified in the source. > No idea why Mandrake would choose not to make it world readable.... It's essentially a paranoid version of RedHat, which is actually a Good Thing (tm), as RH has more holes than a sieve out of the box. > > Harald - -- Henrik Olsen, Dawn Solutions I/S URL=http://www.iaeste.dk/~henrik/ ZOOLOGY, n. The science and history of the animal kingdom, including its king, the House Fly (Musca maledicta). The Devil's Dictionary, Ambrose Bierce. _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 16 Apr 2000 00:36:19 +0200 (CEST) From: Henrik Olsen <[EMAIL PROTECTED]> Subject: Re: Mersenne: V20 beta #3 On Sat, 15 Apr 2000, George Woltman wrote: > Hi, > > At 10:56 AM 4/15/00 -0700, Will Edgington wrote: > >near line > >761 of linux/primenet.c, where there's an fopen("/proc/net/route", > >"r") inside an #ifdef __linux__. Look lower down, after the #endif, > >and note that __FreeBSD__ doesn't have a similar check; it simply > >always returns TRUE. Looks to me like it would be very simple to add > >a check for the fopen() failing due to permissions or whatever under > >Linux and return TRUE (i.e., that the system is connected to the > >network), perhaps based on a new flag in one of the .ini files. > > This is a good fix. The next v20 release will return TRUE if /proc/net/route > is not readable. You can keep the current behavior by setting > "RouteRequired=1" in primenet.ini. > > A question to all you linux users with modems: I assume that the > /proc/net/route file exists when you are not connected. Let me know > if this is not the case (I'll need to change the default setting of > RouteRequired above). /proc/net/route exists as long as the kernel is compiled with networking capabilities, it's the content that varies with the configured devices, ie. its presence alone is not a good indication whether there's currently a dialled up connection. > > Regards, > George - -- Henrik Olsen, Dawn Solutions I/S URL=http://www.iaeste.dk/~henrik/ ZOOLOGY, n. The science and history of the animal kingdom, including its king, the House Fly (Musca maledicta). The Devil's Dictionary, Ambrose Bierce. _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 16 Apr 2000 08:01:54 +0200 From: Martijn Kruithof <[EMAIL PROTECTED]> Subject: Re: Mersenne: V20 beta #3 Henrik Olsen wrote: > > On Sun, 16 Apr 2000, Harald Tveit Alvestrand wrote: > > At 14:51 15.04.2000 +0200, Henrik Olsen wrote: > > >On Sat, 15 Apr 2000, Brian J. Beesley wrote: > > > > On 15 Apr 00, at 4:22, Henrik Olsen wrote: > > > > > > > > > I just tried downloading 20.3, both mprime and sprime, as well as tried > > > > > with mprime 19.0.2 . None of them where able to detect the network as > > > > > being available on a machine running Mandrake Linux, kernel version > > > > > 2.2.14-15mdksecure, probably due to /proc/net not being readable by > > > > > non-root on such a system, which is a bit of a bummer, as I as I don't > > > > > want to have to run it as root. :( > > > > > > > > > > Does a solution exist for running mprime on such a system or will I have > > > > > to use this one as well for SNFS sieving instead of GIMPS? > > > > Check /etc/fstab. > > There's a line there that says something like > > > > none /proc proc something 0 0 > > > > If you change "something" (whatever that is) to "defaults", and umount and > > mount /proc, everyone can probably read it. > It's already > none /proc proc defaults 0 0 > in /etc/fstab, the 550 permissions for /proc/net isn't due to a mount > option, but looks like it's modified in the source. > > > No idea why Mandrake would choose not to make it world readable.... > It's essentially a paranoid version of RedHat, which is actually a Good > Thing (tm), as RH has more holes than a sieve out of the box. > > > > > Harald > Hello, It can even be done easier, mount /proc with the gid=(group id) and make mersenne member of this group >From the docs wich comes with the security patches: Restricted /proc - ------------------ ... This option restricts the permissions on /proc so that non-root users can see their own processes only, and nothing about active network connections, unless they're in a special group. This group's id is specified via the gid= mount option, and is 0 by default. (Note: if you're using identd, you will need to edit the inetd.conf line to run identd as this special group.) Also, this disables dmesg(8) for the users. You might want to use this on an ISP shell server where privacy is an issue. .... As said before the security patch normally does not enable a secured proc filesystem, the mandrake mdksec kernel does. The mdksecure kernel has kernel moodule versions set, which makes it possible to insert a module which is compiled elsewhere, this is clearly less secure. Kind regards, martijn - -- http://jkf.penguinpowered.com Linux distributies voor maar Fl 10 per CD, inclusief verzendkosten! _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 16 Apr 2000 17:24:52 +0200 (CEST) From: Henrik Olsen <[EMAIL PROTECTED]> Subject: Re: Mersenne: V20 beta #3 On Sun, 16 Apr 2000, Martijn Kruithof wrote: > Henrik Olsen wrote: > > On Sun, 16 Apr 2000, Harald Tveit Alvestrand wrote: > > > At 14:51 15.04.2000 +0200, Henrik Olsen wrote: > > > >On Sat, 15 Apr 2000, Brian J. Beesley wrote: > > > > > On 15 Apr 00, at 4:22, Henrik Olsen wrote: > > > > > > > > > > > I just tried downloading 20.3, both mprime and sprime, as well as tried > > > > > > with mprime 19.0.2 . None of them where able to detect the network as > > > > > > being available on a machine running Mandrake Linux, kernel version > > > > > > 2.2.14-15mdksecure, probably due to /proc/net not being readable by > > > > > > non-root on such a system, which is a bit of a bummer, as I as I don't > > > > > > want to have to run it as root. :( > > > > > > > > > > > > Does a solution exist for running mprime on such a system or will I have > > > > > > to use this one as well for SNFS sieving instead of GIMPS? > Hello, > > It can even be done easier, mount /proc with the gid=(group id) and make > mersenne > member of this group Thanks, this solved the problem for me, now I just have to wait for the server to get up again so it can grab someting to work on. - -- Henrik Olsen, Dawn Solutions I/S URL=http://www.iaeste.dk/~henrik/ Should we throw another human wave of structural engineers at stabilizing the Leaning Tower of Pisa, or should we just let the damn thing fall over and build a tower that doesn't suck? Neal Stephenson about cruft, In The Beginning... Was The Command Line _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 17 Apr 2000 02:12:35 +0100 From: "Siegmar Szlavik" <[EMAIL PROTECTED]> Subject: Re: Mersenne: GIMPS and other distributed projects On Fri, 14 Apr 2000 07:56:33 -0000, Brian J. Beesley wrote: >On 13 Apr 00, at 22:47, Francois LeBlanc wrote: > >> On another note, I want to convince my University faculty (Science) to >> run Prime 95 in the computer labs. How can I prove that the client >> will not affect the performance of the computers; even the old Pentium >> 60ish. I'm not sure if I believe that myself. > >Don't forget you can also use the "time of day" stuff (in prime.ini) >to make Prime95 get completely off the system at times when the >system is required to be 100% dedicated to user applications. > This is a good option and I use it very often, especially on slower machines. What I am missing is some 'screensaver-functionality' (i.e. prime95 stops when there is some user interactivity). I would find it very usefull if this can be added to furture versions of prime95 (or even better to the nt service) George? >Basically what I'm saying is that, if you can run what the users want >on a system (no matter how slow it is or how ungenerous its memory), >running Prime95 in the background as well should make no perceivable >difference to the system so far as users are concerned. For instance, > yes, it "should", but I noticed, that on some machines prime95/ntprime gets out of control after a few days and the system is no longer useable. The program seems to get all the cpu time, allthough it runs with the default (lowest) priority. Sometimes it helps to reboot the machine once or twice a day, but just only sometimes :( Any idea, what could be the reason? happy hunting Siegmar _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 16 Apr 2000 23:33:49 -0400 From: George Woltman <[EMAIL PROTECTED]> Subject: Mersenne: Facelift Hi all, It is well past time to give the GIMPS web pages a facelift. HTML, banners, and graphics are not my area of expertise. I made a first draft of a new look and feel - let me know what you think (either to the list or by private e-mail). Visit http://www.mersenne.org/newhtml/prime.htm and http://www.mersenne.org/newhtml/status.htm Some questions for you folks include: 1) Is this an improvement? 2) Can someone come up with a spiffier banner? 3) Any suggestion on using more color (yet still look good given the black and white picture of our hero Marin Mersenne)? 4) Is this too slow to download? Would you rather not have the mouse rollover feature (it adds to the .gif files downloaded). 5) Would you rather I use frames so the menu does not scroll? 6) Is the link to hitbox at the very bottom too annoying? (I get free web stats by using this). 7) I'll work on the site contents this week. Is there any missing info from the current web site that doesn't fit into one of the proposed categories? 8) Any other comments? Thanks for the feedback, George _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Sun, 16 Apr 2000 23:54:22 EDT From: [EMAIL PROTECTED] Subject: Re: Mersenne: SPARC/Solaris client Has anyone considered writing a perl script to interface {mprime|Prime95|other} to Primenet? It seems like dividing the communication work from the math might be worthwhile, and since all the configuration lives in .ini files and the output lives in .txt files, it should be easy for perl to do it. _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 17 Apr 2000 09:45:28 +0200 From: Harald Tveit Alvestrand <[EMAIL PROTECTED]> Subject: Re: Mersenne: Facelift At 23:33 16.04.2000 -0400, George Woltman wrote: >Some questions for you folks include: > >1) Is this an improvement? Mumble. The status page is now too wide. >2) Can someone come up with a spiffier banner? > >3) Any suggestion on using more color (yet still look good given >the black and white picture of our hero Marin Mersenne)? > >4) Is this too slow to download? Would you rather not have the >mouse rollover feature (it adds to the .gif files downloaded). Yes, it's too slow. In addition to removing the mouse rollover, I'd prefer the menu done with styled text, not GIFs. (Disclaimer: I'm in Norway. That means some tenths of seconds of additional load time for every single GIF on the page that cannot be served from cache, compared to the US - NO MATTER how much bandwidth I have) >5) Would you rather I use frames so the menu does not scroll? No. Frames are bad for my mental health. >6) Is the link to hitbox at the very bottom too annoying? (I get free >web stats by using this). would be less irritating if you right-justified it in a table together with the counter, so as not to make the page longer. >7) I'll work on the site contents this week. Is there any missing info >from the current web site that doesn't fit into one of the proposed >categories? > >8) Any other comments? Styling is good. Just make sure information doesn't suffer! Great project! Harald - -- Harald Tveit Alvestrand, EDB Maxware, Norway [EMAIL PROTECTED] _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 17 Apr 2000 11:57:40 +0200 From: "Hoogendoorn, Sander" <[EMAIL PROTECTED]> Subject: RE: Mersenne: Facelift >4) Is this too slow to download? Would you rather not have the >mouse rollover feature (it adds to the .gif files downloaded). No, not for mee (64k isdn) >5) Would you rather I use frames so the menu does not scroll? yes, it would be better, also the menu should fit on one screen, so no picture ??? >6) Is the link to hitbox at the very bottom too annoying? (I get free >web stats by using this). No, not for me, but maybe the logo's could be side by side _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 17 Apr 2000 12:58:25 +0200 From: "Philip Heede" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Facelift On Sun, 16 Apr 2000 23:33:49 -0400, George Woltman wrote: >1) Is this an improvement? Yes, definitely. >3) Any suggestion on using more color (yet still look good given >the black and white picture of our hero Marin Mersenne)? I think the proposed look is fine. >4) Is this too slow to download? Would you rather not have the >mouse rollover feature (it adds to the .gif files downloaded). Yes! As Harald Alvestrand said, not so much because of the size of the .gifs, but because of the time it takes for the browser to connect to the server. (I'm also in Europe, specifically Denmark) >5) Would you rather I use frames so the menu does not scroll? No not particularly. It works quite well as it is, and frames isn't very friendly to text-mode browsers (ie. lynx). >6) Is the link to hitbox at the very bottom too annoying? (I get >free web stats by using this). Not at all. - -- Sincerely, Philip Heede ... Chain Tagline: Now stolen [19] times. _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 17 Apr 2000 15:39:57 -0000 From: "Brian J. Beesley" <[EMAIL PROTECTED]> Subject: Re: Mersenne: GIMPS and other distributed projects On 17 Apr 00, at 2:12, Siegmar Szlavik wrote: > This is a good option and I use it very often, especially on slower > machines. What I am missing is some 'screensaver-functionality' (i.e. > prime95 stops when there is some user interactivity). I would find it very > usefull if this can be added to furture versions of prime95 (or even > better to the nt service) George? Hey, even the screensaver steals cycles when the system is active - it needs to check that the system still is active! If what you mean is, tap the screensaver API and make prime95 execute only if the screensaver is/would be active, then fair enough, I'll support that - provided it's an option. (This is rather similar to mprime running under linux starting & stopping depending on loadavg) > > yes, it "should", but I noticed, that on some machines prime95/ntprime > gets out of control after a few days and the system is no longer useable. ? (see below) > The program seems to get all the cpu time, allthough it runs with the > default (lowest) priority. Sometimes it helps to reboot the machine once > or twice a day, but just only sometimes :( Any idea, what could be the > reason? Right. It is _perfectly normal_ for a compute-bound process to get essentially all the CPU time, providing that nothing with a higher priority is in a computable state. The questions that need to be asked are: (1) is the system really grinding to a halt for some reason? In this case, it sounds as though this may be the case. In other words, _something_ is stopping interactive programs getting to a computable state. (2) if so, what is causing this? (Bearing in mind that Prime95 seems to be blissfully ignorant!) Given that this state is taking time to emerge, I would suspect that the cause is a memory leak reducing the physical memory available to interactive processes to a point where the system performance is badly hit. Prime95 has a nice chunk of memory from when it started & doesn't change this allocation much, so it just chunters on. (Though its own performance will start to deteriorate as page/swap thrashing becomes established). Now Prime95 seems to run "forever" on an otherwise idle system, so I think we can rule out Prime95 as being the source of the memory leak. Note that, if I'm right on this, the system would eventually slow down badly without Prime95 running at all - though it might well take longer for the effects to become obvious. The best diagnostic for this would be to use the Win 9x System Monitor tool (Start/Programs/Accessories/System Tools) - there is a similar tool in NT, and a much improved version if you happen to have the appropriate Resource Kit installed - to monitor the memory usage of the system services (the programs which run all the time Windows is up), and also of the system free memory (which you have to deduce from the disk cache size). After a few hours monitoring, you should be able to spot the culprit. Microsoft have in the past released patches for some Windows components and also for some of their applications which have corrected memory leaks. If a patch is not available, but the leak is in another component which is not essential (e.g. the notorious FindFast service which Office installs for you), then you can also fix the problem by not running that component. If you have inadvertently installed cracker tools like BackOrifice etc. then you'd also expect deteriorating performance. It would definitely be worthwhile checking your systems - even if you decide to give up running Prime95. I'd certainly check out the patch level of your Windows components and whatever applications you are using and bring them up to date. This is worth doing anyway, e.g. Service Pack 6a for Win NT v4.0 corrects a number of known problems with security (as well as general fixes) which can make your systems vulnerable to various denial-of- service attacks. Basically, what I'm saying is that your systems seem to be getting into a state they shouldn't, and I don't think Prime95/NTPrime is playing a part in this. You're seeing Prime95/NTPrime taking a big slice of CPU time on a system that appears to be choked up, but that's because it's about the only thing wnating CPU time left in a runnable state, not a result of the system being overwhelmed by its demands. In other words, Prime95/NTPrime is being blamed for a problem which would exist anyway. The problem needs to be fixed, not what is only a symptom of the problem, and very probably an incorrectly interpreted symptom at that. Regards Brian Beesley _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ End of Mersenne Digest V1 #719 ******************************
