Re: Extreme memory usage for gnome-panel related apps

[David Zeuthen <david fubar dk>]

On Sun, 2007-12-02 at 15:51 -0500, Colin Walters wrote:
> On Sun, 2007-12-02 at 15:39 -0500, David Zeuthen wrote:
> > On Sun, 2007-12-02 at 14:37 -0500, Colin Walters wrote:
> > > And more generally, to have one VM per language type, rather than per
> > > app.
> > 
> > There's a lot of security models that break down if everything is tied
> > to a single process. 
> 
> I'm not sure why people are going from "Unify a few Python programs into
> one VM" into "We must only have 3 processes total!".
> 
> If some application was security sensitive, we could keep it separate.  

That's a fine goal but not really how I (and apparently others) read
your original message. 

(FWIW, personally, I'd like to see all of our service daemons (g-p-m,
g-v-m, pk-update-client, etc.) all sharing the same process space.
Things like that.)

> But fundamentally right now the desktop is still one security domain,
> and I don't see that changing in the near future.

http://lists.freedesktop.org/archives/xorg/2007-November/030631.html

That said, it's probably a few years out before things like password
dialogs a) cannot be poked by e.g. the browser; b) can be poked by the
a11y tools. Bunch of other use cases too (browser, email in confined
domains). But it's something that is badly needed and XACE-SELinux
brings us one step closer.

> > Not to mention a bunch of other problems. It's
> > probably better to just fix the VM's.
> 
> Far harder - and I think it would likely require language semantics to
> change, in particular for Python.
> 
> Having one VM for Python applets would not be rocket science.  Someone
> just needs to spend the few days on it, and get patches to use it
> upstreamed.

Sure, but keep in mind what you're suggesting is a stop-gap fix that
will hide the real problems (per-process overhead), introduce weird and
hard to fix bugs. You know what happens to stop-gap fixes? They become
mainstream and people will never fix the real problem... 

Funny enough, it's also sometimes easier to fix root problems than to
introduce a bunch of stop-gap fixes.

     David