APT-like system for BOINC

[Karl Chen <quarl@hkn.eecs.berkeley.edu>]

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
    out-of-the-box.

(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
    system.

(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