Best Web Browser for MintPPC19?

[Appleuser201]

I haven't gotten around to installing it yet, but I've heard many great things about it and it's great the MintPPC was revived again, having a modern OS customized specifically for PPC.
What is your web browser of choice? Also what web browsers will/could potentially work on this distro? I remember way back somebody being able to get the latest Firefox 70.x working on their PPC Linux (with some bugs and instability)

 

[Jeroen Diederen]

Arctic Fox

 

[Appleuser201]

Arctic Fox

What version of FF is it based on? I've also seen Arctic Fox on other PPC Linux distros, its a great browser.

 

[Jeroen Diederen]

52.9 I believe. @wicknix should know better

 

[wicknix]

AF is based on Pale Moon 27, which had a fork point of FF38 and is patched with select bits of code from 45 and 52. It's a good "all-around" browser that is fairly light on resources. For better web compatibility there is also SpiderWeb and InterWeb which are based on current UXP (PM28 and Basilisk) code which started with a FF52 fork point and are patched with select 60 and 68 bits of code. FF Quantum (as far as i know) only works on 64bit debian sid and 64bit void linux, but with some minor issues yet.

Cheers

 

[Jeroen Diederen]

Firefox Quantum runs in MintPPC64 but has endianness issues (blue color). I never looked into it but Void64 has that fixed.

 

[Appleuser201]

AF is based on Pale Moon 27, which had a fork point of FF38 and is patched with select bits of code from 45 and 52. It's a good "all-around" browser that is fairly light on resources. For better web compatibility there is also SpiderWeb and InterWeb which are based on current UXP (PM28 and Basilisk) code which started with a FF52 fork point and are patched with select 60 and 68 bits of code. FF Quantum (as far as i know) only works on 64bit debian sid and 64bit void linux, but with some minor issues yet.

Cheers

Could Quantum possibly ever work in 32bit Linux?

 

[wicknix]

Anything is possible, but as it stands right now rust won't build on ppc 32bit, so i wouldnt hold my breath. As long as the UXP devs can keep up with the ever changing web technologies and backports, 32bit ppc linux browsers will be ok for awhile yet.

Cheers

 

[goosnarrggh]

Anything is possible, but as it stands right now rust won't build on ppc 32bit, so i wouldnt hold my breath. As long as the UXP devs can keep up with the ever changing web technologies and backports, 32bit ppc linux browsers will be ok for awhile yet.

Cheers

According to this website, rustc is currently a "Tier 2" architecture for all three of: powerpc, powerpc64, and powerpc64le, on Linux with glibc. That means that the official project is spinning automated builds for all three architectures, and broken builds of any of those three is grounds to block a new release.

However, automated tests are not necessarily regularly performed on those platforms yet, and a failure of an automated test for any of those 3 platforms would not necessarily block a new release.

Redirecting...

forge.rust-lang.org

Both Void and Debian Ports are shipping rustc for 32-bit PPC. (1.44 for Void, 1.45 and 1.46 beta for Debian) However, I'm not sure about the best way to run them through a typical test suite.

-------------------
edit: I am taking it upon myself to test this for myself.

I'm trying to use Void's rustc 1.44 to bootstrap rustc 1.45 from source code, and then run through its standard test suite. I'll report back once it finishes, with first-hand knowledge to say how close to self-hosting rustc appears to be on the PPC32 platform.

It should go without saying that this is all happening on a fairly old G4 computer, so regardless of whether it succeeds or fails, it'll probably take a while.

 

[goosnarrggh]

It was slow. But, I can say with a reasonable degree of confidence that rustc is self-hosting for PPC32 on Linux using glibc at the moment.

(Painfully slow - 1.25 GiB of RAM was not enough for the build to run to completion without substantial thrashing to swap during the final few compile steps and especially during the final linking step. Also, the rustc build process makes rather extensive use of /tmp to hold some of its intermediate outputs. With Void defaulting to using tmpfs for /tmp and therefore eating up more and more combined (physical+swap) memory as the build progressed, it only increased the pressure to thrash.)

But I did make it through a successful stage 2 bootstrap of rustc 1.45.2, using Void's prepackaged build of 1.44 as the stage 0 compiler.

I'm still working on assembling the tools I'll need to run the full test suite, because one of the things the test suite wants to do by default, is to check to make sure that all the source code which went into building the compiler was formatted correctly using the rustfmt tool. Void PPC doesn't currently provide a prebuilt rustfmt as part of its rust package.

The canonical version of rustfmt normally only likes to be built with the current nightly prerelease of the compiler because its own source code makes liberal use of internal unstable compiler features, but it looks like there may be a way to force it to be built in-tree alongside the rest of the rustc toolchain.

I'll report back again later.

 

[goosnarrggh]

I'll report back again later.

The "ui" test suite (the first of the functional tests) reported 10,164 passed tests, 103 ignored, and 26 failed.

Next would come the fun part of figuring out what went wrong in each failure, why they failed, whether or not they are still failing in the nightlies, and what would need to be done to resolve each. Possibly beyond my depth, but it might be an interesting learning opportunity.