On 6/25/07, Christopher Blizzard <[EMAIL PROTECTED]> wrote: > Most of the stuff that Alex has done is (carefully) independent of any > vserver or container discussion. Specifically, the update system in > question could be applied inside of a container as easy as it would be > outside of the container.
I not sure I agree that the filesystem portion of the implementation ought to be completely independent of the network portion. I think that networking desiderata are going to impact our choices among the various upgrade schemes, and I'd prefer to have a high level design for the whole thing before we get too attached to particular bits of code. As one example, since network reliability goes down quickly as message size increases, it seems (to me, at least) that our upgrade data messages should be made as small as possible. It's not clear to me that our current design minimizes upgrade transfer size. > Re: broadcast, that's basically the same as any laptop exposing presence > information. For _transmission_ of an update, it's an interesting > question as to whether or not to use a multicast update kind of thing. Do laptops usually wake each other up to process presence information? [Hopefully not.] Should they do so for urgent security upgrades? [Hopefully.] Here's a draft proposal: We listen to multicast address foo:bar:xxx:xxx:<n + 1> if we currently have version # n installed on the machine. Then we won't be woken up by our friends announcing that they have version n like we do, but we will be woken up as soon as someone gets version n+1. On 6/25 Alex L wrote: > mDNS *is* multicast. But the blobs won't be exposed over mDNS, that is > far to much data for a protocol like that. Really? Do we know that? What's a typical 0-day patch look like? Have we tried to see how few bits it could be squashed into? > Binary diffs seem much less useful. They enforce a specific base version > that you have to have around, and they enforce the direction of upgrade. This is *exactly* why we need to have the big picture view. My understanding is that we *are* expecting all laptops to have identical bases, that the upgrade propagation rate and upgrade (in)frequency will be sufficient that all laptops will be running the same version of the software (save for a few stragglers who go on a long trip for a few weeks), and that the vserver copy-on-write mechanism will be used to perform rollback (so that we only need to worry about the forward direction). I'm not saying that my assumptions are correct. But I feel that deciding file formats before we've come to a big picture consensus may be premature. > If you can cheaply generate at runtime (on the client) a minimal diff > between any two versions you can avoid storing unnecessary information, Not sure exactly what you're getting at here: that we transfer complete blobs over the network but store them on the XO as binary diffs? My working assumption is that network and storage costs on the XO should be minimized as much as possible. Transferring complete blobs fails on these grounds. --scott -- ( http://cscott.net/ ) _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel