Release managers just made the call that Firefox 3.0 will release with a known bug which brings Linux systems to their knees. Firefox's system-killing performance bug
The second-class Linux support policies of the Mozilla foundation continue... I imagine the reasoning went something like it has always gone in the past: "the platform that matters most is the one where we, the Foundation, get the most market penetration."
Webkit, here I come.
Update 2008-05-23: There are now two proposed workable solutions.
Profile
jasondclinton- Jason D. Clinton
Page Summary
- (Anonymous) : most people will get a patched version anyway [+7]
- (Anonymous) : Missing words [+0]
- (Anonymous) : webkit [+0]
- (Anonymous) : patch to be taken by Linux distributors, and in first FF3 update [+0]
- (Anonymous) : Question [+1]
- (Anonymous) : Reply to topic [+3]
- rtcm : The bug is in the kernel [+4]
- (Anonymous) : (no subject) [+2]
- (Anonymous) : how to reproduce? [+0]
- (Anonymous) : good [+2]
- jmtd : (no subject) [+1]
- (Anonymous) : please no... [+0]
- diegocg : (no subject) [+1]
ext_50297 : DOING. IT. WRONG. [+5] - (Anonymous) : Beta...? [+2]
Comments
And, also, the Mozilla community (and the corporation!) invested a huge amount in Linux this time around. Firefox 3 is the browser that Linux users always wanted. Our native theme code is new and feels great. (In fact, that's where the "native" theme code from WebKit comes from!) It's a first class platform for us, hands down.
Christopher Blizzard
The problem is that no one knows what the solution is. The patches that are proposed on the bug are not the solution: the problem is calling fsync. Reducing the number of times that fsync is called by 50% doesn't change that fact that calling fsync at all brings the system to its knees. I repeat: there is no patch for distributions to apply. And--even more disturbingly--it appears that no one has any idea how SQLite actually works. In short: Mozilla has spent little time investigating this problem even though it makes an entire platform completely unusable (after a sufficient quantity of profile data has accumulated).
It's going to be PR disaster if it's released in this state. Linux users will swear off Firefox for years if they experience this kind of system-killing performance. The browser market is heating up; Mozilla can't afford to take that chance.
While still serious, I would assume most people's builds will be provided by their distro's.
We've invested a ton in improving the Linux experience in Firefox and Gecko, including a bunch of work on native theme code that I think you might find in another layout engine now :), and I think that shows in the product. We take our cross-platform commitment quite seriously, and I think it stands up very well against that of any other web technology stack.
Mike Shaver
What am i missing here?
Midori doesn't count at all, as it is similar to an near-alpha release.
Another thing that bugs me is that I don't know exactly what WebKit renders or not. Seriously.
I googled a month ago and got this in a forum: http://www.neowin.net/forum/index.php?s=093d1cd056e12f6688d7ca24fa7ba7ed&showtopic=628125
Reall bad.
=(
cheers
If it is not used, we could easily patch the epiphany startup code so that these files are removed, though.
I'm using Firefox 3 beta 5 and then rc1 since the beginning of April and I'm really happy of it. The new library/history/bookmarks manager, the awesomebar, they're really good. I was becoming very disaffected about firefox on linux but this release is wonderful.
I recently updated Liferea 1.4.14. Suddenly it's very very slow. And no wonder, it also uses SQlite now.
And I don't think it's wrong to prioritize win32 over Linux - arguing that they should have the same priority is like when debian tried to give the same priority to all the architectures. The vast majority of users (x86) got harmed by this policy. Same would happen for Firefox. Just because Mozilla has a sensible policy doesn't means they hate Linux.
No, it's not, fsync on ext3 will sync the entire buffer in memory, which is bad for performance. That doesn't change the fact that it shouldn't be used like this in the first place though.
http://www.flamingspork.com/projects/libeatmydata/ = solution, a bad one, but it works. I use it for a few other things (pidgin for example does a lot of fsync for absolutely no reasons, cached buddylist icons for example..), I couldn't get it working with firefox though for some reason.
Not one human being is going to use a 3.0.0 Linux tarball. Quite a few human beings will use a 3.0.0 Windows binary. So the exact reason for punting it is correct; that breaking process for the sake of a binary that nobody will use isn't worth it.
"PR disaster". I wonder whose fault that will be. MoCo's, for following a reasonable release process, or the same attention whores that whine *every time* a new Mozilla release happens?
- Chris
Except that the problem, of course, is that Mozilla has punted the responsibility to distributions. There isn't a known-good patch, yet. Instead of prioritizing finding a solution, the policy is: pass the buck downstream.
The sick irony here is that downstream diverging from upstream is exactly what the entire Iceweasel debacle was and continues to be all about.
Edited at 2008-05-21 02:47 pm (UTC)
and like jason said ppl might move away from ff. i for one did not know why ff is so insanely slow in lin, nor did i care enough to search why.
i just dropped it altogether and went back to opera. you could ask why i didnt go back to ff2 and the answer is rather simple as well. im not so much the fan of slow leakware.