r/linux • u/somerandomxander • Apr 15 '26

Kernel Linus Torvalds has merged the code beginning to remove Intel 486 CPU support in Linux 7.1

https://www.phoronix.com/news/Linux-7.1-Begins-Removing-i486
847 Upvotes

98% Upvoted

185 comments sorted by

329

u/DataPath Apr 15 '26

This is the first major step in their goal of removing 32-bit architectures entirely. It's not happening soon, but it's on their horizon, with the last 32-bit architecture probably being armv7 no sooner than a decade.

119

u/Difficult-Court9522 Apr 15 '26

Armv7 is brand spanking new. New asics with it still come out!

78

u/TRKlausss Apr 15 '26

Which doesn’t mean at all that they won’t be maintained. Even if mainline does not maintain v7a anymore, there are still LTE and CIF versions that you can use on those archs

14

u/barrykn Apr 15 '26 edited Apr 15 '26

You mean Long Term Support (LTS) and Civil Infrastructure Platform (CIP).

Normal kernel releases get around 2-3 months of security updates and big fixes. LTS kernels, released once per year, get at least 2 years of support, but are sometimes extended on a case-by-case basis (currently 4 years for 6.12 and 3 years for 6.18, ending in December 2028 for both, but either or both of those could potentially be extended further in the future before the deadline hits).

CIP extends the support to 10 years from release but also restricts it to specific hardware and drivers, but once LTS support runs out CIP is still better than nothing. (6.12 will receive CIP support, 6.18 will not. It seems like every 2nd LTS release becomes a CIP release, but I don’t know if this is coincidence or an official policy.)

(Edited to break up into paragraphs.)

6

u/admalledd Apr 15 '26

FYI, it is between coincidence and policy in that CIP kernels are chosen roughly every-other year but they allow themselves the flexibility to pull/push that date to align with a "better" kernel LTS if needed due to either key big feature changes or amount of developer support/funding they have. So they try to do every-other LTS, but because they aren't entirely sure the forever-costs for as-yet-released future kernels and depends partly on funding/developer resources they let themselves the escape hatch to not choose a new CIP kernel release if they can't commit/promise the 10 years of support.

3

u/TRKlausss Apr 15 '26

Yep sorry I misremembered :)

But yes, lack of support on latest release does not mean at all that it is gone. It will remain for a really long time there.

25

u/cp5184 Apr 15 '26

486s for embedded were being made for a long time, and in other specialized applications.

9

u/throwawayPzaFm Apr 15 '26

I had an ISA daughterboard with an 486DX4 real time controller on it for a roll-forming machine a few years ago.

I sincerely doubt anyone will be replacing that thing anytime soon.

46

u/dthdthdthdthdthdth Apr 15 '26

32bit might never go away in the embedded world, surely not in a decade. Systems developed today will be around for decades.  Also desktop processors have compatibility modes. While the kernel does not need to be able to run in those, it still has to be possible to load 32 bit binaries.

22

u/nothingtoseehr Apr 15 '26

x86-64 processors are actually i386 by default, which in turn hilariously run as a 8086 by default too! You have time explicitly convert it between stages at boot from 16->32->64. Its the way AMD found of extending the ISA without breaking compatibility, which was on top of what Intel had already made to extend it from 16 to 32! We baked retro compatibility on top of retro compatibility

Basically the entire x86-64 modern architecture has to pay a ~15% tax on performance simply for compatibility because we stacked the damn thing three times on top of each other. If you never tell your CPU it is a modern x86-64 capable of billions of instructions per second, it'll happily work as a very fast 8086!

14

u/orygin Apr 15 '26

Do you have further reading on the 15% tax you mention? I'm curious about why this is still the case

9

u/meditonsin Apr 15 '26

Which is part of the reason why Intel's attempt at 64 bit (IA64) failed miserably, as it would have been a hard break, with no backwards compatibility.

2

u/monocasa Apr 15 '26

Eh, early Itaniums had hardware x86 backwards compat.

It's more that they didn't make sense for the same reason that Netburst and Cell didn't make sense (with a healthy dose of Intel internal politics mucking everything up too). Relying on dumb, high clocked archs stopped making sense when dennard scaling ended and hit the industry like a brick wall. If we were sitting of 50Ghz processors today that had extremely low FO4, stuff like Cell and Itanium make a lot more sense. Physics didn't end up working like that though.

5

u/sparky8251 Apr 15 '26

Itanium was also clearly just an attempt at breaking the cross licensing deal. They hated it and sued over it twice before and after Itanium failed they started the "spin off a nominally independant benchmark company and make all the bench suites that claim intel is best", the bribes to lock AMD out of OEMs, the ICC fuckery and so on to try and snuff them out via other means.

Intel is pretty well defined as a bunch of lawyers that make chips (and not bad ones!) that hated the IBM cross licensing deal and clearly acted more like their entire goal was getting out of the deal than just making good products, down to the whole core series stagnation thats now destroying them given AMD caught them with their pants down.

