13 ms·
The future of 32-bit support in the kernel
- shmerl 1y agoOn the userland side, there is some good progress of using thunking to run 32-bit Windows programs in Wine on Linux without the need for 32-bit libraries (the only edge case remaining is thunking 32-bit OpenGL which is lacking needed extensions for acceptable performance). But the same can't be said for a bunch of legacy 32-bit native Linux stuff like games which commonly have no source to rebuild them. May be someone can develop such thunking for legacy Linux userland.
- hinkley 1y agoWin32S but the other way around. Win64S?
- 5- 1y agomost of those games would have windows builds? that said, i sometimes think about a clean-room reimplementation of e.g. the unity3d runtime -- there are so many games that don't even use native code logic (which still could be supported with binary translation via e.g. unicorn) and are really just mono bytecode but still can't be run on platforms for which their authors didn't think to build them (or which were not supported by the unity runtime at the time of the game's release).
- shmerl 1y ago> most of those games would have windows builds? Yeah, that's a reasonable workaround, as long as it doesn't hit that OpenGL problem above (now it mostly affects DX7 era games, since they don't have Vulkan translation path). Hopefully it can be fixed.
- cwzwarich 1y agoIt shouldn’t be difficult to write a binary translator to run 32-bit executables on a 64-bit userspace. You will take a small performance hit (on top of the performance hit of using the 32-bit architecture to begin with), but that should be fine for anything old enough to not be recompiled.
- shmerl 1y agoI would guess so, but I haven't seen anyone developing that so far.
- Fulgen 1y agoIn some ways, Windows already does that too - the 32-bit syscall wrappers [switch into a 64-bit code segment](https://aktas.github.io/Heavens-Gate https://aktas.github.io/Heavens-Gate) so the 64-bit ntdll copy can call the 64-bit syscall.
- deleted 1y ago[deleted]
- eric__cartman 1y agoHow many of those legacy applications where the source is not available actually need to run natively on a modern kernel? The only thing I can think of is games, and the Windows binary most likely works better under Wine anyways. There are many embedded systems like CNC controllers, advertisement displays, etc... that run those old applications, but I seriously doubt anyone would be willing to update the software in those things.
- xeonmc 1y agoPerhaps a new compatibility layer, call it LIME -- LIME Is My Emulater
- ninkendo 1y agoLIME Isn’t Merely an Emulator
- dontlaugh 1y agoIn practice, the path for legacy software on Linux is Wine.
- majorchord 1y agoI have heard people say the only stable ABI on Linux is Win32.
- jnwatson 1y agoIt is amazing that big endian is almost dead. It will be relegated to the computing dustbin like non-8-bit bytes and EBCDIC. Main-core computing is vastly more homogenous than when I was born almost 50 years ago. I guess that's a natural progression for technology.
- Aardwolf 1y agoNow just UTF-16 and non '\n' newline types remaining to go
- hypeatei 1y agoUTF-16 will be quite the mountain as Windows APIs and web specifications/engines default to it for historical reasons.
- int_19h 1y agoIt's not just Windows and JavaScript. On Apple platforms, NSString is UTF-16. On Linux, Qt uses UTF-16 strings. Looking at languages, we have Java (which is where JS got this bug from) and C# both enshrining it in their respective language specs. So it's far more pervasive than people think, and will likely be in the picture for decades to come.
- electroly 1y agoICU (International Components for Unicode, the library published by the Unicode folks) itself uses UTF-16 internally, and most of these things are built on ICU. I agree strongly with your conclusion--UTF-16 isn't going anywhere. I don't think the ICU people are even talking about changing the internals to UTF-8.
- account42 1y agoQt could really change if they wanted to and really should have by now - it's not like they keep long-term backwards compatibility anyway unlike the others that you mentioned. Of course they chose to integrate JavaScript so that's less likely now.
- skywal_l 1y agoRemoving nommu feels wrong to me. Being able to run linux on a simple enough hardware that anybody sufficiently motivated could write an emulator for, help us, as individuals, remain in control. The more complex things are, the less freedom we have. It's not a well argumented thought, just a nagging feeling. Maybe we need a simple posix os that would run on a simple open dedicated hardware that can be comprehended by a small group of human beings. A system that would allow communication, simple media processing and productivity. These days it feels like we are at a tipping point for open computing. It feels like being a frog in hot water.
- lproven 1y ago> Maybe we need a simple posix os that would run on a simple open dedicated hardware that can be comprehended by a small group of human beings. That was part of the plan for Minix 3. Clean separation in a microkernel, simple enough for teaching students, but robust. But Intel used it and gave nothing back, and AST retired. :-(
- reactordev 1y agoWe need accessible open hardware. Not shoehorning proprietary hardware to make it work with generic standards they never actually followed. Open source is one thing, but open hardware - that’s what we really need. And not just a framework laptop or a system76 machine. I mean a standard 64-bit open source motherboard, peripherals, etc that aren’t locked down with binary blobs.
- EVa5I7bHFq9mnYK 1y agoAren't 32 systems more power-efficient? It costs less energy to switch 32 transistors than 64.
- ainiriand 1y agoWhat makes you think that a 32 bit system has 32 transistors? For example, from the top of my head, the pentium pro had a 86 bit direction bus and a 64 bit data bus.
- kimixa 1y agoOn anything but the smallest implementations, the 32 vs 64bit alu cost difference is pretty tiny compared to everything else going on in the core to get performance. And assumes the core doesn't support 32-bit ops, leaving the rest of the ALU idle, or does something like double pumping. Really the ALU width is an internal implementation detail/optimisation, you can tune it to the size you want at the cost of more cycles to actually complete the full width.
- octoberfranklin 1y agoIt's the MMU width, not the ALU width, that matters. Lots of machines are capable of running with 32-bit pointers and 64-bit integers ("Knuth mode" aka "ILP32"). You get a huge improvement in memory density as long as no single process needs more than 4GB of core.
- kimixa 1y agoI assume you mean "pointer width" - ala the x32 ABI and similar, and more about cache use than "Switching Transistor Count". But really that's a software/OS level thing, and though the benefits have definitely been shown, the seem small enough to not be worth the upheaval. Though possibly related, larger pages have been shown to have significant speedups without changing the ABI (as much, at least mmap() and similar will have slightly different specifics). IMHO the only possible "benefit" to 4kb page sizes is to (ab)use it to trap things like array overruns - though using that is a poor substitute for /real/ bounds checking - a lot can go wrong within 4kb, after all.
- Mathnerd314 1y agoLinux has become the dominant operating system for a wide range of devices, even though other options like FreeRTOS or the BSD family seem more specialized. The widespread adoption of Linux suggests that a single, versatile operating system may be more practical than several niche ones. However, the decision to drop support for certain hardware because it complicates maintenance, as seen here, would seem to contradict the benefit of a unified system. I wouldn't be surprised if it really just results in more Linux forks - Android is already at the point of not quite following mainline.
- charcircuit 1y ago>Android is already at the point of not quite following mainline. It follows the latest LTS which I think is reasonable especially since phone vendors wants to have support for the device for several years.
- jacquesm 1y agoFunny, I remember 32 bits being 'the future', now it is the distant past. I think they should keep it all around, and keep it buildable. Though I totally understand the pressure to get rid of it I think having at least one one-size-fits-all OS is a very useful thing to have. You never know what the future will bring.
- smitty1e 1y agoTechnologies have lifecycles. Film at 11.
- justin66 1y agoThere's always NetBSD. I'm pretty sure that's supporting x86 as far back was 80486 and 32-bit SPARC as far back as... something I wouldn't want to contemplate.
- petcat 1y agoJust because support would be removed from current and new versions doesn't mean the old code and tarballs are just going to disappear. Can dust off an old 32 bit kernel whenever you want
- SlowTao 1y agoAlways to option to fork it. Linux Legacy? Linux 32? Linux grey beard!
- nektro 1y agoimportant to remember that this fate isn't going to happen again with 64bit
- ry6000 1y agoI can’t help but wonder if kernel devs realize how much this discussion sounds like something you’d expect from Apple. They are talking about obsoleting hardware not because it’s fundamentally broken, but because it no longer fits neatly into a roadmap. Open source has always been about making hardware outlive commercial interest and let it run long after the hardware vendor abandons it. I'm pretty shocked to see comments like "the RAM for a 32-bit system costs more than the CPU itself", but open source isn’t supposed to be about market pricing or what’s convenient for vendors; it’s about giving users the freedom to decide what’s worth running. I understand that maintainers don’t want to drag around unmaintained code forever, and that testing on rare hardware is difficult. But if the code already exists and is working, is it really that costly to just not break it? The kernel's history is full of examples where obscure architectures and configs were kept alive for decades with minimal intervention. Removing them feels like a philosophical shift, especially when modern hardware is more locked down and has a variety of black box systems running behind it like Intel ME and AMD PSP.
- margalabargala 1y ago> open source isn’t supposed to be about market pricing or what’s convenient for vendors; it’s about giving users the freedom to decide what’s worth running. Ehhh, it's about users having the ability to run whatever they like. Which they do. If a group of users of 32 bit hardware care to volunteer to support the latest kernel features, then there's no problem. If no one does, then why should a volunteer care enough to do it for them? It's not like the old kernel versions will stop working. Forcing volunteers to work on something they don't want to do is just a bad way to manage volunteers.
- ry6000 1y agoThat is a fair point! I do think though that it would make sense for maintainers to at least put out an open call to users and developers before dropping something as fundamental as 32 bit support. The reality is that not all users are going to be kernel developers, and even many developers today aren’t familiar with the workflow kernel development requires. Mailing lists, patch submission processes, and the cultural expectations around kernel work are all a pretty steep barrier to entry, even if someone does care about the removal and also happens to be a developer. The other dynamic here is that the direction in Linux does come from the top. When you have maintainers like Arnd Bergmann saying they would "like" to remove support for hardware (like the ARM boards), that sets the tone, and other contributors will naturally follow that lead. If leadership encouraged a philosophy closer to "never break existing hardware" the same way we’ve had "never break userspace" for decades, we probably wouldn’t even be debating removing 32 bit. I’m not saying kernel devs need to carry the weight alone, but it would be nice if the community’s baseline stance was towards preservation rather than obsolescence. :(
- natas 1y agothe netbsd team agrees! more users for us.
- octoberfranklin 1y agoThe Apple Watch has 32-bit memory addressing (and 64-bit integer arithmetic -- it's ILP32). Granted it doesn't run Linux, but it's a very very modern piece of hardware, in production, and very profitable. Same for WASM -- 32-bit pointers, 64-bit integers. Both of these platforms have a 32-bit address space -- both for physical addresses and virtual addresses. Ripping out support for 32-bit pointers seems like a bad idea.
- deleted 1y ago[deleted]
- mrpippy 1y agoWith watchOS 26, S9/10 watches will be going to normal ILP64 ARM64. RAM limitations were one reason to use arm64_32, but a bigger reason is that the first watches were only ARMv7 (32-bit) so by sticking with 32-bit pointers, Apple was able to statically recompile all the 3rd party (ARMv7) apps from LLVM bitcode to arm64_32. https://www.macrumors.com/2025/06/16/watchos-26-moves-apple-watch-to-new-architecture/ https://www.macrumors.com/2025/06/16/watchos-26-moves-apple-...
- int_19h 1y ago64-bit memories are already in wasm 3.0 draft (and in any case this isn't a platform where you'd need the Linux kernel running).
- SAI_Peregrinus 1y agoWASM isn't being used to run the Linux kernel, it's run by an application on top of an OS. That OS can be 64-bit, the WASM VMs don't care.
- wibbily 1y ago> One other possibility is to drop high memory, but allow the extra physical memory to be used as a zram swap device. That would not be as efficient as accessing the memory directly, but it is relatively simple and would make it possible to drop the complexity of high memory. Wild, like some kind of virtual cache. Reminds me a bit of the old Macintosh 68k accelerators; sometimes they included their own (faster) memory and you could use the existing sticks as a RAM disk.
- chasil 1y agoUnfortunately, I am still using a 32-bit kernel using high memory. It was caled "PAE" - physical address extensions. $ cat /proc/version Linux version 2.6.18-419.0.0.0.2.el5PAE ... (gcc version 4.1.2 20080704 (Red Hat 4.1.2-55)) #1 SMP Wed Jun 28 20:25:21 PDT 2017
- doublepg23 1y agoWhy? Industrial controller?
- webdevver 1y agoi do miss being able to read and memorize hex addresses. 64 bits is a little too long to easily 'see' at a glance. or see at all for that matter.
- greatgib 1y agoIt's the end of an area, Linux used to be this thing that was running on quite anything and allowing to salvage old computers. I think that there is a shitload of old desktop and laptop computers from 10 to 15 yrs that are still usable only with a linux distribution and that will not be true anymore. Now Linux will be in the same lane as osx and windows running after the last shiny new things, and being like: if you want it, buy a new machine that will support it.
- Dylan16807 1y agoDesktops and laptops from 10 to 15 years ago are basically all 64 bit. By the time this removal happens, we'll be at 20 years of almost all that hardware being 64 bit. By the time hardware becomes "retro", you don't need the latest kernel version. Lots of distros already dropped 32 bit kernel support and it didn't cause much fuss.
- account42 1y ago20 years isn't all that much though. We maintain houses for much longer than that so why should we accept such low lifetimes for computers.
- leoedin 1y agoBecause they're fundamentally different things? A house is a machine for providing weather protection. The difference between a modern house and an old one is pretty minor. A computer is a machine for doing calculations. The difference between a modern computer and an old one is - by more or less any metric you can think of - many orders of magnitude. Calculations per Watt, calculations per second, calculations per unit volume etc. It's not even like we're breaking them. This is just the maintainers of the Linux kernel choosing to not spend their time maintaining compatibility with the old architectures.
- Mashimo 1y agoYou might still be able to install linux, just not with the latest kernel.
- johnklos 1y agoSo Arnd Bergmann thinks that all future systems, embedded included, will have 64 bit CPUs? Or will embedded just stop using Linux and move to the BSDs?
- SAI_Peregrinus 1y agoEmbedded has already split: You've got 8-bit, 16-bit, and some in-between MCUs that never ran Linux in the first place. You've got 32-bit MCUs that never ran Linux in the first place. You've got FPGAs that never really even run software. And you've got "application processors" like the ARM Cortex-A series that get used for "embedded Linux" in some cases. ARM Cortex-A series won't release any more 32-bit ISAs, so that mostly just leaves RISC-V as a potentially-relevant 32-bit ISA that might get new CPU designs. That's a small niche within an already small niche in embedded. Most embedded systems aren't using Linux, they're using an RTOS or bare-metal code.
- adgjlsfhk1 1y ago8 and 16 bit are dying pretty rapidly. You can make some pretty tiny 32 bit CPUs (e.g. https://github.com/YosysHQ/picorv32 https://github.com/YosysHQ/picorv32 is a RV32 with only a couple thousand transistors). On a budget optimized process node (e.g. 28nm), the core is absolutely tiny and all of the cost comes from the (s)ram.
- SAI_Peregrinus 1y agoYeah, I expect them to get relegated to Chip–on–Board (the little black epoxy blobs you'll see in 4-function calculators, cheap multimeters, & the like) ASICs as integrated MCUs and as soft cores in some FPGAs. I'd only go with an 8-bit or 16-bit chip at the extreme end of cost–constrained ultra–high–volume design already, 32-bit MCUs are cheap enough for everything else.
- jtolmar 1y agoFrom the article: > The kernel is still adding support for some 32-bit boards, he said, but at least ten new 64-bit boards gain support for each 32-bit one. And > To summarize, he said, the kernel will have to retain support for armv7 systems for at least another ten years. Boards are still being produced with these CPUs, so even ten years may be optimistic for removal. Everything else, he said, will probably fade away sooner than that. So, no, he does not think that at all.
- stephen_g 1y agoThis seems pretty uninformed on the embedded side - the speaker is I'm sure very qualified generally but it sounds like mostly on the server/desktop side of things. Like on Armv7-M it's said "Nobody is building anything with this kind of hardware now" - this is just wrong to the point of ridiculousness. Thousands of new products will be designed using these microcontrollers and still billions of units will be produced with them in them - now, true that almost none of those will run Linux on those MCUs but it's crazy to say "nobody" is building things with them. Many of course are moving to Armv8-M microcontrollers but those are 32 bit too! On the Linux side, there are things like the AMD/Xillinx Zynq-7000 series that will be supported for many years to come. It's not the worst idea in the world to deprecate support for 32-bit x86 but it is not time to remove it for ARM for many years yet.
- Dylan16807 1y ago1. Until proven otherwise, let's assume that the speaker at the Linux conference was probably talking about Linux and saying something not ridiculous. 2. That sentence wasn't about 32-bit, it was about devices without MMUs.
- nagamsreekar 1y ago[dead]
- meisel 1y agoIt seems like it takes just one user using a certain piece of hardware to justify it being supported in the kernel, which is surprising to me. The cost to kernel dev velocity is not weighed more heavily against that?
- hamandcheese 1y agoSometimes, supporting special use cases like this can be a valuable exercise since it shows you all the places in your project that you made assumptions without even realizing it. It seems plausible to me that supporting niche users improves quality of the project as a whole.
- kstrauser 1y agoTo a point, yeah. Adding BE support to my (userspace) code revealed some bugs that affected LE, too. Oops! But you can take that too far, too. Like, go ahead and assume power-of-two aligned byte sizes. If someone wants to make an 11 bit byte, let them handle that in their own non-upstreamed fork. No user code’s going to work right on it anyway. You can be so flexible that it turns everything into a giant slog. I doubt 32 bit support is anywhere near that horrid; commenting on the idea more than this specific case.
- bjackman 1y agoIn general I don't think the marginal benefit of removing support for a certain piece of hardware would be significant in most cases. Most of the kernel is generic across a broad enough spectrum that removing one slice of that spectrum isn't likely to change its breadth. E.g. there's some stuff like erratum workarounds for old x86 CPUs that would be nice to drop, but they are part of a big framework for handling x86 diversity. Dropping individual workarounds doesn't let you drop the framework. Exceptions are gonna be cases where dropping the support removed something significant from the lowest common denominator. Big stuff like word size, memory ordering (I assume dropping Alpha would be quite handy), virtual address space limitations.
- SAI_Peregrinus 1y agoOne known user. Linux doesn't have automatic telemetry in every distro (or even most distros), the kernel devs don't really know how many people use. So if they know of one user, there are probably more users that just haven't come to their attention on the mailing lists.
- sylware 1y agoI have 32 bits support on my x86_64 gaming ring, _ONLY_ for the steam client. The "steam client" is still a 32 bits ELF executable, which statically loads openGL and x11 libs... (namely not even a wayland->x11 fallback or a opengl->CPU rendering). We would be all better with a nogfx static PIE executable, even a nogfx dynamic PIE executable if they want to explore the ELF setup of a distro.
- shevis 1y agoI’m surprised no one is talking about the 2038 problem.
- unregistereddev 1y agoThat is not specific to 32-bit system architectures. The 2038 problem is specific to timestamps that are represented as milliseconds since the Unix epoch and are stored in a 32-bit integer. It's quite possible (and common) to deal with 64-bit integers on a 32-bit system architecture. I am also surprised how little attention the 2038 problem gets. However, I also wonder how big a problem it is. We've known about it for years and all the software I've touched is not susceptible to it.
- SAI_Peregrinus 1y agoIt got fixed in the kernel & musl in 2020. It got fixed in glibc in 2021. Everything built against the currently-supported versions of those things will have 64-bit `time_t` since the headers are updated. It mostly only matters for proprietary programs distributed only as binaries that don't get updates, for systems that no longer get updates at all, and for people running computer history museum exhibits. Some distros take a long time to update, but even the longest don't have 17-year support cycles. I'm sure it'll cause someone some issues, but it'll be very niche by 2038. Most of the sorts of systems that it could cause problems for aren't being used to plan things years in advance, some probably don't even do anything with the date. So it's a niche within a niche (unupdatable systems used for future planning) that's likely to have problems soon, and overall probably no longer a big deal. TL;DR: It's solved upstream, only an issue for some systems that don't get updates.
- listeria 1y agoIt's actually seconds since epoch, not milliseconds. Here's a small program to verify it: date -u --date='2038-01-19T03:14:08' +%s | perl -ne 'printf "%#x\n", $_' It is also mentioned in perldoc Time::Piece [1], as a warning for people whose build of perl uses 32-bit integers for time. [1]: https://perldoc.perl.org/Time::Piece#Use-of-epoch-seconds https://perldoc.perl.org/Time::Piece#Use-of-epoch-seconds
- datenwolf 1y ago> There are still some people who need to run 32-bit applications that cannot be updated; the solution he has been pushing people toward is to run a 32-bit user space on a 64-bit kernel. This is a good solution for memory-constrained systems; switching to 32-bit halves the memory usage of the system. Since, on most systems, almost all memory is used by user space, running a 64-bit kernel has a relatively small cost. Please, he asked, do not run 32-bit kernels on 64-bit processors. Ohhh yes! So, a couple of weeks ago I came across a discussion where some distro (I don't remember which one) contemplated removing 32-bit user space support, suggesting to users to simply run a VM running a 32 bit Linux instead. It was a stupid suggestion then, and this statement is a nice authorative answer from the kernel side, where such suggestions can be shoved to.
- DrillShopper 1y agoProbably SuSE. We use SLES15 at work and their bizarre decisions in SLES 16 to remove X servers (except for XWayland), remove 32-bit libraries, and complete removal of their AutoYaST unattended install tool in favor for a tool that is maybe 25% compatible with existing AutoYaST files still baffles me. We spent months moving to SLES15 from a RHEL derivative a few years ago and now we basically have to do it again for SLES16 with as big as the changes are. We have some rather strong integrations with the Xorg servers, and Wayland won't cut it for us currently, so we're stuck unless we want to rearchitect 20 years of display logic to some paper spec that isn't evenly implemented and when it is, it's buggy as shit. I've been pushing hard for us to move off SLES as a result, and I do not recommend it to anyone who wants a stable distribution that doesn't fuck over its users for stupid reasons.
- chasil 1y agoRed Hat has removed i386 multilib in rhel10. "Linking against 32-bit multilib packages has been removed. The *.i686 packages remain supported for the life cycle of Red Hat Enterprise Linux 9." https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/10.0_release_notes/removed-features#removed-features-compilers-and-development-tools https://docs.redhat.com/en/documentation/red_hat_enterprise_...
- shasheene 1y agoI think this is premature and a big mistake for Linux. The costs of distros and the kernel steadily dropping older x86 support over the last few years never causes an outcry but it's an erosion of what made Linux great. Especially for non-English speaking people in less developed countries. Open-source maintenance is not a obligation, but it's sad there is not more people pushing to maintain support. Especially for the "universal operating system" Debian which was previously a gold standard in architecture support. I maintain a relatively popular live Linux distro based on Ubuntu and due to user demand will look into a NetBSD variant to continue support (as suggested in this thread), potentially to support legacy 586 and 686 too. Though a Debian 13 "Trixie" variant with a custom compiled 686 kernel will be much easier than switching to NetBSD, it appears like NetBSD has more commitment to longer-term arch support. It would be wonderful to develop systems (eg emulation) to make it practical to support architectures as close to indefinitely as possible. It does feel like a big end of an era moment for Linux and distros here, with the project following the kind of decision making of big tech companies rather than the ideals of computer enthusiasts. Right now these deprecation decisions will directly make me spend time working at layers of abstraction I wasn't intending to in order to mitigate the upstream deprecations of the kernels and distros. The reason I have used the kernel and distros like Debian has been to offload that work to the specialist maintainers of the open-source community.
- ezoe 1y agoIt's interesting that only objection for removing big endian is from IBM and their mainframe and PowerPC. Also big endian is restricted to 32bit in Linux kernel.
- wltr 1y agoI have some 32-bit systems (arm and x86), and it looks like I’m going to use them till the hardware breaks. The old x86 system is power hungry and inefficient, but the thing is, I power it on very occasionally. Like for half a day once a month. So its power consumption isn’t an issue. Probably I should consider some BSD for it. But what should I do with an arm system, if that’s applicable, I have no idea.