LWN: Comments on "No more 32-bit Firefox support"

Missing the reason

millihertz — Thu, 18 Sep 2025 14:44:44 +0000

My experience - of running 64-bit Firefox on an x64 system with 2-8GB RAM and no swap - is that while it doesn't crash, it does occasionally decide to try and use all of the 28GB it has allocated, which rapidly brings the entire system to a halt as executable pages are crowded out by dirty data pages with nowhere to go. This has been depressingly repeatable across every system I've tried it on, and is why I switched back to using 32-bit Firefox in the first place.

Call me old-fashioned, but I would rather have the browser segfault than DoS the entire system it's running on... which, as I understand it, isn't fantastic for security either, to address another point raised in these comments.

Missing the reason

millihertz — Thu, 18 Sep 2025 14:37:52 +0000

I still do exactly this, and it works a treat. By and large, limiting the js heap to 512MB stops it from crashing too; some javascript might break, but that's fine.

FF 32-bit support's probably going to be like it's (direct) ALSA support, community driven

millihertz — Thu, 18 Sep 2025 14:35:31 +0000

I think you've answered your own question. Pipewire is unlikely to be the last word in desktop-level Linux audio, but ALSA clearly isn't ever going away (even if someone backs a Brinks Mat truck up to an enchanted well...) so once you manage to chance upon a stable ALSA config, it's likely to work forever.

Missing the reason

taladar — Tue, 16 Sep 2025 07:11:53 +0000

You might want to have a look at the cgroups(7) manpage to get an introduction to cgroups in general.

Missing the reason

mirabilos — Sat, 13 Sep 2025 17:38:05 +0000

I did in fact not know that; I hadn’t researched into cgroups in more detail.

Much appreciated.

Missing the reason

donald.buczek — Sat, 13 Sep 2025 17:11:03 +0000

> cgroups, and I’ve never saw any useful docs for how to use them other than “just use systemd, man, it’ll do it automagically for you”

You and most people will probably already know this, but of course you can also use cgroups without any special software by manipulating the files and directories in /sys/fs/cgroup (or wherever else you mount the cgroup2 filesystem).
Everything is documented at https://docs.kernel.org/admin-guide/cgroup-v2.html.

However, I don't know whether this helps in the context of libvirt and Docker. I'm not familiar with them and don't know what their requirements are.

Missing the reason

Cyberax — Fri, 12 Sep 2025 20:58:48 +0000

Like, Linux itself?

Missing the reason

mirabilos — Fri, 12 Sep 2025 15:03:45 +0000

Except systemd is not the hammer; systemd is a cheap asian version of a swiss army pocket knife, with too many functions bundled.

"supported"

taladar — Fri, 12 Sep 2025 07:58:12 +0000

There is also a related effect where communities that shrink because they are less and less viable will end up with a much higher concentration of people resistant to change almost by definition as they are the least likely to change.

Similar effects can be seen in the real world with e.g. towns that used to have a viable industry to support them but that industry died. Flexible people move away, people resistant to change stay.

Missing the reason

zdzichu — Fri, 12 Sep 2025 06:08:06 +0000

You have to drive a nail in the wood. People say "just use a hammer, man". And you are like "never hammer, I will manage with this round rock somehow". It's your fault you ignore tools, so stop complaining.

"supported"

josh — Thu, 11 Sep 2025 23:47:15 +0000

Quite a few comments here have been about what is supported, and whether it matters what's supported.

Upstreams don't necessarily want to support every possible configuration, and with limited resources and a desire to keep things feasible and maintainable for contributors, they need to prioritize. People downstream get incredibly upset when they discover their configuration or use case is not a priority and upstream is not willing to do some of all of the work for them.

In particular, many people act as if present-but-unsupported configurations impose no cost, rather than imposing continual costs on those working on the codebase. Sometimes upstreams decide they're no longer willing to pay those costs for configurations used by very few people. And even if someone were willing to put in effort to maintain it, often that effort is in the form of occasional patches, not making up for the continuous costs the configuration imposes.

