Firefox 145 Drops Support For 32-bit Linux (nerds.xyz)
- Reference: 0180048718
- News link: https://news.slashdot.org/story/25/11/11/1757229/firefox-145-drops-support-for-32-bit-linux
- Source link: https://nerds.xyz/2025/11/firefox-145-better-privacy-pdf-notes/
> Mozilla has released Firefox 145.0, and the standout change in this version is [2]the official end of support for 32-bit Linux systems . Users on 32-bit distributions will no longer receive updates and are being encouraged to switch to the 64-bit build to continue getting security patches and new features. While most major Linux distributions have already moved past 32-bit support, this shift will still impact older hardware users and lightweight community projects that have held on to 32-bit for the sake of performance or preservation.
>
> The rest of the update introduces features such as built-in PDF comments, improved fingerprinting resistance for private browsing, tab group previews, password management in the sidebar, and minor UI refinements. Firefox also now compresses local translation models with Zstandard to reduce storage needs. But the end of 32-bit Linux support is the change that will leave the biggest mark, signaling another step toward a web ecosystem firmly centered on 64-bit computing.
[1] https://slashdot.org/~BrianFagioli
[2] https://nerds.xyz/2025/11/firefox-145-better-privacy-pdf-notes/
32bit (Score:2)
As someone who likes older computers and OS's I do understand. The masses are not using 32bit so why put the effort into maintaining it.
32 bits 64 bits big-endian little-endian (Score:5, Interesting)
I support a legacy app that was written back in the 1990s. It originally ran under VxWorks with custom hardware, variously 68k and PowerPC.
The first port I did was to Solaris. No byte-order issues and I kept the 32 bit ABI. It worked well.
When the Powers That Be decided to ditch Sun hardware and Solaris in favour of x86 and Linux I ported it to Linux. Parts of the code weren't byte-order clean, but I worked through them. The code is heavily 32 bit dependent and I never did create a viable 64 bit version (I tried, believe me...), so it runs on our last 32 bit server in the data center. The service it supports is slowly dying so there's no business case to spend any more time or money on it. If the business case existed I'd apply what I've learned in the meantime and rewrite it from scratch anyway.
The Linux port was initially unstable. It would run for a random time, hours to weeks, then two threads would deadlock. After a couple of years of letting it run and watching it crash I traced the deadlock to an "optimization" that didn't actually do anything, with an if statement that had about a one in a trillion chance of going the wrong way. I removed the optimization and the application has been running fine ever since.
...laura
Re: (Score:2)
Why don't you move your application to a normal 64 bit server?
Linux may be getting rid of 32-bit support, but that's only a 32-bit kernel on 32-bit CPU support which outside of the Vortex86 SoC no one makes hardware for.
Linux is NOT getting rid of 32-bit on amd64 userspace support, so your program will run just fine in 32-bit mode. Several distributions have tried to get rid of 32-bit usermode support but that was generally met with resistance.
You don't have to port the code to 64 bit - but it also doesn't
my 32 bits (Score:3)
I still have two 32 bit systems in constant use. One I use as a RAID NAS for personal archive. It has 500MB, works great but has not been able to run web browsers for a long time. This impacts only when I want to install something, which is rare but happens. The other is a laptop with 4GB, and runs (er, ran) Firefox great. I use this laptop all the time, it is my main "walk around" laptop. Sorry to see Firefox leave it.
Do we really need 64-bit? (Score:5, Insightful)
The x86-64 instruction set has some rather nice improvements to the encoding and flexibility with registers. The larger address space can be useful in some applications, but most applications are already bloated and having bigger pointers hasn't improved matters for this bloat problem. For systems that want to access more than 2GB-4GB of physical RAM, there has long been PAE/PSE-36 that permit mapping 64GB physical address space to a 32-bit virtual space. This makes for a pretty decent compromise for a desktop system that might want a relatively small amount of memory per application but have plenty of room for addressing physical RAM and mapping graphics memory.
The pros outweigh the cons with x86-64, and we're going to see OS vendors, application developers, and CPU OEMs trim the 32-bit support back in order to reduce testing and compatibility effort. Even if it seems easy to support 32-bit because the compilers already work, it's an extra build and test pass for a team's automated testing. Those extra passes might be better spent on an ARM64 or RV64 build instead of a x86-32, as those architectures are growing rather than rapidly shrinking.
x32 flopped (Score:3)
> The larger address space can be useful in some applications
Such as high-resolution image editing and high-definition video editing. Compared to a web browser, these aren't quite as amenable to splitting an application into numerous "content processes," each with their own separate 2 GB RAM.
> but most applications are already bloated and having bigger pointers hasn't improved matters for this bloat problem.
For a while, Linux supported an x86-64 ABI called "x32" that limits each process's address space to 2 GB so that more pointers will fit in the processor's data cache. It didn't become popular, in part because of a need to load three versions of the system libraries: 32-bit i686,
Re: (Score:2)
My two cents: I accidentally put 32-bit Windows 7 on a 64-machine, which constrained the RAM to 4 GB. Firefox is used on it daily (albeit as a basic home machine) and it works fine.
Re: (Score:2)
You can't even run Firefox versions newer than 115 since they dropped support for Windows 7 ages ago...
Re: Do we really need 64-bit? (Score:3)
Nowadays with Web Assembly, and the focus of using browsers as app delivery platforms, that 4GiB limit is looking pretty thin. There are desktop apps that require more than 4GiB of addressable virtual space. And if there are desktop apps that require it, there are going to be web apps that require it.
Most things will never use it. 64-bit computing has never been about most things. It's about those exceptional applications that actually require this much memory.
Re: (Score:2)
Using browsers to deliver apps needs to die. as such even 4GiB is plenty and if I had a vote in-browser apps would be limited to 2, no 1, er make that 0.
Re: Do we really need 64-bit? (Score:2)
Did you know a single second of decoded 4k HDR video is about 2 GiB of memory? Your idea of the demands being placed upon modern computing seems out of touch. 4 GiB is not enough to even buffer 2 seconds of modern video.
Re: (Score:2)
If we used segmented protected mode we'd have more like 64 TB* of virtual address space between GDT and LDT entries, half that if we assume the Global Descriptor Table is mostly fixed and only the Local Descriptor Table would have arbitrary entries added at run-time for a program's use.
Having potentially thousands of 4GiB WASM subroutine/overlays in a single process seems sufficient to me. If only the toolchain and kernels handled segmented mode. We kind of left that technology to the mainframe and stuck wi
Re: Do we really need 64-bit? (Score:2)
Segmented memory is a hack necessary for an earlier era of computing. People should stop trying to bring it back to places it doesn't belong.
Re: (Score:2)
I think we'll skip straight to 256-bit words if we re-visit Processing-In-Memory (PIM) and computational RAM. PIM is basically when you have a handful of SIMD/vector operations you can trigger with every memory access. That means you could do 2x2 64-bit float or 4x4 16-bit half float vector operations in one go. With the full 4x4 matrix of half-float/FP16 being very useful for inference, image processing, and maybe training. Even smaller formats like FP8 and FP4 are of course already used on GPUs, so maybe
Re: (Score:2)
64, 65. Whatever it takes.
Re: (Score:3)
Short answer: yes.
A whole lot of code is simplified by being able to use 64-bit pointers. Instead of reading a file block by block, you can just read the whole thing into memory all at once. Eliminating the looping and checking of file position and cache sizes, simplifies a whole lot of code. And simpler means better performance and fewer bugs. Ditto for image file processing and many kinds of data sets.
Sure, it's a tradeoff. More memory availability means programmers get sloppier. At the same time, the pro
Re: (Score:1)
Yeah I mean, why not just.... NOT use any of the RAM above 4GB in your system..