Firefox 145 Drops Support For 32-bit Linux (nerds.xyz) 28
BrianFagioli writes: Mozilla has released Firefox 145.0, and the standout change in this version is 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.
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.
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)
Re: (Score:2)
Re: (Score:2)
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)
Re: Do we really need 64-bit? (Score:4, Interesting)
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)
It's just a different way of looking at primary storage. Object memory is an even finer grain version of the old idea, and it offers some security advantages that linear memory cannot.
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)
Re: (Score:2)
Most things are fine with 32 bit. Some things are not. But here is the thing: A lot of supposedly 64 bit software is really 32 bit with extensions.
32bit (Score:2)
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
Re: (Score:3)
The company standard for servers is RedHat 10. RedHat 10 does not support 32 bit applications.
The legacy app is running happily on RedHat 9.
...laura
Re: (Score:2)
Linux is NOT getting rid of 32-bit on amd64 userspace support, so your program will run just fine in 32-bit mode.
It would be pretty insane to stop supporting 32 bit altogether. Especially as there is a ton of 32 bit systems out there in the embedded space. But even in regular computing, 32 bit is fine for a lot of things and these then just run slower and need more memory when forced to go to 64 bit.
Re: (Score:2)
So do your legacy app needs a current Firefox in order to run correctly?
my 32 bits (Score:3)
No 32 bit here (Score:2)
I use Fedora, which has no 32 bit releases for years, so I have no use for 32 bit Firefox.