| |||||||||||||
Fsyncers and curveballs (the Firefox 3 fsync() problem)Fsyncers and curveballs (the Firefox 3 fsync() problem)Posted May 26, 2008 19:51 UTC (Mon) by job (guest, #670)Parent article: Fsyncers and curveballs (the Firefox 3 fsync() problem)
I think the article makes it clear that Firefox is heading in the wrong direction, very much like its predecessor Netscape. In my opinion the performance problem described is symptomatic of a too complex product. The data storage abstraction used probably isn't the one needed. History is linear data and I would expect it to be best stored in a log (i.e. appended), and indexed piecemal or even on load. But I'm not a Firefox developer so I might be missing the bigger picture here. I am however a user, and most new features are misfeatures to me. The new history system gets all cluttered and is useless to me. I just want to turn it off. Much like the user interface changes in 2.0 which was pretty much all for the worse. All I want is better rendering, perhaps better performance, but above all for it to stop allocating all my memory after a while. It seems there has been more problems around sqlite performance in Firefox. The article links to Christopher Blizzard who describes a problem with Firefox as shipped by Red Hat: Firefox upgraded sqlite, noticed a regression, and backed out the change. Meanwhile, Red Hat package maintainers did not know about the regression and they shipped a faulty package. I do find the article in question very biased towards the Firefox developer's point of view. They would rather have their upstream release shipped in distributions. From my point of view as a user that's not desirable for many reasons. The reason why Red Hat missed the regression is the problem that needs to be solved, not the other way around. Why did it happend? Was it not documented? Why did the build script even accept a library version with a known regression? All this points to a big closed world mentality inside Mozilla where the product is everything and the bigger ecosystem lost. I hope that is not the case as Firefox is a very important product and I would be sad to see it take the Netscape road.
(Log in to post comments)
The road to suckiness Posted May 26, 2008 22:14 UTC (Mon) by man_ls (subscriber, #15091) [Link] Maybe it is time already to lose some of those hard-earned market share points? It is a real pity; as you say, all people want is a fast and lean browser which does not use all available RAM.You may think: well, but most people run Windows and have lots of memory to spare. Maybe it is time to put it to good use! Why squeeze every available bit when everyone has GBs of RAM? Well, just visit www.google.com once more. The home page to the biggest internet company works on every browser and loads fast as lightning. In these days of broadband and dynamic websites it has 2728 bytes. Now compare with how it looked like 8 years ago, at the height of the internet bubble, back when most people had pitiful modems and ISDN was a luxury. Apart from the iGoogle links, it feels the same! Google has not grown rich bloating its bread and butter. As you say, it is the direction taken by Netscape. Next they will rewrite the engine in Java, go Windows-only, integrate a mail client or any other classical silly move. At that point we will be missing a crucial part of our infrastructure, right now when we were getting web designers to pay attention. So we will suffer another period of obscurity and internet monoculture. And then we will have to wait until someone comes along with a new lightweight browser project within Mozilla... Boring.
Fsyncers and curveballs (the Firefox 3 fsync() problem) Posted May 26, 2008 23:39 UTC (Mon) by joey (subscriber, #328) [Link] Benjamin Otte (of swfdec) just wrote a pretty good blog post about why mozilla is in general not meshing well with the rest of linux (not specific to this particular problem) <http://www.advogato.org/person/company/diary.html?start=111> For me, the trademark nonsense was the last straw; I use only gecko now, and am I'm looking forward to epiphany with a webkit backend so I can remove all mozilla stuff entirely.
Fsyncers and curveballs (the Firefox 3 fsync() problem) Posted May 27, 2008 2:38 UTC (Tue) by roc (subscriber, #30627) [Link] > For me, the trademark nonsense was the last straw; I use only gecko now, > and am I'm looking forward to epiphany with a webkit backend so I can > remove all mozilla stuff entirely. This is a strange position. See if Apple will let you use the "Safari" trademark.
Fsyncers and curveballs (the Firefox 3 fsync() problem) Posted May 27, 2008 3:21 UTC (Tue) by vmole (guest, #111) [Link] Apple won't let me use the Safari code, either, so I don't the comparison is apt. OTOH, I don't really have a problem with the firefox trademark position. Steve, Debian Iceweasel user.
Fsyncers and curveballs (the Firefox 3 fsync() problem) Posted May 27, 2008 4:26 UTC (Tue) by ajf (subscriber, #10844) [Link] You do know what "last straw" means, right?
Fsyncers and curveballs (the Firefox 3 fsync() problem) Posted May 27, 2008 19:24 UTC (Tue) by tzafrir (subscriber, #11501) [Link] Tried Epiphany-browser for a while. Couldn't stand the minimalistic user interface and the strange gnome-style UI choices (I don't use gnome). about:config is still way more user-friednly and intiutive than gconf-editor. Having both to look at is even worse. Knoqueror is generally nice. But insisting on using the "text editor" to oped text pages is annoying. There are a bunch of other small things that make it annoying. So I'm still mostly with iceweasel (occasionally still with the iceape that has a few nicer default, but is horrible with extensions)
Fsyncers and curveballs (the Firefox 3 fsync() problem) Posted May 27, 2008 2:36 UTC (Tue) by roc (subscriber, #30627) [Link] > History is linear data and I would expect it to be best stored in a log > (i.e. appended), and indexed piecemal or even on load. Super-fast random access to history is very important. For example when a page loads we have to be able to tell which links should be marked "visited"; if that's slow, page load time is hurt significantly. Indexing things on load would be bad, since people often have tens of megabytes of history data and we don't want to read it all in at startup time, since startup time is also very important. > All I want is better rendering, perhaps better > performance, but above all for it to stop allocating all my memory after a > while. http://www.numenity.org/blog/wp-content/uploads/2008/05/p...
Fsyncers and curveballs (the Firefox 3 fsync() problem) Posted May 27, 2008 4:03 UTC (Tue) by AJWM (guest, #15888) [Link] Tens of megabytes of history data? And you search through all that just to properly highlight the 'visited' links? Geez, I don't give a rat's behind if a link I visited three years ago is properly highlighted. Why not just limit it to the last couple of day's worth or the last 1000 entries? I mean really, WTF? And use a hash table.
Fsyncers and curveballs (the Firefox 3 fsync() problem) Posted May 27, 2008 4:11 UTC (Tue) by roc (subscriber, #30627) [Link] > Tens of megabytes of history data? And you search through all that just > to properly highlight the 'visited' links? > > Geez, I don't give a rat's behind if a link I visited three years ago is > properly highlighted. > Why not just limit it to the last couple of day's worth or the last 1000 > entries? Just go to Preferences ... Privacy ... "Keep my history for at least NNN days" and set that to 2 or whatever suits you. But there are other users we need to serve who want proper link coloring with years worth of history. Making software for a broad audience is hard.
Fsyncers and curveballs (the Firefox 3 fsync() problem) Posted May 27, 2008 16:37 UTC (Tue) by AJWM (guest, #15888) [Link] >But there are other users we need to serve who want proper link coloring > with years worth of history. And for those two users, everyone else suffers? > Making software for a broad audience is hard. Only if you're trying to make "one size fits all". If there really are users out there who want years' worth of link coloring, create an Elephant's Memory edition of Firefox (it never forgets) with the SQL history. For everyone else use something sane. Sure, it means maintaining two slightly different code bases (or one with #ifdefs), but that's often easier than trying to work around the necessary compromises to meet conflicting design goals.
Fsyncers and curveballs (the Firefox 3 fsync() problem) Posted May 27, 2008 17:28 UTC (Tue) by quotemstr (subscriber, #45331) [Link] And so this with every feature? You'll create an exponential number of combinations of feature combinations, all of which need to be tested and debugged. When you _can_ create a system that works for everyone, it's a much better route to go. Look at the Linux processor scheduler: instead of meekly letting everyone have his own special-purpose scheduler, none of which worked for everyone, Linus demanded that there be one scheduler with good general-purpose behavior. And eventually, we got the excellent scheduler we have today. Imagine if there were a special variant of C for every type of program. Imagine if there were types of windows that could be used for bitmap graphics, or vector graphics, but not both. It's a combinatorial nightmare.
Fsyncers and curveballs (the Firefox 3 fsync() problem) Posted May 27, 2008 17:38 UTC (Tue) by tetromino (subscriber, #33846) [Link] >> But there are other users we need to serve who want proper link coloring >> with years worth of history. > And for those two users, everyone else suffers? You know, I find it *incredibly* useful that FF3 remembers months of history. For example, when you are about to click on a rapidshare link, it's very nice to know that you've already downloaded the file two months ago, so that you don't use up your quota and don't incur a two-hour timeout. The improved history handing is one of the main reasons why I had switched from FF2 to using FF3 nightlies.
Fsyncers and curveballs (the Firefox 3 fsync() problem) Posted May 27, 2008 13:37 UTC (Tue) by gerv (subscriber, #3376) [Link] So other simpler web browsers (which can still render the entire web) don't have performance problems at all? Extrapolating from one performance problem to the idea that Firefox is too complicated is a bit of a jump. Firefox is as complex and big as it is (all of a 5Mb download) because the web is complex and big, and people want it all to work right. Working right and using lots of memory don't necessarily go hand-in-hand, as the recent big improvements in speed and memory usage by the Firefox team have shown, but if you think it's still not good enough, show where the savings can be made while still maintaining full web fidelity. The reason why Red Hat missed the regression is the problem that needs to be solved, not the other way around. I think that's what Chris Blizzard is saying. All this points to a big closed world mentality inside Mozilla where the product is everything and the bigger ecosystem lost. Even if this were true (and I don't think it is - see roc's comments in various places listing all the work we've done for and in other projects), where is the law that says that projects have to take decisions based on the good of "the bigger ecosystem"? Surely if someone wants to take all this software and roll it into an OS distribution, it's their responsibility to make it all work together? Upstream may be helpful or may not - but there's no obligation to help. Right? Gerv
|
|||||||||||||
