"Stateless Linux" project

[Havoc Pennington]

On Tue, 2004-09-14 at 18:08 -0400, Steve Coleman wrote:
> The remote on-again-off-again network distributed file system is exactly 
> what CODA is designed for. And it handles laptops in disconnected mode, 
> caches files,  and merges changes back in on reconnect. Lots of good 
> stuff in there, and many lessons learned. You may find slight 
> differences in your requirements but it deserves a close look because it 
> addresses most of the problems I have read about in this thread so far.
> 

Right, the .pdf mentions Coda (and also more generally the idea of using
a filesystem). The major downside of a filesystem approach is that
filesystems are hard, and in the kernel, and supporting another one
isn't trivial. The upside is that you can do some clever things on the
filesystem level that are tricky with rsync-type userspace hacks, even
rsync-type userspace hacks assisted by LVM.

One of the points of the broad term "stateless Linux" though is to
emphasize that our instantiation mode (whether Coda, NFS, AFS, rsync,
live CD, or whatever) is only one tunable element of the architecture;
the other elements should remain constant as you tune this element.

Of course, we'll want to recommend some specific filesystem or other
approach or approaches, I'm not saying we just make it configurable and
forget the problem. What I'm saying is that it's important to keep the
design of the overall system one level "higher" than how the bits end up
on the CPU that execs them.

One thing some of us would like to avoid is two-way sync (merge), since
it seems to be impossible to put a reasonable UI on it no matter how
cool your underlying technology, and seems to crank up the complexity of
the underlying technology in a big way. If instead we do one-way sync
(aka backup) with a very clear and simple user model, it's about as good
for the typical desktop user. Of course, nothing in the architecture
keeps you from using two-way sync, this is just a matter of what to work
on first.

Havoc