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?
Because it has a cooler name than the boring sounding WebKit. Besides, it'll save you 15% on car insurance.
McCain/Palin '08. Now THAT's hope and change!
Why is Gecko worth keeping if it is outdated and bloated?
Because it's bloated as a single app, but less bloated then opening up a new process (or more than one!) for every single web page loaded. Until every computer in use has multi-gigabyte memory, including handheld devices, there will be a need for something lighter than webkit
Variety is the spice of life. If every browser used the same engine, there'd be no competitive spirit to improve it. Besides, when was a monoculture ever a good thing?
I've been using Konqueror for my primary browser for several years now, but still respect the Mozilla group and wish them the best of luck. As long as everyone follows the standards (which the Open Source browser folks have excelled at), the more the merrier!
Dewey, what part of this looks like authorities should be involved?
Holy begging the question Batman!
Yes, I did check Wikipedia to make sure a million angry slashdotters weren't going to kill me for its usage.
This article ignores the real question: Why change? I personally see nothing 'outdated' or 'bloated' about Gecko, and there is no point in changing if Webkit provides no real advantage.
It's required for the XUL based interface?
Similes are like metaphors
Why is Gecko worth keeping if it is outdated and bloated?
You've begged the question, there. The fact is that Gecko isn't outdated and bloated. Mozilla has kept the code up-to-date. They've improved rendering and javascript performance remarkably in recent Firefox releases.
Personally, I'd rather see alternatives being independently developed and improved; all the while competing with each other for mindshare and technical superiority. The alternative, of relying on a single rendering engine for all browsers, is a bad idea. History has taught us it will lead to stagnation and quirky (rather than standards-compliant) rendering.
The whole of the Mozilla code tree is tied into a framework called XPCOM. It is a Cross-Platform reimplementation of Microsoft's COM. The XPCOM influence is extremely pervasive throughout the whole of the Mozilla/Firefox/Thunderbid/Sunbird/Gecko code trees.
WebKit would not fit in very well with the existing ecosystem because it does not tie into the XPCOM framework which is used to tie all of the Mozilla group's projects together. A lot of the potential performance benefits of moving to WebKit would be lost because of all the bridging between WebKit and XPCOM that would be required.
-- There are three kinds of mathematicians: those who can add and those who can't.
Sorry, chrome is cute, but until someone implements adblock and flashblock plugins for it, it stays idle.
The Mozilla crew are still pissed at David Hyatt for choosing Konqueror over Gecko as "the best open source rendering engine available" when he defected from Mozilla to Apple.
That's why they will never consider WebKit. Too much pride.
cat
He's going from talking about rendering engine (webkit/gecko) to talking about how great the features are in Chrome (not the rendering engine, the browser). Then back to rendering engine (gecko). What exactly is your topic?
Just a hunch, but the writer doesnt sound intelligent enough to know the features of a rendering engine.
Recently, I'm seeing some indirect evidence of memory corruption in FF. After a while it fails to download images or connect to the network, for example. You restart the process and it all works like buttah again. Heck, Internet Explorer is more stable than this.
I guess fixing hard to repro bugs is far less glorious a job than bolting on a new JS interpreter (even though the old one was OK to begin with) or tweaking the UI.
While it is certainly true that the mozilla codebase has a rather sordid past, its trajectory has been extremely encouraging(particularly given that it essentially includes its own cross platform widget set, used by mozilla apps and a few others). Javascript performance is competitive with the best, memory performance has steadily improved, and rendering support is quite credible.
I can understand why a third party, starting a project from scratch, might be disinclined to use Gecko; but Gecko seems to be very much on the worthwhile side of the "improve vs. scrap" question.
First of all, WebKit itself doesn't impose the multi-process model that Google's Chrome uses. For example, Safari uses WebKit, and it runs as a single process.
With that cleared up, now, here's the more important flawed assumption in your post: that having the broswer use n processes to display n pages will require n times as much memory as doing it all with n threads in one process. That's far from true, because such a browser can be architected so that the processes use shared memory for all shared resources and state.
The multi-process architecture will carry additional memory overhead, but done correctly, it will scale up much better than linearly. The real costs are the costs of process creation and switching in the OS, plus the costs of the inter-process communication method. Using shared memory for the latter is cheap, but it can potentially make one process bring down the others, defeating the purpose of isolating each page into a process; it's a balancing act, and the memory overhead really depends on what tradeoffs one picks here.
Are you adequate?
Actually, I take that back. The only real overhead is the OS overhead for separate processes.
The architectural choice of what memory contents should be shared between processes and which should be private aren't specific to the multi-process architecture. The same choices and tradeoffs exist in a multi-threaded application; you can choose between having each thread have its own copy of some piece of memory (uses more memory, but isolates each thread from the others), or have all the threads share it (uses less memory, but access must be synchronized, and any bugs involving that shared memory may make one thread bring others down).
Are you adequate?
Please do not take this negatively:
Ya know what I'd like to see? Standards revision.
And yet, they do revise them by working on and ratifying a new version.
It's great to tote out "standards compliance" as the holy grail, but the problem is that there are plenty of things that the standard just does not define.. and those things get discovered by web developers who work around the issues and it never gets back to the standards drafters.
That sounds nice, but you're advocating a moving target. Standards or recommendations would never be finished.
Now there's the link tag but it's optional.. yeah, that's right, the standard says that a browser can optionally implement the tag.. what kind of standard is that anyway? So no-one used it. Instead, they use the img tag and set the width and height of the image to 0.. unfortunately, the standard never said "if the width of the image is zero, thou shalt not render anything."
Just because *you* want it, doesn't mean others do.
Unfortunately even a lot of stuff that is in the acid test never makes it back to the standard, so browser developers have to reverse engineer the Acid test!
I'm guessing you're a web developer. Therefore, you or your company have a demonstrated interest in the recommendations, which means you can sign up and be a member of the committees and advocate your changes and proposals for the next version of the recommendation.
I hope this helps a bit to further your understanding of the process.
https://wiki.mozilla.org/Gecko:DeCOMtamination
Nerd rage is the funniest rage.
Google has Android. Apple isn't putting Chrome on the iPhone. End of discussion.
http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
Speak for yourself, I am a "web developer" (I fail to see how "programmer" doesn't suffice) and I prefer democratic control of software (software freedom) and letting a thousand flowers bloom. Software freedom can be messy but we're better off having that messiness than allowing any one implementation of something to dictate how things work.
Digital Citizen
IE has had the same rendering engine, Trident, since IE4 (1997). MS may claim significant improvements in standards support, but in reality, they seem to only pick the bugs that have names. After five publicly available iterations (up to IE7), why is their overall standards support at least 25% below, on a feature by feature basis, nearly every other rendering engine?
Plus, I have yet to hear anything to rebut the rumors that MS simply can't fix Trident because the code is such a mess, and they "don't want to break websites", which is one of the most backwards arguments for anything on any topic.
Gecko is what they developed.
This is like having an article on Redhat's commitment to the Linux kernel.
As if they could just arbitrary change their flagship product to use the BSD kernel instead.
Or like discussing Microsoft's commitment to the Windows platform.
Just because unix/Linux-based kernels and software are becoming more popular in some circles does not mean that it is conceivable for M$ to drop the Windows kernel in favor of a *IX one.
If Gecko in Mozilla dies it will be because they have developed a better Gecko, or because Mozilla as a whole has died.
for getting the kinks ironed out before they hit the rest of us!
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?
Why is WebKit worth switching to when Chrome had five vulnerabilities in two days?
2008-09-05: http://milw0rm.com/exploits/6367
2008-09-05: http://milw0rm.com/exploits/6386
2008-09-05: http://milw0rm.com/exploits/6372
2008-09-04: http://milw0rm.com/exploits/6365
2008-09-03: http://milw0rm.com/exploits/6355
2008-09-03: http://milw0rm.com/exploits/6353
WebKit isn't touching my machine, thank you very much. Might throw Bunny(the fuzzer) at the codebase, though.
www.isoHunt.com
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?
I never heard of Amica until a friend got rear ended by one of their customers.
Well that's a novel marketing approach...
Seriously, though, perhaps they save money by not blanketing the airwaves with commercials.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
1. Threads are Hard
2. Threads are not magic bullets
3. Threads introduce WHOLE NEW CLASSES of bugs
Threading is only as hard as a bad design makes them. If you have to share data among threads so much that you have to put locks all over the place, that's really a tell-tale sign that the design isn't all that good to begin with. Really, the best threaded designs are almost like lightweight processes to begin with. Keep the number of points where data must be shared across execution chains low, and everything tends to fall into place.
This is my sig.
The downside is that processes are a lot heavier than threads.
How much heavier are they? Off the top of my head, the big internal advantage of threads is that they share the same page tables whereas separate processes have their own... but, each thread is still going to have its own stack and its own state block for when its task gets switched out.
Correct my own stone age knowledge of the Linux kernel, but, aren't threads and processes practically the same thing internally anyway?
This is my sig.
I have an old 12" powerbook with 384 MB of RAM. It started gathering dust when I got a much larger laptop for work, since modern ajax-and-flash-heavy websites were really crawling with so little memory, and that's using both Firefox 2 and Safari. When Firefox 3 came out, I heard how much lighter it was, so I gave it a try. Lo and behold, my old laptop had new life! Safari still feels a little snappier when I only have one tab open, but that's a fleetingly rare condition. Gecko isn't just the technology we have right now, it's the vibrant developer community hard at work making it better. WebKit has less ambitious aims, and achieves them well, but Mozilla would be throwing the baby out with the bathwater if they told everyone to forget Gecko and learn how to do that same optimization work on WebKit.
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
Haven't done much multi-threaded programming, have you?
Say, one thread locks a mutex and hangs.
Whoops! Now all the other threads that want that mutex will wait forever!
I kind of agree with you, but...
The whole point was that generally, these separate tabs will have very little need to interact. Your example of a global mutex brings up the question, of why you would have them all after a global mutex anyway instead of pretty much keeping to themselves.
Obviously something like a memory error or a few other things can bring the whole thing down by bringing down the main process all the threads are a part of. But contention as you raise the issue seems to be less likely than it would be in other kinds of multi-threaded apps where the threads have to communicate or otherwise work in unison with other threads, or at least more manageable and confined to already centralized things like browser settings.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Maybe you're a really good coder and can handle all the issues related to threading.
However the browser you write won't just be running your own code. It will be running code written by Adobe, Facebook 3rd party apps, and so on.
Given that, it's wiser to design your browser to use processes, so if you or somebody else screws up, the offending tab can be killed without affecting the other tabs, and also the memory used gets freed up (this is quite important given the large amounts of memory a tab can use nowadays).
You could in theory have your browser threaded, but use processes for the plugins, javascript and future junk^H^H^H^Hfeatures the W3C comes up with, but at that point how much do you really gain?
Why do you think Microsoft sees Google as the enemy? They are right. Google have just launched a new "operating system".
It's wise for Google's "operating system" aka browser to have process isolation, so that it is harder for one misbehaving instance to take down the rest.
Cooperative multitasking is so 1980s.
IE8 has a new rendering engine. Trident is also included for the compatibility mode. Tim
"Actually, that is far and away the best reason to not mess with it. The user experience is paramount, and when you mess with that, you have failed."
Here is news for you: Every use of a browser has two users - one providing the content, one recieving it. MSIE has constantly failed the first half until IE8.
I guess you missed the second page in the article http://arstechnica.com/articles/paedia/mozilla-committed-to-gecko.ars/2 where they explain why Gecko is worth keeping and where they also explain that it isn't as outdated and bloated as it felt before FireFox 3 ;)
Chrome is all new and bright and shiny, Firefox has some (plenty?) memory leaks, and all of a sudden we go from comparing browsers to making sweeping statements over their respective rendering engines? Why?
How is a rendering engine that scores 85% on ACID3 "outdated"? Why should Mozilla drop a codebase that is quite successful in the marketplace, and that they know intimately and have full control over in favour of one they don't know all that well and is controlled by Apple, just because it's (arguably) king of the hill right now?
Frankly, the summary is a troll -- and the article feels like little more than a jab at free clicks.
Could someone name some of these innovations?
One process per tab? IE8 did that before Chrome.
V8? Both Apple and Mozilla did those things before Chrome was announced.
Showing your favourite sites when opening a new tab? That's Opera's Speed Dial, except automatic and potentially constantly shuffling around, working against muscle memory.
Creating "standalone" applications from web pages? Mozilla and Apple were already doing that.
Incognito mode? IE8 again.
So what are these innovations?
Because in other programming languages, NULL pointers can be caught as exceptions, and the thread can be gracefully terminated.
Michael, I can only use my popup blocker once per episode...
Chrome's innovations are mostly in the JavaScript engine and the process-per-tab architecture, neither of which have much to do with the rendering engine: Gecko v. WebKit is mostly a peripheral issue.