Effectively, obscure configurations become an externality, where people wanting them to be supported expect others to shoulder some of the costs of those configurations, and they often downplay those costs. And some projects have started to decide they're not willing to shoulder those costs, which produces friction. It especially produces friction if a project has not previously made support levels explicit.

For a configuration like "Linux on arm64", for most projects, there's enough critical mass where a tiny tiny fraction of the potential users, working on the project, can easily bear the costs of support. For more obscure configurations, the number of people with that configuration may not be enough that they can collectively sustain all the software they want to run on that configuration. And there's an incentive, rather than giving up and moving to something more supported, to try to collectively *push others* to care more about that configuration, to do some of the work, to bear the externality. And because this becomes an existential threat to the continued viability of the obscure configuration (e.g. as it shrinks), those pushes to others have a lot of emotional valence, often in the form of anger and self-righteousness. And without care, that anger can get concentrated into communities that center themselves around obscure configurations.

In short, there's a continuous cycle, where waning configurations, as the burden to support them becomes larger than the benefit of supporting them, become sources of heavy strife within communities and projects. And it's important for projects to recognize this, and make support levels explicit, and have a means of ending support for configurations very explicitly and cleanly, without a long period of "if people get angry enough and righteous enough can they force upstream to put work into supporting them past the point where supporting them is sustainable".

Missing the reason

intelfx — Thu, 11 Sep 2025 23:23:07 +0000

> Hm, no cgmanager in Debian (bullseye, but likely not trixie either).

Precisely. Case in point.

> Who cares about supported?

Those who write the code that you complain about.

Missing the reason

mirabilos — Thu, 11 Sep 2025 22:52:24 +0000

Hm, no cgmanager in Debian (bullseye, but likely not trixie either).

> > and then there’s the v1 vs. v2 issue
>
> There is no issue. One is obsolete, other is actively supported.

Who cares about supported?

The issue is that some software will only work with one of them. (I *think* I had to mkdir and mount cgroups v1 stuff in trixie to get… something… to work, Docker maybe or libvirt).

Missing the reason

mirabilos — Thu, 11 Sep 2025 22:49:25 +0000

Note the part in the comment you replied to which says:

> never saw any useful docs for how to use them other than “just use systemd, man

You fulfilled the cliché beautifully, though, I’ve to admit.

(No, I don’t and won’t run systemd, period.)

Missing the reason

mbunkus — Thu, 11 Sep 2025 22:27:30 +0000

It sure can. It's as easy as:

systemd-run --user --property=MemoryMax=16G firefox

Missing the reason

intelfx — Thu, 11 Sep 2025 13:49:00 +0000

> because they want to use cgroups, and I’ve never saw any useful docs for how to use them other than “just use systemd, man, it’ll do it automagically for you”

Well, cgmanager exists (or, at least, existed). In its time it was absolutely a viable alternative to systemd, and docker used to support both. The upstream development stopped in 2020, presumably because nobody wanted to do it anymore.

It’s hardly systemd’s fault that it turned out so good nobody actually desired to continue developing the alternatives.

> and then there’s the v1 vs. v2 issue

There is no issue. One is obsolete, other is actively supported.

Missing the reason

mathstuf — Thu, 11 Sep 2025 13:00:59 +0000

`systemd-run` has been able to do this for a long time. I've used it to make sure a build doesn't require more than 4 GB per TU by running a non-parallel build under a strict memory limit. But, AFAIK, it does require using systemd as your init system (or, rather, cgroup manager), so perhaps systemd-run is the "just use systemd, man" solution alluded to here.

Missing the reason

kpfleming — Thu, 11 Sep 2025 10:48:09 +0000

I believe 'systemd-run' can do this now - launch any executable, creating a cgroup to contain it, and set various limits including memory usage. It may be worth a try.

Firefox memory leaks: alternative to a full browser kill and restart to recover the leaked memory

mirabilos — Wed, 10 Sep 2025 00:49:49 +0000

