Hi, On Tue, Aug 18, 2009 at 09:46:23AM +0300, Sergiu Ivanov wrote: > On Mon, Aug 17, 2009 at 01:59:49AM +0200, olafbuddenha...@gmx.net > wrote:
> > It's much more interesting to have a partially customized > > environment *without* booting a complete extra system instance; but > > rather accessing the main system for most stuff. That's what I'm > > calling "light-weight subhurd-like environments" -- but it's all > > very vague, as many of my ideas :-( > > Are you talking about reusing other base system services besides > terminal and root store? Yes. Reusing most of the original system environment, and only replacing specific bits you are interested in. > > Note that while true version controlling filesystems are rather > > unpopular, snapshotting filesystems (ZFS, Btrfs) are quickly > > becoming standard. > > > > The difference is that snapshotting is done explicitely at certain > > points of time, rather than implicitely on certain events. > > Hm, are git commits really different from snapshots? No, you could use git as a snapshotting mechanism of course. (Except that it doesn't save enough metadata out of the box, and that it doesn't have a mechanism to make an atomic snapshot of a changing filesystem... So you'd need additional mechanisms anyways.) But that's really orthogonal. I'm talking about the decision *when* to snapshot. Traditional versioning filesystems tried to record individual file changes. That might actually have worked in VMS (I don't know enough about it to tell); but on POSIX systems, that's not really possible to do properly, as POSIX lacks a notion of atomic changes -- you don't really know when to commit. Also, this can generate a lot of version on certain operations -- which is hard to manage, and could cause serious efficiency issues with large files... All in all, this approach is just not practical, except perhaps in very specific use cases. The snapshotting filesystems we are seeing now OTOH avoid all this, by not trying to track individual changes, but rather only creating snaphots of the current state on explicit request. (With manual triggering, or timers, or whatever.) -antrik-
