Thursday, August 23, 2012

15.0 available

15.0 is now available from the Downloads tab. Share and Enjoy the Release Notes.

Of note, Mozilla themselves disabled pdf.js prior to release, so it looks like it wasn't really ready for primetime after all. The interested can still reenable it from about:config.

Real life and a paycheque is interfering with my hacking time, so 10.0.7 will be a rush job. I'm hoping to have it up by Sunday or Monday and we should still make it on time. I plan to merge the changesets tonight and then run compiles surreptitiously from the field as I pretend to read office E-mail.

I'm still doing planning for 18.0, our "Judgment Day" release. Because we will be shipping a new C++ runtime and other components, this will require more memory, and while 1GB RAM has been a practical minimum (he admits with obvious pain) for some time it will be the supported minimum with 18.0. It may still work on systems with less RAM, but it will definitely be impaired, and we won't accept bug reports on those systems. Assuming 17.0 will still build with gcc 4.0.1, it will be the last version to support 512MB machines. You are on notice. we'll see how it goes, based on Comments

More info when the 17 aurora port begins. For now, please try 15.0 and wait for 10.0.7 this weekend.

11 comments:

  1. The 1 GB RAM requirement could become a problem e.g. for G3 iBooks. Mine still works like on the first day, and TFF is pretty speedy on its 800 MHz processor. But it has 128 MB soldered in, and one free slot that accepts 512 MB max. And that's it.

    ReplyDelete
  2. I suppose we could split the difference and make 768MB the minimum, but even that would be temporary.

    ReplyDelete
  3. (even the 640MB there would be very tight with that and Tiger)

    ReplyDelete
  4. If it's technically required then I guess that's just the way it is… As long as 17 lasts, this will be the ESR machine anyway, so maybe it's not a big deal.

    One little thing I noticed: In the URL field, the message "Go to a website" up to TFF 14 used to disappear right when clicking into the field. Now the cursor blinks left to the word Go, and the message only disappears when I start typing. The same behavior can be observed in the Aurora 16a2 PPC build. Is this intentional? It certainly feels weird. It also happens here in the comments field ("Enter you comment…"). FF 15b on Windows XP also shows this behavior, so it's not our bug.

    ReplyDelete
  5. I see what you're referring to, and it's on regular Firefox on Windows and OS X, so I imagine it is intentional.

    As far as actual memory usage, perhaps Tobias has an idea here, since he's operated such builds. The difference is that it will be carrying its own glibc/c++ instead of using the common system one.

    ReplyDelete
  6. All versions of AuroraFox have been shipped with gcc-4.6's libgcc and libstdc++. Note that what is glibc on Linux is named libSystem on Darwin/OS X. Also don't confuse glibc with glib, the latter being a core library of GTK which is needed for GStreamer in Aurora.

    I didn't compare RAM usage of TenFourFox and AuroraFox but I won't expect huge differences. I'd rather think that if current AuroraFox is running well on your system so will TenFourFox 18.

    ReplyDelete
  7. Okay, then we'll just see how it goes.

    ReplyDelete
  8. Anyway, isn't the total size of libgcc_s.dylib + libstdc++.dylib well under two megabytes (on any given arch, I mean—obviously the files would be a bit bigger in, say, a 4-way universal build)?

    ReplyDelete
  9. For some documents (once they're loaded completely) scrolling is now considerably faster in pdf.js than in the old Schubert PDF viewer. Some content still isn't displayed correctly, but the developers, I think, are doing an excellent job.

    ReplyDelete
  10. @SamB, probably, but size of the component dylibs doesn't necessarily indicate size of the total executable image (they can be greater than the sum of the parts). However, I defer to Tobias' better knowledge of these builds in practice.

    @Chris, there are some things that pdf.js does do better than the built-in OS PDF support, and it's improving, *and* it's probably unfair to compare it against a native solution. Still, it needs a bit more time in the oven, and I'm glad they're continuing to improve it.

    ReplyDelete
  11. This comment has been removed by the author.

    ReplyDelete

Due to an increased frequency of spam, comments are now subject to moderation.