Slashdot Mirror
Why Mozilla Is Committed To Using Gecko
Ars Technica has published an article about Mozilla's commitment to use the Gecko rendering engine instead of using Webkit, which was adopted by Apple and Google for use in the Safari and Chrome browsers. I have been using Chrome on my work PC and find many of its features compelling, and wonder how soon we will see its best innovations in Firefox. Why is Gecko worth keeping if it is outdated and bloated?
It's required for the XUL based interface?
Similes are like metaphors
You're confusing Firefox-the-browser with Gecko-the-renderer. There's no reason Firefox couldn't have one process per tab, and most Webkit/KHTML implementations currently use one process per browser window (like Firefox).
In short, pick something else to distinguish them. You're way off this time around.
Dewey, what part of this looks like authorities should be involved?
Webkit doesn't specify that you have to use a separate process for each page. That's a Google Chrome feature.
There is no excuse for a modern browser to not have this, especially in light of the fact that their main competitor (IE) is developing it.
Here's one excuse: complications when trying to have multiple processes render content on a single window in Mac OS X (mentioned near the end of the tab process isolation section).
It's not clear to me if this is impossible or really difficult to achieve, but I think it'll be interesting to see what Chrome does for Mac OS X.
and most Webkit/KHTML implementations currently use one process per browser window (like Firefox).
Firefox does not use one process per browser window. Firefox uses one process per user profile.
Higher Logics: where programming meets science.
I don't see why this was modded troll - it's a very accurate statement, even if it shows !Mozilla in a good light (even MS, *gasp*). I haven't used a computer with less than a gig of RAM in about five years, and a lightweight app is no good to anyone if it crashes every hour. Firefox has been relatively stable for me all things considered (except for some rogue JS at digg which I abandoned a while ago, I rarely have issues), but Chrome's approach of sandboxing tabs so they don't kill each other probably should have come around tabbed browsing 1.1.
It would be one thing if this approach bloated up Photoshop or something (as if PS wouldn't burst if it got any more bloated), but I spend ALL DAY with my browser open - dozens of tabs often spread across a couple windows. Firefox taking 400MB of my 4GB doesn't bother me considering how much of my time it gets (though since 3.0 and disabling Firebug, it's not usually near that bad), so taking a little more of my system's memory in order to significantly enhance stability is more than worth it.
Hell, even in my pre-Firefox days (actually, I think this was everyone's pre-firefox days, as I'd made the switch around the time of the old mozilla naming fights), I could almost emulate this by digging for that old setting somewhere in the bowels of explorer preference to make each IE6 window run it its own explorer.exe process. And as you might expect, the system as a whole became fantastically more stable upon doing so. IE6 was (and still is) as crash-prone as ever, but it wouldn't take out my other browser windows nor the main GUI process when one took a nosedive (the decision to make the browser and the desktop run in the same process by default has always been well outside the grasp of my understanding). In any case, that should have been a tip-off that each tab should have its own process. To be fair, that setting is so buried that I'm probably one of about five people in the world to have used it (hell if I still know where it is), but there was still an important lesson there.
How are sites slashdotted when nobody reads TFAs?
Separating the browser into one process per tab only helps for the fragmentation problem in the case of memory that is truly private to each process. It doesn't help at all in the case of memory that's shared between processes. If that shared memory is managed as a heap like malloc and free do, it can still fragment. (And it's important to point out that the shared memory doesn't need to be managed like that; a custom memory management scheme tailored precisely to the way it's used could have zero fragmentation.)
There is no way of knowing the memory and performance costs of the multi-process browser without having a lot more detail about precisely which things are private to each process, and which are shared. The comic does nothing to tell us to what Chrome is sharing and what's private to each process, nor how any shared memory is managed.
Are you adequate?
Chrome's doing JIT compilation of Javascript. In this context, separating the broswer into multiple processes protects you from bugs in the JIT compiler that produce native code that makes memory access errors.
Are you adequate?
It's not common sense. The HTML standard doesn't say, for example, how form controls are supposed to be rendered visually - that's the job for either the browser or the underlying platform.
Ditto with fonts. A 12pt font can be one size on your device/platform, and different on someone else's.
Ditto with web pages themselves - the visual rendering is specified IN THE STANDARDS as being implementation-dependent. For example, a screen reader is free to render web pages as audio instead of glyphs and images.
Read the standards. They're posted at w3c.
Then learn proper design. A good workman doesn't complain about his or her tools.
There won't be any locks
The difference of threads v.s. processes has nothing to do whether there are locks or not.
If you have a shared resource you must use locks - no matter if you use processes or threads.
I do not know about Chrome but I'd imagine it does not use shared resources (separate windows, sockets, etc.) which may or may not be a good thing (share cookies of several tabs?). Or maybe it locks only for a (provably) short time ("getGlobalCookie")?