Saturday, August 15, 2020

TenFourFox FPR26b1 available (after all, Mozilla's not dead yet)

TenFourFox Feature Parity Release 26 beta 1 is now available (downloads, hashes, release notes). There isn't a great deal in this release due to continued heavy workload at my regular job and summer heat here in excessively sunny Southern California making running the G5 and the Talos II at the same time pretty miserable, and I also had the better part of a week laid up ill to boot (note: not COVID-19). Still, this hopefully completes the work on DOM workers and the usual security updates, which will switch to 78ESR starting with FPR27. All going well, it will be released on August 25.

With much of the low-hanging fruit gone that a solo developer can reasonably do on their own, for FPR27 I would like to resurrect an old idea I had about a "permanent Reader mode" where once you enter Reader mode, clicking links keeps you in it until you explicitly exit. I think we should be leveraging Reader mode more as Readability improves because it substantially lowers the horsepower needed to usefully render a page, and we track current releases of Readability fairly closely. I'm also looking at the possibility of implementing a built-in interface to automatically run modifier scripts on particular domains or URLs, similar to Classilla's stelae idea but operating at the DOM level a la Greasemonkey like TenFourFox's AppleScript-JavaScript bridge does. The browser would then ship with a default set of modifier scripts and users could add their own. This might have some performance impact, however, so I have to think about how to do these checks quickly.

A few people have asked what the Mozilla layoffs mean for TenFourFox. Not much, frankly, because even though the layoffs affect the Mozilla security team there will still be security updates, and we'll continue to benefit as usual from backporting those to TenFourFox's modified Firefox 45 base (as well as downstream builders that use our backports for their own updates to Fx45). In particular I haven't heard the layoffs have changed anything for the Extended Support Releases of Firefox, from which our continued security patches derive, and we don't otherwise rely on Mozilla infrastructure for anything else; the rest is all local Floodgap resources for building and hosting, plus Tenderapp for user support, SourceForge for binaries and mirrors and Github for source code, wiki and issues.

But it could be a bigger deal for OpenPOWER systems like the Talos II next to the G5 if Mozilla starts to fade. I wrote on Talospace a good year and a half ago how critical Firefox is to unusual platforms, not least because of Google's general hostility to patches for systems they don't consider market relevant; I speak from personal experience on how accepting Mozilla is of Tier 3 patches as long as they don't screw up Tiers 1 and 2. Although the requirement of a Rust compiler is an issue for 32-bit PowerPC (and Tiger and Leopard specifically, since we don't have thread-local storage either), much of the browser still generally "just builds" even in the absence of architecture-specific features. Besides, there's the larger concern of dealing with a rapidly changing codebase controlled by a single entity more interested in the promulgation of its own properties and designing their browser to be those services' preferred client, which is true whether you're using mainline Chrome or any of the Chromium-based third-party browsers. That may make perfect business sense for them and for certain values of "good" it may even yield a good product, but it's in service of the wrong goal, and it's already harming the greater community by continuing to raise the barrier to entry for useful browser competition. We damned IE when Microsoft engaged in embrace, extend and extinguish; we should make the same judgment call when Google engages in the same behaviour. We have no spine for meaningful anti-trust actions in the United States anymore and this would be a good place to start.

5 comments:

  1. I can probably help you with thread_local storage on 10.4 and 10.5 PPC, as we have that working in MacPorts with many gcc versions. Can you tell me the specific thing that is causing you trouble? librsvg perhaps?

    ReplyDelete
    Replies
    1. Thread-local storage typically needs OS support as well as compiler and linker support. How were you able to overcome that? There are ways to hack it with pthreads but you generally need to convert the source to do so, and while it might compile I seem to remember messing with this before and I never got even basic code to run right.

      Delete
  2. gcc -- years ago now -- come up with an "emulated TLS" system that leverages pthreads. In fact, even today, that is _all_ they use on Darwin, even gcc10 on Catalina uses emulated_tls. I can't remember just where it came in -- certainly gcc5 has it -- probably 4.8. You don't even need any flags to make it work -- just put gcc into c++11 mode if it isn't, and away you go.

    This isn't directly relevant to you at present, but for background clang/libc++ use the system's TLS built into 10.7+ via dyld. On 10.4 to 10.6 we use emulated_tls if we're building against gcc's libstdc++, and if we're building against libc++ on 10.4 to 10.6, I enabled llvm's version of emulated_TLS on those platforms (llvm added emulated TLS for a few systems that needed it -- I forget exactly which ones now -- and I just turned that on for darwin 10.4 to 10.6). It has been going now for about four years, and nary a hiccup so far.

    ReplyDelete
  3. By the by-the-way, we are EXTREMELY close to having llvm/clang/libc++ 7.0 running on Tiger PPC darwin. It all works on Tiger Intel darwin. Iain has been working on the last little part -- making the final code output conform to the Darwin ABI standard for PowerPC. Just hasn't quite got it done yet, as he gets distracted with 2x10^5 other projects.

    I am afraid I don't have the skill to fix the ABI myself. It involves making sure the arguments are properly aligned during function calls, and I just haven't got there yet. I suspect you do have that skill, but probably no time. If you have interest, I can bring you up to speed on where we are.

    ReplyDelete
    Replies
    1. Not a lot, no. Maintaining a toolchain on top of everything else is unenticing. It's good to hear that the emulated approach does work (I assume it accepts the standard syntax otherwise). I might try getting a later QEMU to compile with gcc 4.8 since it requires TLS, as a test.

      Delete

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