On Tue, 31 Jul 2012 15:16:34 -0400
Rich Freeman <[email protected]> wrote:

> On Tue, Jul 31, 2012 at 10:56 AM, Ian Stakenvicius <[email protected]>
> wrote:
> >
> > Although that is true, it would be -WAY- too slow to generate said
> > list via equery/q* helpers; I think that's where the
> > extended-attributes and/or cache idea comes into play.
> 
> I agree.  This needs to be high-performance when it comes to
> individual file access.  If it takes 10 seconds per build to populate
> some database or set up a bazillion bind mounts that isn't the end of
> the world, but if it takes an extra 0.1 seconds every time a file is
> read that could add up VERY fast on a large build.

I'd be more afraid about resources, and whether the kernel will be
actually able to handle bazillion bind mounts. And if, whether it won't
actually cause more overhead than copying the whole system to some kind
of tmpfs.

> 
> Ideally I'd like to see the same thing extended to run-time, and short
> of writing some entirely new security model into the kernel or taking
> namespaces to a whole new level, part of me thinks that
> auto-generating SELinux policies might be the solution, so that the
> existing mechanism can be extended.
> 
> The mad scientist in me keeps thinking up crazy schemes so that
> package collisions can be handled by each package just seeing whatever
> it wants to see - maybe the entire filesystem looks different
> depending on what app you use.  Then I realize that bash is an
> application, and how on earth would a human make sense of a system
> where no file has any stable identifier other than maybe a
> content-hashed key.  Then that makes me wonder why we link to
> libraries by filename anyway, when we could just give each library a
> GUID and version, and maybe a more general identifier for cases where
> you have alternate implementations.
> 
> But, as long as we're still just running Gentoo on Unix-like OSes
> maybe tweaking the jail is a good place to start...
> 
> Rich
> 



-- 
Best regards,
Michał Górny

Attachment: signature.asc
Description: PGP signature

Reply via email to