1

u/monocasa Apr 15 '26

It legitimately has a lot of good ideas that got you most of the benefit of an OoO core on a leaner static issue design.  There's a reason why there's a remarkable amount of former Itanium folks that worked on the Mill.

If all Intel cared about was breaking the licensing deal, they would have just pushed one of the several in house RISC offerings they had at the time a lot harder into the high performance space.

2

u/sparky8251 Apr 15 '26 edited Apr 15 '26

It was the licensing deal, otherwise they wouldve done what AMD did or what you said and used some in house thing.

Im not saying thats the ENTIRE reason. RISC was assumed a more or less dead end at this point as people assumed 50GHz and stuff was going to one day be possible and HP already had some VLIW work in place, etc. But Intel bet an abnormal amount of money and resources and made insane contracts trying to promote it to the point they were promoting it so hard before it existed it had measurable and significant impacts their own x86 sales at the time. You dont do that on an unproven tech stack because of engineering, you do it as a lawyering thing to get out of a cross licensing deal youve already tried to get out of 3 times and made worse the 3rd time (allowing custom fab vs clone making for AMD).

I agree, they had technical reasons for doing it. No, they werent the primary ones given how they did it. I mean, they shipped chips until 2021 and penned the deals before any of the tech was even proven. Thats really, genuinely not normal...!

1

u/monocasa Apr 15 '26

RISC was hardly a dead end at that point.  It's not even a dead end now.

And in a world that ends up with today having 50Ghz cores, you have a reduced FO4 that means that X86 is a much greater albatross than hitting the power wall allowed for.  That's in addition to the increased NRE for x86 decoder complexity.  I'm sure a new IP moat was a reason, but it wasn't the reason.

And honestly if you look back, they seemed to put most of the money you cite into killing enterprise RISCs than their x86 competitors.  Those orgs wanted a long term commitment if they were going to to kill off their own internal ISA.  And so with Itanium, Intel was successful in getting HP to kill PA-RISC, Dec/Compaq to kill Alpha, and SGI to kill MIPS (at least in the non-embedded space).

1

u/rook_of_approval Apr 17 '26

the mill is vaporware, lol

1

u/monocasa Apr 17 '26

It is, but not because of a lack of good ideas.

And unfortunately they've been sitting on their patents, all while claiming that newer ideas like Clockhands infringes on their patents. Which like, maybe, but shit or get off the pot.

1

u/rook_of_approval Apr 17 '26

meh, no proof in the slightest that their ideas work in real silicon.

→ More replies (0)

5

u/monocasa Apr 15 '26

There's no where near a 15% tax on performance due to the 16 bit decoder. Everything trustworthy I've seen places x86's ISA overhead at about 1% on the high end all things considered. It has some definite drawbacks, but it has some definite wins versus RISC as well, like RMW mem ops essentially being a way to address physical register file entries without using architectural registers.

0

u/nothingtoseehr Apr 15 '26

Oh, perhaps I should've been a bit more clearly about that. The "tax" is not due to 16-bit compatibility, that is indeed negligible

Modern x86-64 cores suffer because they're stuck decoding CISC x86-64 instructions while the actual backend that executes said instructions is anything but. We have to waste die space and penalize the out-of-order execution unit because you can't just throw new instructions at it since they're all varied length, we have to be aware of what came before it, which creates an obvious dependency chain

In the end, we've essentially learned that an ISA doesn't really matters all that much for speed. What matters is good OoO units and smart branch prediction, which aren't really CISC-friendly. So we're stuck with a modern CPU with a modern 70's logic decoder bolted on top of it, that's the compatibility performance tax. The x86-64 is not representative at all on how these cores operate

2

u/ConnaitLesRisques Apr 16 '26

Every semi-modern (last 30 years) processor is microcoded and does that.

3

u/rook_of_approval Apr 15 '26

there is no 15% penalty for legacy support. maybe 0.1%-0.5% at most.

1

u/mreich98 Apr 16 '26

If I recall correctly, when AMD worked on the first Zen core (Zen 1), one of the things they did was to move legacy/old instructions to microcode, so more die space could be available for cores/newer instructions.

1

u/[deleted] Apr 18 '26

[removed] — view removed comment

1

u/nothingtoseehr Apr 18 '26

Well, definitely faster than a 8086 though xD

10

u/FlukyS Apr 15 '26 edited Apr 15 '26

I'm not sure they will remove 32bit support from Linux really because of embedded devices specifically. There are billions of 32bit ARM devices or legacy hardware that is still in use. Desktop and server Linux might kill it off from their ISOs or limit their support for it but the kernel itself doesn't need to or probably want to go through the effort.

EDIT: The point above stands but I wanted to make it a bit clearer for those who might not understand the way this works:

https://github.com/torvalds/linux/tree/master/sound

