[LWN] The future of 32-bit support in the kernel
Posted by the_gnarts@reddit | linux | View on Reddit | 104 comments
Posted by the_gnarts@reddit | linux | View on Reddit | 104 comments
Ok-Winner-6589@reddit
Most distros don't Support 32 bit kernel neither, and if 2038 would end with issuesaybe continue the support for a Technology that is gona die is a bit dumb
the_gnarts@reddit (OP)
2038 is the hard cutoff. What broken bindings is he referring to? Rust’s
libccrate is a moving target.MeatSafeMurderer@reddit
Common misconception. By using an unsigned integer you can extend it to 2106. And there are ways of representing time since the epoch that do not rely purely on seconds and therefore will not overflow in the same way, at the same time. An example would be using two integers, one for seconds that counts up to 3600, before resetting and one for hours since the epoch which gets incremented once every cycle. Of course this means more memory usage...but who really cares at this point?
Of course none of these solutions will work with older software without updates, but it's not true that it's a hard cutoff. It's only a hard cutoff if nothing is done.
Piotrekk94@reddit
If you can introduce breaking changes why bother with your alternatives, just use 64-bit time_t
MeatSafeMurderer@reddit
Because that's only possible on 64bit hardware; not that many people are running 32bit systems these days, but there are a few holdouts and ostensibly the only reason to maintain 32bit builds is to maintain compatibility with 32bit software running on 32bit hardware.
If that's not a factor, then yes...you can use 64bit time_t, but if you do need it to run on a 32bit system you need to think outside the box a little.
Piotrekk94@reddit
There is no hardware limitation, compiler can split operations on values wider than native with into multiple instructions. Actually Debian plans to implement this for 32 bit ARM https://wiki.debian.org/ReleaseGoals/64bit-time
boar-b-que@reddit
Why would 2038 be a hard cutoff?
Multi-byte and multi-word data structures are things that exist. Yes, they're more complex than single-word and single-byte instructions, but we already use them all over the place.
I think people are a bit too hasty to write off old computers. People still use 8 and 16 bit computers... primarily for gaming, admittedly, but they DO still use them. I don't see 32 bit systems just completely turning into pumpkins 13 years from now, even if their hardware date can't be set correctly.
For industrial computers, I'm absolutely CERTAIN that companies will continue to nurse their ancient hardware along, just like there's pre Y2K hardware still limping along ALL OVER THE DAMN PLACE.
Don't plan on junking that 32 bit machine just yet.
kedstar99@reddit
From an environmental, security perspective this seems nuts no? Most of these machines are significantly lower performance relative to a raspberry pi 5/4b.
The energy cost in a year is about the same cost as replacing with a given raspberry pi 5.
Albos_Mum@reddit
From an environmental perspective, you're forgetting that power consumption isn't the only factor to consider:
Where will these junked systems go after junking? What's the ecological cost of having to produce enough extra modern chips for each customer to replace their 32bit systems? What about the people who are on 64bit capable systems, but very early ones that aren't much faster than the outgoing 32bit systems?
I could go on, but I won't.
kedstar99@reddit
Sure, but there is already quite a strong comparison point with those goods. White goods like fridges and lightbulbs.
In both cases the recommended advise is recycle the old goods and replace with something significantly more energy efficient.
Heck realistically it is possible to get rid of the good and replace it entirely with a VM in the cloud. At which point the resources to make a new rig is a bit moot no?
Albos_Mum@reddit
That's not a strong comparison point though, the key difference is that older PCs aren't completely inefficient in every single performance metric the same way an old lightbulb is nor are they outright toxic to specific parts of the environment and very likely to end up exposed as the refrigerant in an old fridge is.
For one, we only reached the kinda power usage typical of modern CPUs by the time 32bit chips were already on their way out with quite a large portion of the whole 32bit x86 family at full utilisation using similar amounts of power to modern chips specifically designed for low-power at full utilisation, with only the final generations reaching TDPs similar to what we'd expect from performance gear today. Accordingly if you don't need the extra performance and especially if you won't benefit from it, then you might find that even a low-power modern chip won't even save you much in the way of power...This is also why the 386 & 486 lasted until 2007 by the way, they were good enough to work as the brains for a huge amount of machinery (Probably still would be too, honestly) and low power enough that more modern designs didn't really make sense for a very long time.
kedstar99@reddit
They are? Everything from Harddisks + 20 years of silicon innovation + CPU vulnerabilities + advances in cryptography make those machines obsolete. They can be entirely replaced with fanless machines (a la Apple or rpi ARMs).
MrAlagos@reddit
There is a thing in environmental analysis called "life cycle assessment". It is a method to compare two things for their environmental impact based on actual scientific method and not in vibes. As the name implies, it quantifies and considers all the environmental impacts of a thing in its life cycle, therefore eventing is included from manufacture to usage and then to disposal.
Without something like this it's impossible or incorrect to just assume that replacing old hardware is always better from an environmental perspective compared to continuing to use the old hardware. It all depends on the specific cases.
mrlinkwii@reddit
no , its not ,
no its not its miles difference , even a 10 year old system isnt worth it due to power consumption and the price of elecrtrity in the likes of europe
kedstar99@reddit
Okay, so the lack of memory space makes ASLR junk. The lack of PCID support makes swapping page tables and every kind of syscall 2x slow given meltdown. There is a strong lack of hardware modern crypto-ops, no boot attestation (what exactly is the security perk here for this old platform?). This is on platforms that won't get new microcode updates with known significant hardware vulnerabilities.
Yep, the raspberry pi 5 trounces the fuck out of these old systems. Living in the UK with a 27p per kwh, we can do the maths pretty simply assuming 8hr usage. It costs 47 quid assuming a 60W power consumption (pretty reasonable for the old junker) versus 5 quid for the raspberry pi 4b?
I work for one of these hardware companies and did my masters thesis on power profiling of software, want to try again before talking?
2rad0@reddit
Only recently, pi5 is the only one that can arguably handle gigabit ethernet.
kedstar99@reddit
Am running my 4b at gigabit ethernet for my wireguard vpn?
2rad0@reddit
Can you transfer 4 billion bytes a second?
kedstar99@reddit
Have tested with Speedtest-cli from multiple node points and yes they all get gigabit speeds.
2rad0@reddit
Must have been a hardware upgrade, https://forums.tomshardware.com/threads/raspberry-pi-4-network-speed-slower-than-expected.3511216/
kedstar99@reddit
Possibly, all my nodes are designed to be on Ethernet and to minimise power consumption so WiFi is disabled anyway.
cp5184@reddit
Couldn't they just make it an unsigned integer and put it off till like 2100 or something?
boar-b-que@reddit
You could do it that way, but negative 32bit Unix epoch is used in some systems to represent pre-1970 dates. It'll go back to around 1902 if used that way. SFAIK, we don't have any living folks older than 123 years old, so it's literally good enough for government work in that regard.
As is plainly obvious, the solution is to use a 64 bit word to store your timestamp, but there's almost no reason that you can't use a 64 bit word on a 32 bit system aside from increasing your technical debt. You have to have at least a few people around who are willing to work on multi-byte and multi-word encoding schemes.
SilentLennie@reddit
It's a hard cut off from old 32-bit system calls (that's software/libraries aka APIs), this has nothing to do with 32-bit hardware, there are system calls on Linux for 32-bit hardware to 'survive' after 2038, but I think they might still be incomplete.
Niautanor@reddit
Not for desktop computers but there are still lots of embedded systems that use Linux on 32-bit processors used in products with a long service life like cars
SilentLennie@reddit
You misunderstood, this is true. But does the same apply to 2038 ? Do you think new embedded systems will still have them less than 64-bit processors ?
nightblackdragon@reddit
They are usually not trying to use recent software on it. They are far too slow to handle any modern task so what would be the point of running recent software on them?
Even old 64 bit Intel or AMD CPUs are too slow for modern every day use. Current 32 bit only CPUs will be essentially useless for any modern task in 2038.
Important_Lunch_9173@reddit
Maybe too slow for you.
mrturret@reddit
That really depends what that task is. For many industrial machines, a C64 is probably overkill, and they were pretty commonly used as controllers back in the day.
nightblackdragon@reddit
That C64 won’t be running fresh kernel build but old software.
odsquad64@reddit
Not well, anyway
veryusedrname@reddit
Watch me! (please don't, I'm joking)
mrlinkwii@reddit
they mostly dont need a modern kernal , and have specific life expectancy
commodore512@reddit
At that point the last ia32 only Netbook CPU would be 28 years old and even then, there are faster Pentium 4s made 5 years prior. Even the intel Edisons (of which didn't sell well) would be 19 years old.
Even a weirdo like me wouldn't use
polongus@reddit
not everything is about desktop CPUs. there are billions of deployed embedded devices running Linux on 32-bit cores.
wRAR_@reddit
Sure, are they running modern kernels that will be periodically updated to newer ones?
polongus@reddit
yes. if you're building a new low-end embedded linux device today, grabbing something like this would not be an uncommon choice.
that's a 32-bit system with advertised production through 2035.
hak8or@reddit
Haven't you heard, the non existent s in IOT stands for security!
Albos_Mum@reddit
Embedded goes far deeper than cheapo consumer-facing IoT devices, to be fair.
Even the oven at the bakery I worked at was controlled by a 486SX, for crying out loud.
polongus@reddit
yep not surprising when in this thread there's at least two people arguing we should just ship old kernels for the next decade.
Dr_Hexagon@reddit
Except this almost never happens for cheap IoT stuff. Buy an IoT device now and expect to still be getting kernel updates in 10 years?
Maybe if it's B2B and comes with a subscription support model but consumer IoT stuff just gets left to rot with unpatched security holes.
polongus@reddit
there's a vast ecosystem between the desktop and the cheapest possible IoT device running on an ESP8266.
hak8or@reddit
You would be surprised, most companies who design and sell chips are EE focused with very little understanding of software. To them, as long as they get a board support package with a kernel that's at least 10 years old, they are happy and will never upgrade the BSP.
casept@reddit
The company I work for uses 32-bit ARM in several projects and we're preparing to upgrade our kernels. It's really not that rare.
mrlinkwii@reddit
they can always use old/current kernals
polongus@reddit
and that's why the S in IoT stands for security.
mrlinkwii@reddit
manufacturers should be using said parts but whatever
syklemil@reddit
It's not hard to imagine some oblivious user keeping a product past EOL around because it still does its job (and participates in a botnet on the side). A lot of us hate replacing hardware that still works. See also: The amount of WinXP systems that are still around.
At some point the responsible thing to do becomes to brick the devices, which also makes people incredibly angry. Permanently disabling networking might be an alternative for some products, though aforementioned IoT products aren't gonna be very usable in that case.
polongus@reddit
what exactly do you base that on?
reputable vendors are absolutely pushing armv7 products TODAY with 10+ years of guaranteed availability.
mrlinkwii@reddit
you shouldnt be using 32bit only cpus in 2025 ( due the inherent limitations with 32bit ) i know their used to cut costs and corners but common
polongus@reddit
sorry but this is just an ignorant take.
commodore512@reddit
Oh, I was thinking the scope of OP was IA32. I'm sure 32-bit RISC will be supported until at least 2050.
polongus@reddit
yeah, I should probably watch the actual talk. the article opens with this engagement bait
but the pictures from their slides show they are quite aware of the embedded reality.
popcapdogeater@reddit
The problem is there's only so many people available and willing to maintain legacy systems and legacy support puts a growing burden on the overall project, sometimes that burden is minor, sometimes not.
I don't know the answer. I accept that eventually old code has to just go. I don't like e-waste, so I certainly don't want things deprecated too quickly in the name of "progress"
mrlinkwii@reddit
no they dont and if they doi their using older not current kernals
mrturret@reddit
Things like industrial machinery and infrastructure that uses hardware that old is still in common use. There's an entire industry around making boards compatible with 80s and 90s DOS software.
ilep@reddit
Sure, you could be clever and use better formats, but many people are not. Many programs are written in a hurry to ship and "will fix it later", then forgotten since it "just works".
You could use unsigned time_t to extend the limit, like NFS protocol does. That would certainly help push it past the limit. You could also use 64-bit time_t in a 32-bit program if you wanted to.
But like there are solutions, there are problems that come from elsewhere. There are industrial PLCs with custom timeformats that will rollover far sooner than the 32-bit signed Unix timestamp.
wRAR_@reddit
Yeah, it's only a cutoff for broken software, not for all of it.
CrazyKilla15@reddit
It is, sadly, subject to egregious backwards compatibility issues that make fixing many bugs very difficult, because if it ever releases a breaking update, due to how foundational it is, and how often libc types appear in public APIs, it breaks thousands of downstream crates. The infamous "libcpocalypse". See also https://github.com/dtolnay/semver-trick. I dont think theres any good writeups of "the libcpocalypse" and what exactly it entailed, sadly.
Also relevant is https://github.com/rust-lang/libc/issues/3248 which specifically mentions 64-bit time issues on 32-bit targets, among other breaking issues.
nightblackdragon@reddit
I agree that Rust could use more stability but “libcpocalypse” was in 2015 when Rust was still a new thing. Ecosystem stability takes time, Rust was just starting in 2015.
CrazyKilla15@reddit
You seem to be fundamentally misunderstanding the problem.
The libcpocalypse happened in 2015, and not since, because libc has not released breaking changes to avoid causing another. Not because "2015 is ages ago and Rust is beyond that now".
Literally just read the issues I linked on the libc repo about breaking changes that they want to Someday make, which will necessitate another libcpocalypse because thats what kind of just happens when a major foundational crate has a breaking update
LonelyResult2306@reddit
at this point im convinced rust is a cult
nightblackdragon@reddit
I'm not misunderstanding the problem, I'm saying that libapocalypse was not as big deal as it seems because in 2015 Rust ecosystem was far from stable and things like that are expected. The fact they are planning to do more changes like that and the fact that a many popular Rust crates don't provide stable API is the reason why I said that Rust could use more stability.
CrazyKilla15@reddit
You clearly are, because your comment makes no sense to me. It doesnt matter when the libc crate releases a breaking change, in 2015 or today. If it releases a breaking change, all the crates downstream of it will be affected.
If anything, this is more true now, because even more crates depend on it, have it in their stable APIs, etc.
I just can't see how you have come to the conclusion that libc can release a breaking change today and have the fallout be not a big deal
SmileyBMM@reddit
This is one of the big reasons I soured on Rust personally. I love the core language and it's memory safe nature, but it seems to have inherited a bunch of the core issues Python also has.
CrazyKilla15@reddit
I dont really think so? This isnt an issue with Rust, this is an issue with a very popular crate that happens to be maintained by the Rust developers, which has very strict compatibility requirements to ensure your code keeps working, and a strong desire to avoid requiring every one of the millions of crates that directly or (mostly) indirectly depend on it to have two major versions of it in their dependency tree, or have to have a coordinated update all at once.
Pythons issues are usually considered to be its batteries included standard library full of obsolete modules. Rust does not have a batteries included standard library full of obsolete http clients.
libcis not part of the standard library, It is an external crate.Theres no language that can avoid these issues, because these are issues with simply having dependencies used by a lot of people. Even C can't avoid these issues, because most of the issues are due to the sometimes subtle complexity of C across different targets and platforms. Thats why most cross- or often even single- platform C project of moderate complexity are full of
#defineand#ifdefguards based on platform, platform version, C compiler, C compiler version, C library version and type(musl, glibc, bionic, other??),feature_test_macros.7, etc. It is very difficult to bind to or natively work with "arbitrary C library, in a way that is compatible with all of them"gmes78@reddit
This issue stems from C, though?
thomas_m_k@reddit
From reading this, it seems the problem is that on 32-bit systems, C programs find the
time_ttype they want through preprocessor magic which doesn't work on Rust? So it's unclear whichtime_ttype Rust should bind to on 32-bit systems.syklemil@reddit
If we look at e.g. the source for
libc::time_tonarmv7-unknown-linux-gnueabihfwe can see that it does support agnu_time_bits64flag to aliastime_ttoi64instead ofi32, though.muslis apparently all 64-bit already, and i686 is dying or dead already with Debian dropping support, so the problem seems to be restricted to GNU libc on architectures like 32-bit ARM.I don't know whether there's more logic that needs to be applied, or if he by "broken" means "willing to be compatible with 32-bit systems that are not Y2038-ready".
syklemil@reddit
Yeah, we can look up the current
libc::time_toni686-unknown-linux-gnuand see that it's an alias fori32, but it seems like it needs to play some more advanced guessing game to figure out if it's on a 32-bit installation of a distro wheretime_tisi64, e.g. if it's on Debian <= 12 or >= 13 (though 13 also wound up dropping i386 support).There is something of a guessing game already: If we look at the source we see that there's a provision for
gnu_time_bits64which will setlibc::time_tto be an alias fori64.I guess ultimately part of the issue is that Rust could just set it to be
i64, but then it'd break compatibility with old, broken systems that can't handle Y2K38. And the Debian < 13 systems likely didn't all vanish in a puff of smoke as soon as Debian 13 appeared last month (especially since the Debian 13 release notes indicate that they stopped supporting i386 and that users of that should reinstall as amd64 or retire the hardware; likely I should've used some arm triplet instead ofi686as the example).Twig6843@reddit
Who the fuck is using x86 in 2025?
thesaddestpanda@reddit
A bazillion embedded systems, legacy systems, etc.
Kevin_Kofler@reddit
Grrr, what should I run on my LG G Watch R then? Will I be stuck with the ancient vendor kernel that AsteroidOS ships forever? Things are currently looking somewhat promising to get reasonable postmarketOS support for this watch eventually, but the mainline kernel desupporting the CPU architecture would end that pretty quickly.
bubblegumpuma@reddit
PostmarketOS would probably run the last 32-bit version of the kernel or a fork of that which retains the 32-bit support. That device already uses a 'close to mainline' kernel rather than the actual mainline Linux kernel anyway, as is the case for a lot of Qualcomm devices in PmOS.
Provoking-Stupidity@reddit
You can't keep supporting dead EOL stuff forever, it just holds everything else back.
polongus@reddit
32 bit processors are very far from EOL.
mrlinkwii@reddit
they mostly are EOL
Minkipunk@reddit
not at all, look at the STM32MP1 series for example https://www.st.com/en/microcontrollers-microprocessors/stm32mp1-series.html
These are used to run Linux on embedded devices.
polongus@reddit
just as one example, look here:
https://www.nxp.com/products/nxp-product-information/nxp-product-programs/product-longevity:PRDCT_LONGEVITY_HM
i.mx6/7 products have longevity guarantees through 2035.
hereforthepix@reddit
Yup. There's more to Linux than servers and desktops/laptops; I just helped a client deploy on a 32-bit ARM they're going to sell for another decade.
SteveHamlin1@reddit
I hope the device manufacturer is contributing money and/or developer time to the "keeping 32-bit kernel working" efforts.
hereforthepix@reddit
NXP (et al.) are selling container-loads of these things and do have their own parallel kernel trees
nekokattt@reddit
except for things like modems and routers...sure
Luceo_Etzio@reddit
They hang on (for now) in microcontrollers, embedded systems, and specialty stuff, but yea for general computing purposes, they're floating down the river.
polongus@reddit
perhaps what /u/mrlinkwii doesn't realize is that the embedded linux market dwarfs linux on the desktop, and even outnumbers linux servers by some counts.
syklemil@reddit
Yeah, people like GKH will point out that the vast, vast majority of Linux kernels these days are running on stuff like phones.
The proliferation of VMs means that there are more kernels running than physical servers, but I don't really expect the amount of VMs / person to rival the amount of phones / person.
astrobe@reddit
Phones are definitely not a good example. As TFA points out, the vast majority of smartphones are on 64 bits, only low-end phones for kids or elders.
The problem is that systems running armv7 are typically "invisible"; that is, they don't have to show a GUI on a color (touch)screen. GUI stuff is expensive in every way (CPU, but also RAM and storage), especially if you have the "good" idea of using a browser for that (GUI with GTK/Qt/FLTK is more affordable - but then you can't easy-hire web developers...). It is still doable but it limits both what you can do with the GUI and your main functionality. When the GUI consists in e.g. a monochrome LCD panel, like an air-conditioning system or a simple VoIP intercom, a 32 bits system can easily manage.
syklemil@reddit
Eh, I still think it shows that what we think of a traditional GNU/Linux server or desktop isn't the main body of Linux kernels (or glibcs) running around the world. Like both the "I got Linux running on my toaster" and all the "I found Linux running in the wild" show, there's more of it that most of us just don't know about because its job is mainly to be invisible, and not really recognisable as "a computer".
On the server and desktop markets, 32-bit is dead and really has been for a while, but that doesn't mean that we have any inkling of what the linux-on-the-toaster-and-in-the-lightbulb market is like.
polongus@reddit
no they are absolutely not.
realitythreek@reddit
I’ve not used 32bit hardware in about 10 years but interesting talk. And to anyone worried, this is only kernel and not userland so steam would be fine.
nekokattt@reddit
So what chip does your WiFi router/modem have?
wRAR_@reddit
My current router has aarch64. My previous router, bought 9 years ago, had armv7, sure, but it died this year and didn't support .11ax.
nekokattt@reddit
My router is using a BMIPS4350 chip, which is running MIPS32. The most recent routers for companies like TPLINK are still using ARMv7 hardware (such as Archer GXE75). So 32 bit is still definitely in use in general for low powered tech.
HttpCre@reddit
Any modern router that isn’t absolutely dirt cheap is probably running on 64-bit silicon…. and if it is 32-bit then you probably won’t be getting any updates anyway..
realitythreek@reddit
Honestly no idea, and to your point it could be 32bit ARM. Although my understanding is newer routers are have 64bit processors/kernel.
mrlinkwii@reddit
it should be removed ( with some sort of soultion for 32bit software like the way windows dose it )
Kevin_Kofler@reddit
A lot of devices supported by postmarketOS are 32-bit only!
mrlinkwii@reddit
still dosent make them not ewaste
SteveHamlin1@reddit
You're confusing GUI-focused consumer hardware with embedded systems that the article placed a good amount of focus on.
Modern industrial systems/controllers running on 32bit chips are very, very common, and not e-waste in the slightest.
Kevin_Kofler@reddit
If the devices still work, they are not eWaste.
revcraigevil@reddit
Even Debian is dropping support for i686/32-bit. Trixie has no upgrade path for it.
wRAR_@reddit
But not armhf, yet.
patrakov@reddit
Am I the only one surprised that the MIPS architecture is only mentioned in the comments?
the_gnarts@reddit (OP)
MIPS32 is listed in the chart with ingenic and ath79 tagged active.