Linux Finally Starts Removing Support for Intel's 37-Year-Old i486 Processor (phoronix.com) 131
"It's finally time," writes Phoronix — since "no known Linux distribution vendors are still shipping with i486 CPU support."
"A patch queued into one of the development branches ahead of the upcoming Linux 7.1 merge window is set to finally begin the process of phasing out and ultimately removing Intel 486 CPU support from the Linux kernel."
More details from XDA-Developers: Authored by Ingo Molnar, the change, titled "x86/cpu: Remove M486/M486SX/ELAN support," begins dismantling Linux's built-in support for the i486, which was first released back in 1989. As the changelog notes, even Linus is keen to cut ties with the architecture: "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. As Linus recently remarked: 'I really get the feeling that it's time to leave i486 support behind. There's zero real reason for anybody to waste one second of development effort on this kind of issue'..."
If you're one of the rare few who still keep the decades-old CPU alive, your best bet will be to grab an LTS Linux distro that keeps the older version of Linux for a few more years.
"A patch queued into one of the development branches ahead of the upcoming Linux 7.1 merge window is set to finally begin the process of phasing out and ultimately removing Intel 486 CPU support from the Linux kernel."
More details from XDA-Developers: Authored by Ingo Molnar, the change, titled "x86/cpu: Remove M486/M486SX/ELAN support," begins dismantling Linux's built-in support for the i486, which was first released back in 1989. As the changelog notes, even Linus is keen to cut ties with the architecture: "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. As Linus recently remarked: 'I really get the feeling that it's time to leave i486 support behind. There's zero real reason for anybody to waste one second of development effort on this kind of issue'..."
If you're one of the rare few who still keep the decades-old CPU alive, your best bet will be to grab an LTS Linux distro that keeps the older version of Linux for a few more years.
Hubble out of support (Score:5, Interesting)
Re: Hubble out of support (Score:5, Informative)
It uses VRTX, reportedly. Linux wasn't suitable as a real-time OS when the Hubble was designed, or really even when the Hubble got the 486 installed in 2009.
Re: Hubble out of support (Score:5, Informative)
Linux isn't suitable as a real-time OS now either strictly speaking. In fact that one of the top hits from a search on Linux RTOS is a paper from NASA (from a comparatively recent 2019) discussing the performance of Linux with every RTOS relevant kernel feature set into the most ideal position. Their conclusion was... well you probably will hit your event deadline if you throw fast enough hardware at it, but it is still nothing like a true RTOS.
Re: (Score:2)
Worst case, if they need true realtime functionality, there is QNX, which has predated Linux and is still going. Not sure if it supports 32 bit, but wouldn't be surprised.
Re: (Score:2)
Re: (Score:2)
2019 was 7 years ago, and the Linux kernel has had hard realtime capability for a very long time. Of course, the kernel doesn't live in a vacuum, so using a properly configured kernel, using an embedded distribution, and properly tuning it is necessary for best results, as discussed in the linked document. I don't even have to read the NASA paper you didn't bother to link to in order to guarantee that you didn't read and understand it, then genuinely
Re: (Score:2)
2019 was 7 years ago, and the Linux kernel has had hard realtime capability for a very long time.
Congrats, you proved my point well. All of Linux's "realtime capability" (in quotes since the kernel still does not achieve true real time reponse, it can't, it's fundamentally not designed for it) is old. There's been no meaningful developments in the past 6 years in this space. Which means that my reference is still quite valid.
As is yours by the way. You countered the point I made that NASA did a detailed analysis in 2019 that determined it is not a true RTOS, with some Red Hat post from less than a year
Re: Hubble out of support (Score:3)
Re: (Score:2)
Real time capabilities but not fundamentally real time. Though for 99.99% of the applications it would not matter as long as your hardware is strong enough.
I can see that for space it would become an issue.
Re: (Score:3)
Does Hubble need 'embedded' or "real time' (Score:2)
It uses VRTX, reportedly. Linux wasn't suitable as a real-time OS when the Hubble was designed, or really even when the Hubble got the 486 installed in 2009.
Why was VRTX chosen? Because of the embedded environment or because of real time needs?
If the decision was about embedded and real-time was not required, then Linux would be a viable solution today. Today, embedded Linux is a fine choice for non-real time needs.
My first Linux CPU (Score:3)
Went to a Comdex and saw this new fangled thing called a network switch. 3-4 of those in our system solved our problems.
Re:My first 486 story is compute-bound (Score:4, Funny)
Yeah, early '90s I got a school computer lab to run as a render farm overnight. Had a script that would lock the systems from 11PM - 5AM (building was closed/empty 10PM - 6 AM). Everything worked fine until a power blip shut down the systems. On reboot, they were all locked and my script wasn't running to unlock them.
Luckily, my gf at the time was working as lab assistant, checked on lab before first class and called me (just for technical help). She was pissed when I explained that I had caused the issue but we were able to get everything reset in time for class.
Still, the Comp Graphics prof suggested I look for a career in IT instead of fine arts. Took his advice; the future was so bright I had to wear shades.
Not a 486 thing, but... (Score:5, Interesting)
Somebody thought it'd be a great idea to remove full 10Mb Ethernet support from two recently-purchased routers I tried at home (bought the second after the first didn't work).
Turns out this would've cost me my venerable and much-loved Roku Soundbridge M500 and M2000 network music players, which are working just fine, thanks.
I had to buy a cheap switch to put between them to straighten this out. Waste of money.
I understand that 486 support takes up needed and scarce dev resources, and it seems reasonable to me to remove it.
But I wonder what hidden breakage (like my case) happens as a result of making these "reasonable" decisions.
Re: (Score:2)
My $DAYJOB's data center switch upgrade got switches that have 48x 10G SFP+ ports plus 8x 100G QSFP+ ports. When we installed them, we realized that some really old Dell Poweredge servers try to drop to 100M when using shared DRAC (with the dedicated DRAC port also being 10/100M only), and the switches don't support 100M. We also had to look at a bunch of rack PDUs to find options that were 1G rather than 10/100M.
100M uses less power than 1G, so I guess that's why Dell did that (sounded like a good idea to
Re: (Score:2)
Re: (Score:2)
Again, it's about power saving. Idle 1000BASE-T draws noticeably more power than idle 100BASE-TX (IIRC the drop from 100BASE-TX to 10BASE-T is not as significant). There are Energy Star ratings and EU rules about how much power an "off" and "standby" device can draw, so dropping to a lower NIC speed helps reach those levels.
There was a proposal for a "low power idle" mode extension of 1000BASE-T, not sure if that went anywhere or got implemented.
Re: (Score:2)
I also like the idea that if you stick a copper SFP into modern "merchant silicon" switch (Broadcom Jericho), you may or may not get working autonegotiation. And copper devices like to have that on by default, even if it's technically not needed for Gigabit Ethernet. And then there might be half-assed support where support for autonego is only for clause 37, but not clause 73 (or vice versa, don't remember which. Anyway, it meant that hooking up a Juniper SRX to a Cisco NCS 57C3 (or anything else using Jeri
Re: Not a 486 thing, but... (Score:2)
My flagship TV from 2025 still came with a 100 Mbps Ethernet port. Wi-Fi is faster. I don't understand why they would cheap out on that on a $3000 TV.
Re: (Score:2)
My Marantz SR6015 uses a 100Mbit NIC too. Not that it matters with music, but still... And it's not like that receiver is low-end either...
Re: (Score:3)
Re:Not a 486 thing, but... (Score:4, Informative)
It's not that "they removed 10Mbps support" so much as the underlying ethernet hardware (MAC and/or PHY) used by that new router simply doesn't support it. Might not even support 100Mbps either; once you cross into multi-gigabit world, sub-1Gbps support is the exception rather than the rule. Why? Because that would require a more complex (ie expensive) design and be utilized by almost nobody.
Re: Not a 486 thing, but... (Score:2)
Sure. I understand well that things change.
However, it'd be nice if the box had a big yellow burst that said: "Now Without 10Mb/s Support That Has Worked Until Now On The Same Connector Ever Since We Came Up With It!"
Sucks to get it home and find that this one is borked, too.
Re: (Score:2)
Re: Not a 486 thing, but... (Score:2)
Well, because neither router says what you suggest on the package. Each mentions 2.5Gb Ethernet ports, but neither says what other standards the ports support.
Neither does the switch I used to fix the situation: it advertises 1Gb Ethernet ports.
The "big yellow burst" (yeah, of course I was being a little facetious) could let you know "this won't support the minimum speed, in the way everything else with this connector has for decades".
As it stands, nothing on the box will answer that question before you buy
Re: (Score:2)
Re: Not a 486 thing, but... (Score:2)
This happened a couple days ago and I have the boxes here, went and looked at them. A GFiber WiFi 6e, and an Asus RT-BE86U. GFiber's info is mainly online, but same problem.
Re: Not a 486 thing, but... (Score:2)
Using WoL (wake-on-LAN) also tends to use 10 Mbit Ethernet. There isnâ(TM)t an LED light combination for that speed on my 2.5 Gbps NetGear switch (so the port lights are all off) but otherwise it still works.
Re: (Score:3)
Re: (Score:2)
Actually, many consumer gigabit Ethernet switches lack 10Mbps support these days. They are 100/1000baseT only.
Business and enterprise switches though I've found (including Cisco ones, which you can find dirt cheap used) still are 10/100/1000Mbps. Even newer business and enterprise class switches retain support.
Of course, once you step into 10Gbps Ethernet, you have to be careful because many only are 10Gbps only, while some do support 1/10Gbps. 2.5Gbps support is iffy unless it's specified which is annoying
Re: (Score:2)
Actually, many consumer gigabit Ethernet switches lack 10Mbps support these days. They are 100/1000baseT only.
Business and enterprise switches though I've found (including Cisco ones, which you can find dirt cheap used) still are 10/100/1000Mbps. Even newer business and enterprise class switches retain support.
I have a HP Aruba 3810M, 48 port PoE, 40 of them are 1G and 8 are "SmartRate" 10G. It's consider "obsolete" and nearing EoL. It does support 10M on the 1G ports but 100M is the lowest you can set it from the browser. You have to get into the cli to force 10M. It does not support 10M on the 10G ports, and while the spec sheet doesn't show it the option to lock to to 100M is in both places so I assume it actually does. I might have to go play around with this later with some 10/100M cameras I have.
Of course, once you step into 10Gbps Ethernet, you have to be careful because many only are 10Gbps only, while some do support 1/10Gbps. 2.5Gbps support is iffy unless it's specified which is annoying since many things have 2.5Gbps ports.
I've on
Re: (Score:2)
A modern Ethernet PHY already has to support multiple different encoding schemes, MLT-3 for 100BASE-TX and PAM-5 for 1000BASE-T (and PAM-64, etc for higher speeds like 2.5 or 10 gig.) Eliminating the Manchester encoding for 10BASE-T is a logical way to save on cost and complexity, especially since most companies probably don't have a lot of legacy 10 mbit only gear to test with.
Re: (Score:2)
spending effort to maintain support for stuff nobody is using is not reasonable. Would you write a book, if you were certain nobody would ever read it or even want to?
Don't say "but what about a diary," even a private diary generally has one intended audience if it is the author themselves, for their own recollection.
writing software that no computer will ever run makes very little sense, even from an educational standpoint.
- as to the hidden breakage. Probably not much, because if you don't know about th
Re: (Score:3)
The software is already written.
Yes it's already written. Use a kernel with the code still there. It's not like your 486 will have any application that requires the latest kernel, if your system even manages to boot at all.
The problem with written code is that if it remains "supported" it places a burden on all other code changes made to the product. Someone needs to do regression testing to make sure it's not broken. Someone needs to do security auditing and potential bug fixing. And above all, these are not reasonable requirements for h
Re: (Score:2)
To me, the 'fix' seems to be spinning up a new arch branch, call it x86-old or whatever. Use that to bring up a clean start 386/486/etc arch so that people playing in the main x86 area aren't tripping over the old code. We've got all the info needed to do so already sitting there in the src. Now, if there are enough users left to drive such a branch, dunno. I still play with my Soekris 4501 and 4801 as a hobby but I'm no longer using them in production, and my C knowledge isn't good enough to make this happ
Re: (Score:3)
It's the same situation as when Reiser3 was removed. Anyone who was using it in a new kernel could tell that performance w
Re: (Score:2)
The code has been actively tested on real hardware recently, as noted I've got two 486s that I've been abusing with modern Linux via Gentoo for years, both have been active in the last 6 months, and I'm not the only one poking around, but there aren't massive numbers of us for sure. If it wasn't getting feedback, there wouldn't be any friction to devs touching support for later generations 'cause they wouldn't know they've broken things for the older kit.
Re: (Score:2)
The code has been actively tested on real hardware recently
You misunderstand the term tested. Testing != using. Unless you used your Gentoo box to read through the commits to the kernel and then run specific tests against the 486 code to ensure there were no regressions.
Re: (Score:2)
I used it to build itself, kernel and userland, so not testing for anything specific but letting it chew the fat at 100% load for a couple weeks continuous usually flushes out most issues if there are any at the kernel level?
Re: (Score:3)
My recollection is they had to put some fixes in for 486 support on real hardware a couple years ago because someone discovered it only actually worked on emulators (maybe just qemu) which wasn't quite matching real hardware.
https://lkml.org/lkml/2024/10/... [lkml.org]
Re: (Score:2)
At this point, it'd be reasonable to make arch/x86 require 64-bit and that arch/x86-old dir keep 32-bit. It'd allow for massive cleanup of old code that was last maintained a couple of decades ago.
I was kind of shocked to find out how expensive (Score:3)
A lot of people complain about the Sega 32x and Atari Jaguar ports of Doom but it was mind-blowing to be able to play Doom on $300 worth of hardware in 1995. If you wanted a computer that could match the performance of even a Sega 32x you were dropping at least $1,500. Literally five times the price.
But I do remember when prices came down after I got back into computers after a bit. Picking up a 486 DX 100 for about $150 and then going to a computer shop asking for a Vesa local bus video card for it and the guy just pulled it out of a junk pile and gave it to me. Remember going home and booting up primal rage and X-Men children of the atom on that thing and being blown away with that computer could do. Terminal velocity .
486 seemed magically advanced in the mid 1990s. (Score:3)
My first Linux installation was Redhat 3.03 on a 16MHz 386/SX system in mid-1995. For those of you without an AARP card, that's a 32 bit CPU with a 16 bit bus, which Intel released to cannibalize the market for the 286, which did not have a memory management unit. That means no swapping, you run out of ram, it was game over.
I think the 486/25 that replaced the 386/SX arrived in ... 1996 ... and it had an astonishing *eight megabytes* of memory. I had kept a one megabyte LIM/EMS 4.0 physical memory card from my 286 when I got the 386/SX, and that actually mattered with Windows 3.x. I put it in the 486, but given that vast eight megabyte expanse of dram it didn't last long.
Then in late 1997 my employer went bankrupt and as part of the dissolution I brought home the dual Pentium 133 system with 32 megabytes of ram. I remember all my IRC friends were so jealous of that monster ...
Re: (Score:3)
The 286 did indeed have a memory management unit.
The problem with its segments was that they were limited to 64Kb each.
So basically a souped up 8086 with read/write permissions on segments and protection rings.
Back in the day I skipped all that crap. It was. great when the 386 came along.
Oh, I remember, the company I worked for at the time had a big document, given under NDA, that described all the bugs in the 286 chip. Most of them were failures of the memory protections.
Re: (Score:2)
Wasn't there an 80186? That literally nobody built anything with? Like, it was almost a proof of concept?
Re: (Score:3)
The 80186 existed, but the problem was the 80186 integrated various components such as the clock generator and interrupt controller directly into the CPU, but did so in a way that was incompatible with how IBM built the IBM PC. So the 80186 found its way into some not-quite-IBM-compatible computers like some Tandy models and a few other oddballs including some early PDAs. Otherwise, it it was used mostly for embedded applications.
Re: (Score:2)
We had a suite of RM 80186 PCs at school. Running DOS and Windows 3.0, but some custom version - they wouldn't run under standard DOS so upgrading was not possible. Somehow they had 960k of base memory rather than the usual 640k.
Re: 486 seemed magically advanced in the mid 1990s (Score:2)
I had a 186 in my palm top. But building a fully IBM PC compatible with a 186 was impossible as the integrated hardware was different. You could run modified versions of MS-DOS on it and get the vast majority of programs working, just not 100% of them.
As long as my Pentium 90 still works (Score:2)
Re: (Score:2)
Re: As long as my Pentium 90 still works (Score:2)
Re: (Score:2)
Interesting fact (Score:2)
But I guess using a 486 today is pretty unique anyway, so it doesn't really matter.
I was there... (Score:3)
I was there, three thousand years ago...
Ok, well it was only ~35 years ago, but I well remember cobbling together installable floppy images from Usenet to get Linux running on my 486DX with a bunch of GNU utilities. This took many hours of downloads and preparation over a dial-up connection, but this was the only way to install because even SLS hadn't come out with a coherent Linux distribution yet.
My 486 system had a whopping 4MB of RAM with a 200MB hard drive (my first). I massively overpaid for it and charged it all on my shiny new Circuit City credit card while I was still in college.
At my student job, I had an awesome, monochrome DECstation 3100 running Ultrix 3.1, so the thought of being able to run UNIX at home was just awesome.
Those were the days. :)
This isn't about the i486 (Score:2)
Re: (Score:2)
Yeah, Via made a clone that was similar not-quite-i586 fairly recently too.
I have an old embedded box with one that has SATA 6Gbps ports on it that I thought I would use zeroing out old hard drives.
I tried Puppy, DSL, SystemRescueCD, and a bunch of others and none would finish boot. FreeDOS is fine.
It's either eWaste or I need to dig out an Infomagic CD from the attic to get Redhat 9 pr whatever. Probably need to look up when the jump from 3 to 6 happened in SATA land.
But Linus is correct that actual dist
Makes sense (Score:2)
What is it worth to compile the kernel for an architecture that doesn't support enough RAM to boot a recent Linux kernel?
Why wait so long? (Score:2)
This is dumb, they should have already entirely dropped support for IA-32 by now. The AMD Athlon 64 was released in 2003, so the patents for amd64 have already expired, and you can source Skylake era Xeons all day long on eBay for less than $5 per processor.
I remember the 386 & Redhat CDROM.. (Score:2)
Re:Typical Stupidity (Score:5, Insightful)
name one other mainstream os that supports 486 processors.
Re: (Score:1)
Re: (Score:3)
"Support", not "in use". IBM sure as hell doesn't support OS/2 any more.
Re: (Score:2)
https://www.arcanoae.com/arcao... [arcanoae.com]
Re:Typical Stupidity (Score:4, Insightful)
..which doesn't support 486s, so the OP's statement that OS/2 still supports 486s is still not true.
Re: (Score:3, Informative)
OS/2 isn't going to remove 486 support anymore than linux kernel 2 is going to remove it.
OS/2 has two future branches still in production.
eComStation which requires a 586 or newer, and ArcaOS which requires a 686 or the "pentium pro" version of the 586.
Neither one support 486.
Re:Typical Stupidity (Score:5, Informative)
From the most current OS/2 release:
"Hardware Requirements
Intel Pentium Pro or higher, or an AMD Athlon or higher. 64 Bit CPUs are supported (however ArcaOS will run in 32-bit mode). Computers with ARM CPUs are not supported. Apple Computers are not supported (regardless of CPU). The Vortex86 CPU is not sufficiently compatible to run ArcaOS and is not supported."
i.e. minimum hardware requirements are a 686 instruction set.
Re:Typical Stupidity (Score:5, Informative)
Not sure what you mean by "mainstream" but the BSD distros do. :)
Re: (Score:2)
NetBSD?
Re: (Score:3)
Just today I noted that GIMP 3.2.2 (an application, not an OS) has dropped support for 32-bit x86.
Re: (Score:2)
Tuxera ROM-DOS supports it. $55/copy, and it comes with networking.
Re: (Score:2)
Re:Typical Stupidity (Score:4, Informative)
No year will ever be the year of linux on the desktop with this stupid attitude of throwing working code away.
Who is still using a 486 and also needs modern kernel features? Let them run an older kernel. They are going to have to run older software anyway because a 486 with more than about 16MB is rare, and modern Linux distributions require multiple GB of RAM.
Re:Typical Stupidity (Score:5, Insightful)
and also needs modern kernel features
This is a part everyone seems to miss when the get freaked out about Linux itself or some distribution dropping support for something 30 years old...
In 2026 if you are still using a computer older than mid-90s (and very more than likely even one from after the mid 90s) it is because it is part of some very specific process that almost certainly has you not making changes, which are almost certain to include software changes too.
Just because Linux 7.x can't be built for i486 any more does not stop you from grabbing any prior version and using that. Thinking about 486s specifically, I know there are actually a lot of odd things like hardened industrialized PCs and some routers and the like running licensed 486 cores and late manufacturing Intel parts; that are still in use. You can even still buy some new. It would not surprise me to learn people are running Linux on a good number of them, it would surprise me to learn people are running Linux newer than 5.10 or 5.15 on them. Even in the most exotic memory configurations a 486 is going to top out at 3.5GBs of memory, I guess you could do nearer to 4GB on a ISA only system (No PCI or VLB). You really going burn 16MB or more of that just on the kernel?
Let's be real if you are running a 468 you are probably using using Linux 2.0 - 2.6 already. Not being able to use 7 hardly affects you.
Re: (Score:3)
As someone who uses old hardware, I agree. I have one small PC that I run Linux on. It's a 586, so, in theory I could run even the latest kernel, but in practice I run Debian 8, because Debian 9 does not boot on it (either 128MB RAM is not enough for it or the CPU is missing some feature).
The newer versions would probably run slower anyway.
I have a 486 though, maybe I should try to see which latest Debian version runs on it.
Re: Typical Stupidity (Score:3)
Kernel support for an architecture does not translate to distribution support for that architecture. Just because a Linux kernel supports a 486 CPU, but that doesn't mean the latest distribution of a given flavor of Linux will run on a 486.
For example, can Ubuntu 2024 LTS run on a 486 machine?
Hasn't this already happened? From 2025 - https://www.zdnet.com/article/... [zdnet.com]
Re: (Score:3)
Re:Typical Stupidity (Score:5, Informative)
Using IOT devices with kernel 2.6 in these days is just asking to be hacked.
Not really...
Almost all IoT devices work by phoning home. They call some remote server, and do some API stuff, send some message poll for new messages / instructions. They tend to have very little if anything listening.
If they do get onwd its because the infrastructure that supports them gets compromised, at which point its really the infrastructure that was hacked and not the device. The other thing that happens - all the gosh darn time - is what ever little web based interface they have for setting up wifi/IP settings/etc is some terrible CGI thing with some form of injection vulnerability. Again though if that gets pwnt, it is only after some ofther failure of your internal network security. That is a concern, I understand defense in depth, I get foothold and dwell time issues, However a newer kernel won't prevent that kind of compromise. Lack of shell escaping on calls to system() or bad choices around using eval() will get you popped on Linux 7.0 as easily as 2.0.
Re: (Score:3)
Almost all IoT devices work by phoning home. They call some remote server, and do some API stuff, send some message poll for new messages / instructions. They tend to have very little if anything listening.
Are you talking about professional well made IoT devices designed for corporate management? Because holy shit are you wrong about general consumer IoT devices doing no listening. There's a reason for the running joke that the S in IoT stands for security.
In fact much of the community driven IoT interfaces for tinkerers rely on the fact that someone has hacked a device almost universally via an active open listening port to force it to work with something other than it's Cloud service.
Your best beat at secur
Re: (Score:2)
If the people building the stuff are not onboard with security issues, then have a modern kernel which could run on their hardware will not improve the situation. Such people probably already forked the kernel ages ago to patch it to run on their device, and they've included 23 explicit compromises to ease their internal needs (wouldn't an open remote shell be useful for debugging?). They won't be merging in security fixes unless the issue has made the news with their specific devices, and they won't be p
Re: (Score:2)
If the people building the stuff are not onboard with security issues, then have a modern kernel which could run on their hardware will not improve the situation.
Why the distinction? The point is that in some cases security would be just fine if the software were kept up to date. The fact that a device has a listening port open doesn't mean security is good or bad, it means it has specific functionality. One of the biggest problems in the consumer IoT world is that 99% of the shit out there is set and forget, open to any bug regardless of whether the vendor has patched it in newer products. Deploying modern software is fundamental to the issue under discussion.
Re: (Score:2)
I am going call - homemade IoT stuff someone built themselves with a SBC or something out of scope.
What consumer or SoHo products can you point at that don't use the phone home model? I can't think of single one. Even stuff that really really should be able to talk to something local like my ecobee thermostats don't..
Let us also take DOS conditions out of scope, again if someone can send whatever packet that triggers a DOS on the device they are already on your internal network.
So the threat here if you sm
Re: (Score:2, Interesting)
Re: (Score:2)
Re: (Score:1)
Plenty of 486 around that had more than 16M of RAM, especially these days.
Impossible to figure out what you think you meant while you're mixing tenses. 486s with more than 16GB of RAM were extremely scarce and now they are even scarcer, they are not more common. Probably they are a larger percentage of the remaining 486s, but that is not the same thing as there being plenty around.
Radiation hardened 486s still sold (Score:2)
Plenty of 486 around that had more than 16M of RAM, especially these days.
Impossible to figure out what you think you meant while you're mixing tenses.
I believe radiation hardened 486s for aerospace applications are still being sold.
Pray tell, what modern desktop runs in 64MB of RAM (Score:5, Informative)
...Because that's the upper limit of high-end 486 motherboards.
The 80486 was essentially e-waste by the year 2000. Even ultra-conservative Debian completely dropped support for the i486 over decade ago (with Squeeze going out of LTS in Feburary of 2016 after a 5 year run)
Incidently, the first Linux install I ever performed was in early 1997, on an ISA-only 486DX33 motherboard +200MB pre-DMA IDE drive that I literally rescued from the trash.
Re: (Score:3)
I have a high-end 486 motherboard with four 72-pin SIMM slots and PCI slots that accepts up to 192MB of RAM. For some reason it can't handle four 64MB SIMMs so it won't do 256MB, but it'll handle three fine. Or one 128MB and one 64MB one. But adding anything more makes it not boot and it seems to be a chipset limitation. At one point a couple years ago I had it maxxed out at that complete with an AMD 5x86 120mhz, PCI USB, video, and sound cards and Windows 98 and it did work but... other than for funsies th
Re: (Score:2)
Re: (Score:2)
Back in 2001, me and my girlfriend (now wife) had an old 486-100MHz with 32 MB RAM, running SuSE Linux. I was using it on purpose so that I could not rely on CPU raw power (and VGA) to make my code run decently. It worked. When my code ran on the then modern Pentium II, it had lightning speed. Eventually the 486 died a few years later. We still remember it fondly.
I still do the same trick. My ACER laptop is from 2011 with 3GB of RAM and it is running Mint Mate, 2022 version.
Re:Pray tell, what modern desktop runs in 64MB of (Score:4, Interesting)
The 80486 processor was _technically_ capable of addressing 4GB of RAM. But given that the largest 30-pin SIMM produced was limited to 16MB (due to 24-bit addressing) in practice the upper limit was 128MB, using 8* 16MB SIMMs. (I'm not aware of any mass-market motherboard with over 8 30-pin SIMM slots, but I'm willing to be corrected) Late 486 boards supported 72-pin SIMMs which could theroretically go up to 128MB, but the largest FPM (not the later/faster EDO!) SIMM I was able to find is 64MB, and those 72-pin-equipped 486 boards appeared to still be limited to just two slots, again, for 128MB effective max.
(Additionally, many motherboards were limited to using only 16MB or 32MB max RAM due to cost-cutting with respect to the onboard L2 cache)
And sure, you could use a nice flashy GUI on an Amiga 500 with its M68K and 512K of RAM, but that doesn't mean the A500 is terribly usable for real-world tasks today. Like it or not, folks expect modern $10 systems to achieve far more than what was state-of-the-art thirty years ago.
Re: (Score:2)
For the anecdote, i saw adverts for 486 motherboards which accepted 128 Mo or RAM before the 486DX2 was even available. I never tested them, of course.
Later, there were also souped-up versions of the 486 like that AMD with a quadrupled clock multiplier you could run at 160 Mhz.
I wonder (i don't know) if there are more modern clones running at a higher clocks for specialized tasks, maybe because a 486 design would be immune to some vulnerabilities and its design is out of patent right now.
A bit like those 6
Re: (Score:2)
the vortex86dx SOCs seem to be somewhat along those lines.
I don't know what cpu they are copying but it is used in rasteri's tiny WeeCee
Re: (Score:2)
Not contesting your point in any way, but 128MB 72-pin SIMMs exist. Not sure how common it was back in the day, though, and support on the motherboard side is questionable. I know it exists because I had (and still have) one in my Mac Performa 630 (68040).
Re: (Score:2)
and even 486 could go beyond 64M of RAM.
Could and Did are two distinct words in the English language. Very few 486 machines ever existed with more than 64MB of RAM. They were for insanely niche applications. Now we change the debate from do we support what is today an incredibly rare architecture, to do we support what is today an incredibly rare architecture for the purpose of a niche that almost certainly doesn't exist anymore on that platform?
We can keep going down this rabbit hole of "but it did support", only to find there's a single machine
Re: (Score:2)
"Those who forget the past are doomed to repeat it."
Linux literally is "repeating the past". Its very name is derived from the designs it copies.
"No year will ever be the year of linux on the desktop with this stupid attitude of throwing working code away."
LOL no, that's not it.
Re: (Score:3)
Re: (Score:2)
You are welcome to continue development on support for the 486 if you need continued support for it. The kernel is open source and you can easily clone yourself a local repo and continue 486 support maintenance while merging in new features as time goes on.
Re: Typical Reality (Score:2)
There's throwing away working code, and there is hording old bits even though nobody is even testing them before making changes. Don't be a hoarder. And feel free to hand any important 486 code to any other GPL kernel project. Or switch to NetBSD for your 486 needs.
Re: (Score:2)
Re: (Score:2)
I like having a monitor with xearth on it.
You can't grab the source [xearth.org] and build it for a newer architecture?