They aren't ending support for 32-bit Windows. If the ratio of 32/64 bit users on Linux matched those on Windows, then this would affect 0.5% of their users.

Abandon is too strong a word. I imagine most people who are still using 32 bit operating systems aren't too concerned about getting the very latest version of firefox either.

within those numbers are people who don't really have a preference one way or another, and just didn't bother to upgrade. I have to imagine that the group of people that must use 32-bit and need modern features is vanishingly small.

Mozilla is in extremely dire straits right now, so unless this "lot of people" make a concerted donation effort to keep the lights on I would be hardly shocked by the sunsetting.

Yeah consumer CPUs have been 64-bit since what, the PowerPC G5 (2003), Athlon 64 (2003), and Core 2 (2006)? There were a few 32-bit x86 CPUs that were released afterward, but they were things like Atoms which were quite weak even for the time and would be practically useless on the modern internet.

More generally I feel that Core 2 serves as a pretty good line in the sand across the board. It’s not too hard to make machines of that vintage useful, but becomes progressively challenging with anything older.

32 bit Atom netbook. I use offpunk, gopher://magical.fish among tons of services (and HN work straight there) and gemini://gemi.dev over the gemini protocol with Telescope as the client. Mpv+yt-dlp+streamlink complement the video support. Miserable?

Go try browsing the web without UBlock Origin today under an i3.

I haven’t tried it, but as bloated as the web is, I don’t think it’s so bad that you need gigabytes of memory or a blazing fast CPU to e.g. read a news website.

As long as you don’t open a million tabs and aren’t expecting to edit complex Figma projects, I’d expect browsing the web with a Pentium + a lightweight distro to be mostly fine.

Idk, I think this is sad. Reviving old hardware has long been one thing Linux is really great at.

A CMPXCHG16B instruction is going to be faster than a function call; and if the function is inlined there's still binary size cost.

The last processor without the CMPXCHG16B instruction was released in 2006 so far as I can tell. Windows 8.1 64-bit had a hard requirement on the CMPXCHG16B instruction, and that was released in 2013 (and is no longer supported as of 2023). At minimum Firefox should be building with -mcx16 for the Windows builds - it's a hard requirement for the underlying operating system anyway.

There was recent story about f-droid running ancient x86-64 build servers and having issues due lacking isa extensions

https://news.ycombinator.com/item?id=44884709

but generally it is rare to see higher than x86-64-v3 as a requirement, and that works with almost all CPUs sold in the past 10+ years (Atoms being prominent exception).

As far as I can tell, GCC supports compiling multiple versions of a function, but can't automatically decide which functions to do that for, or how many versions to build targeting different instruction set extensions. The programmer needs to explicitly annotate each function, meaning it's not practical to do this for anything other than obvious hot spots.

You can do that to some limited degree, but not really.

