Hello, On Tue, Sep 22, 2009 at 01:58:52AM +0200, olafbuddenha...@gmx.net wrote: > 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.
I see. I've always thought that sub-hurds worked in this way right now :-( Is it very hard to make things work like this, or is it the lack of developer time that hinders sub-hurds from being this flexible? > > > 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.) Aha, that's clear. > 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.) I'd like to have a snapshotting filesystem at my box, because having experienced the possibility to roll anything back in git, I'd be happy to be able to do so with the non-git-managed files :-) Regards, scolobb