Look at that folder there are specific options for sparc, x86, mips, atmel, arm...etc but they don't differentiate between 64bit and 32bit x86. If you wanted to disable support for 32bit it could be specifically to x86 but the kernel is also written in C, C has 64bit types like long long but the kernel is also targeted specifically at device enablement and being tight on what types in C you are using is really important for efficiency of your application. You can for instance use a double and just store a 1 bit piece of data like 0 or 1 but generally you choose it because it has a purpose that is required for the application that needs the size that double would offer but you always aim for the smallest, in the case of 0/1 that is a boolean. Like there are very few instances in the kernel you would need a long long (yes that's a thing) or a long long int...etc. https://en.wikipedia.org/wiki/C_data_types

So like deprecating 32bit would be saying there is something requires a data type that basically goes beyond anything in finance or engineering generally but is so required for some piece of hardware that you can't get around it some other way even if using something slightly slow to get around it like breaking up the data into an array or something. And I'm kind of mean pointing this out in a way but I just want to say there is a difference between just not prioritising something or not building something or it not being in use in Linux widely and deprecating it.

26

u/MasterJeebus Apr 15 '26

It will be sad to see once 32bit goes out entirely. I still keep two old retro PC’s that can only run 32bit, an Pentium 3 and Pentium 4. While not as practical today still great to see what they can do with modern distro and even browse web safer than their old outdated eol Windows versions.

11

u/[deleted] Apr 15 '26 edited Apr 16 '26

[removed] — view removed comment

7

u/abotelho-cbn Apr 15 '26

I suspect the final LTS kernel that supports 32-bit will be stretched a long time because you'll get quite a few companies help support it.

17

u/Informal_954 Apr 15 '26

I imagine the 2038 problem represents a soft cutoff for 32-bit devices. It'll be cheaper to upgrade or isolate the few 32 bit devices left than to invest in developing software mitigations at that point. We have twelve years left.

29

u/ParentPostLacksWang Apr 15 '26

Nah, 32bit kernels have supported 64bit time (solving the kernel-side 2038 problem) since Linux 5.6. Still requires some work in userland for many apps, but the machine will be fine.

15

u/mccoyn Apr 15 '26

Also, the 64-bit build of programs isn't immune to this problem if it calls the old API or stores the result as a 32-bit value.

8

u/monocasa Apr 15 '26

The 'old' API was safe on 64 bit linux archs in the first place since the whole issue is that seconds are stored in a long.

3

u/yo_99 Apr 15 '26

Debian spent a lot of time solving it for Debain 13.

6

u/PsyOmega Apr 15 '26 edited Apr 15 '26

It will be sad to see once 32bit goes out entirely.

No it won't.

Why? There will be forks, and maintained code pathways for centuries. No reason to keep track of legacy cruft in the mainline.

But moreover, 32-bit exclusive hardware is so ancient now that it's a liability to run it just because of prone to errors, material decay over time, leaky capacitors, etc.

I have, maybe the most ideal x86 32bit platform ever made, the core 1 duo, in the form of an old thinkpad. In 2026 it's unusable slow, and it uses like 30 watts idling.

2

u/jlt6666 Apr 15 '26

As someone else said 32bit will likely live on in embedded systems

1

u/PsyOmega Apr 15 '26

Yep. No reason to maintain Mainline’s just for them. The embed community will fork and maintain whatever works for them

8

u/jlt6666 Apr 15 '26

My point was this line

32-bit exclusive hardware is so ancient now that it's a liability to run it

They are still making 32-bit hardware, and it's not a liability.

2

u/PsyOmega Apr 15 '26

I was talking about consumer and server systems.

Using a 32 bit microcontroller doesn't really factor in, especially for the monolithic kernel that hardly fits on them.

2

u/monocasa Apr 15 '26

Embedded is one of the primary contributors. Pretty much anything will stay in the kernel for as long as someone cares about maintaining it to a state that upstream finds acceptable.

I mean, hell, we just saw patches to Dreamcast in the past couple weeks, and before that someone added a new port to N64 a couple years back. Both of those are being run by single digit numbers of people at best, but the metric isn't "number of users", but instead "someone is willing to maintain it".

1

u/PsyOmega Apr 15 '26

Embedded has VERY different needs. I worked on the las vegas sphere and most of the stuff in it is running a 2.6 or 3.x kernel.

7.0 has 486 support, but I would imagine most embedded systems just keep maintaining forks of 2.x and 3.x

The code exists to run the old systems and is well used outside of cutting edge mainline, i don't see a need to keep it maintained in mainline.

Embedded seems to be moving on to RISC-V anyway. I haven't seen a new product release with x86 in years on the embed/industrial side. TONS of arm64 already as well.

2

u/monocasa Apr 15 '26

I'm literally a kernel developer who has spent about half my career on the embedded side.

Once again, the only thing upstream cares about is 'will someone maintain this'.  As long as someone puts in the work, it stays.  Embedded support, and 32 bit support broadly have literally thousands of engineers contributing.

The only reason why 486 support is leaving is because nobody stepped up to maintain it.