There are more relevant modern examples, but one example that I really think illustrates the issue well is floating point instructions. The x87 instruction set is the first set of floating point instructions for x86 processors, first introduced in the late 80s. In the late 90s/early 2000s, Intel released CPUs with the new SSE and SSE2 extensions, with a new approach to floating point (x87 was really designed for use with a separate floating point coprocessor, with a design that's unfortunate now that CPUs have native floating point support).

So modern compilers generate SSE instructions rather than the (now considered obsolete) x87 instructions when working with floating point. Trying to run a program compiled with a modern compiler on a CPU without SSE support will just crash with an illegal instruction exception.

There are two main ways we could imagine supporting x87-only CPUs while using SSE instructions on CPUs with SSE:

Every time the compiler wants to generate a floating point instruction (or sequence of floating point instructions), it could generate the x87 instruction(s), the SSE instruction(s), and a conditional branch to the right place based on SSE support. This would tank performance. Any performance saving you get from using an SSE instruction instead of an x87 instruction is probably going to be outweighed by the branch.

The other option is: you could generate one x87 version and one SSE version of every function which uses floats, and let the dynamic linker sort out function calls and pick the x87 version on old CPUs and the SSE version on new CPUs. This would more or less leave performance unaffected, but it would, in the worst case, almost double your code size (since you may end up with two versions of almost every function). And in fact, it's worse: the original SSE only supports 32-bit floats, while SSE2 supports 64-bit floats; so you want one version of every function which uses x87 for everything (for the really old CPUs), one version of every function which uses x87 for 64-bit floats and SSE for 32-bit floats, and you want one function which uses SSE and SSE2 for all floats. Oh, and SSE3 added some useful functions; so you want a fourth version of some functions where you can use instructions from SSE3, and use a slower fallback on systems without SSE3. Suddenly you're generating 4 versions of most functions. And this is only from SSE, without considering other axes along which CPUs differ.

You have to actively make a choice here about what to support. It doesn't make a sense to ship every possible permutation of every function, you'd end up with massive executables. You typically assume a baseline instruction set from some time in the past 20 years, so you're typically gonna let your compiler go wild with SSE/SSE2/SSE3/SSE4 instructions and let your program crash on the i486. For specific functions which get a particularly large speed-up from using something more exotic (say, AVX512), you can manually include one exotic version and one fallback version of that function.

But this causes the problem that most of your program is gonna get compiled against some baseline, and the more constrained that baseline is, the more CPUs you're gonna support, but the slower it's gonna run (though we're usually talking single-digit percents faster, not orders of magnitude faster).

I consider it unlikely, but perhaps there's some instructions that don't have a practical polyfill for x86?

It'd be ~0.1% of Firefox users that use 32-bit Linux, extrapolating from e2le's statistics, not 2.6%. Have to draw the line at some point if an old platform is becoming increasingly difficult to maintain - websites today aren't generally still expected to work in IE6.

Firefox shouldn't need special support by the web, the same relationship can't be said of architecture specific binaries.

[dead]

They edited the article to clarify that they're only dropping support for 32-bit x86.

If they are like me, they simply never realized they needed to re-install Firefox after upgrading the OS.

Mozilla should try to automate this switch where the system is compatible to it.

Some people are under the misapprehension that 32-bit programs need less ram, which might explain that, but that's still a large number regardless.

Debian has stopped supporting x86 32bits recently, Chrome did so 9 years or so ago.

We've carefully ran some numbers before doing this, and this affects a few hundreds to a few thousand people (hard to say, ballpark), and most of those people are on 64bits CPUs, but are using a 32bits Firefox or 32bits userspace.

The comparatively high ratio of 32bits users on Windows is not naively applicable to the Linux Desktop population, that has migrated ages ago.

An open source project should also use its resources effectively. There is always the possibility for a community fork.

Are you sure about that? There are Android Go targets that are 32-bit to reduce memory usage, even on 64bits CPUs.

If the libraries were missing entirely, I'm not sure 32-bit Firefox would even start. But if they were present and nothing was keeping them updated (pretty likely on an otherwise 64-bit system), they'd pretty likely become out of date -- which could certainly explain spurious crashes.

If they made it as far as being able to lose something they were working on, then it's less likely to have been a missing library problem. But I don't know what it was; people do successfully run Firefox on 32-bit Linux.

Firefox does have problems with old profiles, though. I could easily see crud building up there. I don't think Firefox is very good about clearing it out (unless you do the refresh profile thing). You could maybe diagnose it with about:memory, if you were still running that configuration.

It's Debian, it can handle 32 bit and 64 bit applications at the same time, and the package manager makes sure you have all the dependencies.

I didn't change libraries, it was a gradual switch where you convert applications to 64 bit - and I didn't think to do Firefox, but it wasn't missing 32 bit libraries.

It was simply a profile that I'd been continuously using since approx 2004, and it was probably too large to fit in 32 memory anymore, or maybe Firefox itself needed more memory and couldn't map it. (The system had a 64 bit kernel, so it wasn't low on RAM), but 32 bit apps are limited to 2/3/4GB.

Here is one of the crash reports: https://crash-stats.mozilla.org/report/index/15999dc2-9465-4...

(I happened to have an un-subitted one which I just submitted, all the other ones I submitted are older than 6 months and have been purged.)

It would crash in random spots, but usually some kind of X, GLX, EGL or similar library.

But I don't think it was GLX, etc, because it also didn't save my profile except very very rarely, which was actually a much worse problem!!

(This crash is from a long time ago, hence the old Firefox version.)