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.

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.

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

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.

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).

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).

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.

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

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.

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.

(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.)