System update spec proposal

Ivan Krstić krstic at
Tue Jun 26 14:58:47 EDT 2007

On Jun 26, 2007, at 2:21 PM, Christopher Blizzard wrote:.  Also
> I would have appreciated it if you had given direct feedback to Alex
> instead of just dropping your own proposal from space.  It's a crappy
> thing to do.

Let's not make this about approach on a public mailing list, please.

> 1. There's a lot in here about vserver + updates and all of that is
> fine.

There's terribly *little* in there about VServer. The COW mechanism  
simply provides a convenient method to enforce containment of a  
process that's about to go and do as it pleases to your OS files. If  
you have a simpler way to do it, who cares about VServer?

> 2. Because you have to use lots random
> exceptions during its execution and once it starts you can't really
> control what it does. problems at hand rather than seeing the  
> hammer we have on the shelf and
> thinking that it's obviously the right solution.

I'm sure there's a technical argument somewhere between the hand- 
waving and the gratuitous hammer metaphors? The COW image gives rsync  
its own little playground. If rsync then doesn't do *exactly* what  
you expect it to do, to the bit, you've hit an error condition. And  
rsync is pretty good about doing what it's told these days.

> 3. Still requires a server and doesn't let you
> propagate changes out to servers as easily as his code does.

It requires a server because I think it's outrageous to consider  
spending engineering time on inventing secure peer-to-peer OS  
upgrades, never before done in a mainstream system, over a network  
stack never before used in a mainstream system, two months before we  

> Basically aside from the vserver bits, which no one has seen, I don't
> see a particular advantage to using rsync.

I'll ignore the meaningless VServer jab and point out that rsync  
exists, is used in production all the time, is a known quantity, and  
is a way to get this implemented *now*. We can play with Rube  
Goldberg-style updates later.

Ivan Krstić <krstic at> | GPG: 0x147C722D

More information about the Devel mailing list