nice paper on FireFox memory usage reduction

Christopher Browne cbbrowne-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org
Thu Jan 19 23:13:13 UTC 2012


On Wed, Jan 18, 2012 at 7:45 PM, Jamon Camisso > Maybe I'm too or
prematurely optimistic, but a few cycle of development
> that are focused on optimizing instead of just throwing more hardware at
> things would be nice.

There's a certain value in that.

This has evidently been happening with Firefox, and I suppose
something akin has happened with Chromium, including designing with a
rather different process model (somewhat more in keeping with "Unix
philosophy").

I find it a fascinating thing, when using Chromium-based browsers,
that if one misbehaving process for one window gets killed, it has the
bad habit of shutting down the processes for A Number Of Evidently
Related Windows (Google's services, I'm looking at you!).

Some efforts are going into broader kinds of alternatives (uzbl,
conkeror, luakit), that is, web browsers that:
- start new processes to open new windows
- are deeply scriptable

It's not all good
- I'm not thrilled with the usability; they have a bit too high a
learning curve.  By starting with "nothing," and forcing the user to
build their own interface, this guarantees idiosyncrasy of it all,
which doesn't thrill me.  The popularity of common add-ons for Firefox
and such demonstrates that there *are* common things that people want,
and I don't think much is won by playing against that.
- There seems to be a temptation to turn this into a single
all-singing, all-dancing process, and it seems to me they'd be *more*
onto something if they had a split of "The Browser" into
   - Browser windows
   - A bookmark and history manager, that *isn't* a web browse, but
rather a quite separate process with separate window
   - A "browser process" manager [I'm not sure exactly what it should do...]
   - A password manager
   - A cookie manager
The "Unix Way" is for these to not all be 'captive UIs,' but rather
separate processes that are useful in their own rights that do useful
things for the Other Components Of The System.

Thus, the cookie manager captures data surrounding cookies, and allows:
 a) Browser windows to ask for that data
 b) Scripted requests to do the same, and to manipulate the cookie data

Similar is true for bookmarks, passwords, etc.

Many of us know that The Unix Way to do documents is to build *roff
files, and set up a pipeline of processes (perhaps in a Makefile) to
automagically transform source into output.  That's kind of an obvious
handling of document management, that's very deeply opposite from the
All Singing All Dancing word processor.

I'd be interested in seeing something that's more of an in-between, a
more "Unixy word processor," with some of the aspects of graphical
interaction we see in the "ASAD" (All Singing, All Dancing) WPs.

But it doesn't need to tightly integrate spell checking - popping a
window to show off recommended improvements in a separate process is a
fine idea.

-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list