Re: subhurds etc.

[Sergiu Ivanov]

Hello,

On Tue, Sep 22, 2009 at 01:58:52AM +0200, olafBuddenhagen@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, olafBuddenhagen@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