32-bit web browser woe for 2026 and beyond

vmb

vmb

It's been an interesting few days of patching 'Copy Fail' on Linux machines, but one unfortunate casualty for me has been the 32-bit Devuan installation on a Samsung N140 that I have been happily using for months. Devuan replaced a broken upgraded FreeBSD 14.x build. This was an intel DRM/Xorg old hardware issue last year on the same device. I have since compiled a DRM fix for another FreeBSD forum user so I am likely to go back to using FreeBSD 14.4 on that handy laptop that I just use for Ethernet switch configs, but that's rambling further off topic...

After applying the 'Copy Fail' mitigation to Devuan 6, which was the last Linux machine that I had to do, I upgraded all of the packages and I should have stopped there. However, I was tired after working through the night and I ran 'dist-upgrade' to install a newer kernel and associated packages. Sadly, I found afterwards that I could no longer log in via Slim into an XFCE session on Devuan.

There were multiple issues that had crept in that I remembered from debugging a similar problem with FreeBSD/Linux DRM earlier this year. I fixed each in turn on Devuan but after switching back and forward between Slim and Lightdm I found this particular Devuan issue was an additional problem with PAM and it not finding SystemD on Devuan. Very, tired now, I had enough and needed a quick solution. I installed OpenBSD 7.8, configured XFCE4 and got back to a familiar (although minus ZFS) state in less than an hour. Now to install Firefox and Chromium. Where are they?

The OpenBSD package installer pkg_add cannot find either browser. I checked the OpenBSD ftp mirrors and neither are present in the i386 package repo. They are both in the amd64 repo. OpenBSD decided to stop building 32-bit Firefox and Chromium some time ago. I checked earlier OpenBSD releases. They are in 6.x but missing from 7.x . No Palemoon or Waterfox either, just Dillo and Otter, neither of which can render a page that looks anything like what it would in Firefox or Chromium.

I checked the EOL date for 32-bit Firefox and it is in September 2026 for the last ESR version 140. Can I be bothered to build from OpenBSD ports an i386 version of Firefox 140 ESR? No. I will install FreeBSD 14.4, install my custom intel DRM and lock the packages for the DRM and Firefox so that they cannot be easily replaced/removed. Then look for another reasonably priced 64-bit ThinkPad x260/x270 with dual batteries to replace the Samsung N140.

So what did I learn from this experience?

1. X11 under Xorg is in a death spiral, Wayland is their future. Xlibre is the salvation for those that want to stay with X11. However, that too has it's own issues as there were no 32-bit package builds of Xlibre that I could find which is why I chose Xenocara in OpenBSD as an alternative for this use case. I must stop using or relying on 32-bit tools in production, they are still OK for non-critical hobbies.

2. Old Linux is in a death spiral. Cutting out support for older hardware has moved up from an occasional thing to a purge. Linux, SystemD and Wayland will converge into one operating system where they are all dependent on each other. With Ubuntu on their maniacal expedition to replace core utils with Rust versions and Rust creeping into the Linux kernel, I don't think it will be long until there is an amd64/arm64 'SystemW' or 'SystemR' desktop/server operating system that will replace old Linux altogether. I would not be suprised if a consortium of non-SystemD distros comes together to fork old Linux from a pre-corroded kernel version. I should stop using Linux/Docker and make more of an effort to build FreeBSD jails from scratch again instead of using the easy Docker option. Hopefully, the work that Daemonless is doing with Podman on FreeBSD will gain a lot more traction.

3. Browser based systems are client/server systems. If the server has an interface that requires modern browser standards, then the client must support them. There is no point using a HTML5 server side application with a HTML3 browser that does not have Javascript or CSS if the server software has a minimum requirement for HTML5. The end of 32-bit HTML5 capable browsers means the end of 32-bit desktop operating systems in a world dominated by web based client/server systems.