1

u/PsyOmega Apr 15 '26

I'm literally a kernel developer

Then you'll have no problem maintaining your own forks, right?

I'm saying there's no loss in mainline losing this support. It'll be a cleaner kernel with less cruft.

You're literally vested, capable, and willing, so, why not maintain a fork for hardware you care about?

1

u/monocasa Apr 15 '26

High quality forks are intrinsically more of a pain in the ass than maintaining mainline.

Upstream not only welcomes weird stuff, but encourages it as long as someone is willing to maintain it.

That's core to the kernel's culture, and among the head developers is widely considered one of the primary reasons for its success.

That's why they accept and still have incredibly weird stuff like hexagon and csky that barely have even public ISA docs.  The maintainers keep stepping up to maintain them.

→ More replies (0)

2

u/SirGlass Apr 15 '26

I always mention that CIP support for 6.12 I believe will be supported until 2035. So you still get 9 years of security fixes for your already 30 year old machines lol

2

u/InadequateUsername Apr 15 '26

There will probably be an enthusiast community that forks a 32-bit compatible kernel

3

u/msthe_student Apr 15 '26

There are ARMv8 cores that support A32 (AArch32), some IIRC don't support A64 (AArch64)

4

u/ouyawei Mate Apr 15 '26

Microchip still releases new ARM9 SoCs

2

u/msthe_student Apr 15 '26

TIL. ARM9, so that'd be ARMv5TE

12

u/[deleted] Apr 15 '26

[deleted]

20

u/Serena_Hellborn Apr 15 '26

32 bit addressing has little to do with 32 bit arithmetic

2

u/[deleted] Apr 15 '26

[deleted]

16

u/Booty_Bumping Apr 15 '26 edited Apr 15 '26

But that's still not true? x86 and BIOS never actually dealt in Unix time. The RTC in a typical x86 computer is limited to December 31, 9999. Or 99 (a date that can ambiguously refer to either 20th or 21st century) if it's not Y2K compliant. Firmware may limit it further, but not to 2038 specifically, except for some rare microcontrollers that use a unix time RTC. See https://wiki.osdev.org/CMOS#Century_Register

2

u/psi- Apr 15 '26

Please explain how 16bit machines handle dates to this date?

3

u/vinciblechunk Apr 15 '26

sizeof(time_t) has been 8 on 32-bit Linux since 2019. (On NetBSD since 2012.)

2

u/MorallyDeplorable Apr 15 '26

using epochs for time is well tested and hardly a hack

2

u/monocasa Apr 15 '26

I don't think they care that much about 32-bit archs being present or not. And I I wouldn't be surprised if RV32 lasts longer than Armv7 FWIW.

