Hello all,

There is a New setup proposal just being realeased on the BOINC site. It's gonna be a lot more userfriendly imho.

Introduction
This is a proposal for a new install/setup mechanism for BOINC, designed to be simpler and more user-friendly, and to succeed even when proxy setup is needed. The major changes are:

From the user's viewpoint, an account is now identified by the combination of email address and (user-supplied) password. Email address is unique; no two accounts have the same email address.

Email addresses are not verified. Nothing prevents a user from creating an account with an email address they cannot access.

The email address and/or password of an account can be changed via the web.

The setup process attempts to identify cases where proxy configuration is needed, and prompts user for information.

Account keys are still used, but are not generally visible to users. Account keys are used by the core client to identify and authenticate itself to the server. An account's key never changes (so core clients don't need to learn when email address or password has changed).

---

Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

Hello all,

There is a New setup proposal just being realeased on the BOINC site. It's gonna be a lot more userfriendly imho.

I am a bit confused about this following paragraph:

Pathological cases
user X can create an account with user Y's email address. If Y tries to register later, he'll get an error message. But: Y can go to the web site, have the password mailed to him, change the email address of the account (to anything), then register again. Y will than have an account with his email address, and sole access to it. User X will have access to the old account, but not the new one.

I understand the idea upto the point where Y has to register again. If he changes the email addy to something that only he has access to, does this not stop X from having access to it? Or, will X be able to get the new email addy (but not the password) by using the account key?

Jim

---

I understand the idea upto the point where Y has to register again. If he changes the email addy to something that only he has access to, does this not stop X from having access to it? Or, will X be able to get the new email addy (but not the password) by using the account key?

Jim

That's possible. I don't quite understand it as well.
The crunching and the stats are not involved, as they don't care about this changes.
But the next time s/he will join the forum or look at his/her account, s/he will probably get an error message. If s/he has no further information about his/her account (like the 32-hex or something), it's probably lost for good.

I think it will be a bit like those folks from Classic, who never cared about their account data, as they never needed them, and can't get their accounts connected now. But for someone who misused my email-addy, I think s/he has to live with it ;)

---

Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

I'm not sure I like this proposal to make registration more user-friendly.

It's not out of some techno-snobbery either, I couldn't write a bash script to save my life - and I've been trying :)

The first and perhaps main reason, is that eventually by default, this new system will not validate the e-mail address entered by emailing the account key entered to it. It may sound a stupid reason, but the developers admit this is a weakness and have a list of ways to correct errors introduced by this method. It seems to me a waste of resources to change the registration process to one tht even the dvelopers admit will introduce problems.

The second reason is that registration on the project websites will eventually be eliminated. This is of course linked to the first reason but mainly I like registering on the project websites. Silly, I know :)

---

Need help? Check out the excellent Unofficial BOINC-Wiki!
'We are the BOINC. Prepare to be assimilated.'

The only item in the proposal that I don't think is a big improvement is this one:

"User is prompted for project URL."

Why? If the Manager runs and sees that it is attached to NO projects, it should read a "list of current projects" from the files that came with the Manager, and put up that list to allow the user to pick one. This would eliminate probably 90% of the complaints from Classic folks who say "I don't wanna haveta decide anything and look it up, I want it to do SETI only!" - all they'd have to do is click one time...

The list would include "Other not listed...", which would prompt for a URL.

Once attached to any project, hitting the "Attach to new project" button should bring up the list again. The list could be updated automatically just like any other XML file kept by the Manager.

Bill

"User is prompted for project URL."

(snip)

Once attached to any project, hitting the "Attach to new project" button should bring up the list again. The list could be updated automatically just like any other XML file kept by the Manager.

I can see the logic in having you input the URL. Mostly since more and more new projects are being developed and the connection XML file you mention would have to come from some server somewhere. It's probably easier just to ask for the project URL than maintain a current listing in XML that must then be updated on all project servers that run a BOINC project.

---

To truly explore, one must keep an open mind...

So have a popup list of all the currently known projects, and then have an "other" box, where you can enter url.

---

Mostly since more and more new projects are being developed and the connection XML file you mention would have to come from some server somewhere.

That could even contribute to the users always be updated on existing projects! The click on the 'attach' button would just have to download the projects file.
Then only a project would be lacking which never was announced to BOINC - and what could make less sense than that?
An "others..." prompt for an URL yet should be included (for projects in test).