4. 16-bit DOS runs well on 32-bit hardware, often only using a fraction of the PCs physical capabilities. I have been interested for some time in the modularity of DOS and I have been experimenting running NetWare 5 on thin client PC's that have higher specs than the typical servers that I installed it on 28 years ago. There are Realtek network drivers for the server and ODI clients! I have not yet tried Borland Paradox 3.5 SQL Link to a modern IBM DB2 Community Edition on Linux but I will do. Old technology can still have a place in the modern world when it fits the requirement perfectly. It doesn't have to be scrapped just because the herd has moved on elsewhere. I recently discovered that FreeDOS can run on a specialised ESP32 microcontroller!
 
32 bit is dead for general-purpose machines. Current office workloads like web browsing do not work fast enough on machines older than 15 years - and then 64 bit CPUs were common. It is reasonable to discontinue support here, as the limits of 32 bit are often reached and need special attention - for a really low gain.
 
32 bit CPUs have a place, 16bit CPUs have a place, 8 bit CPUs have a place.
The issue is "that place is shrinking".
Supported amount of physical memory is a limiting factor.
Modern browsers want lots of memory, so running a browser on a memory limited system, limits the usefulness.
Now using a 32bit system to actually serve data, no GUI, just CLI is probably still feasible
 
32bit CPUs have huge places on automotive ECUs. But those are "embedded of embeddeds", not at all for general purposes. Minimum mandatory performance and functionalities, but extreme durabilities are required.
(Recent engines require performance and integer precisions that cannot [or hard to] be achieved by 16bit or below CPUs. Off topic, but before, ECU standed for "Engine Control Unit", but recently, as other components started requiring controllers, stands for "Electronic Control Units")

If automotive consoles (dashboards or for rear seets) has web browser in it, it could be running on 32bit CPUs for more than another decades. Maybe proprietary OEM products if really implemented in ECUs.

But usually regularly sold tablets would be preferred for rear sheets, not connected to CAN network for automotive ECUs for security.
 
Even embedded devices are often cheaper if they use general-purpose hardware. A 64 bit chip is cheap nowadays, there need to be really good reasons not to use it, even if a 32 bit chip would fit the need.
 
DerTeufel said:
Even embedded devices are often cheaper if they use general-purpose hardware. A 64 bit chip is cheap nowadays, there need to be really good reasons not to use it, even if a 32 bit chip would fit the need.
Click to expand...
Sadly this is true. Alot of cost also is driven by peripherals. Modern stuff is highly integrated, older stuff not so much.

Now extend the automotive ECU to airplanes. Most airplanes are fly by wire so redundant controllers sw doing stuff.
ETA:
Sorry that sounds incomplete. The rest of the thought was modern hardware that is cheaper can/should be used, but the FAA gets very specific about things that are approved or not approved. Substitutions are hard to do
 
