But let’s not bury the lede here: after several days of screaming, ranting and scaring the cat with various failures, this blog post is finally being typed in a fully profile-guided and link-time optimized Firefox 82 tuned for POWER9 little-endian. Although it multiplies compile time by nearly a factor of 3 and the build process intermittently can consume a terrifying amount of memory, the PGO-LTO build is roughly 25% faster than the LTO-only build, which was already 4% faster than the “baseline” -O3 -mcpu=power9 build. That’s worth an 84-minute coffee break! (-j24 on a dual-8 Talos II [64 threads], 64GB RAM.)
This whole post is a ringing endorsement of Firefox and why the technology landscape – especially the alternative operating systems and hardware platforms landscape – needs Firefox. There really isn’t any other viable option.
Chromium? Chromium is open source, but a lot of its important functionality is hidden behind a needlessly complex process of setting up and registering API keys that’s about as intuitive as designing an atomic bomb from scratch on a deserted island. On top of that, Chromium is still a Google project, and as Google’s reluctance to support important features on Linux shows, Chromium is designed for Google’s interests – nobody else’s.
WebKit? WebKit requires developers to build an entire web browser around it from scratch. While that can lead to awesome applications, it also means replicating every single bit of functionality users have come to expect from their browsers. Things like bookmark and tab sync, extensions, and so on – all have to be built and maintained form scratch.
Firefox is the only complete package someone can port to another platform and end up with a complete browser package. Sure, it’s definitely not an easy undertaking to port a program as complex as Firefox, but in a lot of cases, it’s probably easier than porting WebKit/Blink and building a browser around it from scratch.
It’s sad to see what became of the KHTML DNA on that front..
Apple never open sources a full desktop component, only the bare minimum they are legally required to do.
This post is hitting a really raw nerve for me right now. I’ve spent the last two weeks trying to get Firefox to work on my G5 (aka POWER4) big endian PowerPC. This really used to “just work.”
Today, Firefox depends on nodejs as part of its build system. You actually have to compile the Chromium Javascript runtime to compile Firefox. And since Javascript these days is a JIT compiler, you need that compiler to generate instructions for your platform. Node has some support here, where IBM folks have contributed big-endian PowerPC support…for AIX and POWER5. It generates instructions that don’t exist in CPUs included in any Mac and doesn’t implement the Linux calling convention correctly.
Once you get past that, you find out things like it’s using a graphics library whose maintainers are just actively opposed to any kind of big endian support, and there’s a slew of community patches to try to make it work.
But actually, I haven’t gotten that far, because it hangs or segfaults on launch. But then I noticed that if I run Firefox on Intel but set the X display to the big endian PowerPC, Intel Firefox crashes too. So now I get to debug that.
The environment I’m using is Gentoo – it’s really a bog standard Linux except for the CPU architecture.
Anyway, the point is, weeks later, something that used to be straightforward still doesn’t work. It’s true that Firefox is big and complicated, but Libreoffice just worked first try. There’s something about the web ecosystem and its desire to rebuild everything every couple of years that is very hard to support on a broad range of systems, because all of the code is new and immature. The instant it’s fixed to support something, a whole new thing arrives that doesn’t support the thing that just got fixed.
The real thing about this post is that IBM threw in the towel and went little endian because they could see this was a losing battle. The news here isn’t that Firefox is ported from one little endian machine to another, it’s that it doesn’t work on a big endian machine anymore.
I wonder, would Pale Moon compile for a Big Endian machine? As they forked from Firefox before they went Quantum.
I share your frustration but I don’t think IBM and OpenPOWER has any other choice but to focus on Little Endian because it is trivial to port a large range of x86_64.
Besides even going full on LE, there are still many hurdles that the OpenPOWER community have to face, for example Google’s Webkit refusal to support the platform making life so hard for the community.
Firefox 82 builds for ppc64. Void linux has it for ppc64, ppc64-musl, ppc64le and ppc64le-musl.
https://github.com/void-linux/void-packages/tree/master/srcpkgs/firefox/patches
Firstly, thank you for the link. Anyone who has patches called “skia sucks” is going to be on the right track.
Unfortunately I don’t see patches for nodejs. I’ve read a lot of threads on related issues in the last couple weeks, and they typically look just like this one, where somebody says “this doesn’t work” and somebody says “works for me” and it requires a lot of close examination that they’re talking about different processor generations or similar.
It may be true that a POWER5+ based machine can compile node, and run it long enough to compile Firefox, and with things like Skia fixed the result actually runs on POWER4. But that doesn’t mean POWER4 can compile Firefox on its own, and for better or worse, there’s a lot of these chips out there since they were the last generation of mass produced chips aimed at real consumers. To muddy the waters even more, there are people saying they have node running on ppc32 but what they mean is POWER5 in 32 bit mode, not a truly 32 bit CPU.
Edit: In the context of Gentoo this is particularly frustrating, where packages that do not work get marked as stable because they worked in somebody else’s configuration. From there the old package that still works on an older chip gets removed.
Anyway, based on this I’ll try picking up the version of node that void is using and see if it has been fixed to work on POWER4.
Take a look at https://repo.voidlinux-ppc.org/stats.html as well. You can search for packages and see on which architectures they’re available. The build master is a POWER9 machine – it might be quite difficult to actually build Firefox on a G5 with only 4GB of memory. But it does RUN on ppc64.
https://github.com/void-linux/void-packages/tree/master/srcpkgs/nodejs
4GB? I wish. I have the final iMac G5 (https://everymac.com/systems/apple/imac/specs/imac_g5_2.1_20.html) which has a maximum configuration of 2.5Gb, and mine has 1.5Gb which seemed like plenty in 2005. Linking libxul takes 45 minutes (and a huge swap partition.) Looking now though it costs $15 to get the 2Gb module that it really wants, so I should probably go upgrade, haha.
But, repeating above, processor generations matter. The stats page shows nodejs working on ppc64 – but which ppc64? I’m sure firefox runs on ppc64 (after hacking through skia et al), but which ppc64?
https://github.com/void-linux/void-packages/blob/master/common/build-profiles/ppc64.sh#L1
It’s explicitly designed to work on a G5 (970) or newer. The primary void-ppc maintainer has a Dual G5 tower that he tests on. Swing by #voidlinux-ppc on freenode sometime.
Edit: apparently I can’t reply to you for some reason, so I hope you see this.
The node part of the build system is only for some of the tests I though? I’m pretty sure it’s not needed to build. mach bootstrap may try to install it, in general the bootstrap script is meant for the “just make everything work on intended platforms” case.
Nice work though the perf is still sub-par to Chromium unfortunately. Now we need to raise funds to get JIT support
Based on what metrics? Firefox does have a JIT, arguably it has a more advanced JS engine than Chrome’s V8.
Firefox does not have a Javascript JIT on POWER hardware.
Here’s my barely-researched and possibly ill-informed first comment ever on OSAlert after lurking for years (and it’s more about the technology landscape than the alternative platforms that are the focus of the article); take it for what it’s worth. (By the way, thanks to the staff for a computing news site that doesn’t make me feel as much like the “product” as many of the others!)
While I agree with Thom’s conclusion that we really need Firefox, I think the case is overstated in a few ways. How many of the Chromium APIs (1) are actually important to users, (2) don’t have close alternatives such as accessing Google services manually via the web, and (3) have analogues that are more easily available to Firefox derivatives? The only API I see on the list that obviously meets these criteria is the extension store; I believe access to addons.mozilla.org is totally unrestricted (at least, I can “wget” xpi files with no problem). We should give Google credit for spearheading some browsing-related initiatives that have major benefits for users, such as Certificate Transparency. And Mozilla has done some user-hostile things. The one that has bugged me the most recently is the situation with Firefox for Android: the only official sources that consistently have the latest stable official build are the Google Play and Apple stores, and the official build includes some closed-source software as well as some third-party tracking software (which theoretically can be turned off in the settings, but I’m still nervous).
But the biggest point is still that, without Firefox, even the unbranded Chromium might have more freedom to do really user-hostile things, which would put the public up a creek.
Firefox is absolutely an integral part (at the moment) of the web, and should be used by everyone and supported monetarily, sadly.
Were them to stop development, I’m afraid that the open internet would be set back at least a decade. and it would be a nightmare for the open community (it already is bad enough, people not wanting to support open standards without DRM).