Posting a message that it is offline is preferred. But keep on folding has my vote.
Hopefully this will be fixed quickly![]()
yes, leave as-is, it quits
no, change it so it keeps folding anyways
Ok this issue has come up a number of times in the past so lets decide it once and for all in a democratic way. The main idea behind the client/screensaver exiting upon startup if the main server is down, is that we didn't want people doing a lot of work while the server was off, and then flooding it when it came back on. Also, if we ever wanted to terminate the project, it would get people the message that it was over and they wouldnt keep folding needlessly.
Now that the server backend is more powerful, and this can be circumvented by using the -if option anyways, it is not such a big deal anymore, and perhaps more of an annoyance. So please vote - should the client exit if it cannot reach our main server upon startup? Yes or no
Howard Feldman
Posting a message that it is offline is preferred. But keep on folding has my vote.
Hopefully this will be fixed quickly![]()
Proud member of the Dutch Power Cows
Definitely keep folding and don't go back to the desktop.
Brian sorry about my attitude but I was frustrated that you said you couldn't see the problem. You should have mentioned the build up of data and slamming the server before. I am glad that isn't a problem anymore.
Let it keep folding, and don't terminate the project.![]()
If you do terminate the project you should do an update that doesn't use the cpu and just prints a message stating that the project is over when someone runs it so they can see the output.
I agree with Welnic.
Keep it folding and never terminate the project![]()
Now there's an idea!Originally posted by Welnic
If you do terminate the project you should do an update that doesn't use the cpu and just prints a message stating that the project is over when someone runs it so they can see the output.
You could even just ignore all command line parameters (including -qt). On Unix, you might be able to explicitly open /dev/tty, too, just to make sure you get the controlling terminal (as opposed to /dev/null, if someone has redirected output there). Writing the same to error.log might be another way to get the message across on Windows (or even everywhere).
And just so you don't use a lot of server bandwidth with the update, you could post (here or on the News page; here might be better, assuming "here" is still the preferred way to get in contact with the users at that point -- I wonder if a mass email to everyone would work?) first, and keep the update unavailable for say a week. That would knock out the users that read these forums, assuming they could get at all their boxen inside of a week. Autoupdate after that week, for the users that don't read the forums or the News page or their email account.
I think we may have a winner!![]()
"If you fail to adjust your notion of fairness to the reality of the Universe, you will probably not be happy."
-- Originally posted by Paratima
I can't argu With a Team M8Originally posted by HansArne
Keep it folding and never terminate the project![]()
![]()
Hell No!! Proj On!
Agent Smith was right!: "I hate this place. This zoo. This prison. This reality, whatever you want to call it, I can't stand it any longer. It's the smell! If there is such a thing. I feel saturated by it. I can taste your stink and every time I do, I fear that I've somehow been infected by it."
no, change it so it keeps folding anyway
.
.
As long as you are thinking of the client/server interface, would you please also do some brainstorming about situations where the client CAN reach the server.
I had started a separate session for the beta (in addition to the regular client). I wanted the beta to complete through generation 250, so I let it run (-i f) past the switchover instant. When it came time to upload (-u t) the filesets from the beta, the server INSISTED on first downloading the updated client. Only when the new client had been installed in that session did the server allow me to upload the filesets. My point is that I had ALREADY updated my normal DF session with the new client -- I went ahead and deleted the beta session when I had finished the upload, so I did not NEED to have the beta session be updated as well.
When the user is asked "Do you want to download the new client?", and the answer is "No", would it be possible (e.g., for -u t) for the client to go ahead with the upload, instead of exiting ?
mikus
I agree with all the replies above. There seems to be an unusual amount of agreability in the air. Maybe it's the season, but I don't think so. . . .
=^..^=
AZ Lynx
=^..^=
Fold On!
![]()
YES... Keep on folding.
I agree also with the point made by Mikus.
"When it came time to upload (-u t) the filesets from the beta, the server INSISTED on first downloading the updated client."
I have been at the wrong end of a 26.4 bps line when this occured. It is very frustrating that the server insisted on doing an update before I could upload the current results, especially as there was this deadline (and I would never use that update anyway because it was a sneakernet copy!!).
Ned
Ned: Here's how I solve that problem on my sneakernet boxen. I download the new install package on a separate machine and unpack it onto a USB thumb drive. Then I go to each of the sneakernetters in turn, stop the folding, load the new files, then upload the stored gens, then restart it. Saves a great bunch of time.
If the sneaker-netters are on a network (mine aren't), it's even easier.
HOME: A physical construct for keeping rain off your computers.
Fold On for sure... all my boxen work off-line via that lovely client dfGUI but when it comes to upload and the server is borked well it stuck but yeah upload the results 1st then ask for an upload not just die when you say no to the update...
Semi-retired from Free-DC...
I have some time to help.....
I need a new laptop,but who needs a laptop when you have a phone...
Now to remember my old computer specs..
fold on i say
that way i wouldn't have to leave it folding offline (for fear of the pc spending a full day on, doing nothing when there are server problems)
very frustrating to find all the clients have shut down due to the server being offline... so much so that I have virtually stopped trying to get them all back on line... this singular problem has caused me to drift away from this project... glad to see addressing it is being considered...
cover me... I'm going in...
That was the primary reason I took DeepToast offline after The Challenge.
Bringing a hundred machines back online - or worse - figuring out which of the hundred had gone down - was a royal pain in the patootie.
DeepToast is long since gone, but I'd probably buy fifteen or twenty duallie Xeon P4s to put back on the project if it weren't so inclined to go down...
With those kinda numbers, running them offline also isn't practical...
Keep them running![]()
Rock On!
Let if fold!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Folding.......
pharmd24
Keep folding!![]()
Folding 24/7 for a cause
www.hardCOREware.net
HCW DF Team!
OK. A proteine changeover is coming up and the votes are clear.
Question is: Will this be implemented before the next changeover?
In other words. Will we be able to quit the client and restart it on January 13th?
The young cows are eager to know![]()
Proud member of the Dutch Power Cows
The change has been made for the new executables available next week
Howard Feldman
That's good news, Howard. Thanks a ton!
Yes, thank you, thank you, thank you!
![]()
"If you fail to adjust your notion of fairness to the reality of the Universe, you will probably not be happy."
-- Originally posted by Paratima