Re: what's next for the linux kernel?

[David Leimbach]

ss, is gone, so is the file.
>
> > Back on topic...
> >
> > The problem with private namespaces on Linux is that they really
> > aren't so much.  mount will update /etc/mtab for all to see and even
>
> Userspace problem.-)

Sure is, which is why I think it's easier to fork a BSD to make it do
what someone wants than to roll my own linux distribution :-).  
Perhaps that's a problem of perception and not a really good
measurement of the amount of energy involved in either alternative.

Sometimes it sure seems easier to keep the userspace stuff with the kernel.

> > I think private namespaces could actually be made more-so but the rest
> > of the system has to cooperate and I doubt that I have the energy to
> > do the evangelism and requisite proofs of concept for Linux.  It's far
> > easier for me to just use Plan 9 and Inferno instead of trying to
> > assimilate Linux, even though I think I'd prefer Linux if it were more
> > like the former two.
>
> The plan is:
>
> 1) make namespaces joinable
> 2) ???
> 3) profit
>
> No, that's wrong. The plan is (should be?):
>
> 1) make namespaces joinable in a sane way
> 2) wait for the shared subtree patch
> 3) make pam join the per-user-namespace
> 4) make pam automount tmpfs on the private /tmp

I'm not sure what you mean by a joinable namespace.  I also am not
sure I want them :-).

I think of namespaces as being fundamental to the process model and
that they are inherited from the parent and new ones are created in a
sort of COW fashion [or at least have similar behavior].

You might want a session namespace instead of a joinable per-process
namespace but I think that might be a slightly different point of
view.

Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/