T-Aoki having been in that area for a decade, these HMI "silver box"es also run 64 bit CPUs now. At least they did when I wrote code for them. But you have to take into account the penny pinching of bean counters. So you get a system with some 64 bit MIPS cores and a multi threaded real time OS on that, only to find it has 64MB of main memory for all the nice features you are going to have - including a web browser that displays the POIs from archived, compressed HTML pages. Also the layer cake of HALs upon HALs drains every performance you might have. Some of my "little list of horrors" coding examples come from that time. BTW, CAN is mostly not a problem as long as you have a dedicated bus for HMI/entertainment (and don't even think about streaming movies about that, looking at a certain brand in the south *cough*). What can make your head spin is when the CAN gateway is not bridged correctly, so the power off broadcast from your radio which was meant to shut down external amps, microphone arrays, .... escapes and shuts down components on other parts - like power steering and engine control.

And please all, don't forget certification processes. The ECU software is certified for a system, and when you change that you need to re-do all that. This can be extreme to a point when NASA was gobbeling up all original 8086 chips from ebay they could find, since they were used in some launch control and it was still cheaper to pay 5 digits for them then re-run all the certification process. AUTOSAR is not much different, only that the manufacturers usually have the capacity to store a huge amount of these chips and don't need to redo the layout while the series is running. Well, at least untill some bean counter comes around and talks about "lean production"...
 
What's severe on automotive ECUs are heats, humidities and smokes.
To protect from humidities and smokes, ECU boards are often dipped into resins except for terminals or tightly sealed, making harder in heats.

So parts used, especially semiconductors and electrolytic capacitors are usually special automotive grades (at least ones inside engine compartments), not in generic grades, thus, automotive manufacturers were paniced on COVID19.
 
DerTeufel said:
They still do work, but current browsers run very slow on 32 bit only processors like Pentium 4 Athlon XP, older Intel Atom etc. I tried it also with Pale Moon, it is painfully slow.
Click to expand...
I had already abandoned 32-bit FreeBSD last year. However, losing the ability to use a HTML5 compatible browser on any 32-bit BSD or Linux has meant the end of 32-bit desktop use.

I have found that 32-bit virtual machines in a 64-bit VPS can save RAM which avoids going up to the next pricing tier. I haven't used that dodge for a while.
 
Crivens said:
T-Aoki having been in that area for a decade, these HMI "silver box"es also run 64 bit CPUs now. At least they did when I wrote code for them. But you have to take into account the penny pinching of bean counters. So you get a system with some 64 bit MIPS cores and a multi threaded real time OS on that, only to find it has 64MB of main memory for all the nice features you are going to have - including a web browser that displays the POIs from archived, compressed HTML pages. Also the layer cake of HALs upon HALs drains every performance you might have. Some of my "little list of horrors" coding examples come from that time. BTW, CAN is mostly not a problem as long as you have a dedicated bus for HMI/entertainment (and don't even think about streaming movies about that, looking at a certain brand in the south *cough*). What can make your head spin is when the CAN gateway is not bridged correctly, so the power off broadcast from your radio which was meant to shut down external amps, microphone arrays, .... escapes and shuts down components on other parts - like power steering and engine control.

And please all, don't forget certification processes. The ECU software is certified for a system, and when you change that you need to re-do all that. This can be extreme to a point when NASA was gobbeling up all original 8086 chips from ebay they could find, since they were used in some launch control and it was still cheaper to pay 5 digits for them then re-run all the certification process. AUTOSAR is not much different, only that the manufacturers usually have the capacity to store a huge amount of these chips and don't need to redo the layout while the series is running. Well, at least untill some bean counter comes around and talks about "lean production"...
Click to expand...
Yes, thus, 32bit ECUs are still "required" with proper "supports", even though newly manufactured models switches to 64bit.

And yes, aerospace area are far, far and far more stricter than automotive area (can any of you, who are not at all worked on the area, believe that even consuming parts like igniter plugs for jets are required to have serial numbers and all records on production retained per serial number?).

ISO/TS 16949 for automotive area is stricter than generic ISO 9001.
And JIS Q 9100 (equivalent with AS9100 and EN9100) for aerospace area is stricter than ISO/TS 16949.

Sorry, too offtopic here.
 
T-Aoki said:
And yes, aerospace area are far, far and far more stricter than automotive area (can any of you, who are not at all worked on the area, believe that even consuming parts like igniter plugs for jets are required to have serial numbers and all records on production retained per serial number?).
Click to expand...
Oh yes, been there done that, moved the metric tons of paperwork... And then you get management from the automotive area trying to build airplanes like they did before. Ideas like having the wire harness for a complete bloody plane made "just in time" by hand in some godforsaken place on the other side of the planet. "But it's cheaper, and they can react to changes much faster." And if things fail, you fly to the curb and wait for the tow plane - or what was the idea?
 
Crivens sounds like we've had some overlap on experience/customers. "Paperwork to justify that the line of code should be x=x-1 instead of x=x+1" fun times
 
vmb said:
However, losing the ability to use a HTML5 compatible browser on any 32-bit BSD or Linux has meant the end of 32-bit desktop use.
Click to expand...
iBook G4 makes a cool retro gaming laptop :cool: (it connects to my Wifi 6 router surprisingly; TenFourFox/32-bit old Firefox loaded some stuff with quick tests)

2026-01-26-16-19-51-963.jpg


Not too sure about FreeBSD's support on that laptop though for graphics (couldn't get installer started) or what games might be available; I'd start with devilutionx and doomsday!
 
You must log in or register to reply here.
Back
Top