Why Mozilla Is Committed To Using Gecko 632
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?
lite (Score:5, Insightful)
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
Heterogeny (Score:5, Insightful)
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!
The real question is ignored here... (Score:3, Insightful)
Woah... (Score:5, Insightful)
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.
Re:The real question is ignored here... (Score:5, Insightful)
No chrome until adblock and flashblock (Score:2, Insightful)
It's NIH (Score:3, Insightful)
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.
What is the writer talking about? (Score:3, Insightful)
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.
Makes me wonder, too (Score:3, Insightful)
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.
Not really a serious question. (Score:5, Insightful)
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.
Um, are you sure of that? (Score:5, Insightful)
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.
Re:Woah... (Score:3, Insightful)
Remember when IE was the de facto standard? Remember how it stagnated and we were stuck with IE6 brokenness for years until Firefox came along and kicked their ass in gear? That's why we need competition. Having one single dominating platform will result in stagnation.
Re:lite (Score:5, Insightful)
Maybe I'm missing something, but it doesn't seem incredibly shameful to me.
Amendment (Score:5, Insightful)
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).
Re:Heterogeny (Score:5, Insightful)
Re:Woah... (Score:5, Insightful)
Re:Heterogeny (Score:1, Insightful)
You do know the standards allow you to render things in slightly different ways, don't you?
What you say is true, but more or less meaningless. The fact that the standards allow this mean that the standards suck, not that the behavior is ok.
If you need pixel-perfect rendering, the web isn't the right medium. It's not designed for that.
Maybe it wasn't designed for that at the beginning, but it needs that now, and we should adjust how we address it accordingly.
Re:Woah... (Score:4, Insightful)
Re:lite (Score:1, Insightful)
Because Gecko is actually less outdated than Webkit. When Webkit can run extensions/plugins without crashing, then may be -- then Webkit could be a serious contender.
Re:Heterogeny (Score:3, Insightful)
Gecko just had a major two-year-plus makeover, and it still isn't as good as Webkit. One could argue that Webkit of two years ago stacks up reasonably well with Gecko of today.
Mozilla spent so much time on rendering engine refactoring, and they want to focus on stabilizing 3, and then moving to Firefox 4.
Moving to a new rendering engine might seem daunting. I don't see Mozilla approaching the project themselves.
There is a new QT branch of Firefox, but even that isn't a proper QT branch. It uses QT widgets, but QT is integrated with Webkit, provides its own JS implementation, etc. I'd love to see an outside team fully develop a QT/Webkit/Xulrunner fork of Firefox that allows me to use Firefox extensions on top of a Webkit rendering engine.
Re:Heterogeny (Score:5, Insightful)
Re:lite (Score:2, Insightful)
Really? You think threaded tabs bring stability to the browser. WHAT? How the HELL do you figure that?
Re:Why did Google Choose webkit! (Score:3, Insightful)
Google has Android. Apple isn't putting Chrome on the iPhone. End of discussion.
Re:It's NIH (Score:4, Insightful)
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.
Re:Heterogeny (Score:4, Insightful)
Re:lite (Score:5, Insightful)
IE 8 actually a process-per-tab (almost) model, like Chrome does. The logic of how to split tabs and stuff into different processes is different, but the general idea is the same. One thing Chrome does that IE doesn't, as far as I know, is that Chrome runs plugins like Flash in a separate process, while IE still keeps them in the tab's process.
The threads vs process distinction is very important, actually. Processes each get their own address space, while threads share an address space. This means processes can't write to each other's memory (except through things like shared memory segments), whereas threads can trample all over the other threads. A thread per tab model does protect you from a rogue Javascript freezing the browser's UI, but it doesn't protect you from a poorly written plugin that does something stupid like dereference a NULL pointer. If you really want reliability, you want processes instead. The downside is that processes are a lot heavier than threads.
Re:lite (Score:5, Insightful)
... unless there's thread contention, or memory corruption, or a deadlock, or they use a non-thread-safe library with a global lock, or one thread has to handle a signal, or there's a segfault, or....
Re:Heterogeny (Score:1, Insightful)
He was trying to make the point that webkit-using browsers can be better(Chrome) OR worse(Safari) than the Gecko-using Firefox browser.
Re:lite (Score:5, Insightful)
> How is that hard to see? It's not exactly a great insight.
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!
How's THAT for great insight?
Repeat after me:
1. Threads are Hard
2. Threads are not magic bullets
3. Threads introduce WHOLE NEW CLASSES of bugs
Re:Gecko is not outdated or bloated. (Score:5, Insightful)
IE has had the same rendering engine, Trident [wikipedia.org], 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 [webdevout.net], 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.
Re:Heterogeny (Score:5, Insightful)
As a current web developer, I develop with KHTML. When I like it, I verify that it looks the same under Gecko (and it always does). If it's a major change, I'll check it under MSIE and screw around with the CSS until IE manages to display it without barfing. I don't bother testing with Opera anymore because I've never once seen it fail on a valid page that renders under KHTML - it's just kind of assumed that it will work.
So with all the HTML engines out there, you only have to test two camps: MSIE and everything else. Adding another standards-compliant engine wouldn't increase my workload one iota.
Re:lite (Score:5, Insightful)
Re:Heterogeny (Score:3, Insightful)
When I wear my web designer hat, I can almost agree with you. The various browsers can be pretty frustrating.
As a web USER, I couldn't disagree with you more. I like being able to bump up my font size. For the most part, what you are describing sounds like those sites that take a big flash file and put an html wrapper around it. I HATE those sites, but if you need pixel perfect - go for it.
Mozilla IS Gecko (Score:4, Insightful)
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.
Re:lite (Score:5, Insightful)
that's not an argument for having a memory-hogging web browser.
yes, CPU clock speeds are going up, and memory prices are going down, but a web browser should still be a relatively lightweight application by itself.
there are much better uses for the increase in standard memory size in desktop computers. with computers as advanced as they are today, i should be able to have a web browser running in the background while i'm working in Photoshop, Illustrator, or other memory-intensive applications. even if you're not multi-tasking, the extra memory should go towards opening more tabs, running java applets, rendering flash applications, or streaming media.
there seems to be a negative trend of basic office applications becoming increasingly resource-intensive at a pace that negates simultaneous increases in computer processing power. that's not technological progress, that's just inefficient software development.
there's no reason that an office secretary should require a dual-core CPU and 2 GB of RAM when all she really needs to use her computer for is checking e-mail, word processing, web browsing, and possibly edit spreadsheets or run slide show presentations like PowerPoint.
i mean, what good is increased CPU efficiency and cheaper memory when all of that is offset by increased hardware requirements for basic software applications? with the current energy-crisis, we ought to consider whether or not the average person should need to keep pace with Moore's law for simple computing tasks like web surfing or word processing. given the huge strides made in CPU efficiency, a modern web browser should be lean enough in its most basic configuration to be capable of running on a modern low-power PC.
it doesn't make sense to constantly upgrade one's computer just so all applications run just as slow as they did before.
And God bless them (Score:3, Insightful)
for getting the kinks ironed out before they hit the rest of us!
Re:lite (Score:4, Insightful)
...it's trivial to figure that out. Let me explain it to you: you have tab A, and tab B. If tab A and B share the same thread, they will hang each other if one of them hangs. By putting them in separate threads, tab A and B can hang, but not affect each other.
How is that hard to see? It's not exactly a great insight.
Wrong, a misbehaving Thread can and will hang the entire process. If anything Threads will INCREASE the chance of hanging the entire browser, because correct Thread programming is HARD!
Re:lite (Score:5, Insightful)
Why? Is it really that big of a deal? Don't open a tab that's going to lock up your browser.
Oh that's why all those links were labeled "will crash your browser if clicked"! It makes so much more sense now. I kept expecting my browser to fail gracefully and continue operating and didn't realize I just wasn't supposed to click all those links listed as such.
In other news I would like everybody to stop running executables which crash. The OS shouldn't need to keep them isolated since you shouldn't be running applications which crash in the first place. /sarcasm
You must be a gymnast because you really had to bend over backwards pretty far to justify yourself.
Re:lite (Score:5, Insightful)
yes, CPU clock speeds are going up, and memory prices are going down, but a web browser should still be a relatively lightweight application by itself.
Why? I spend more time in the web browser--by far--than any other application. Email? 10 years ago I used a standalone email app, now I mostly use webmail. 5 years ago I used AIM. Now I use web chat. Picasa? Google documents? Between javascript advances, DOM, rich media, plugins, TABS, etc etc etc, today's browser does things not even imaged in 10 years ago.
Chrome's very purpose is to make the browser a more generalized application development platform. Heck, WEBKIT is used in the same way (and XUL, etc for Firefox). The web browser ain't just for HTML circa '97 anymore. The web browser is probably the single most important application for most users.
there seems to be a negative trend of basic office applications becoming increasingly resource-intensive at a pace that negates simultaneous increases in computer processing power. that's not technological progress, that's just inefficient software development.
Exactly right. MS Office is a great example of this. The average user utilizes a very small percent of the functionality of Office, and yet everyone suffers the bloat. Can you honestly say that most people don't get anything out of a more rich browsing experience?
Re:Browser is not just for HTML (Score:1, Insightful)
I think HTML need to compete with other formats, especially un-structural markups.
It is time to explore a un-structural markups, hopefully a standarized process will start soon. Structural markups is very expensive and incomplete. There are many cases which can not handle well, for example, it never handle footnotes nicely.
Excuse me, but -- what? Do you even understand what the term "structured" means?
Also, just because HTML doesn't have a convenient method for handling footnotes doesn't mean that it's a failure of structured markups in general. For example, see LaTeX.
Re:lite (Score:3, Insightful)
The only word that suffices to describe Firefox's lack of threaded tabs is "shameful". There is no excuse for a modern browser to not have this,
You do know that there are not currently any stable browsers with threaded tabs, don't you? There are exactly two browsers attempting this that are both in early betas. You speak as if it's been common for years and Fx is way behind the game.
Re:Heterogeny (Score:1, Insightful)
Sorry if designing for the web is a hard job, but the notion that the web should get easier for everyone to use (because we don't have to adjust to any differences in different browsers) is only appealing to everyone.
Your concern is touching, but I'm not a web developer. Also, fixed that for you.
Re:Heterogeny (Score:3, Insightful)
Yeah, except requiring things to be rendered the same way all the time isn't "harming functionality", it's common sense. In fact, where exactly does one get off saying that you have a "standard" if there's any room for interpretation at all?
A screen reader for the blind has to interpret standards compliant HTML differently to a visual web browser. The point of allowing clients to interpret the standards differently is that they can present the content in the way most suitable to the user, not the designer. We, the users, are more important than you, the designers.
Re:Heterogeny (Score:3, Insightful)
If you want guaranteed pixel-perfect control, use images. HTML allows you that much.
Re:lite (Score:5, Insightful)
Given infinite resources to code and debug applications, that may be the case.
On the other hand, given realistic design specifications, given the current level of compilers and code verification, the advantage to spawning new threads all the time for processes that aren't super I/O intensive is quite often far overshadowed by the complexity introduced by doing that.
Obviously, it's a design decision, but threaded tabs simply put more onus on the developers to sit around troubleshooting race conditions and inter-thread communications, rather than actually focusing on user-oriented features and performance enhancements.
6 in one, half dozen in the other.
But you don't do yourself any service by dogmatically insisting on it, like it's a magic bullet.
You sig is funny btw
But I want to eat cookies all the time! I want to do it!!.
Yes... and threads too. :-)
Re:Heterogeny (Score:3, Insightful)
The idea that we can create a standard that makes a page work both functionally and prettily on both an iPhone and a quad-core machine with a 30 inch display is just stupid.
Layouts must be open to change. The disparity between iPhone and 30 inch display is impassable next to the disparity between even IE5 and Webkit.
Re:Heterogeny (Score:5, Insightful)
Re:Heterogeny (Score:4, Insightful)
I'm a (former) web developer, not a designer. The only way to achieve pixel-perfect rendering is if your entire page is one big image. Can you make sure every line of text wraps at the same point on every browser on every platform with every combination of installed fonts and user-selected options? I'd be amused to see you try.
The most effective way I've found to design sites is for me to sit down with a designer, have them sketch and me point out what should stretch, what will change on different browsers, what they can control and most importantly what they can't control. After a few iterations of this with a designer they're generally pretty good at designing flexible layouts which look good, comply with standards and degrade properly. Designs which work on small and large screens. Designs which still look OK with images turned off. Designs which work if the user turns off CSS. Designs which work when a visually impaired person makes the fonts 4x the size or uses their audio browser. The better ones "get it" and relish the challenge and often go on to become highly competent at HTML and CSS so they can do all the front-end work themselves.
I was amazed how many still (this was a couple of years ago, but the web was a decade old by then) didn't know this stuff, they just worked in Photoshop and handed off designs to be coded up, expecting it to always look exactly they way their PSD did. Perhaps things have improved drastically in the past couple of years and the majority of web designers have added a text editor to their armoury, but judging by many of the sites I see that still hasn't happened.
Re:Mozilla IS Gecko (Score:2, Insightful)
Microsoft *has* replaced the windows kernel.
You don't seriously think Vista's running on anything remotely similar to Windows 95's kernel, do you?
Re:The real question is ignored here... (Score:2, Insightful)
Chrome is crap because it has many bugs and it lacks features. Take a look at Chrome roadmap. Wait, I can't find an official one. Suffice it to say, Google made a statement that they plan to add support for extensions. Obviously the Chrome browser is not feature complete -- not even close. So how can it be not crap? I don't know about you, but I always, always use Firefox extensions and cannot live without them. Right now I have 11 extensions loaded and I use 10 of them all the time. I sometimes use greasemonkey and sometimes I don't. I like having it there just in case any web site gives me crap I don't want to deal with.
Secondly, Chrome has bugs. Many of them. It crashes often. The fact that you have independent tabs is NO EXCUSE. Those separate processes are meant to protect you from Javascript crashes that bad website programmers subject you to and not from Chrome internal bugs.
Chrome uses more RAM than Firefox.
Firefox is a real, honest to God product. It's available right now and it works 100%. I have no complaints about it as a user and a few niggles as a developer. Chrome is basically vapor. It's a prototype of what may shape up to be a decent browser. The amount of work Chrome devs have ahead of them is staggering. It's not something they'll finish in a few months!
It's completely unfair to compare a polished, feature-complete product, with a buggy prototype.
Gecko will get 100/100 on Acid 3 in due time, I am sure of it. Gecko has always had excellent standards compliance. Just because Webkit got ACID 3 test pass first doesn't mean a hell of a lot. It means something when you rub Microsoft's nose into it, because Microsoft has no intention of ever complying with standards (due to business reasons). But Gecko is not Microsoft. It will do ACID 3, I am sure of it, and if not, there will be a damn good explanation (like maybe the standard committee saying that ACID 3 is not a good representation of standard compliance, or some such...) why not (unlike with Microsoft which basically says "f-u" as its sole reason).
So the published Gecko software performs better on ACID according to you than the published Chrome software. So you are really stretching all credulity by comparing this prototype and wishful thinking with a solid product.
Re:Woah... (Score:4, Insightful)
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?
One that makes sense?
Out of curiosity -- when was the last time you used lynx? Or links2? Or w3m? Browsers don't even have to implement images at all.
Seems to me, about the best they can do is define what the behavior should be when implemented. So, I'd suggest just using the link tag -- it's not like your page will break if it's not implemented, it'll just be slightly slower.
And I've found that prefetching images isn't useful, most of the time. Let the browser cache do its job.
Thankfully the interest in Acid tests has taken on this role. 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!
Aren't the Acid tests documented?
Sure, it's easier if you only have to read the standards, but if you're just looking for a higher Acid test score, that seems like the obvious solution.
Re:lite (Score:3, Insightful)
i understand that the web has evolved quite a bit over the years--trust me, i know.
but when you discuss the relative importance of the browser compared to other applications, you still need to look at things in context:
one of the main benefits of the web as an application platform is that you can start accomplishing previous desktop computing tasks using a thin client. why is that? because with software as a service, all of the data processing is done server-side. all your browser needs to do is render the presentation, everything else is run on the web server.
but you're absolutely right, even web UIs have become much more involved; today's web apps/interfaces are a lot more interactive, and significantly more responsive. some of this is due to increased capabilities/complexity of the desktop browser. however, much of this is also because the actual content to be rendered by the browser's layout engine is much more complex and resource-intensive.
it's like watching a QuickTime video in your browser, or playing a Flash game. the actual content is much more resource intensive, just as a Web 2.0 interface with lots of div layers, images, event-tracking, JavaScript libraries, and not to mention all the CSS style rules that are loaded with each site. but these are resource requirements in addition to the actual browser application. if a browser with a single blank page loaded eats up 1 GB of memory, then how is it going to deal with 10-15 tabs, each loaded with rich web content.
i've also become quite dependent on a lot of Firefox extensions that help me check my mail and even develop/debug web applications. but these are all superstructures that are loaded on top of the basic browser application. my Firefox installation takes significantly longer to load than a standard installation. if Firefox were to become more of a resource hog, then how would i even run these plugins that i use daily?
Re:lite (Score:0, Insightful)
Haven't done any multi-anything, have you?
Say one process uses a posix semaphore and hangs.
Whoops! Now all the other processes that want that sem will wait forever!
How's that for a great insight?
Bottom line: multiprocessed and multithreaded programming are strictly equivalent. The only difference is that one will make you jump through hoops to share stuff. That forces you to think twice about what should be shared and how, which is cool. It also adds an entire class of issues. Picking one over the other isn't a feature. It's an implementation detail.
And while I appreciate Google's ingenuity in admitting that bugs always happen, what I want, as a user, is a browser that does not die. At all. Ever. I've had Camino and Safari running since I came back from holidays, 3 weeks ago, and they haven't. Which is more that can be said for the PR-full, albeit beta, "multiprocessed" chrome I've seen at work (I run Linux myself).
Re:Heterogeny (Score:3, Insightful)
I assumed you were a web designer rather than web developer, but either way I was wrong. I think I get what you're saying now though. You want what you would see if you borrowed my computer to be consistent with what you see when you use your computer. Sorry, but my needs are not consistent with your needs and our experiences shouldn't be consistent either. If you want a consistent experience, you can have it - just don't change things at your end. Demanding that your experience be consistent with mine simply for the sake of consistency, which is what your desires amount to, is wholly unreasonable.
Incidentally, if you want to strongly emphasise something, the correct tag is <strong> (which means "strongly emphasise this", typically rendered as bold in graphical browser, but will be emphasised by audio readers, text-mode browsers etc. as well). The <b> tag means "make this bold if you can, but you're free to ignore this tag if you can't" and the emphasis may be lost in an audio or text-mode browser. An extremely common mistake (it's not always a mistake to use <b>, but in your case it was as loss of the emphasis would change the semantics) and one which displays the widespread misunderstanding of the design of HTML and why it works the way it does. It's inconsistent because it's better for conveying information that way.
Re:Heterogeny (Score:5, Insightful)
Actually, I think a design that hangs off the edge of my browser window because I've got the window set narrower than 800 pixels is pretty ugly. I also think text too small to read is ugly, and gets really ugly when I force it to increase size.
Yet a web page (even Slashdot does it) that lays itself out to fit MY choices is beautiful.
The standards allow a little bit of wiggle room, but the user being in control of the "page" you're drawing on and to a certain extent the printer as well, adds a LOT more variation. If you take the control freak approach you will have ugliness. Possibly with the exception of people who use Windows and are used to their browser expanding to fill the whole screen.
Re:lite (Score:1, Insightful)
You, personally, are the reason I can't convince managers to use open source products.
I hope you're proud of your own stupidity.
Re:lite (Score:1, Insightful)
Really, come on! I tired of 'thread bashing'.
1. If you insinuate that multi-process programming is easier than multi-threaded programming any time that resources need to be shared, than you are plain wrong.
2. In a non-threaded program you are running essentially a single thread. If that thread hangs, your whole program hangs anyway. Mutex or no mutex.
3. True - but they also solve a whole new class of problems. So they are not a universal bullet, I would not multi-thread hello world. But when the time comes to when you need them - it sure feels like a magic bullet.
Anyway. SOMEONE POST SOMETHING ON TOPIC! I am more than half way through this, and I still don't know why WebKit is cool, and why Mozilla won't use it! (And multi-threaded vs. multi-process is not that reason)
Re:Heterogeny (Score:5, Insightful)
Re:Mozilla IS Gecko (Score:5, Insightful)
Design matters (Score:5, Insightful)
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.
Re:Heterogeny (Score:3, Insightful)
I guarantee even the best workman will complain about their tools if said tools are unable to complete the task they are supposedly meant to do.
Thread INTERACTIONS are hard (Score:3, Insightful)
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.
Re:lite (Score:5, Insightful)
"Lack of threaded tabs is shameful" - Why? Is it really that big of a deal? Don't open a tab that's going to lock up your browser.
Other good advice: don't get on a plane that's going to crash. Don't get on a boat that's going to sink. Don't work for a company that's going to go bankrupt.
"IE developing it" - Oh noes! We need this now, if IE has it then FF needs it! Guess we should go ahead and make FF IE5 complient then, since IE is as well. Forget that standards nonsense, IE has it so we need it.
When Internet Explorer, of all things, has new, useful, and (dare I say) innovative features that make people's lives easier and more productive, far ahead of Firefox, then either it's time for FF to stop resting on its laurels, or it's time to start giving the IE team some well-deserved kudos. Either way, attention must be paid.
If you're encountering enough lock-ups to cause you to need to be able to end a single tab's process regularly (which is pretty hard to do in Chrome with all the tabs having the same process name mind you) then have fun with your threaded tabs. Me, I'm just not going to open sites that are likely to lock up my browser. There aren't many out there, I haven't seen a single one in a couple of months.
Good thing Chrome itself includes a process manager that will let you end a specific process based on what the name of the tab is, how much memory it's using, how much bandwidth it's using, and so on. Pretty keen.
Your post reads like so much 'LA LA LA I CAN'T HEAR YOU!' that I'm forced to wonder why your emotional attachment to Firefox is so deep. Seriously, it's just a browser, lighten up.
Re:Gecko is not outdated or bloated. (Score:4, Insightful)
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.
Re:Makes me wonder, too (Score:3, Insightful)
Now as a support technician I shudder at your post. It lacks any specific information and therefore relevance.
1) What version of FireFox are you talking about?
2) What plug-ins are you running?
3) What platform are you running it on?
4) How is that patched?
I'm running an updated FF3 on Vista (my employer makes me use the latter) and have IETabs, some skin, FireFTP, Downthemall, PDFDownload and Download Statusbar installed. This whole construction works flawlessly all day every day, and you could argue my browsing requirements are on the heavy side.
It's not a bug / class issue until many users report the behaviour under particular circumstances. So until a bug is found, the time is well spent on bolting a new JS interpreter onto the thing and tweaking the GUI.
Wait wait... (Score:5, Insightful)
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.
Chrome innovations? (Score:2, Insightful)
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?
Re:Heterogeny (Score:3, Insightful)
Yeah, well, that's the point - but if the designers want to match font size exactly with an image X pixels high, then they are setting up a failure.
Re:lite (Score:5, Insightful)
Re:lite (Score:4, Insightful)
Allow me to return the favor..
1. FF3 Has never crashed on you and Chrome has. You said you've used FF3 for "over a month." That means you weren't using it in Beta. Chrome is still Beta. Apples meet Oranges.
2. "Don't open a tab that's going to lock up your browser." Wow. You know, you're right. No reason for modern OS's to use protected memory. Lets all go back in time 20 years and use shared memory. After all, don't run an app that's going to lock your OS.
3. "Guess we should go ahead and make FF IE5 complient then" You can just read about this one [wikipedia.org] on wikipedia.
4. "pretty hard to do in Chrome with all the tabs having the same process name mind you" ... huh? The chrome task manager uses the page title as the process name. Click on the page title you want to kill, press "end process" and you're done.
5. "There aren't many out there" You're on one right now. The new discussion system here has locked up FF2 on my system dozens of times. It doesn't happen as much anymore, but it still does when there's >500 comments and I'm reading at +1.
6. The truth is, having one process per web application makes sense. 20 years ago OS's transitioned from cooperative multi-tasking and shared memory space to preemptive multi-tasking and protected memory space. That change allows us to do everything we take for granted now, although it probably wasn't NECESSARY to meet the needs of the time.
Google is correct: Most of the "websites" we love and use every day are actually web applications. And when you're running 5 applications in one process, you're right back into the 1980s world of cooperative multi-tasking. And in FF3 if one tab decides to throw a JS alert() box, that thread is no longer "cooperative" and all JS execution on the other 4 tabs has stopped.
And no, today's applications aren't yet at the point where they NEED their own process. But who knows how web app development could be retarded by not giving developers the kind of environment that has proven successful for Win32 development.
The truth is that you'll probably see this in FF4. It IS the next major leap in browser tech. Tabs took us from dos-era one-page-at-a-time browsing into a Win3.1 era of "almost multitasking."
Now we're about to enter the "NT era." No use fighting it.
Chrome vs. Firefox (Score:3, Insightful)
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.