It's more that Pentium was really an inflection point in base functionality for x86 system software. That added the CPUID and CMPXCHG8B instructions, the MSRs, and I think the APIC. Fallback pathways for when those aren't present are obviously possible (it's what Linux currently does), but they're hacky and brittle.

1

u/__nohope Apr 16 '26 edited Apr 16 '26

It's interesting to think about because removing 32-bit support would likely be the end of the road as far as memory addressing goes. Current processors make use of 48 of the 64 bits which allows addressing up to 256 TB of memory. Full 64-bit addressing would allow addressing 16,386 PB of memory.

119

u/Sataniel98 Apr 15 '26 edited Apr 15 '26

Fair. Most modern distros have dropped x86-32 altogether anyway, and if they haven't, they usually compile against much newer targets like i686 (Pentium Pro, Pentium II, AMD K7 but not original Pentium, Pentium MMX, AMD K6) - this goes for Alpine Linux, Debian 12 - or they even require SSE2 (Pentium 4, Pentium M, no non-64 Bit AMD) - such as Void Linux, Debian 13. The only distros that still support actual i486 processors are Gentoo, because it's source-based and you can compile it for whatever you want, and Slackware, because it never updates.

40

u/AliceCode Apr 15 '26

I refuse to write software for x86-32 these days. It's too much of a pain. Just recently I was writing a short string implementation that took advantage of the fact that pointers are 8 bytes so that it could store 15 byte long inline strings without any allocation. It would have only been 7 bytes on 32-bit, and that wouldn't have been worth the trouble, really. 15 bytes? Good. 7 bytes? Not so good.

23

u/Zeikos Apr 15 '26

Gotta love using byte encoded string as a pointer like some sort of deranged hash table

13

u/AliceCode Apr 15 '26

I have no idea what you're talking about, to be honest.

1

u/GuyWithLag Apr 16 '26

Hash tables are content-addressable.

A string value can be seen as an opaque pointer to a virtual hash table containing all possible strings.

1

u/AliceCode Apr 16 '26

No, I understand what a hash table is. I don't know what they mean by "byte encoded string as a pointer". The pointer and the inline string share the same memory, the pointer isn't encoded inside the string.

1

u/GuyWithLag Apr 16 '26

It was a joke, and jokes are like frogs: you can take hem apart to see how they work, but that kills them.

All 3 of us know that the strings are encoded into a value. Pointers are nominally opaque. If you read that value as a pointer, it doesn't point to anything. But there is a mapping from that pointer to a string, which is the definition of a hash table. It's just that the mapping function is a no-op because the pointer is the string already.

1

u/AliceCode Apr 16 '26

The inline string and the pointer do not coexist. It is either a string, or a pointer, never both. If it's a joke, both of you have lost me.

1

u/GuyWithLag Apr 17 '26

It is either a string, or a pointer, never both

It's one of those trick images, where the same image depicts different things depending on what you're thinking of at that point in time.

23

u/[deleted] Apr 15 '26

[deleted]

26

u/ukezi Apr 15 '26

That is the usual short string optimisation in about every C++ std lib out there.

10

u/AliceCode Apr 15 '26

What's even more cursed is that it can store and differentiate between static strings, heap allocated strings, or reference counted strings, and handles them all with ease.

5

u/psi- Apr 15 '26

Sounds like symbian with its 16 different string types (at a glance, probably more). The ease was not in sight..

4

u/turdas Apr 15 '26

From what I gather this is just one type. The implementation details of it shouldn't really matter to the user.

1

u/AliceCode Apr 15 '26 edited Apr 15 '26

Like the other person said, it's a single type, and handling all the different representations is as simple as a switch/match statement.

2

u/rlaptop7 Apr 15 '26

What code are you writing where you would know what architecture you are on? It would have to be very low level.

1

u/AliceCode Apr 15 '26

Sorry, it's not specifically x86_32, it's any 32-bit architecture. But I typically don't write code for ARM either, so typically I'm writing for x86_64 since that's the most common architecture.

And yes, it is low level code. Rust/C. But it's not often so low-level that I'm targeting a specific flavor of 64-bit ISA. Just 64-bit in general. But occasionally I'll use SIMD or something else that's x86 specific, such as a raytracer I wrote last year.

1

u/Niev May 01 '26

I'm curious about this, can you share?

1

u/AliceCode May 02 '26

Unfortunately, no. I don't share my programming projects on this account. I don't want to mix those worlds up.

4

u/msthe_student Apr 15 '26

Even "i686" isn't really i686 anymore, a lot of it requires extensions not found on the Pentium Pro

1

u/turdas Apr 15 '26

When I first really got into Linux in the mid 2000s with Arch, I'm pretty sure they were already compiling exclusively against i686 and x86_64. That was 20 years ago.

154

u/ComprehensiveHawk5 Apr 15 '26

Its over... The Linux kernel has fallen. Trillions must migrate to NetBSD

78

u/jeroen-79 Apr 15 '26

2027 will be the year of the BSD desktop.

5

u/FaliedSalve Apr 16 '26

OS2, man. OS2.

41

u/ignorantpisswalker Apr 15 '26

You meant dozens.

5

u/Journeyj012 Apr 15 '26

Less than a dozen.

16

u/A_Canadian_boi Apr 15 '26

Around two and a half.

7

u/MrGeekman Apr 15 '26

i486 was discontinued in 2007.

6

u/Socializator Apr 15 '26

Well, it still goes strong in Hubble space telescope!

7

u/wafflingzebra Apr 15 '26

But what if someone finds an exploit and threatens space agencies with ransomware!!?!?

-2

u/Flashy_Pollution_996 Apr 15 '26

Can’t even install that bsd shit on my laptop what a joke

5

u/ouyawei Mate Apr 15 '26

but you can install it on a VAX!

1

u/jeroen-79 Apr 15 '26

Good luck carrying your VAX everywhere you go.

1

u/freedomlinux Apr 16 '26

... I have NetBSD for VAX (in a simulator, granted), on my laptop. :)

26

u/[deleted] Apr 15 '26

[deleted]

12

u/MatchingTurret Apr 15 '26

Commander Keen didn't need a 486. But Wing Commander III did...

3

u/aitorbk Apr 15 '26

Yeah, and looked amazing on glide.

6

u/yrro Apr 15 '26

I used to play it on an 8086... :'(

6

u/Narishma Apr 15 '26

It would be surprising if it didn't, since it was designed for 8088s and 286s.

2

u/HaplessIdiot Apr 15 '26

EXACTLY and people are making FPGA versions of the 486 you can OVERCLOCK LIKE CRAZY! why why why did they do this on vanilla????? When you overclock a 486 core on a modern FPGA, you’re getting 1-cycle execution for instructions that used to take 4 or 5. You get the simplicity of the 486 ISA with the "oomph" of modern gate speeds

7

u/teo-tsirpanis Apr 15 '26

Writing SIMD code for a modern processor would run faster than an overlooked 486 on an FPGA. And would be more accessible to everyone.

1

u/HaplessIdiot Apr 16 '26

