APT-like system for BOINC
BOINC is an open-source distributed-computing framework
(http://boinc.berkerley.edu) that has various applications
associated with it. Projects using BOINC (e.g. SETI@home) have
their own application executables which the BOINC core client runs
to do the main computational work.
So far now the distribution model for applications has been: the
server has binaries for each version for each operating system /
architecture. When a user runs BOINC for platform P, the version
string for P that was hard-coded at `configure' time is sent to
the server and it tells the user which file to download and
run. (BOINC applications are RSA-signed. I'm omitting details
about when a new application version needs to be downloaded or
what an old version restricts.)
We would like to flip the model so that the user can compile his
own binaries and tell the server what application versions he has
(for those projects whose applications are open-source).
(Tampering with the application is generally avoided or detected
through redundancy and project-specific algorithms.)
Designing this new system can learn a lot from APT. Users would
have a server list similar to /etc/apt/sources.list (format might
be XML though); at least one source for each project the user has
joined. For our own projects (currently SETI@home, Astropulse) by
default it would point to our servers which have application
binaries for popular systems.
Classes of users are:
(1) Users of popular operating systems that want it to "just
work"; most fall in this category. We must provide binaries
for them with a sources.list that is configured to work
(2) Users of unpopular operating systems that want it to "just
work". They need to be able to add a source from somebody
else that has compiled applications for this project for their
(3) Users that are adventurous or paranoid or want to optimize for
their specific processor, and want to compile everything
themselves. They could add a source pointing to a local
file:// archive or http:// on another trusted machine.
(4) System administrators?
The update/upgrade process would need to be automatic (and
optionally not automatic). Multiple versions of the same
application, at least temporarily, would be useful.
I'm not sure yet if different distributions
(stable/testing/unstable) are useful.
Any comments on if/how this should be implemented? Would anyone
like to help us design and develop such a system?
Karl 2003-12-26 22:04