Re: Extreme memory usage for gnome-panel related apps
- From: David Zeuthen <david fubar dk>
- To: Colin Walters <walters redhat com>
- Cc: "Nickolay V. Shmyrev" <nshmyrev yandex ru>, Martin Ebourne <lists ebourne me uk>, desktop-devel-list gnome org, jamie <jamiemcc blueyonder co uk>
- Subject: Re: Extreme memory usage for gnome-panel related apps
- Date: Sun, 02 Dec 2007 15:57:59 -0500
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.
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
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.
] [Thread Prev