Good point, I’ve used that as well.

Sometimes there are tabs that just use up lots of resources (RAM, but mostly one full CPU) in the background, despite disabling service workers, so I still do that.

Firefox memory leaks: alternative to a full browser kill and restart to recover the leaked memory

Duncan — Wed, 10 Sep 2025 00:23:23 +0000

I generally exit firefox (and anything else) when not in use as well, but I'm using a bit different technique for firefox memory management.

First detailing the memory issue I see: For me it's generally youtube, but I expect the same happens on other "infinite scroll" sites, particularly image (thumbnails for youtube) -heavy ones. My particular issue may be exacerbated by extensions, likely either HoverZoom+ when actively hovering over many thumbnails over time (thus assuming the memory for those is leaked), or, someone else's theory I read, that uBlockOrigin's blocked connections somehow don't fully close and thus leak memory over hours of blocking youtube ads, etc.

Regardless, using a single tab for hours on youtube, either searching (with perhaps a thousand hover-zoomed thumbnails over several hours), or playing multiple videos (tho fewer longer videos doesn't seem to leak as much as many short ones, could be from either many more blocked ads or many more thumbnails loaded, tho with fewer zoomed than the first scenario) eventually uses multiple gigabytes of RAM, even sending me gigs deep into swap on a 16 gig RAM system if I let it go long enough. (Tho I've never had it actually crash, likely because I have an equal 16-gig swap partition on each of four SSDs (so I can stripe them using equal swap-priority values for all four), so 64 gig swap in addition to 16 gig RAM, and I've never let it get beyond single-digits gig into swap.)

In the search scenario, if I middle-click to launch the actual videos in new tabs, then close those tabs in a relatively shorter time to go back and search further from the main search tab, the newer tabs don't seem to accumulate as much and closing them doesn't seem to release much either -- the big memory usage is all in the main search tab that has stayed open. And simply refreshing the page doesn't reclaim the lost memory, nor does deleting cache (which is on tmpfs so does use some memory), so the culprit isn't the tmpfs cache. And FWIW, forcing garbage collection from about:memory doesn't help either -- whatever's leaking, firefox doesn't consider it garbage to be collected!

*BUT*, either duplicating the tab (along with its session history) and closing the old one, or (with another tab open, say just open a new-tab to its default page, or one of the separate-tabbed video pages, so the entire browser doesn't close), closing the offending tab and immediately doing a reopen-closed-tab, keeps the tab's session history, but releases all that leaked memory, sometimes double-digit gigs of it!

So I don't close/kill the entire browser, I simply ensure at least one additional firefox tab is open so the browser itself doesn't close, then either duplicate the leaking tab and close the old one, or close and reopen the leaker. That gets my RAM back without killing the full browser.

Perhaps you'll find that useful as well, tho admittedly, in some cases it's likely less hassle to just do the kill and restart thing. (Much like after upgrading various in-use libraries and apps, while reverting to a text-mode login and running something to tell you what's still using deleted/stale files and restarting it, plus possibly having systemd reload itself too if it's on the list, can usually avoid a full reboot, it's often just easier to just do the reboot and get everything fresh all at once, rather than doing it one app at a time.)

FF (direct) ALSA support

Duncan — Tue, 09 Sep 2025 22:59:17 +0000

>> And with only a single active audio device to talk to, there's no /need/ for pulse/pipewire device-routing.

> Good for you. But I hope you understand you are in a *tiny* minority.

Well, I did say this was for me, and that it didn't really apply to most Linux users (tho as edited -- believe it or not my original was much longer than that long thing above -- that disclaimer was rather weaker than my original).

Of course for many of us that's what makes Linux so great, that it's open and not forcing a single-size-fits-all solution on everyone. All those "tiny minorities" together may not make a majority (in Linux scope I guess that'd be Android), but together they're anyway a significant minority, and the larger Linux community would be missing something quite valuable without them.

FF (direct) ALSA support

mirabilos — Tue, 09 Sep 2025 22:33:45 +0000

Nah, Bluetooth is pretty much unusable as it’s also on the 2.4 GHz band which is already congested with microwaves, way too many WLANs from all the neighbours in the same house, adjacent and opposite houses, and whatever that neighbour to one side is occasionally doing.

I just recently had my new employer give me a decent wired headset.

FF (direct) ALSA support

pizza — Tue, 09 Sep 2025 12:21:43 +0000

> And with only a single active audio device to talk to, there's no /need/ for pulse/pipewire device-routing.

Good for you. But I hope you understand you are in a *tiny* minority.

The "normal" use case these days involves on-the-fly switching between built-in speakers and bluetooth. Or increasingly, bluetooth only. (And BT is a real PITA to use if you want to interact with ALSA directly. It exposes a lot of application bugs too, I might add. The same sort of bugs that were blamed on pulseaudio back in the day...)

FF (direct) ALSA support

taladar — Tue, 09 Sep 2025 09:39:50 +0000

> But one thing a gentooer building and importantly _upgrading_ packages themselves *quickly* learns is that having unused packages installed isn't just bad security practice, when you're building the upgrades, it's *expensive* in time and compute resources. There's a very high incentive to just uninstall those things you don't /really/ need, or even the ones you might need occasionally, but find yourself upgrading more often than you actually run them.

As a fellow Gentoo user of many years I can't confirm that at all. The number of packages is basically meaningless for upgrade times, what does matter is the few really, really large packages that take ages, lots of disk space and lots of RAM to build (looking at you any fork of webkit/blink/chrome/....). Small packages in particular often take more time to unpack than to build and even if they were a binary package they would not take significantly less time to install.

Missing the reason

jmalcolm — Tue, 09 Sep 2025 07:33:19 +0000

i386 in Debian was already not "386". In fact, Debian i386 would not even run on a Pentium, even in Debian 12. It needed a Pentium Pro (i686) at a minimum.

It should also be noted that AntiX is continuing 32 bit support apparently. Presumably AntiX based distros like MX Linux and DSL will as well. If you are a fan of 32 bit Debian, this is a way to keep getting it.

FF (direct) ALSA support

Duncan — Tue, 09 Sep 2025 05:25:09 +0000

>> why not skip the ever-changing middleman?

Indeed. Additionally, for me, tho this doesn't apply to most Linux users, at least to the extent they apply here, particularly since most install from distro (or flatpack/snap) binary packages.

As already mentioned I'm a Gentooer. While they do have prebuilt binaries available these days, as I suspect most gentooers I prefer my own customized builds.

But one thing a gentooer building and importantly _upgrading_ packages themselves *quickly* learns is that having unused packages installed isn't just bad security practice, when you're building the upgrades, it's *expensive* in time and compute resources. There's a very high incentive to just uninstall those things you don't /really/ need, or even the ones you might need occasionally, but find yourself upgrading more often than you actually run them. And more to the point, that goes for the build options (gentoo USE flags) that control optional features on your leaf packages but pull in additional dependencies to supply those features, as well.

Put simply, having a package installed really is a different expense proposition when you're building /and/ /building/ /upgrades/ yourself, than if you're simply installing prebuilt binaries.

But that's the general case I could have replied to directly above. Here there's more specific points:

> Because pipewire makes things like screen sharing work reliably

It's not just screen sharing. In fact, here screen sharing would be a net-negative as the only conceivable screensharing would be malware so better not to have it available to be abused.

But the same mechanism is used (on wayland, X of course lets any app have at it) for screenshotting and at least on plasma, for plasmashell taskmanager plasmoid thumbnailing. For the latter, fortunately kwin's taskswitcher plugins aren't affected since kwin's the plasma wayland compositor, and with a near 25 MegaPx desktop (3 by 4k bigscreen TVs as computer monitors) and multiple desktops, window-stacking is often avoided, so focus-follows-mouse and the keyboard-triggered kwin task-switchers are enough and I don't need nor have configured any plasmashell taskbars or the like. Screenshotting would be more useful, particularly for filing kde related bugs since I track live-git (via the gentoo/kde project overlay packages available for that purpose) for most of my kde stuff, but spectacle, plasma's screenshotter, requires pipewire.

But it's not worth it just for that. I can word-describe the problem in bugs I file, and if they aren't immediately fixed (as bugs against live-git often are), someone else generally eventually comes along and provides screenshots where I can't due to missing pipewire.

> because with an audio server running *not* talking to the audio server means going through an extra layer, because using pipewire makes it easier to control where different audio goes (or comes from)...

But no audio server here to talk to, so it's not running and talking to alsa directly isn't an extra layer for the gentoo distro firefox. For firefox-bin, the gentoo-packaged mozilla-built binary (or for the mozilla-packaged user-installed binary), there's the apulse shim library as an extra layer talking to the prebuilt binary via the pulse/pipewire api, but that's still thinner than the non-shim full version of either would be.

And with only a single active audio device to talk to, there's no /need/ for pulse/pipewire device-routing.

Multi-stream audio merging, assuming your hardware can't handle it (my current hardware doesn't but my old hardware did), can still be useful, but alsa can software-merge streams via dmix of properly configured. I've had mixed results trying to get it working (it seems to work sometimes but not reliably), probably because the configuration and documentation for it is a bit arcane and I'm still doing something not quite right, but in theory it's available from alsa.

Turns out, however, that most of the time I actually prefer my primary audio stream uninterrupted. This actually kind of surprised me when I switched to less capable hardware that didn't handle that itself, but I found most of the time I prefer /not/ having sound effects and even second "feature" streams interfering with my enjoyment of whatever I'm already playing!

So it turns out that's not something I'd want to install pulse/pipewire for either, both because alsa can at least theoretically handle it if properly configured, and because it turns out I don't actually want multiple streams most of the time anyway.

Now one thing I /did/ find worth digging into the alsa documentation and text-editing the alsa config for, was the alsaequal 10-band equalizer. I believe a pulse-based equalizer is significantly closer to plug-and-play, but after setting up a bunch of presets and a script to activate them, plus adding another menu to my existing custom hotkey-activated menu setup so activating a new eq preset is a two-key sequence (using an "extra" key on my logitech keyboard as the first one), I'm quite happy indeed with how that turned out. =:^) (Tho FWIW I did run a firefox eq extension before that, primarily for youtube.)

All that said, reports suggest pipewire's a more stable solution than pulse was, and definitely, pipewire's window snapshotting and thumbnailing functionality make it more practically useful than the audio-only pulse, so I'll probably switch to it "someday", maybe when/if I ever get that threadripper hardware upgrade I want and will be rebuilding for the new hardware anyway... But that could be a few years...

Missing the reason

tao — Mon, 08 Sep 2025 11:52:45 +0000

48 bits? That's, what, 256TB?

I think that once the memory usage of your browser starts approaching those numbers even Chrome and Firefox would start looking for memory leaks...

Missing the reason

Lennie — Mon, 08 Sep 2025 09:54:09 +0000

"If Debian keeps 32-bit architectures"

Well... funny you should mention that:

https://www.debian.org/releases/stable/release-notes/issu...

Memory limits

arnd — Mon, 08 Sep 2025 07:50:04 +0000

Modern Firefox is likely to hit both the physical (installed) memory limits and the virtual addressing limits of 32-bit machines, and it really only gets worse over time:

On arm32 and x86-32 systems running a kernel config with HIGHMEM and VMSPLIT_3G, the per process address limit is 3GB, as the 32-bit address space is shared with the kernel's lowmem (768MB) and vmalloc (256MB) areas.
Physical memory on x86-32 hardware is theoretically limited to 4GB with CONFIG_HIGHMEM_4G, but in practice the chipsets have a 3GB limit at best. 32-bit arm systems can theoretically go up to 16GB with HIGHMEM and LPAE, but most SoCs cannot connect more than 2GB (four 256Mb x16 DDR3 chips).
The 3GB virtual address limit will typically get lowered to 1.75GB or 2GB once the kernel loses support for highmem, because one has to use CONFIG_VMSPLIT_2G to keep accessing 2GB the physical memory (lowmem). 32-bit systems with 3GB or more RAM at that point lose both physical memory and virtual address limits.
On 64-bit systems, the virtual addressing can go up to 4GB for 32-bit compat tasks, so there may be cases where a particular 32-bit browser binary works fine when tested on 64-bit systems, but is unable to fit within the virtual limits on 32-bit kernels with the same amount of physical memory.
Both browser implementations and popular websites tend to use more memory every year, from a combination of added features and developers caring less about low-end devices. 3GB of physical memory is already tight for opening multiple tabs, while 3GB of address space may not be enough for a process showing a website with a lot of complex Javascript.
Mozilla is pushing integrated AI features into their browsers, which likely brings a lot of workloads over one of the above limits, making it completely unusable.

Missing the reason

sylvestre — Mon, 08 Sep 2025 07:41:24 +0000

32 bit will still be supported

Missing the reason

sylvestre — Mon, 08 Sep 2025 07:40:06 +0000

upstream here
We only stop generating Linux 32 bit builds.
32 bit will still be supported at least for arm .

Missing the reason

ibukanov — Sun, 07 Sep 2025 20:28:32 +0000

Both Intel and Arm still does not allow to use addresses beyond 48 bit even if formally the address word is 64-bit. Which means that SpiderMonkey (JS engine in Forefox) even on 64 bit can use NaN boxing technique, https://searchfox.org/firefox-main/source/js/public/Value... . However when future processors start to support bigger address space, like 52 bits or even more, the SpiderMonkey will need to be redesigned.

Missing the reason

mb — Sun, 07 Sep 2025 18:49:00 +0000

Reminds me of this:
https://xkcd.com/1172/

Missing the reason

mirabilos — Sun, 07 Sep 2025 18:27:33 +0000

Eh, Firefox reopens tabs on start after a crash. I often `xkill(1)` it to reclaim memory, even, and generally exit it when not in use.

Most of the programs I use run in a terminal, so…

Missing the reason

mirabilos — Sun, 07 Sep 2025 18:06:05 +0000

No, I’ve had enough trouble to get libvirt and/or Docker working because they want to use cgroups, and I’ve never saw any useful docs for how to use them other than “just use systemd, man, it’ll do it automagically for you”, and then there’s the v1 vs. v2 issue…

Missing the reason

josh — Sun, 07 Sep 2025 18:02:38 +0000

For me, if my *entire* browser crashes, I lose most of the applications I have running, other than those running in a terminal. The move towards tab isolation (as well as general improvements in browser stability) has been a huge improvement.

Missing the reason

mb — Sun, 07 Sep 2025 17:01:13 +0000

Using the 32bit version of an application just for limiting its memory use sounds like using a hammer as tool for a problem where you'd actually need to use a screw driver.

Have you looked into cgroups for limiting the memory consumption of applications?
That would even work with multi process applications.

Missing the reason

mirabilos — Sun, 07 Sep 2025 16:52:30 +0000

I know.

But at that time (before it split itself into multiple processes) it was still a very useful way to save on RAM.

I’d love to still be able to limit that, at least on the “8 GiB is maximum you can put in” laptop.

Missing the reason

mirabilos — Sun, 07 Sep 2025 16:50:39 +0000

Not supporting does not have to mean actively dropping the code though, one can hope.

Missing the reason

mirabilos — Sun, 07 Sep 2025 16:48:54 +0000

> Then it would just crash or fail

But that’s *precisely* what I want! The browser can always be restartet, using less memory than before and not loading possibly problematic tabs (or I can switch to lynx), but the rest of the system is not under memory pressure by a boring webbrowser.

> it has multiple processes these days, each of which has its own address space.

Yes, that’s why I used past tense when I said I used to use i386 builds.

I’d still prefer that these days…