I suspect the reason the Linux release binaries don’t get downloaded a lot is because they’re not shipped in any distro packaging format (RPM and deb being the obvious ones). Let’s also not forget that there’s no 64-bit builds of Firefox/Thunderbird on any platform either (another reason Linux distros have to step in and provide them…).

In an ideal world, there should be Mozilla repos for RPM/deb and 32-bit/64-bit, but the impression I get is that either there isn’t enough resources/willpower to get this done or the “easy” option of leaving the distros to do the builds/packaging takes the load off the Mozilla developers (but isn’t this like saying “Microsoft should build and ship Windows Firefox for us”?!).

I read up on this from the bug, and this story, a few days ago. I re-read today and something struck me. You’re writting this off as an OS bug and ‘we didn’t do this’.

Well… I also ran through your proposed fix for ‘lowering fsync temporarily’.

So, in the final fix of this: You will fsync the same amount as you do now. Correct?

Therefore, do you anticipate that Firefox will cause disk activity continually? You’ve just said here that your fsyncing isn’t a problem. You say that when it doesn’t actually write, that is a problem.

So you think Firefox should write out to disk that often?

FF 2.0.10 + and FF 3.0.* have been the most unstable releases for me, both on Windows and Linux. I moved to 3.0 when 2.0.10 and above stopped being usable, and had to keep up with each 3.0 release because the number of ‘click link, firefox dies’ bugs was unbelievable.

I installed Opera. I just want to know – what is causing all these regressions? Adding pingback support? I bet it bloody well is, some stupid feature that nobody wants, and it is causing crashing issues. Anyway.

In Songbird SQLite has given us a fairly quick, fairly reliable datastore, but we’ve come across a ton of limitations, bugs, and unexpected performance problems. We’ve also had to make compromises when modeling our application’s data as a set of tables, columns and relations that hurt us a little now and will probably hurt us more in the long-term.

In my experience here I’ve found SQLite’s best feature is the development community. Once we’re able to produce reduced test cases for the problems we’ve had there’s a really quick turn around with fixes, unit tests and releases.

This having been said it strikes me as mistaken to block on the call to fsync/F_FULLFSYNC. This is the correct semantics for dealing with standard database type operations, submitting orders for sale, inventory etc.. etc.. where it’s very important not to let a transaction appear to complete without storing that data to disk. This isn’t the case with firefox. No further harm will occur if the user goes about his buisness and bookmarks another site in the second that firefox would otherwise have been stalled on the write to return.

A well designed database could guarantee that no system corruption had occured by still occasionally submitting fsync requests and checking when they complete and ensuring that information needed to regenerate the prior version of the database in case of a crash is never overwritten until the fsync calls return telling it that new metadata blocks have been written.

Also just to clarify about what OS X is doing. OS X is offering exactly the correct semantics. In OS X fsync guarantees that the file has been written to the disk drive. However, with NCQ the disk drive may choose to reorder that write or leave it in buffer for some time. F_FULLFSYNC does a normal fsync and also flushes the buffers on the disk. I know this is what you meant above but it wasn’t very clear to me until I looked it up so I thought I would clarify.

The reason this is the correct semantics is that it lets the programmer optimize their interactions with storage if they know that the disk is supported by a battery or otherwise guaranteed to actually flush it’s internal buffers. Hopefully one day all disks will be so designed.

People use our binaries

[citation needed]