Lynn, upon rereading the posts, refreshing my reading on Account Managers, doing new reading on GuiRPC, discerning some of the details provided about security, and placing information provided within the context of the new understanding, I have to say that I now agree with you, that most of the posts have attempted to be helpful. So I apologize if my frustrations with absorbing new information spilled over to my interpretation of posts.
Many of the responses were coming from other perspectives, which is part of what we seek from a list like this. But unless one already understands the perspective offered, it's going to take more then a line or two for one to see how it applies to the situation at-hand. I for one have not installed a BOINC client via a GUI since a sandbox creation was a selectable feature, and have not taken steps to manually create a sandbox for my installations. I have never used a Mac. I have never used the GuiRpc, other then via boinccmd. So statements about how it can't work are immediately dismissed, because I see on my own machine that it does. Statements that it shouldn't work are easily taken as hostile, and yet perhaps were meant in reference to the default configuration (which I apparently am not using), and so were intended to specifically indicate that a current release default installation has a bug if the same behavior were observed. And statements about BOINC apps being blocked from using the network (which is the whole purpose of some projects), and what BOINC apps should and should not be allowed to do are clearly just misguided. An app should be allowed to do anything the architecture supports... when it follows the architected authentication. So, now that I've learned about the details behind the GuiRPC, I can see why it was brought up, and sometimes slipped in place of boinccmd in descriptions and how it is relavant. Now that I understand that the doc about when boinccmd requires a password misguides one to believe it has anything to do with the directory it is run from, rather then the user credentials that are running it, I can now see how statements about it won't work are correct... for many installations. And certainly the default install is of great interest. But the linkage between "sandboxed" and "default" was not clear to this ole timer that read all the doc about all the steps that one had to take to sandbox BOINC on their machine. So it sounded to me like a description of a rare user case where one had followed all of the steps, rather then the common user case where one has done a default installation. So again, my apologies if I got defensive. And my thanks for the assistance. It is all making a lot more sense now. Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running rose...@home just might! http://boinc.bakerlab.org/rosetta/ There are two issues here: 1) What you can do with the current environment. 2) What should be possible. I'm not questioning what you've found. You've complained that BOINC is overstepping its bounds by saying that it shouldn't be possible for one project to "manage" others. (and I'll note in case anyone misses it that BOINC is not saying that officially). Most of the discussion seems to be how to accomplish what you want (and what additional tools you might need) without removing the walls between project and client. Sounds fairly open to me. That's why I don't get the whole paragraph I quoted below. Sounds like most folks are generally okay with the concept, and are looking for ways to do it without further relaxing security. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