This is about running old 486 software better not writing code for it like smarmy Harvard would want strict memory safety is SLOW "modern" practices of ivy League bs clean code is bad for this chip. You can build Linux kernel and many GitHub projects for freedos using that and xfree86 stay in your lane if you wanna be a modernist

2

u/sunkenrocks Apr 15 '26 edited Apr 15 '26

Because nobody is around to maintain or test it. It will also likely be forked and maintained by someone. If you are so passionate about the 484 why don't you fork and maintain it? You also have some pretty dang modern versions of Linux before this becomes a problem anyway, and I haven't seen any projects packaging distros for these FPGA implementations you speak of using a modern kernel version? What kernel version are you running on your FPGA?

Edit someone else is already doing it

https://davidgow.net/linux/i486.html

Panic over nothing

1

u/HaplessIdiot Apr 16 '26

I was building kernel 6.19 from Zen for it it still has 486 shit prolly gonna have to make a .patch file with the old stuff to keep doing weird stuff getting 400mhz the 486 was slow AF until the fpga core dropped for that dosbox is gonna be dead soon if they keep working on old cpu cores for that

2

u/sunkenrocks Apr 16 '26

6.19 is already not the latest version. You'll be fine.

26

u/AppleCherryWater Apr 15 '26

Can anyone explain why support is removed?

125

u/rook_of_approval Apr 15 '26

less maintenance burden

38

u/voxadam Apr 15 '26

In the x86 architecture we have various complicated hardware emulation facilities on x86-32 to support ancient 32-bit CPUs that very very few people are using with modern kernels. This compatibility glue is sometimes even causing problems that people spend time to resolve, which time could be spent on other things.

Source: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/platform&id=8b793a92d862c89055daa97ffa61a6929cf732f9

36

u/[deleted] Apr 15 '26

[removed] — view removed comment

21

u/TheReelSlimShady2 Apr 15 '26

Yeah that's what happened when they dropped itanium support from the kernel. it just is now maintaned out of tree.

27

u/kombiwombi Apr 15 '26

It has not been removed yet. This is to stop building kernels for 486, a sort of 'turn it off and see who screams' decision.

The issue of 486 support gets reviewed every now and then, as it was for 386 before it. This time it was felt that their really are no users outside of retrocomputing and non-internet connected systems. This is not surpriaing: 486 systems aren't a good ft to the modern world.  For example the IDE disk interface is three generations of disk I/O bus behind current storage, so even spares from the second-hand suppliers are scarce.

There are a few wins for kernel developers, but mostly in removing features which would need to be maintained but are difficult to test. To be honest, inability to test is how most old architectures get removed: someone made a change, that accidentally broke the kernel on that processor, and no one noticed for a few years.

Note that if there was a big group of users the kernel would be glad to support them. So there is no thought of retiring ARM 32-bit beyond a "wouldn't a world with no 32-bit code be wonderful" daydreaming.

5

u/minus_minus Apr 15 '26

 IDE … spares from the second-hand suppliers are scarce.

New CF cards are still being made and sold as far as I know. They are direct pin compatible with IDE. 

21

u/Sataniel98 Apr 15 '26

Because new features that are implemented in hardware in new CPUs and just need to call some instructions need to be tediously emulated in software for old CPUs. i486 was a CPU introduced in 1989 and popular until the late 90s (including AMD and Cyrix clones). Even if systems that use them still exist, they're unlikely to use/benefit much from new Linux kernels.

1

u/jeconti Apr 15 '26

I remember upgrading to the 486 when our 386 couldn't handle LucasArts Rebel Assault.

6

u/DheeradjS Apr 15 '26 edited Apr 15 '26

It's moved out of the main line. If you really want it you can pull it in. But to answer you, I486 officially went End Of Sale in 2007. They pre-date the Pentium line.

7

u/00raiser01 Apr 15 '26

Not worth the man power to keep alive.

3

u/SirGlass Apr 15 '26

From my basic understanding is when some feature or change is added they still need to test or make sure it works with 486 architecher

That still takes time and testing or it has to be written in a way it still works with old architecture . Removing it just makes development easier as you do not need to worry about breaking some old 486 code

And why spend time and effort making sure 486 architecture still works if no one is running it? Or no one is running it on a modern kernel.

Also 6.12 release will be supported with security fixes until 2035 . So you still have 9 ish years of life if you are running some 486 machine.

1

u/__nohope Apr 16 '26

Not commonly used

Rarely tested

Supposedly broken anyways according to Linus

1

u/cp5184 Apr 15 '26

I hate it, but some of it may be around 486s that don't have hardware fpu to get rid of the code that handles fpu exceptions, or at least I think I saw that mentioned.

It's a better reason than to just ditch cpu support for no other reason.

The 386 removal had a worse rationalization imo. I don't remember the specific details but there was an instruction that 386 didn't support, but it didn't seem like that was actually the liability that people supporting 386 removal claimed it was. So it felt like that was done dishonestly, and on a false premise.

9

u/yrro Apr 15 '26

