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. On 2/23/2010 12:08 PM, Mark Pottorff wrote: > Please don't paint me the poster child for creating an insecure client > environment. I've neither created, nor suggested any such thing. You may have > already had one, and perhaps now you better see it for what it is. Don't > shoot the educator. > > > 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/ > > > Date: Tue, 23 Feb 2010 11:19:04 -0800 > From: "Lynn W. Taylor"<[email protected]> > Subject: Re: [boinc_dev] How to locate boinccmd on client > To: [email protected] > Message-ID:<[email protected]> > Content-Type: text/plain; charset=UTF-8; format=flowed > > > > On 2/23/2010 10:29 AM, Mark Pottorff wrote: >> > I wasn't aware that the BOINC project team feels it is necessary to > define what projects should and should not do. I thought it was an open > community. > > Now, this is just being snarky. > > I'm not on the development team, so I'm speaking as an outsider who > hopes he's contributed a little once in a while. > > I expect BOINC to take whatever steps are reasonably available to > protect my machine from hacking. > > That means that project "A" should not be able to run rough-shod across > my machine. It should not be able to access files that do not belong to > project "A" and it should not be able affect how my machine runs. > > It's my machine after all -- and my choice. > > The rest of the discussion has been to define terms like "project" and > "account manager" and how, conceptually, they're different. > > Sounds like the people most likely to write the code are open to > extensions to the account manager interface to allow "more management" > because that fits what an account manager should do. > > Not what a project should do, for good or bad. > > "Open Source" is not the same as insecure -- and open community is not > the same as "everything goes." > > > > > _______________________________________________ > 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. > _______________________________________________ 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.
