It may simply have been a less needed; on Windows if Mozilla doesn't offer a binary then users won't get the program, on Linux there's already distro packages for that.
Some distros like Debian Stable and the RHEL clones track the ESR versions of Firefox instead of the latest release, so I could see users preferring the official binaries in that use case.
This is a good point, but I had assumed that the distro package repository owners make these packages using the officially published binaries, and had to go out of their way for linux/arm64 because of the lack of an official binary. Is that not the case?
Oh no, distro packages almost never use upstream binaries. The only major case I'm aware of is Arch AUR and Gentoo -bin packages, but that's the exception not the rule.
That is interesting extra context. With that in mind, it doesn't really make sense to me why anybody (especially Linux distro vendors) would care then. Which seems to clash with the article's statement:
> Firefox's Linux binaries have been produced for x86 32-bit and x86_64 but any AArch64 binaries on Linux have been left up to Linux distribution vendors and other third-parties wanting Firefox on Arm.
Which I infer means distro vendors were the beneficiary of the new linux/arm64 binaries, since it's implied they would no longer need to worry about compiling their own binary. Guess not then.
I would read that line roughly as "Mozilla published (source and) binaries for 32 and 64 bit x86, but ARM has been solely Mozilla publishing code and distros building their own binaries". So yeah, in many ways I think this is a relatively minor change for Linux ARM users. The main place I could see it mattering is if users wanted to get binaries directly from Mozilla that's an option now, and the most likely reason I can think for that is to get bleeding edge binaries - either stable versions before the distro updates or to get beta/nightly versions that the disto doesn't ship at all.
Mozilla finally relenting that arm64 isn't just a fad? Or did they just enable this with some CI infrastructure they couldn't get working with qemu?
It may simply have been a less needed; on Windows if Mozilla doesn't offer a binary then users won't get the program, on Linux there's already distro packages for that.
I guess I'm curious how many folks on Linux are using official binaries instead of just using the distribution packages? Still good to see regardless!
Some distros like Debian Stable and the RHEL clones track the ESR versions of Firefox instead of the latest release, so I could see users preferring the official binaries in that use case.
This is a good point, but I had assumed that the distro package repository owners make these packages using the officially published binaries, and had to go out of their way for linux/arm64 because of the lack of an official binary. Is that not the case?
Oh no, distro packages almost never use upstream binaries. The only major case I'm aware of is Arch AUR and Gentoo -bin packages, but that's the exception not the rule.
That is interesting extra context. With that in mind, it doesn't really make sense to me why anybody (especially Linux distro vendors) would care then. Which seems to clash with the article's statement:
> Firefox's Linux binaries have been produced for x86 32-bit and x86_64 but any AArch64 binaries on Linux have been left up to Linux distribution vendors and other third-parties wanting Firefox on Arm.
Which I infer means distro vendors were the beneficiary of the new linux/arm64 binaries, since it's implied they would no longer need to worry about compiling their own binary. Guess not then.
I would read that line roughly as "Mozilla published (source and) binaries for 32 and 64 bit x86, but ARM has been solely Mozilla publishing code and distros building their own binaries". So yeah, in many ways I think this is a relatively minor change for Linux ARM users. The main place I could see it mattering is if users wanted to get binaries directly from Mozilla that's an option now, and the most likely reason I can think for that is to get bleeding edge binaries - either stable versions before the distro updates or to get beta/nightly versions that the disto doesn't ship at all.
I use the binary package because Ubuntu only provides a Snap, and that lacked some permissions I wanted (reading installed html docs).
Distros generally don't provide Nightly at all.
Hope this means we get a Tor browser soon too. This has been a huge gap