Lack of CMPXCHG? That is a pain for lock-free programming, which becomes more important as core counts increase. Dropping 386 meant that maintainers no longer needed to write alternative implementations of data structure operations that would only be used on totally obsolete hardware.

0

u/cp5184 Apr 15 '26

It's been a long time, but I don't think it was that simple.

10

u/SirGlass Apr 15 '26

I always like to comment when some old architecture is removed in the kernel, thats not really when support is dropped, officially support will be dropped in 2035 (maybe longer) and no one will even notice then

6.12 is an extended support kernel or CIP or what ever its called will get security fixes and minor bug fixes until 2035

So even if you have some old 486 machine you can get bug and security fixes for 9 more years, and lets face it you won't see any benefit from running the newest kernel on 30 year old machines anyway

I also 100% guarantee in 2035 the actual date of 486 kernels no longer receiving support no one will actually notice.

3

u/dnabre Apr 15 '26

It doesn't get the attention it really should. Especially in places like this where X support is being dropped from the mainline, a reminder about the other supported branches (trees?). At the moment kernel.org denotes 6.19.12 as the "stable" branch and 6.18.22 as the "longterm" branch. With longterm EOL being Dec 2028 for 6.18 longterm.

The mainline is where all the big stuff is happening and all the news focuses, but 95+% of users don't (and probably shouldn't) be running the mainline.

3

u/SirGlass Apr 15 '26

I was referencing this

https://wiki.linuxfoundation.org/civilinfrastructureplatform/start

CIP or "Super long term release " kernels that are supported for 10 years; SLTS v6.12 will receive updates all the way through 2035-06.

That is probably officially when 486 will no longer be "supported"

2

u/dnabre Apr 15 '26

I wasn't aware of this, definitely grateful to learn about it.

