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.
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?
https://wiki.mozilla.org/Gecko:DeCOMtamination
Nerd rage is the funniest rage.
That's why they will never consider WebKit. Too much pride.
Not because the enormous investment in XUL - including the wealth of third party themes / extensions / etc?
Webkit & Gecko have different goals & strengths. It would be impractical for firefox to switch. This a pragmatic decision & nothing to do with pride.
There are shills on slashdot. Apparently, I'm one of them.
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.
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?
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.
Reading those it is not apparent to me that they are due to WebKit issues. Are they?
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.
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.
"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.
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.