![]() |
![]() |
#12 |
Oct 2019
5·19 Posts |
![]()
Nope. I mean to inform the user about the information (by account or software) and let the user choice "not to update" manually. If the user not respond for a period of time, this can be seen as agreed by default. Again, it's common sense that the machine is determined by the user.
Last fiddled with by Fan Ming on 2020-07-24 at 13:24 |
![]() |
![]() |
![]() |
#13 |
Undefined
"The unspeakable one"
Jun 2006
My evil lair
23·283 Posts |
![]() |
![]() |
![]() |
![]() |
#14 |
Oct 2019
9510 Posts |
![]()
No, silence usually means to accept the default option. If the user doesn't response for quite a while(for example, 1 year), that usually means it's Okay for their machine to update to a newer version of mprime. If the update cost little network/disk usage, it may be a proper option that can be considered (There may be other conditions that not suitable to update, additions is welcomed). It's the user's responsibility to take the risk of older unsupported version of software. Even if we just leave it, then the user get forced LL-DC work because of assignment rule changes no matter they've chosen "get LL-first time test" option before, that may be the result that the user doesn't want either -- they may not want to contribute their machines for pure DC work at all. Moreover, I do believe that this kind of user is much prefer to get first-time tasks instead of pure DC work, so that's the reason that I propose this idea, not the intention to offend any of users' right, and not an irresponsible idea that lacks careful consideration, either.
Last fiddled with by Fan Ming on 2020-07-24 at 14:14 |
![]() |
![]() |
![]() |
#15 |
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest
658910 Posts |
![]()
My take on updating, from 24 years of GIMPS participation:
Just as some older gpus can't run recent versions of gpuowl, or any at all, some older cpus can't run recent versions of prime95/mprime. Forcing an update on them would end their productivity. But they can still be productive running P-1 or verification, both of which are much faster than even LL DC. Forced updates by timeout of lack of refusal could cause a lot of havoc, particularly for someone who did set and forget setup on dozens or hundreds of machines. (Curtisc...) PrimeNet ceasing issue of LL first tests at some point will motivate users to migrate to PRP. It is the user's choice whether to update. The user has the right to run what he chooses, or nothing at all. In corporate settings, updating may be an issue for obtaining or retaining approval. It is common to do evaluations of new versions before doing a broad rollout. Forced updates of any kind will reduce user participation. Automatic updates of any kind if implemented would need to be opt-in, not failure to opt-out or no-choice-in-the-matter. Updating is itself a nontrivial programming task. Ensuring an orderly shutdown, file compatibility between old and new version, perhaps a rollback capability, all take effort. There are more useful tasks for our scarce valuable programmer talent now. Last fiddled with by kriesel on 2020-07-24 at 15:08 |
![]() |
![]() |
![]() |
#16 |
6809 > 6502
"""""""""""""""""""
Aug 2003
101×103 Posts
10,613 Posts |
![]()
Further, there is no back door in Prime95 to allow for forced updates (either server push or client fetch).
The thread was initially locked by happenstance. When I spun it off, the first post was from a locked thread. So this thread inherited that attribute. |
![]() |
![]() |
![]() |
#17 | |
"TF79LL86GIMPS96gpu17"
Mar 2017
US midwest
11×599 Posts |
![]() Quote:
Note also that EWMayer and Preda have made the same choice, as have authors and maintainers of other GIMPS gpu applications. For my own use, in the gpu app tender program I've been using, I added a manually initiated client pull of updates for compiled versions of that tender program from a specified network share location. It's not trivial, to a) make an update process work b) that is OS-agnostic or identifies and handles multiple OSes correctly c) and deals with the locked-in-use file situation; I chose to implement as launch a separate update process, with delay sufficient for shutdown of parent process; child process does update of files on disk, then relaunches parent process, user is there to see if it worked or failed and figure out how to clean up any mess that creates d) even manually, much less handling various exceptions if automated Any rollback is entirely manual. And I didn't have to deal with any download-failure issues, since I compile the tender program and place it on the network share myself. Work in progress file version compatibility can be an issue for GIMPS application updating. Or work assignments. Gpuowl has had transitions where work types or PRP residue types were incompatible from one version to the next. Backward compatibility of supported types' file formats is limited. See https://www.mersenneforum.org/showpo...7&postcount=12 There have also been cases documented in prime95/mprime where it's advisable to finish a computation before updating to a newer version to avoid complete loss of progress on an assignment in progress. (P-1 as I recall; there may have been other cases.) Last fiddled with by kriesel on 2020-07-24 at 16:47 |
|
![]() |
![]() |
![]() |
#18 |
Undefined
"The unspeakable one"
Jun 2006
My evil lair
145558 Posts |
![]() |
![]() |
![]() |
![]() |
#19 | ||
"/X\(‘-‘)/X\"
Jan 2013
2,953 Posts |
![]() Quote:
Quote:
|
||
![]() |
![]() |
![]() |
#20 |
Oct 2019
5×19 Posts |
![]()
It's indeed that there shouldn't be automatically update for this kind of software. But this is an important update that can be seen as necessary security update. Sure, old machines that do other tasks such as DC, P-1, even TF is not necessary to update, but I think most machines that have chosen the "LL-first test" are actually capable of newer mprime versions.
Most users that chose the option and leave their machine for several years usually they don't want to contribute their machines for pure double-check work, but first-time tests. And usually they don't mind their mprime software to be updated to newer versions -- at least they ran mprime software several years on their machine. I do believe this is based on the acutal situation, and it's meaningless for some to argue with the meaning of some words. As for technically reasons, with careful test and benchmark of newer versions of mprime on some CPU microarchitectures that are not too old (for example, Core2), it would be no matter for these machines to update. If there is not a simple way to implement the update on program, at least informing them is OK(by account, or E-mail, or additional primenet info on software). However, it's indeed a problem that they just didn't response and were forced to do DC work because many of them don't want their machines to be contributed to pure DC work. I think this problem should be solved if no automatically update is feasible. Last fiddled with by Fan Ming on 2020-07-25 at 02:59 |
![]() |
![]() |
![]() |
#21 |
P90 years forever!
Aug 2002
Yeehaw, FL
22×3×659 Posts |
![]()
Calling v30 a "security update" is quite a stretch. Yes, having everyone upgrade would be beneficial to GIMPS, but it ain't gonna happen.
1) It goes against a long GIMPS tradition of letting users decide what they want to do. 2) It is impossible. What we can do is encourage users to upgrade. 1) Post the news on the GIMPS main page. 2) Send out the first GIMPS newsletter to those that opted in. The first newsletter in over 20 years. 3) Deprecate the ability to get first-time LL tests. |
![]() |
![]() |
![]() |
#22 |
Undefined
"The unspeakable one"
Jun 2006
My evil lair
23·283 Posts |
![]() |
![]() |
![]() |
![]() |
Thread Tools | |
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Impact of AI | xilman | Lounge | 19 | 2017-01-26 16:03 |
First pre-impact discovery for NEO search! | cheesehead | Astronomy | 42 | 2013-11-22 04:54 |
GPUs impact on TF | petrw1 | GPU Computing | 0 | 2013-01-06 03:23 |
GPU TF work and its impact on P-1 | davieddy | Lounge | 161 | 2011-08-09 10:27 |
Another Impact on Jupiter | Spherical Cow | Astronomy | 24 | 2009-08-12 19:32 |