The Linux Kernel May Finally Phase Out Intel i486 CPU Support (phoronix.com) 154
"Linus Torvalds has backed the idea of possibly removing Intel 486 (i486) processor support from the Linux kernel," reports Phoronix:
After the Linux kernel dropped i386 support a decade ago, i486 has been the minimum x86 processor support for the mainline Linux kernel. This latest attempt to kill off i486 support ultimately arose from Linus Torvalds himself with expressing the idea of possibly requiring x86 32-bit CPUs with "cmpxchg8b" support, which would mean Pentium CPUs and later:
Maybe we should just bite the bullet, and say that we only support x86-32 with 'cmpxchg8b' (ie Pentium and later).
Get rid of all the "emulate 64-bit atomics with cli/sti, knowing that nobody has SMP on those CPU's anyway", and implement a generic x86-32 xchg() setup using that try_cmpxchg64 loop.
I think most (all?) distros already enable X86_PAE anyway, which makes that X86_CMPXCHG64 be part of the base requirement.
Not that I'm convinced most distros even do 32-bit development anyway these days.... We got rid of i386 support back in 2012. Maybe it's time to get rid of i486 support in 2022?
Towards the end of his post, Torvalds makes the following observation about i486 systems. "At some point, people have them as museum pieces. They might as well run museum kernels. "
Maybe we should just bite the bullet, and say that we only support x86-32 with 'cmpxchg8b' (ie Pentium and later).
Get rid of all the "emulate 64-bit atomics with cli/sti, knowing that nobody has SMP on those CPU's anyway", and implement a generic x86-32 xchg() setup using that try_cmpxchg64 loop.
I think most (all?) distros already enable X86_PAE anyway, which makes that X86_CMPXCHG64 be part of the base requirement.
Not that I'm convinced most distros even do 32-bit development anyway these days.... We got rid of i386 support back in 2012. Maybe it's time to get rid of i486 support in 2022?
Towards the end of his post, Torvalds makes the following observation about i486 systems. "At some point, people have them as museum pieces. They might as well run museum kernels. "
Commercial OS (Score:5, Insightful)
If nobody is willing to pay for it, and nobody is willing to do it for free, then it might as well go away as it's clearly not all that important.
If there's some maintenance need then somebody can pay to maintain a fork, and backport security patches.
Re:Commercial OS (Score:5, Interesting)
A guy I know from college is still checking and maintaining 486 compatibility on his mid-90s era 486/33. He's been doing it since pre-1.0 Linux. Not the most glamorous volunteer work, but it's astonishing to think that he's been doing it for almost 30 years for no other reason than his own amusement.
Re: (Score:3)
Re:Commercial OS (Score:5, Informative)
Is there an embedded microcontroller that has the entire ISA on it?
There are embedded systems still being made that use 486s.
VXIpi-486 Model 500 [apexwaves.com]
TS-4400 [embeddedts.com]
Re:Commercial OS (Score:5, Informative)
Re: (Score:3)
There were plenty of later 486s with PCI slots, and there are plenty of PCI to USB2 controllers out there that should be compatible with them. I'm not sure if there are any PCI implementations of USB3, and certainly no PCIE for 486s.
The 486 topped out at 100mhz (DX4) I believe, other manufacturers might have made faster ones. And while a 486 isn't going to drive a modern wifi card or gigabit network adapter at full speed, being compatible enough to actually join the network is useful even if you can't satur
Re: (Score:3)
For what it's worth, the m68k was used in industrial equipment all over the world for decades. It would make sense to keep support for that, as there is probably still active equipment being used with 68030+ CPUs.
Maybe it's because we're so used to so many bad phone-home behaviors from literally every other piece of software out there, but I'm a little surprised Linux doesn't have some kind of basic hardware survey for what it's being installed on, just so they can see if anyone is actually installing mode
Re: (Score:2)
>I think a better issue is what exactly are features a modern kernel has that are likely to pose an issue to 486 users if they don't have them.
Security updates that have not been backported, or will not be backported? Or will there be a dedicated group who spins up a fork of the last 486 kernel and does all that?
I agree and would go even further... (Score:5, Interesting)
Make a chronogram/roadmap so that every 3 years, Linux get's rid of a bunch of x86-32 only Processors:
Now, asking for cmpxchg8b
In 3 years time ask for true PAE (and not the PSE of the OG Pentium)
In six years ask for 32 bit SSE support or some other instructions in 32 bit to weed out some other 32Bit only x-86
In 9 years time ask for SSE2 support to weed out another chunk of 32bit only processors
In 12 years time as for some other instuction(s)... lather rinse repeat, until all 32 bit only x-86s are weeded out.
Re: (Score:2)
Re: (Score:2)
I guess it depends if there are any significant use cases for Linux on machines that don't support those features, and if not supporting them has any benefits.
Older machines tend not to be running the latest software, or internet facing and in need of security fixes. It doesn't make much sense to run a 486 server when you can get a much better one literally for free. There is always BSD too.
This got me thinking about how valuable 32 bit support is, vs. 64 bit only. There are still a lot of ARM devices with
Re: (Score:3)
Oddly enough, MIPS was actually one of the first architectures to have 64bit support - back in 1991 with the R4000.
Re: (Score:3)
If you want to run BSD on an antique, you want netbsd [netbsd.org]. Before Linux ran on everything, netbsd ran on everything. And now that Linux is dropping older architectures, perhaps we are headed back that way again.
Careful now. (Score:2)
There are many embedded industrial systems that use Vortex86 chips which are generally i586 with some i686 extras. So long as lots of new chips are being put into embedded industrial systems then they should be supported.
Eliminating ancient code paths is nice but impairing security in industrial systems is a bad idea.
Re: (Score:2)
Fair enough. The companies producing these products should therefor have no problems working with Linus and maintaining those specific architectures. This is already what happens for other architectures that companies base their products on.
Re: (Score:2)
At this point, it probably would be a better idea to create a i486 fork of the linux kernel, with everything that you won't find on a 486 machine stripped out of it.
Those machines have tiny memory amounts if compared to modern ones, and not much of what is being added to the newer kernels apply anyway.
Re: (Score:2)
There are plenty of 32 bit CPUs out there. Maybe not in the intel space. But in ARM they are still very common. And probably are still currently being produced.
The question should be how much effort does it take to keep compatibility with line X of CPUs and how much do we care about keeping line X working. In 32-bit, I still think we care a lot about many of them.
Re: (Score:2)
why would any of the IoT need x64 or other smart devices need it? (honestly I dont want my vacuum, air purifier, fridge to have network or internet capabilities)
But any of those things, even my security cam, why would it need anything more than 32bit? it's just wasted. Oh, you mean my light bulb somehow needs more than ~3GB or ram?
I bet most of those systems have less than 1G of ram, so most of the benefits of x64 would be wasted. And lets not forget that x64 can result in larger binaries and no performance
Re: (Score:2)
why would any of the IoT need x64 or other smart devices need it? (honestly I dont want my vacuum, air purifier, fridge to have network or internet capabilities)
But any of those things, even my security cam, why would it need anything more than 32bit? it's just wasted. Oh, you mean my light bulb somehow needs more than ~3GB or ram?
I bet most of those systems have less than 1G of ram, so most of the benefits of x64 would be wasted. And lets not forget that x64 can result in larger binaries and no performance boost.
X-64 (and ARM-64 for that matter) had more goodies than the increased memory space alone.
There was a big cleaup of the ISA, not implementing 64bit equivalents for seldom used 32 bit istructions, and implementing some 64bit instructions with no 32 bit equivalents that dramatically increased performance. Also, some architectural changes too, for instance, the security model went from 4 rings in X86 to only two in X64 (an error in my view, but that is another discussion).
Also, TFA (and to a lesser excent, my O
This goes totally against what Linux is all about. (Score:2, Insightful)
Re: (Score:2)
If it were important enough to somebody, they're always welcome to go create a fork and continue with it that way.
Re: (Score:2)
There's no need to support hardware simply for the sake of being able to say 'it runs on this hardware.'
But the great thing about the Linux kernel actually isn't that it supports virtually any platform; it's that if you, personally, want it to support a certain platform, you can make it happen, if you choose to.
Re: (Score:2)
If anyone here started using Linux back in 1992 like I did.. What's great about the Linux kernel is there is support for virtually any platform.
If there's one thing that Linux is about, it's anything that Linus damn well says it is. There's really no higher authority on it.
Also the support for virtually any platform shall not come at undue expense. Linux still does run on any platform, just go download the appropriate version from your appropriate space in history. If you're expecting your 30 year old hardware to do something modern, don't. Linux may run on everything, but not all versions of Linux runs on everything and expecting it to is silly.
Re: (Score:2)
If anyone here started using Linux back in 1992 like I did.. What's great about the Linux kernel is there is support for virtually any platform.
In 1992, the only arch supported by Linux was i386. The second supported architecture was alpha, in kernel 1.1.67 released on November 22, 1994. For the majority of Linux's existence, netbsd supported more architectures. Of course, there are Linux ports which have never been shared with the world, but the same is true of other operating systems as well.
Close call. (Score:5, Interesting)
While the 486 arch is still used in some embedded industrial systems (e.g. ZFx86 [zfmicro.com]), I was far more concerned about the far more popular Vortex86. As luck would have it, all but the very earliest are based on i586 and have the cmpxchg8b instruction.
I don't know about the rest, so I hope the embedded industrial chip makers are paying attention because Linus may be about to kneecap their products.
Re: (Score:2)
I think there are some radiation-hardened CPUs that are used for certain military and space applications.
Of course, they could use old Linux or something not Linux.
Linux so behind the curve (Score:3)
Re: (Score:2)
Apple x86 support was very short lived, it's only really macs released in 2006 that were x86, they moved very quickly to 64bit with the second release macbook, imac and mac mini (the mac pro was 64bit from the start).
The imac actually took a step backwards, as the G5 imac was 64bit.
The only 32bit x86 apple ever supported was the first generation core which had SSE2/SSE3, nothing earlier was ever supported.
They really should have skipped 32bit x86 entirely, and gone straight to 64.
Incorrect PAE assumption (Score:4, Informative)
The few distros that still support 32-bit x86 mostly do for the Geode LX and similar VIA processors that provide a barebone 686 instruction set without PAE. Heck, older Geodes are not even barebone 686, but rather 585 with all the bells and whistles. That ought to remain the base platform.
For everyone else, there's essentially zero reason for remaining on 32-bit CPUs.
First they came for the... (Score:5, Funny)
First they came for the 386, but I did not speak out because I do not run a 386 PC.
Then they came for the 486, but I did not speak out because I do not run a 486 PC.
Then they came for the Pentiums, but I did not speak out because I do not run a Pentium PC.
Then they came for me, and I had no working web browser so fuck knows if anyone cared.
NetBSD (Score:4, Insightful)
Re: (Score:2)
Plus NetBSD solved the Year 2038 Issue on 32 bit CPUs well before anyone else.
I feel like solving a problem 26 years early is a somewhat hollow victory.
This is good (Score:2)
We need variety in OS development. Yes, I do like Linux, and yes I have been advocating its use for over 20 years now.
However, it has practically dominated the entire open source computing. All the way from microcontrollers to large datacenters Linux is the only choice for many folks.
It would be rather nice if we had a lightweight, but modern OS that covers pentiums (used for its reliability in NASA and other applications), and ARM0, and similar chips at the same time, with limited RAM and instruction sets.
Old hardware, old kernels ... or just the Pi (Score:2)
If someone is still using old hardware, that is no longer on the market, then in a certain way it makes sense to lose software support for it at some point, especially in the main projects. At the same time, I am curious what businesses are still using 486 computers for and whether they really need a recent kernel for it?
I am also curious when 386 support was kicked out of the kernel, whether any forks were created by anyone, to deal with that user base?
For some old hardware, the Raspberry Pi seems to be th
Fine (Score:2)
I guess I'll port FUZIX [fuzix.org] to i486 and clones. Mine is a real piece of crap [dmp.com.tw], but I have four of them. (all variations of the DMP EBOX-2300)
Sometimes software has to push hardware phase-outs (Score:2)
I'm not a fan of "artificial obsolescence" by any means! But there's often a point reached where people will keep trying to use really obsolete computer hardware simply because they're too cheap to buy something newer/better, and/or they're too lazy to make the effort to upgrade what's still working.
At this point in time, I can't imagine a scenario where you had a justifiable reason to keep running i486 CPUs with Linux rather than at LEAST moving up to an also way obsolete Pentium class CPU?
You literally hi
x87 floating point (Score:2)
I guess that's true, Intel never made a cut-price Pentium chip with no floating point unit, and I guess none of the competing vendors did. But isn't it possible we might get CPUs without x87 floating point produced in the near future? Since if you have high-performance floating point code you will be using SSE or later instructions, and crusty old stuff calling x87 will still run acceptably fast un
Re: (Score:2)
But isn't it possible we might get CPUs without x87 floating point produced in the near future?
Possible, but unlikely. Embedded has moved on to cheaper cores.
Re: (Score:2)
CONFIG_MATH_EMULATION is used in other architectures as well (PPC, RISC etc)
MiSTer (Score:2)
Would this break on the MiSTer FPGA AO486 core? Genuinely curious, because the core isn't exactly a 486 representation. Then again, the hardware is designed to run old software rather than modern software, so I guess the comment about "museum kernels" would equally apply.
Drop 32-bit support altogether and re-license (Score:2)
The push should be to drop support for IA-32 altogether, with AMD's x86_64 ISA as the new de facto and de jure standard. It would behove the community to then re-license this legacy GPL code under the more permissive Apache License 2.0 so that the BSD community can be given the opportunity to use it. A monoculture of anything is usually bad.
Re: (Score:2, Interesting)
And what, other than complain, have you done about it? Are you back-porting software so it will continue to run on older CPUs? If you aren't competent to do that, are you donating time or money to the cause?
Or are you just a whiny bitch?
Re: (Score:2)
And what exactly are you using a 33 year old processor whose primary manufacturer hasn't even made in 15 years for? I'm sure there are workloads that an 80486 can handle, but unless your supporting legacy hardware, I can't imagine why you would use it. As it is, older kernels will still support the 486 and if there's still any significant numbers of people out there running Linux on 486 systems, then the last mainline kernel to support the processor can be forked and support continued, and where possible, s
Re: (Score:3)
To my mind, the last 486-class processors doing real work are in industrial control and probably running DOS. But it would be interesting to know if my prejudice is correct or not. It's hard to imagine that people are still forced to use them for personal purposes when ARM SBCs would probably fit their needs much better.
Re: (Score:2)
I'd be very surprised if anyone was depending on a modern/current Linux kernel on a 486-class machine for anything other than hobbyist "Neat that it still works" kind of stuff. Like you said I'd expect any 486s still out there to be embedded machines running the same bit of software for 30 years. If it's got a value and use, even if it's just reducing the testing surface, I say get rid of it.
And I say that as a retro enthusiast who has occasionally booted current Linux kernels on silly machines just for the
Re:Most software has phased out pre sse2 cpus (Score:4, Insightful)
A fair amount of new or refurb 486/Pentium with ISA or original PCI for industrial use are, surprisingly still sold world-wide, with a wide variety of OS's. There's also a market for "newl manufacture" retro office systems, with Win7/Win7Pro, Win2k, Win XP etc. It's mind-boggling :p
Re: (Score:2)
Absolutely they're still sold, but I'd be shocked if any of them sold as replacement parts were depending on Linux 6.0 for anything. I'd expect them to be running the original controller software (probably still based on DOS, maybe Win3.x) or something more suited to embedded work like QNX or some other RTOS. If a company really is depending on an open source community maintaining support for a 30+ year old processor, it sounds like something they could/should be taking on themselves to maintain. Also the b
Re: (Score:2)
Some of these are actually sold with legitimate keys for Win2k, XP, Win7 etc. There's also versions of OS/2 offered
Re: (Score:2)
We ran OS/2 on 386s and 486s at work (desktop OS) in the mid 90s. And we ran Windows 3.1 in a VM from within OS/2! Had a link on the desktop to open a 3.1 window.
Re: (Score:2)
Exactly this. I have long been a computing hobbyist and I still have a few last dregs of my weird computer shit habit around, like a Geode LX development board (with ISA slots) and a Dt geode SFF... They're not used though :)
Re: (Score:3)
There are probably some old decrepit ATMs out there running OS/2 on 486 hardware.
RTOS support 386, 486 (Score:2)
To my mind, the last 486-class processors doing real work are in industrial control and probably running DOS.
Some will be running a RTOS. QNX support 386, VxWorks 486, FreeRTOS 486.
Re:Most software has phased out pre sse2 cpus (Score:5, Interesting)
But I'm going to wager outside of pretty specialized industrial and lab hardware, and a few hobbyists, this isn't going to have any impact at all. Heck, what's the last version of Windows to even run on a 486? My hunch is Windows ME and Windows 2000.
In the SBC/SOC world, Free DOS and MS DOS are king.
Windows 95/98 are trivial to run on a 486 with full DOS support, but isn't common due to the RAM requirements. Windows compact still works fine.
Anything with an NT kernel would be both surprising and very specialized indeed.
At that level the more common options are Linux, QNX, OS/2, and VxWorkx instead.
That said, you're quite right that this will have little to no impact.
Embedded systems are still manufactured with the 486 core. It's an easily implemented core and licensing it is surprisingly affordable.
However these systems are rarely network facing in any way a kernel security patch would be helpful.
We already custom built user-lands since their purpose is very different from what desktop distros aim for.
Re: (Score:2)
The last 486 systems I ran was a 486DX-33 with 8mb of RAM as a desktop running OS/2 Warp (prior to that it had run Slackware Linux), and a 486SX-25 laptop someone gave me, that I threw Minix because it had just enough RAM and hard drive space to make that an option. The last time I even turned that laptop on was probably around 2003, so it's been the better part of two decades since I even looked at a 486 machine.
Re:Most software has phased out pre sse2 cpus (Score:4, Informative)
The last 486 system I worked on was early last year.
This was an embedded SoC of course. The modules are about $60 USD and only about $10 of that was to license the CPU core. It even came with onboard ISA (for pc-104) and PCI controllers.
We had to support an old latency sensitive BacNET TSR library with the additional requirement of fat32 support.
It used to be based on FreeDOS, and was DOS 7 via Win9x before that.
It didn't utilize any of the Windows shell or GUI at all, it was just an unfortunate MS licensing thing.
Those older ones were the 128 MB RAM versions, but today they also have 1 GB chips.
Here we still use Linux kernel 2.0 and DosBox to host the TSR and DB2 engine.
(A nice legacy stack of turtles all the way down!)
Re: (Score:2)
I wouldn't do it today unless I had a very stupid reason, but NT4 would run fine on a 486. My last 486 was a HP Vectra with 16MB RAM, which is way more than enough. NT4 was fairly comfortable in 4MB, and 8MB was spacious unless you were running content creation apps like (Aldus!) Pagemaker or Adobe Photoshop (version 2.x at the time, IIRC...)
Radiation hardened versions (Score:2)
And what exactly are you using a 33 year old processor whose primary manufacturer hasn't even made in 15 years for?
Are you sure the radiation hardened versions used for spaceflight are no longer made?
The rad-hardened stuff tends to be older CPUs, even when the rad hardened CPU is a new product.
I think the Mars rovers are basically running rad hardened PowerPC G3 CPUs.
Of course, these sort of applications will probably be running an actual RTOS like QNX not Linux.
Re:Most software has phased out pre sse2 cpus (Score:5, Interesting)
It has to happen at some point - the year 2038 bug is looming. This is actually a current problem, as I worked for a charity using a 32 bit Linux database with ages stored in 2 digits. When they moved to 64 bit Oracle, all kinds of issues happened. This is why I have a day job, as I found them :\ 1938 births stored as 2038 is bad.
Re:Most software has phased out pre sse2 cpus (Score:4, Insightful)
I used to work with a VMS-influenced app framework that uses 1950 rather than 1970 as its zero time. Mostly it uses double-double format to hold timestamps (whole and fractional seconds in the respective binary64 value), but anyone who stuck a time value in a signed 32-bit integer had a Y2018 problem they had to fix a few years back.
What's really sad is that most of the code that I saw people fixing was written after 2000, so the authors should have been well aware of the range problems. They were never constrained by wire formats or extreme bandwidth limits, so they could have just used a larger data type from the start.
Re: (Score:3)
It has to happen at some point - the year 2038 bug is looming.
There are a variety of ways to work with 64 bit data types on 32 bit architectures. All of them involve a performance hit, but hopefully having to convert timestamps is not something that's going to lock up your CPU. Most 32 bit processors newer than the 486 have ways to work with longer data types natively. Notably, MMX has functions that operate on some 64 bit types — MMX supports a 64 bit quad word, as well as the predictable packed data types that will fit into it evenly in powers of two. Therefor
Re: (Score:2)
Ahh, I see you've never encountered the idiocy of the DATE, TIME, and DATETIME column types, nor the idiocy in the JDBC standard about how it deals with temporal types. Generally storing dates/times in a database (* for most purposes) as anything but milliseconds-since-UTC-epoch plus a time zone (when required) is a disaster waiting to happen.
(*) Astronomers (sidereal, UT1) and historians (look a
Re: (Score:2)
It's quite sad if Oracle doesn't have multiple data types for that, and even sadder if they can't figure out how to handle it internally so you don't have to know the difference. I have successfully avoided dealing with RDBMSes other than Postgres for a while, though.
Comment removed (Score:5, Informative)
Re: (Score:2)
the year 2038 bug is looming...
...1938 births stored as 2038 is bad.
You misunderstood the year 2038 bug then. Unlike the Y2K, this has nothing to do with the decimal representation of the date (2 digits for year), but instead with the binary representation (seconds since January 1st 1970 UTC). So any computer still using 32 bits for the seconds in time would misinterpret post 2038 dates as being in 1902, not 1938.
Re: (Score:3)
Re: (Score:2)
The real mystery is why Intel was still making 32 bit cpus alongside 64. Nothing in the consumer space has a requirement and all it did was fill the market with slow junk. Nothing like running windows Vista on a netbook with 2gb of ram and a platter drive.
Re:Most software has phased out pre sse2 cpus (Score:4, Interesting)
The real mystery is why Intel was still making 32 bit cpus alongside 64.
No mystery there. They had the factories, and there were customers, hence demand for those factories' production lines to continue making those processors. Such factories required maintenance, personnel, and other things that cost not only money, but also time, so once demand for those older designs dropped enough that keeping those factories running would have provided less than the minimum amount of profit Intel thinks reasonable for a production line, they were decommissioned.
Re: (Score:2)
Remember XP64? Nobody else does either because there were no drivers for it. So 32 bit kept trucking along until the middle of the Windows 7 era or so, by which time the ODMs had caught up and made 64 bit drivers.
Re: (Score:2)
So what industrial application required a 32 bit Core series cpu? Literally no one ever asked for such a thing. Possibly aviation or medical but they tended to not be Intel anyhow. Intel was churning out garbage and manufacturers bought it.
Re: (Score:2)
What's your problem with that?
My 486 system used Vesa Local Bus and that died the death along with the 486. If you run museum hardware then you should be able to accept museum software.
The original Pentium P5 was introduced a few months short of 30 years ago. One of the machines I still use is 12 years old and runs 4 processors at around 50 times the speed
Re: (Score:3)
I do run a 486 for funsies and retro gaming, and aside from doing it a couple times just for the sake of it I've never tried running modern Linux on it in any sort of useful way. Definitely no skin off my back if it goes away, I intentionally run approximately-period-accurate stuff like DOS and Windows 3.x. I'd never try to throw a modern distro on it and try to do anything with it - A few years ago I'd actually gotten some full graphical setup install going and X was... well, not great. It was actually kin
Re: (Score:2)
A few years ago I'd actually gotten some full graphical setup install going and X was... well, not great. It was actually kind of almost usable by running Firefox as a remote X from a modern machine, but even as a thin client it was painful.
If you cared you could use Chameleon Xoftware to do that job, the performance was quite good. I used to remote a lot of stuff to Windows boxes. You would also want the TGV TCP stack, it is worlds faster and more efficient than anyone else's. This is irrelevant for most purposes, but it would help here.
Re: (Score:2)
I remember buying a Pentium 60, with a whopping 32 mb of RAM, to run Windows 95. ATI Rage64 video card with 2 mb of vram. Soundblaster AWE 32 with WaveBlaster daughterboard.
Still had to have custom autoexec.bat and config.sys files to get Wing Commander 2 to run with animations and digital sound.
I think it's OK to start depreciating hardware from the 90s.
Re: (Score:3)
This is one of the questions I've been wondering. Why are we still bothering with 32bit OSs. We have been turning out 64bit cpus for almost two decades and multicores a few years later. There are no multicore pure 32 bit cpu's. Virtually every OS since Windows 7 needs at least a dual core cpu to run, so you are going to be running it on a 64b bit cpu. Since you are going to be running even a 32 bit OS on a 64 bit cpu why bother with a 32 bit OS at all?
Re: (Score:2)
There's still a lot of 32-bit out there, in systems/appliances that run for 20+ years, some in SMP configurations even. I know of one installation that STILL runs 3x dual Pentium 3's in lockstep+comparison, despite the system now being 18 years old(yes, this was built when P4's and Athlon 64's were battling it out). Replacing that with a certified modern system hardware solution would cost on the order of millions of euros, not just for the hardware, but for all the testing, the scheduling of downtime for f
Re: (Score:2)
The Core Duo is a multi core 32bit cpu... I believe Intel were also putting out multi core 32bit atom cpus until fairly recently.
And 64bit CPUs have been around longer than that, Intel/AMD were the last ones to catch up. There were 64bit MIPS and Alpha chips available in the early 90s.
Re: (Score:2)
Re: (Score:2)
Not yet. They would need to pull support for Pentium, Pentium II, and Pentium III CPU's as well. Even the first Pentium 4 CPU's were 32bit only.
Re: (Score:2)
Some of the fastest Pentium 4s might be usable today, I have a P4 laptop with 3GB of RAM and a fast P4m (want to say 2.8ghz? I think it was the fastest P4m available) that just barely manages Windows 7 in a usable way, if you're patient. An SSD would help. Big ol' thick Dell Inspiron 1150. When its battery was still getting a good hour and a half (as late as 2018!) I used to use it as my interview note taking machine when my team at work was doing team interviews for new candidates (it was a quirky company
Re: (Score:2)
Up until about three years ago I was still using some old Pentium 2s as VPN routers. I used Linux, because I'm most familiar with iptables. They worked great for that workload, and there still sitting on a shelf so I wager I could probably start them up right now.
Re: (Score:2)
At some point for workloads like that you have to consider the cost of energy. Yes, you can use some fossil of a PC with a 350W power supply to do the job of a 10W single board computer like a Raspberry Pi, but it kind of becomes irresponsible after a time.
Re: (Score:2)
Of course, that's assuming that you can get a hold of a Raspberry Pi. They seem to have been back-ordered for months. There are alternatives, but they tend to cost a lot more.
Re: (Score:3)
Oh these days I wouldn't recycle aging hardware. Power is one consideration, reliability is another. Start using 10+ year old hardware, and suddenly you're dealing with blown capacitors, power supply issues, and the price of even a 250w PSU is high enough that it's not worth keeping them alive. Honestly, short of legacy applications, I can't imagine any reason I'd run a 486 machine at all, and the only reason to run a physical box is if its specialized hardware that won't work on modern machines and thus ca
Re: (Score:2)
Intel also made 32-bit only Atom processors until 2011. I'd imagine that a lot of those ended up in embedded storage networking and storage devices that run on some flavor of Linux.
Re: (Score:2)
Dinosaurs are cool, but they died out a long time ago
we dont actively dedicate resources to keeping dinosaurs alive.
What?
Dinosaur meat and dinosaur eggs are the most commonly consumed animal protein sources today.
Hell, I'd literally just finished eating a plate of dinosaur hearts.
We definitely dedicate resources to keep dinosaurs alive.
Re: (Score:2)
Re: (Score:2)
You... you... monophyletist!
(This is also why we are all fish.)
Re: (Score:2)
The oldest cpu I'm currently running is a k6-III-450; I need it for specialized hardwwith.are. I'm refurbing some pentium pro servers to play duke nukem . :)
Re:That's pretty stupid (Score:5, Insightful)
A number of embedded CPUs run on 486-compatible cores, so phasing out "486" cuts off all of those, too.
Those embedded systems can be used with the last kernel that supports 486 processors, provided they don't use networking access. If they do, the companies making those designs can pay for a kernel developer to backport recent networking security fixes to that last compatible kernel -- and then release those fixes as a new minor point security fix release for that last kernel version.
Or they can go fully into keeping support for 486 processors as a set of patches against the latest official kernel. The only difference is that it will be on them to keep these patches fully aligned with the kernel, not on kernel developers to keep those patches in mind while developing and updating their code, which is simply fair.
Re: (Score:2)
I think the AC is volunteering.
Re:That's pretty stupid (Score:4, Interesting)
cannot leave its own working parts well alone.
In the Linux kernel, there's no chance that code can ever be left alone perpetually.
The kernel is continuously being improved, with some parts undergoing redesign. That means some of the working parts will have to be modified just to keep working with the new designs. Even if they didn't, they'd still need to be tested against the new stuff to make sure it doesn't break.
This puts too much burden on the new code for no good reason.
It's not like they're dropping support for processors that are only just 10 years old. We're talking about the 486 here.
If you want working parts left alone, there is absolutely NOTHING stopping you from forking the last git commit before 486 support is removed and continue to use that. There is nothing that would stop that code working if you have the hardware to run it.
Re: (Score:2)
I'm going to wager most currently used 486s aren't running Linux at all. The last of that era of CPU that I'm seeing is usually running some sort of embedded version of DOS. The problem at this point for kernel maintainers is that there aren't likely a lot of 486 systems still up and running to build the kernel for, so increasingly support becomes almost hypothetical. Sure it probably will run, but if the maintainers don't have an easy way to guarantee that, then it actually becomes somewhat risky to even m
Re: (Score:2)
As far as I know, nobody is saying the old kernels will stop working. Just use them. Resources are not infinite. If you support everything in perpetuity, eventually the support footprint will consume everything you've got.
So pick a lane. Either deprecate some stuff, or simply give up on advancement. You can't have all of both.
Frankly, I was surprised to hear that support for those chips was still there.
Re: (Score:3)
Just did a search and it appears to support 'cmpxchg8b' so it shouldn't be impacted.
Re: (Score:2)
The oldest PC/104 device I could find was Pentium (i686) based.
https://www.electromyne.de/Mot... [electromyne.de]
Re: (Score:2)
> https://www.electromyne.de/Mot [electromyne.de]...
Honest question - is a Raspberry Pi 4 running an x86 emulator slower than a 386SX/40?
Re: (Score:2)
Honest question - is a Raspberry Pi 4 running an x86 emulator slower than a 386SX/40?
Probably not, but you also have to consider that a lot of embedded PCs are connected to hardware you couldn't trivially connect to a raspi.
Re: (Score:2)
yes, and your not about to go monkeying with whatever software all that IO is controlled by
The last PC104 board I had was a discarded out of some old XY machine that dispensed whatever, and it had a Vortex86 chipset, more or less a 800Mhz 486, ran dos and windows fine, but (standard off the shelf distro) linux didn't know what to do with it and had all sorts of random issues, that was a decade ago
Re: (Score:2)
For the purpose of controlling industrial equipment, yes, because you also need to do cycle accurate emulation of ISA buses and other interfaces to get the same expected latencies and other behaviour, at which point the emulation is simply too slow. Not to mention getting the Raspberry Pi physically connected to those interfaces. And cycle accurate and emulating the right performance together is a must, to guarantee the same known failure modes. You can't bring in new, unknown failure modes. Javascript/Pyth
Re: (Score:2)
Processor and memory don't need to match...
You can connect a 64bit chip to 32bit memory albeit at a performance hit, and many 32bit chips (eg the pentium upwards) have a 64bit memory bus...
It wasn't uncommon for earlier 32bit chips to be connected to 16 or 8bit memory because it was cheaper, eg the 486SLC used a 16bit memory bus.