On Tuesday 29 October 2002 17:28, Gareth Randall wrote: > > I'd like to suggest that prime95/mprime be "modularised", and that only the > core calculation component be kept closed source.
Umm - actually the core calculation component is "open source" (but subject to restrictive licence). See source.zip. > I realise that the code > for generating verification codes must remain restricted, No - there is an alternative, which is for results submitted to be accompanied by a secure certificate generated by the server. > because that is > the only authentication that work has really been done and done correctly. There are a couple of points here: (1) the verification code may be crackable; (2) there may be ways of persuading the program to submit results without actually executing all the iterations required. If every user had a (free) secure certificate, all results submitted would be traceable to the individual user. This scheme would also make it possible for other clients to use the automatic server interface, instead of having to rely on the manual forms (& not getting PrimeNet credit for work completed). > > However, I do not see any reason why any of the building blocks other than > the core calculation component actually need to be restricted. I also see > many benefits of them being made open to contribution. Sure... and this will become increasingly important if (when!) the mass PC market starts to diversify from the current universal IA32 architecture. > > [non-contentious material snipped] > > The computation module would be simplified, I doubt it! > > > The key benefits are: > > 1. Removal of many bottlenecks caused by the understandibly limited time of > core developers. > > 2. Substantially easier bug-fixing. (What's error 2250 again? Quick search > of the source for the server comms module. Oh yes, that means...) > > 3. Vastly increased potential for user participation and development. > 4. (Important) Ease of implementation on other platforms. Only the core computation stuff really needs to be optimized to all hell. The server comms & general control stuff would probably be more than efficient enough if it was implemented in perl, java or something else inefficient but portable. 5. (Important, for those who like eye candy) Ability to add customized "skins". > > > Prime95/mprime could be regenerated as a collection of programs, such as: > > On Windows: One executable and multiple DLLs > or: Multiple executables, and one calculation component in Win32 > command-line mode. The benefit here is a (small) saving in memory by not having to load unused code. Multiple DLLs are probably the best way to achieve this saving. The downside of this approach, from the developer's point of view, is that you get shafted if/when M$ change an API without telling you. > On UNIX: Separate binaries and scripts. One script to > start the collection running. Better still: build a version with what you want compiled in / loaded as modules at run time / omitted (like the linux kernel - though obviously much simpler!), monolithic or as a suite of smaller "simple" programs, depending on your personal taste. > > Wouldn't it be great if from some point in the near future, "feature > request" posts to this newsgroup became more like "I've written a fancy > improved frontend to GIMPS with some cool graphics, see this link for more > info", Actually that happened Sunday! > > Further, the ability for users to run their own personalised frontends > might give GIMPS the tangible advantage over other distributed projects > that many readers would so like to find. Agreed. Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