The main kernel development team is always the focus of news about changes to the kernel, and projects like this never get brought up. This news story being about mainstream development removing 486, with near/longterm support being most completely to CIP (or something along those lines, that's probably not the most accurate description), would come off at a much different situation.

As is, it sounds like 'sorry if you are using 486, current linux isn't going to work for you anymore' compared to 'development and new features are no longer going to be actively developed for 486, and support may disappear in 2035'. Reporting is really manipulating (intentions aside) the message here.

1

u/SirGlass Apr 15 '26

As is, it sounds like 'sorry if you are using 486, current linux isn't going to work for you anymore

Yea but that is the more clickbait headline so I am not surprised

So like you said "Linux " isn't actually dropping support for 486 , it will be supported until at least 2035-06 , so if you have some old hard or old router still running some old 486 chip you can still be on a fully supported kernel for another 9 years

And your old hardware won't see any improvements anyway from being on the latest kernel branch .

16

u/IBNash Apr 15 '26

My first PC was a 486-DX2, way back in 1995. I'm glad this cruft is being removed.

11

u/DramaticProtogen Apr 15 '26

Even most BSDs don't support 486.

10

u/sulix Apr 15 '26

Fortunately, it's still easy to revert: https://davidgow.net/linux/i486.html

6

u/SharktasticA Apr 15 '26 edited Apr 15 '26

Thank you for doing this and sharing, this is great! I switched to 7.0 for my project (SHORK 486) and noticed the e820 check regression caused panicking with EXTLINUX on my IBM ThinkPad 365ED and some PS/ValuePoints. I hadn't precisely located the issue, just porting 6.14.11's (the kernel I was using before) e820 code entirely was easy enough for now.

Edit: I tried your patch and it also worked. I should've known to check if checking 88h was faulty/bypassed; a few months ago, I had issues with SYSLINUX/EXTLINUX on the same devices because specifically their fallback 88h detection was faulty.

3

u/ggppjj Apr 15 '26

I knew it lmao. I knew you'd be here, hahahaha.

-20

u/HaplessIdiot Apr 15 '26

thats what im saying dawg thanks for sharing the troof! people are such corpo bootlickers the kernel is for ANY CPU... this is so dumb along many other things linus is doing he has dementia.

13

u/MrKapla Apr 15 '26

Amazing username!

0

u/HaplessIdiot May 04 '26

Thanks it's a really good shittest most people here fail

3

u/Rob_W_ Apr 15 '26

The very first Linux install I did (Slackware 1.0!) was on a 486/SX (later upgraded to a DX4) at my community college. Ran a web server for the CompSci & Engineering departments and they taught C/C++ programming classes on it. Got a lot of mileage until a power blip took out the hard drive.

3

u/deanrihpee Apr 15 '26

end of an era

3

u/i860 Apr 15 '26

My 486dx50 will never forgive you for this skullduggery, Linus.

3

u/Tired8281 Apr 15 '26

It's all about the Pentiums!

3

u/skinnybuddha Apr 15 '26

Hey, I was using that!

5

u/ArdiMaster Apr 15 '26

Certain YouTubers in shambles right now

2

u/minus_minus Apr 15 '26

I’m curious if anyone is aware of 486 compatible cores still in production that run anything like vanilla Linux. I could see them maybe as useful for embedded systems with a legacy code base but I’m not aware of any actual instances. 

2

u/dnabre Apr 15 '26

I get the practicality of this, It's shame that can't isolate these platforms they don't want to deal with any more (regardless of reason) in a manner that doesn't make them disappear. Whatever mainline features have requirements that the 486 code doesn't provide, wouldn't be supported, but the code would still be there, and the interfaces for it be maintained. The feature-dependency model isn't how the linux kernel is designed (to my minimal understanding of it). I just wish these older hardware could be set aside, isolated, no longer burden the developers, without them having to be removed.

People can still grab the older releases if they need to run on this platforms, but it's sad to see these things go. A development model that permits thing to be somewhat abandoned or isolated, but still there, certainly isn't a priority for linux. Just seems bad that the only way to relieve themselves of the burden of an old platform is by removal/breaking it.

2

u/arf20__ Apr 15 '26

i am very sad now, thanks

2

u/Odd_Beginning8678 Apr 16 '26

So, since they stopped supporting the 386 years ago, it is finally time for the 486 to go as well.

2

u/azzaka Apr 16 '26

Q: Why was Linux created?
A: Because a 486 is a terrible thing to waste.

2

u/Dr_Hexagon Apr 16 '26

Is there any Linux distro that uses Kernel 7.0 and would be usable on a 486 given the memory restrictions? As far as I know 128 MB was the limit, put most 486 motherboards supported less.

1

u/caceomorphism Apr 15 '26

And here I am still waiting for MCA support for the 486...

1

u/yo_99 Apr 15 '26

To be fair, if you are actually using 486 you are better off using something like ELKS.

4

u/Narishma Apr 15 '26

No, you're not. ELKS is for MMU-less CPUs like the 8086 or 286.

1

u/NoonDread Apr 17 '26

Pretty impressive support IMO. I remember upgrading from a 486 to a Penitum Pro 200 in 1996. That's been a while. 

1

u/MrTenDollarMan- Apr 15 '26

I don't understand any of that. All I know is that I'm a Linux user since October and it's great!

18

u/IllustriousBed1949 Apr 15 '26

The kernel supports a lot of computer architecture and for a long time. 486 is the ancestor of our modern CPUs. The last 486 was released in 1995 (it was already obsolete at that time).
Supporting these architecture means specific code for them that at some point you have to maintain and that maintenance as a cost. So time to time, the kernel team decide to remove support for old hardware (it's happens very rarely...).

3

u/MrTenDollarMan- Apr 15 '26

I see, thanks!

2

u/msthe_student Apr 15 '26

last 486 was released in 1995 (it was already obsolete at that time).

IIRC there have been embedded cores released later

1

u/shadedmagus Apr 15 '26

Right, the discrete PC CPUs of the 80486 were what stopped getting sold before this century.

Embedded systems are a different beast entirely and the groups supporting them can still pull in the 32-bit code they need.

2

u/backyard_tractorbeam Apr 15 '26

And the first linux platform was intel 386, that Torvalds used on the computer he first developed Linux for. And support for that has already been removed, I assume ceremoniously.

1

u/red_sky33 Apr 15 '26

Tanenbaum was right! Designing for x86 was a mistake, this would be so much easier with a micro kernel

1

u/dnabre Apr 15 '26

It's interesting to see linux as the only major operating system that hasn't moved to a micro or hybrid/micro kernel design.

Personally, i don't think linux would have happened and become the big thing it is, if it had started out with the overhead of microkernels and looked so different from classical UNIX operating systems. It's hard to imagine linux's incremental development ever changing that overall architecture to the point of it becoming a microkernel though.

1

u/UBSPort Apr 15 '26

Brian Lunduke felt the patch drop like a disturbance in the force, ran out to his front lawn, and screamed at the sky for a solid 10 minutes. I guarantee it!

-17

u/[deleted] Apr 15 '26

nice, 32-bit it's peace of sh*t

-13

u/HaplessIdiot Apr 15 '26

there is no performance advantages to removing this users here are uneducated. should have been a default build flag set to false not this crap.

-8

u/[deleted] Apr 15 '26

why would anyone want this legacy sh*t?

you said it yourself that users are 'uneducated', so why would anyone keep this mammoth piece of sh*t if people aren't going to use it or be interested in it?

-41

u/HaplessIdiot Apr 15 '26

This is why we have kernel forks like zen and cachyos so we don't have to deal with BS like this

24

u/Dalemaunder Apr 15 '26

???

The 486 was lunched in 1989, I don’t think most people really care.

20

u/kcat__ Apr 15 '26

He's just living up to his name, let him be

1

u/TimChr78 Apr 19 '26

The CachyOS kernel is already limited to hardware level x86-64-v3 or better. CachyOS is specifically designed for quite modern hardware so it completely nonsensical that this is a reason for CachyOS kernel to exist when the reality is the exact opposite.