Proposal: Fedora@Home
| From: | Bryan Che <bche-AT-redhat.com> | |
| To: | fedora-advisory-board-AT-redhat.com | |
| Subject: | Proposal: Fedora-AT-Home Project | |
| Date: | Wed, 05 Mar 2008 09:48:34 -0500 | |
| Message-ID: | <47CEB2C2.1010803@redhat.com> | |
| Cc: | fedora-devel-list-AT-redhat.com | |
| Archive-link: | Article, Thread |
Hi, my name is Bryan Che, and I am a long-time Fedora user and also the Red Hat product manager for a new Red Hat product, Red Hat Enterprise MRG (http://redhat.com/mrg). I would like to propose to create a new "Fedora@Home" project at Fedora which would use the open source technologies in MRG (and which have already been submitted to Fedora). MRG includes a grid scheduler based on the Condor project created by the University of Wisconsin (http://www.cs.wisc.edu/condor/). This scheduler includes the ability to harness idle CPU capacity from desktops and also schedule to virtual machines. I'd like to create a Fedora@Home project where Fedora hosts a MRG grid scheduler, people can donate CPU time on their computers for computations, and we schedule meaningful or useful work to these people's computers. This would be like an open and general-purpose Folding@Home or SETI@Home project. Ideally, we could include the client software for computation as part of Fedora distributions and build out a large, million+ node open grid for things like Fedora infrastructure tasks, scientific computing, or socially-beneficial work. This would be fantastic for Fedora as it would allow us to lead the open source movement into the area of open services and community computing based on open source. It would also be a great marketing showcase for Fedora by showing our leadership in grid technology and in the power of our community. And, it would provide Fedora users a feel-good way to contribute to Fedora--even if they don't code--by contributing CPU cycles towards things like builds or automated testing. Finally, for full disclosure: as the product manager for MRG, I would also love to be able to point to a Fedora@Home project as a showcase of the technologies in MRG at work in a massive, public grid. Red Hat and the University of Wisconsin recently signed a partnership that makes available the Condor source code under an OSI-approved open source license (mostly ASL). We have packaged Condor, submitted it to the F9 development branch, and are maintaining it there. The University of Wisconsin's Condor project remains our upstream code base and community. So, from a technology perspective, we should be able to build Fedora@Home using technologies that will all be in Fedora. What are your thoughts on this? (Please post replies to fedora-advisory-board@redhat.com as that is where I will be following discussion) Thanks, Bryan
(Log in to post comments)
Proposal: Fedora@Home
Posted Mar 5, 2008 20:14 UTC (Wed) by dowdle (subscriber, #659) [Link]
I hope the Fedora folks go along with it. If they do, I wonder if it could make it into Fedora 9? Perhaps that would be asking too much. Sounds like a way cool idea. I'd also imagine that several other distros would join in and add MRG grid as an optional feature... and then we could also use it to measure some other things... so a certain level of accuracy... like how many users are using which distro. Heck, the distros could even compete against each other... as to which distro has the most computing power and donates the most CPU cycles. Not quite accurate but better than Distrowatch's link thingie I think. :) Hmmm, I'm assuming that an institution with a large number of MRG systems... could also use the feature for local computational jobs? That being built in would be handy for institutions that already have MRG based grids in operation... and I'm assuming it'll be a default feature of RHEL at some point... or an addon option?!? While Rocks Clusters offers more grid computing technologies... I'm wondering if adding MRG to Fedora and other distros would have an impact on Rocks Clusters deployments?
security of distributing builds
Posted Mar 6, 2008 6:07 UTC (Thu) by pjm (guest, #2080) [Link]
There are some obvious security issues with trusting the build results of random users. The problem with building is that it takes about as long to check that the result is correct as it does to do the work yourself. The only workable scheme that springs to mind is to limit the users to those who can already subvert the binaries by other means, which is (by design) quite a small number of people. (Note that subverting a binary is harder to detect than subverting source code, so should ideally exclude people whose only other means of subverting binaries is by subverting source code.) You can't use a trust criterion of "the person has always given correct builds in the past when we've checked the results", because it's still worthwhile for a black-hat to send N corrects builds followed by 1 incorrect build, and one incorrect build of one object file (indeed function) is all that's necessary. A criterion of "N people give the same result" is problematic because of (a) need N large enough to reduce risk of collusion, whereas (b) it requires N-fold duplication of work (see also the objection about increased environmental cost of using extra CPU cycles).
Security of distributing builds
Posted Mar 6, 2008 12:07 UTC (Thu) by midg3t (guest, #30998) [Link]
No-one would seriously entertain the idea of allowing untrusted builds into the official software archive.
There are many cases when the potential for bad data to be returned is not much of a problem. For instance the grid could be used as an unofficial build farm with on-commit autobuilds. If there's a strange build failure then the first step would be to reproduce that failure in a similar environment. The release builds would still be done on more secure (controlled) machines.
Similarly for scientific applications the aim might be to look for outliers - eg. how SETI works - once again "interesting" results are always reprocessed in a controlled environment.
security of distributing builds
Posted Mar 20, 2008 7:22 UTC (Thu) by robbe (guest, #16131) [Link]
> There are some obvious security issues with trusting the build results of random users. I, too, surmised from the name "Fedora@Home" that they are planning to offload some Fedora build work onto users -- but nowhere in the announcement is this actually proposed. Seems just to be a suboptimal project title...
security of distributing builds
Posted Mar 24, 2008 10:13 UTC (Mon) by pjm (guest, #2080) [Link]
I'm not sure what announcement robbe means, but the fourth paragraph of the parent article mentions Fedora users contributing CPU cycles towards things like builds ; this is what I was replying to.