Bills idea sounds VERY suggestive to me.

:-)= Greybeard

---

All about BOINC: BOINC-Wiki (by Paul D. Buck)

Mostly since more and more new projects are being developed and the connection XML file you mention would have to come from some server somewhere.

That could even contribute to the users always be updated on existing projects! The click on the 'attach' button would just have to download the projects file.
Then only a project would be lacking which never was announced to BOINC - and what could make less sense than that?
An "others..." prompt for an URL yet should be included (for projects in test).

Bills idea sounds VERY suggestive to me.

:-)= Greybeard

I can see a problem here. The present system forces you to visit the project website and find out something about the project when you sign up (theoretically anyway). If all the project urls were available in the client, an overenthusiastic beginner could end up signing up to all available projects on one computer, get fed up and abandon most. This already happens to some extent, but I can see it happening to a far greater extent in that case.

---

Need help? Check out the excellent Unofficial BOINC-Wiki!
'We are the BOINC. Prepare to be assimilated.'

......

Bills idea sounds VERY suggestive to me.

:-)= Greybeard

I can see a problem here......

Got in a bit to late to edit my previous post.

I think many problems with perceived user unfriendlieness of BOINC could possibly be resolved by a redesign of the front pages of the Seti BOINC website, the first BOINC project that most people encounter. Personally I think the rest of the Seti BOINC website is up to scratch although it could do with some sort of advanced search function, as others have commented.

In my inexpert opinion the ClimatePrediction website does a far better job of explaining what you are getting into.

Just an opinion, but I would like to hear what others think. Am I foolish, is it really a problem with the software?

Edit :Whoops too much bold :)

---

Need help? Check out the excellent Unofficial BOINC-Wiki!
'We are the BOINC. Prepare to be assimilated.'

It might make more sense to preload the downloaded client with the project URL where you obtained it - so download from Berkeley you would get SETI 100%, from Scripps you would get Predictor 100% etc.etc.

Not fixed, the user could always attach to other projects and play with preferences later.

The list of available projects could surely be held on a server somewhere and be available to the BOINC client on demand as an XML file - that would be a nice way of letting novice users know (a) what projects are available and (b) remove any doubts whether they are supported. I would suggest this list specifically excludes closed or otherwise restricted (alpha/beta) projects.

Measures of this type would make things much simpler for crossover users IMHO.

---

project_list.xml example:

(project_list)
(project)
(project_name)SETI@Home(/project_name)
(platform)Windows(/platform)
(platform)Linux(/platform)
(platform)Macintosh(/platform)
(master_url)http://setiathome.berkeley.edu/(/master_url)
(/project)
(project)
(project_name)Einstein@Home(/project_name)
(platform)Windows(/platform)
(platform)Linux(/platform)
(platform)Macintosh(/platform)
(master_url)http://einstein.phys.uwm.edu/(/master_url)
(/project)
(project)
(project_name)SZTAKI(/project_name)
(platform)Windows(/platform)
(platform)Linux(/platform)
(platform)Macintosh(/platform)
(master_url)http://szdg.lpds.sztaki.hu/szdg/(/master_url)
(/project)
(/project_list)

