System update spec proposal
Mike C. Fletcher
mcfletch at vrplumber.com
Tue Jun 26 15:03:22 EDT 2007
Christopher Blizzard wrote:
> So notes on the proposal:
> 1. There's a lot in here about vserver + updates and all of that is
> fine. But we've been pretty careful in our proposals to point out that
> how you get to the bits to the box is different than how they are
> applied. I don't see anything in here around vserver that couldn't use
> alex's system instead of rsync. So there's no added value there.
I would agree that vserver is largely orthogonal, with the assumption
that we don't do a direct-to-file-system update (already discussed and
My understanding here is that Alex's system is currently point-to-point,
but that we don't yet have any way to distribute it on the mesh? That
is, that we are looking at a research project to determine how to make
it work in-the-field using some form of mesh-based discovery protocol
that's going to try to optimise for connecting to local laptops. I
personally don't care which way we distribute, but I'm wary of having to
have some mesh-network-level hacking implemented to provide discovery of
an update server.
I'd be much more satisfied if there were something that could hook into
some Jabber/Tubes/whatever distributed service that's already written
and ready-to-go. Of course, we wouldn't be able to do the
nearest-neighbour update mechanism without the mesh topology
information, but I'd be tempted to make that topology information a more
general mechanism that any application could access, rather than making
it a part of this particular daemon, and I'd be tempted to make that
happen later rather than earlier.
I could have mis-read the comments and status on Alex's system, though.
After all, it's just a custom per-file rsync operation, so it should be
possible to update from almost any source, just as with rsync. It is
the auto-discovering and the like that sound rather low-level and
fragile to me. In other words, if we wanted to run s/rsync/Alex's
system/ over Ivan's proposal, I'd be largely fine as long as the
protocol is stable and reliable. My concern is in trying to leap
directly to the optimised laptop-to-laptop case with low-level network
> think that we need something that's actually designed to solve the
> problems at hand rather than seeing the hammer we have on the shelf and
> thinking that it's obviously the right solution.
Fair enough AFAICS, as long as the protocol can be robust and stable
within the time frame.
> Basically aside from the vserver bits, which no one has seen, I don't
> see a particular advantage to using rsync. In fact, I see serious
> downsides since it misses some of the key critical advantages of using
> our own tool not the least of which is that we can make our tool do what
> we want and with rsync you're talking about changing the protocols.
Hmm, interestingly I see "using our own tool" as a disadvantage, not a
huge one, but a disadvantage nonetheless, in that we have more untested
code on the system (and we already have a lot), and in this case, in a
critical must-never-fail system. For instance, what happens if the user
is never connected to another XO or school server, but only connects to
a (non-mesh) WiFi network? Does the mesh-broadcast upgrade discovery
protocol work in that case?
Mike C. Fletcher
Designer, VR Plumber, Coder
More information about the Devel