Re: Hiding nodes with unionmount

[Arne Babenhauserheide]

Am Montag, 3. August 2009 07:25:38 schrieb Sergiu Ivanov:
> I suppose this may work if you have the rights to write chroot/ , but,
> unfourtunately, I can't check it.  For some reason, when I try chroot
> <dir> /bin/bash , it tells me that it cannot find /bin/bash , although
> this executable definitely exists :-(

Does it also exist in the chroot? 

You need chroot/bin/bash, I think. 

> My understanding is that a sub-Hurd is something like another instance
> of Hurd running on top of the same instance of gnumach.  It seems that
> a sub-Hurd may reuse some servers from the main Hurd.  I'm not really
> expert in this area, so you will probably like to read this:
> http://www.gnu.org/software/hurd/hurd/subhurd.html .

From what I understand, a subhurd means booting a second Hurd in the current 
Hurd session, and the way to start it isn't quite userfriendly. 

As soon as the "subhurd needs root" issue is solved, it should allow every 
normal user to boot his own system. 

And it would be nice to be able to just use the same base Hurd for the main 
hurd and all subhurds - it needs a readonly mounted partition, so it might be 
possible to use the same partition for different subhurds and unionmount the 
specific files into it. 

I don't know enough about the details to be able to judge if this would really 
be possible. 

> > That would even allow me to do a "rm -rf /" which would naturally make
> > the system unusable for me (my / would be empty), but wouldn't affect
> > anyone else. My personal environment would then simply contain a notice
> > for the filterfs that it should filter out all files :)
>
> So, you store diffs between the real / and your version, right?

With a VCS yes. 

> > We could then check which file we removed, and if the underlying
> > filesystem changed, we'd be able to see the diffs and "merge" the changes
> > with our changes.
>
> So, you are talking about something like branches?  The master branch
> being the original / and each user having their own branch, right?

Jupp. It's only a strange idea, but I kinda like it :) 

We should be careful with talking about that, though: VCS filesystems have 
been ridiculed almost as efficiently as the Hurd :) 

The difference here would be that we could define fixed steps for committing, 
for example logout. 

It could even mean that the system isn't saved till logout. All changes could 
be in memory, until we logout and commit. 

If memory seems to dangerous, they could be in the (persistent) git staging 
area... I think my spider sense is tingling :) 

In Mercurial they'd be in a temporary clone (since that uses hardlinks it 
would'nt take much more space than the git staging area). 

The only problem would be that the necessary diskspace for the base system 
would be more than doubled. With todays 1TiB disks this shouldn't hurt too 
much, though. Userdata could still be in simple user-dirs (for optimization). 

> This sounds very interesting :-) I had the idea of employing git (for
> instance) in managing my ~/ , but it makes little sense.  Multi-user
> management is much more interesting :-)

:) 

I manage most of my writing projects with Mercurial, one dir per project, and 
since that's quite convenient, I think git for the home partition isn't a bad 
option either. 

It also massively simplified backups. 

And I'm thinking of moving towards subrepos to make a backup as simple as 

$ hg clone ~/ backup # initial
$ hg pull # incremental update

Just remember to exclude the Movies ;) 

> Hm...  I'm not sure a package manager could replace a VCS: what it you
> *modify* some files in /etc/ ? AFAIK, package managers are not
> interested in what the installed files contain, so I'd say that a VCS
> is required anyway.

When you modify you'd just save a snapshot which overwritees the file. 

The package manager would just supply the list of already existing files, and 
the list of files which correspond to packages the user updated. 

- me: "Hey, translator, please setup my system."
- translator: "Hey portage, which packages do you have installed?"
- portage lists packages
- translator: "And which of these packages do we already have in the base 
system; never mind the versions?" 
- portage lists packages
- translator: "give me the corresponding files, please."
- portage lists files
- translator filters out the given files and unionmounts the locally installed 
replacements. 

Since portage knows about all files it installed itself, t also knows about 
most config files. 

But maybe this would take more logic than a real VCS... 

The main advantage of using the package manager is that it doesn't double the 
required diskspace. 

> I still cannot see how a package manager can do that.  I'm setting up
> Gentoo now, and I'm reading the Portage chapter of the handbook, but
> it doesn't really help in understanding how it could track files.
> Could you please explain how it should work?

I can give you the approximate commands (requires the currently masked portage 
2.2): 

# in the base system
$ emerge -p @installed > base # gives all installed packages

# in the user-system (before _logout_)
$ emerge -p @installed > user # gives all programs of the user environment
$ diff -u base user > diff # gives all packages which differ in the user env

# get a list of packages which are different in user from those in base
$ cat diff | (some sed magic) > hidepkg  

# Get the files
for i in `cat hidepkg | xargs`; do equery files $i >> hidefiles ; done

$ (Filter all files in hidefiles from the user environment)

> I think the possibility of this is implied by design: every
> modification of a system-wide configuration file is stored as a diff
> and is not applied to the *real* file.  So you can do whatever you
> want in your environment :-)

For massively-multi-user-setups I assume that this would save damn much space 
compared to full virtualization. 

To use the package manager instead of a VCS would save space, as long as the 
size of the changed files doesn't exceed the size of the system history + the 
size of the diffs. 

size_pkg_man = base_size + all changed files
size_vcs = base_size + base_history + all diffs (user-history)

> > A firewall could for example be a translator on the network device, so it
> > would automatically be completely transparent, and an audio equalizer
> > could be a translator on /dev/dsp
>
> You are suggesting very interesting translator use-cases :-) I think
> they are pretty orthogonal with multi-user management via the mine
> translator, so one could implement these already now (well, except for
> /dev/dsp).

I'm simply dreaming - but sometimes dreams come true; just look at the huge 
free software community. 

Though... would anyone back at MIT in the birthtime of GNU have even dared to 
dream of the sheer size of todays free software community? :-)

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
              http://infinite-hands.draketo.de

signature.asc
Description: This is a digitally signed message part.