The "platform" lines would allow the Mac version, for example, to not list Message@Home... obviously those could be a lot more specific. (And I've left out a bunch, this is just an example.)

As for "accidentally" signing up for projects you weren't interested in... when you pick a list item, it should go to that website - meanwhile, it puts up a "sign up for this project? Yes/No" box. Gives them a chance to read the website and say "no" if they aren't interested. Think about how many "User Licenses" you have to read and okay on software today...

Bill

It could even be distributed. A host attaches to a new project, and the project sends information about the project (and whether to distribute or not). The host then sends this information back to every project server it connects to. The list is then included in every download from the server to any host.

The only problem is vetting out worm, virus and for profit projects.

The only problem is most projects defer to BOINC.ssl.berkeley.edu to do the actual download, and this complicates the initial setup.

---

BOINC WIKI

It could even be distributed. A host attaches to a new project, and the project sends information about the project (and whether to distribute or not). The host then sends this information back to every project server it connects to. The list is then included in every download from the server to any host.

The only problem is vetting out worm, virus and for profit projects.

The only problem is most projects defer to BOINC.ssl.berkeley.edu to do the actual download, and this complicates the initial setup.

Good points against distribution, even with the "it should be distributed" ideal...

I'd actually only keep THIS file at UCB. (If UCB down, and no file on computer, put up error message to try again later.) It shouldn't need to be updated very often - BOINC is what, two years old or so? How many projects have come and gone? A handful?

No reason to "automate" it - maintain it manually. It just doesn't change that often, probably barely more often than the client software itself. It's a "convenience" - they can ALWAYS enter the URL manually.

It could even be distributed. A host attaches to a new project, and the project sends information about the project (and whether to distribute or not). The host then sends this information back to every project server it connects to. The list is then included in every download from the server to any host.

The only problem is vetting out worm, virus and for profit projects.

The only problem is most projects defer to BOINC.ssl.berkeley.edu to do the actual download, and this complicates the initial setup.

Good points against distribution, even with the "it should be distributed" ideal...

I'd actually only keep THIS file at UCB. (If UCB down, and no file on computer, put up error message to try again later.) It shouldn't need to be updated very often - BOINC is what, two years old or so? How many projects have come and gone? A handful?

No reason to "automate" it - maintain it manually. It just doesn't change that often, probably barely more often than the client software itself. It's a "convenience" - they can ALWAYS enter the URL manually.

One has clearly gone. One is questionable whether it will come back from comatose. There are about 6 or so in production and about 15 more in Alpha / Beta stages. There is one of questionable background (anyone want to try Russian? - it appears to be a for profit Grid connection).

---

BOINC WIKI

Better late than never.

I don't like the idea of a login driven by email address for many reasons :

- If you have a long email address, it's not easier at all
- If you change of ISP, your email address may change. If you can change it, it's not a reference. If you can't you're done
- We've got yet 3 identifications : The project id, the cross project id and the account number. What's the use of a fourth one ?
- For any reason, you may want to create 2 accounts (one for home and one for work for example) with a single mail to centralize. email is dedicated to contact, it's not a "single" identifier

I would rather prefer the idea of a single login for all projects, with, maybe, the cross-project id. The first time you have to copy it in the field, then for next projects (with an auto list in the client) the client should be able to retrieve it, so a single clic could be enough to configure a new project (may be 2, "are you sure ?" lol)

But anyway, up to my mind, the more urgent is to have a true network client, something like BoincView, really nice, but with a better integration (for example, if you want to track results done, you have to scan you PC every 5 seconds ... should work with 1 or 5mn at least instead. Message queue is not managed. It's a copy of client current queues. If you restart a client, messages are lost)

We should not forget that connecting to project is done once/project/machine. So another nice way could be to configure the first machine, save a conf file, and pass it to the others machines which will use it to connect ...

---

"In a world without walls and fences, who needs windows and gates ?"
for the team

So another nice way could be to configure the first machine, save a conf file, and pass it to the others machines which will use it to connect ...

This can already be done. Copy the account_*.xml files from source to target, restart BOINC at the target - done.

---

BOINC WIKI

I do think the idea for simplifying/automating setup of a proxy server is a great idea, but what interests me, is how will it be implemented in the command-line client?

A message saying 'cannot connect to project server, please use a proxy' or something like that? Or just the same old error message?

Anyway, I think this whole project should be very low priority. The database should be thoroughly debugged first and then the BOINC graphics capable client/manager for Linux and OSX released.

But I'm the first to admit I'm no programmer :)

---

Need help? Check out the excellent Unofficial BOINC-Wiki!
'We are the BOINC. Prepare to be assimilated.'

But I'm the first to admit I'm no programmer :)

[font='courier,courier new']That's a Good Thing.

Programmers who are stuck in the programming mentality tend to overlook things. It's like a blind man not realizing he's (as they say) "visually impared" until someone with 20/20 vision points it out to him.

The best Debuggers are not Devs, but Users.[/font]

---

The best Debuggers are not Devs, but Users.[/font]

I will disagree here. Developers tend to make horrible testers, as do most users. An ideal tester can find ways to break the software that seem absurd, and then write everything down so that the developer can then find the bug and fix it. Most developers have problems with the first part (finding sequence that causes the bug) and most users have trouble with the second (remembering exactly what happened and writing it all down). Note the rants from users "Its s***, hoplessly broken...". Only developers make good debuggers (finding and fixing the cause of the problem in the code).

---

BOINC WIKI