Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Tuesday October 25 2022, @02:21PM   Printer-friendly
from the out-with-the-old dept.

Linux Kernel May Drop i486 Support as Torvalds Backs Pentium Plan:

The 486 CPU is somewhat of a relic these days, but its legacy in the Linux kernel has lived on. The i486 has been the de facto minimum for decades. Even Linux, that long-term supporter of outdated architectures, is considering giving up on the chip and removing support for the 486 processors, just like it did for the 386 back in 2012.

The news comes via a post on the Linux Kernel Mailing List (opens in new tab) from Linus Torvalds himself. Recently keen on adding things like the Rust programming language (opens in new tab)and support for Intel Arc GPUs and Loongson CPUs (opens in new tab) to the Linux kernel, Torvalds is now considering removing the venerable 486, writing: "We got rid of i386 support back in 2012. Maybe it's time to get rid of i486 support in 2022?"

The idea, which seems so obvious in these days of Raptor Lake and Ryzen 7000, received a certain amount of pushback, with the claim from some users that new hardware based on the superannuated silicon was still being shipped. When the same plan was raised a year ago, one user said they were still using a 486, and wanted to continue doing so.

The 486, which dates back to 1989, is currently the minimum possible spec for running Linux, and works best with lightweight distros such as Tiny Core Linux.


Original Submission

This discussion was created by janrinok (52) for logged-in users only, but now has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 3, Interesting) by Freeman on Tuesday October 25 2022, @02:43PM (14 children)

    by Freeman (732) Subscriber Badge on Tuesday October 25 2022, @02:43PM (#1278356) Journal

    After a certain period of time, providing support for an ancient CPU is just more effort than it's worth. There's always the option to use an old build, but you're not receiving security updates at the point. To a certain extent, it makes sense to drop support. From a, I have some old i486 hardware lying around, perspective. It kinda sucks. Am I really going to try and do anything critical on decades old hardware, though? Should I even trust it to be secure at all? Even though I nuked windows on it a very long time ago? Last but not least, is it even worth using? When I can power up a RaspberryPi with very low power consumption and have at least similar performance, if not better performance. I'm much more likely to do an interesting project with newer tech, than ancient tech. Unless I'm literally making a museum, is there any point. At that point, is there any point to not just keeping x thing at old version any way and disconnecting it from the internet?

    --
    Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
    • (Score: 4, Insightful) by sjames on Tuesday October 25 2022, @03:17PM (11 children)

      by sjames (2882) on Tuesday October 25 2022, @03:17PM (#1278360) Journal

      One nice thing about Free software is that old versions aren't disappeared into the void.

      • (Score: 2) by vux984 on Tuesday October 25 2022, @03:38PM (10 children)

        by vux984 (5045) on Tuesday October 25 2022, @03:38PM (#1278366)

        The knowledge base around them is pretty fragmented though. It's bad enough getting support/documentation for the 'current/supported' release these days, but on anything old its just an exercise in frustration. It's doable, but it's got to be a passion project / hobby because it sure isn't "efficient use of ones time" if you are trying to be productive.

        • (Score: 4, Interesting) by Immerman on Tuesday October 25 2022, @04:52PM (9 children)

          by Immerman (3985) on Tuesday October 25 2022, @04:52PM (#1278376)

          Somehow I suspect that if you're trying to do something with a 486 these days, an efficient use of time isn't really something you care about. Nor for that matter are an an efficient use of energy or space.

          If you're looking to make a museum piece, do it right. Track down an old 90's Linux distro, or a copy of Windows 95.

          • (Score: 2) by bzipitidoo on Tuesday October 25 2022, @07:21PM (5 children)

            by bzipitidoo (4388) Subscriber Badge on Tuesday October 25 2022, @07:21PM (#1278403) Journal

            Whole lot of stuff would have been done a lot, lot more efficiently if only the doers had waited for better tech. With today's tech, the Transcontinental Railroad could be built in less than a year, instead of the 4 years they needed. Astronomers are, I'm sure, still searching for Planet 9 right now with what they have, despite the progress on a new telescope that, when it comes online in another 2 years, will easily and fairly quickly find Planet 9, if it exists.

            Many an old software project is so terribly dated, its functionality completely superseded, you wonder, was it worth making at all? Like, pretty much every utility ever made for floppy disks in particular. Hard disks utilities may go the same way. For instance, disk defragmentation. Useless on an SSD. Maybe even useless on an HDD with a modern file system such as btrfs.

            The x86 architecture has a lot of cruft, such as, the decimal math operations, the string search operations, and much of the stack manipulation, especially the miserable stack based x87 floating point math. All these things have been superseded by better algorithms. Still improving are operations to support virtualization. A big improvement from the 386 to the 486 were operations to support semaphores. Then there's the system stuff around the PC-- BIOS and the like. Really, it'd be best to dump the whole damned x86 architecture.

            • (Score: 4, Interesting) by Immerman on Tuesday October 25 2022, @08:39PM (3 children)

              by Immerman (3985) on Tuesday October 25 2022, @08:39PM (#1278415)

              On the other hand, if we waited for better tech it might never have happened at all. Very often there's a feedback effect - without the cheap transportation of rail, and the huge markets it opened up, would the advances in automation and mass production that would make it so much faster to deploy today have occurred even remotely as fast as they did?

              I think it's not worth questioning whether something should have been done at all by looking at where things are today. Rather you should look at what it enabled in the interim. Just how much growth and economic activity was enabled by the existence of a transcontinental railway over the last 150 years? Far more than enough to justify taking an extra 3+ years to build it up front, I'd wager.

              Same thing with floppy and defrag utilities. Or heck, the sometimes dramatically performance-enhancing advanced disk formatting utilities for pre-IDE hard drives*. They all eventually became mostly useless as technology improved, but they provided decades of added utility and cost savings for hundreds of millions of people. The important question is, did the cumulative benefits to all those people outweigh the cost of developing the utilities. Based on the ones I felt were well worth the price, and the fact that the producers were selling enough money to be worth continuing to improve them (and attract competitors), I'd say there's not even really a question there.

              *An aside since now that I've remembered the advanced hard disk formatting, I have to share the story: It was not uncommon for early hard drives to have little if any buffer, so that the drive head would read one sector, and then have to wait to finish sending the data to the motherboard before reading again, at which point the next sector was already passing by, so you then had to wait for the platter to perform a complete revolution before the next sector could be read. Potentially after *every* sector read. With the right tool though you could reformat the drive so that the next logical sector would skip ahead one or more physical sectors so that it would be just coming under head by the time the drive was ready to read again, dramatically improving the performance. It was a bit trial and error figuring out the optimal spacing for any particular drive, but being able to read many sectors per revolution instead of just one had dramatic results.

              By the time I discovered the tool as a young tech enthusiast IDE drives were becoming common, with their more complicated integrated controllers that pulled off all sorts of such performance- and capacity-enhancing tricks "behind the scenes". But I still got a lot of mileage using that software to "supercharge" the older PCs that my friends and I typically had access to.

              • (Score: 2) by FatPhil on Tuesday October 25 2022, @09:15PM (2 children)

                by FatPhil (863) <{pc-soylent} {at} {asdf.fi}> on Tuesday October 25 2022, @09:15PM (#1278421) Homepage
                "Interleaving" - I seem to remember the BIOS on my first 286 with a RLL drive offered such a "low level format" where you could change the interleaving. I think it was obsolete by the time drives were "IDE", as the integrated drive electronics took care of all of that for you.
                https://en.wikipedia.org/wiki/Interleaving_%28disk_storage%29

                I think my ZX Spectrum, with Interface 1 and microdrives, had the same thing for the same reason - that was *tape*, so missing the next block was *incredibly* expensive, you had to go all the way round to the start again. (A classic Sinclair cheap-arse solution to a problem - but it worked. Kinda.)
                --
                Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
                • (Score: 2) by bzipitidoo on Wednesday October 26 2022, @12:10AM (1 child)

                  by bzipitidoo (4388) Subscriber Badge on Wednesday October 26 2022, @12:10AM (#1278465) Journal

                  Oh my, yes, I remember sector interleaving. Did it all the time to Apple II disks, and saw exactly the same improvements gp talked about. There was an even better way: make DOS more efficient. The stock stuff would "double buffer", that is, read a sector into the area of memory designated for temporary storage, then copy that data to its final destination. Simply writing directly to the final destination was enough of a speedup that the computer would be ready to read the next sector in time, no interleaving needed. Lot of 3rd party DOSes did just that. One last trick I figured out, for a tiny bit more speed, was adding a slight delay to the disk format routine, so that the first sector of the next track was perfectly positioned for reading after moving the arm from the last sector of the previous track. The original format routine was a little too fast at formatting, and so when reading, the computer would just miss the start of the next track.

                  Early computers and software had a whole lot of low hanging fruit of that sort. I often hacked into games, examined the algorithms, and when I came across an especially lame one, replaced it with a much better one. The speedup made the games more enjoyable.

                  • (Score: 2) by Immerman on Thursday October 27 2022, @01:09AM

                    by Immerman (3985) on Thursday October 27 2022, @01:09AM (#1278669)

                    Ooh... I never heard that one. Then again I never really dabbled in 3rd-party DOSes either. I went from Vic20s and C64s to PCs in the... early 386 days I think it was. Still had lots of old PCs around for a poor kid to play with, but things were advancing fast, and the internet with its wealth of knowledge was still mostly a university thing.

            • (Score: 2) by DannyB on Thursday October 27 2022, @07:10PM

              by DannyB (5839) Subscriber Badge on Thursday October 27 2022, @07:10PM (#1278816) Journal

              Really, it'd be best to dump the whole damned x86 architecture.

              Well said!

              How many poor helpless transistors could be freed if the chains of decades of legacy baggage could be snipped off. >8 Snip.

              --
              How often should I have my memory checked? I used to know but...
          • (Score: 3, Interesting) by sjames on Tuesday October 25 2022, @10:29PM (2 children)

            by sjames (2882) on Tuesday October 25 2022, @10:29PM (#1278441) Journal

            The other likelihood is some old piece of equipment with an old interface to an industrial PC running on a '486. Possibly with an ISA card.

            • (Score: 2) by Immerman on Wednesday October 26 2022, @12:48AM (1 child)

              by Immerman (3985) on Wednesday October 26 2022, @12:48AM (#1278470)

              How often is the OS on a typical piece of old industrial equipment updated?

              • (Score: 3, Insightful) by sjames on Wednesday October 26 2022, @01:06PM

                by sjames (2882) on Wednesday October 26 2022, @01:06PM (#1278531) Journal

                As rarely as possible. But it's nice that old compatible distros remain available in case a drive eats itself or similar.

                Also nice that the source remains available to take care of corner cases.

    • (Score: 2) by canopic jug on Tuesday October 25 2022, @03:31PM (1 child)

      by canopic jug (3949) Subscriber Badge on Tuesday October 25 2022, @03:31PM (#1278364) Journal

      From what I read, it had more to do with the developers not having access to the hardware in question any more. If you are doing all the work in an emulator or virtual machine, there's only so much you can test and it is not the same as running on "bare metal". If that's the case then, fine, it's time. There is a lot more old unmaintained cruft that can be removed. Perhaps they can train up a team to focus exclusively on "tedu"-ing the code base before it is way too late.

      On the topic of old code, has the 32-bit code base moved to 64-bit time yet? Was there an upgrade? [lkml.org] or not? Or are there still kernels which are being deployed today in embedded hardware with long life cycles which are going to make their presence known on 19 January 2038 at 03:14:07 UTC? That's just over 15 years away and any machines with a 25-year life span are there ticking away already.

      --
      Money is not free speech. Elections should not be auctions.
      • (Score: 2) by FatPhil on Tuesday October 25 2022, @09:17PM

        by FatPhil (863) <{pc-soylent} {at} {asdf.fi}> on Tuesday October 25 2022, @09:17PM (#1278422) Homepage
        I know some Arm maintainers, and they still test kernel builds on OMAP1 boards that they refuse to let die. (And everything since.)
        --
        Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
  • (Score: 4, Funny) by Rosco P. Coltrane on Tuesday October 25 2022, @04:29PM

    by Rosco P. Coltrane (4757) on Tuesday October 25 2022, @04:29PM (#1278372)

    There comes a time when everybody wants a good pentium plan.

  • (Score: 3, Touché) by takyon on Tuesday October 25 2022, @06:10PM (2 children)

    by takyon (881) <takyonNO@SPAMsoylentnews.org> on Tuesday October 25 2022, @06:10PM (#1278392) Journal

    When the same plan was raised a year ago, one user said they were still using a 486, and wanted to continue doing so.

    With an old kernel.

    --
    [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
    • (Score: 2) by Thexalon on Tuesday October 25 2022, @07:28PM (1 child)

      by Thexalon (636) Subscriber Badge on Tuesday October 25 2022, @07:28PM (#1278404)

      And I'd also recommend keeping it air-gapped from the Internet, just to be on the safe side.

      --
      The only thing that stops a bad guy with a compiler is a good guy with a compiler.
      • (Score: 2) by SomeGuy on Tuesday October 25 2022, @10:25PM

        by SomeGuy (5632) on Tuesday October 25 2022, @10:25PM (#1278439)

        Internet? Would that even work over their parallel port Laplink cable?

  • (Score: 3, Insightful) by ShovelOperator1 on Tuesday October 25 2022, @06:29PM (6 children)

    by ShovelOperator1 (18058) on Tuesday October 25 2022, @06:29PM (#1278395)

    It looks like 486 is obsolete on the desktop. And it generally is - Linux GUI, while totally usable in 486 in early days, grown so much that it is unusable in 32-bit with less than 2GB of RAM. Even when CDesktopEnv is used, other apps will need more RAM.
    However, many of these small embedded modules with ISO connectors called "system-on-module", PC/104, and some embedded control circuitry, they have 486s on it. It is usually not Intel's 486 - in best cases you will find low-voltage AMDs, in the worst - some unknown chip like "486+VGA+advanced I/O" in it, but they are all there, and they are controlling machinery.
    But do they need updates? They usually run DOS+DPMI+dedicated software. Some run a DOS+GEM spin-off, I restored one using FreeDOS and it works even today. I know about two running some stripped-down Unix-ish system with semi-rtos kernel (based on Minix???). One German device was running an unusual thing (called like "System for Mobile"?) which I called "DOS-RTOS", because running in protected mode it offered DOS interface, a multitasking using strange hack and RT process "slot". I have seen Linux maybe once or twice, and never GNU toolchain (or a very minimized one).
    These machines will not miraculously grow USB4 controllers or GPU acceleration boards. They do not offer SSH. They are mostly secure with their old software burned in their silicon drives.
    Well, I just cannot see anything newer instead of this hardware. Modern PC CPUs have an on-chip spyware and remote control modules, so they are unfeasible for production-critical applications. Chinese ARMs look a bit better, mostly because you can compare to references during auditing, but rewriting the software is impossible (e.g. source code lost in 1989), and boot procedure is unacceptable - I don't know even did they sort the things out with RPi and the part that loads the code to cache is verified or not.
    However, phasing out the 486 will phase out some drivers which when lost will create a real loss of supported hardware. And hardware support in Linux is the thing Linux devs should be proud of. I could not connect old ATA drive to my Debian notebook to recover the data. Used a dock, its parallel port and an old EPAT board I found somewhere around. Boom! - it worked in Linux and it looks like Linux has kernel support for so old and so rare hardware as the converter of printer port to hard disk channel.
    After X11 lost its support for all National Semiconductor stuff, actively used in control hardware, I started to be cautious with phasing these things out.

    • (Score: 2) by Thexalon on Tuesday October 25 2022, @07:38PM (4 children)

      by Thexalon (636) Subscriber Badge on Tuesday October 25 2022, @07:38PM (#1278408)

      Linux GUI, while totally usable in 486 in early days, grown so much that it is unusable in 32-bit with less than 2GB of RAM.

      What exactly do you mean by "Linux GUI", out of curiosity? Because to the best of my knowledge, Xorg isn't that big (it may be smaller than XFree86 was, because you only have to load up the stuff you actually want), and lightweight window managers like XFCE and Blackbox still exist. And checking right now, it looks to me like my fairly heavy-weight Gnome is taking 500M.

      --
      The only thing that stops a bad guy with a compiler is a good guy with a compiler.
      • (Score: 2) by Immerman on Tuesday October 25 2022, @08:45PM (3 children)

        by Immerman (3985) on Tuesday October 25 2022, @08:45PM (#1278416)

        500M is a bit much, considering that in its heyday most 486 motherboards could only handle *maybe* 8MB of RAM.

        • (Score: 0) by Anonymous Coward on Tuesday October 25 2022, @09:23PM (1 child)

          by Anonymous Coward on Tuesday October 25 2022, @09:23PM (#1278423)

          most 486 motherboards could only handle *maybe* 8MB of RAM.

          Early 486 motherboards used 30-pin SIMM slots for RAM. There is always a multiple of 4 of these slots, usually 8. These can be populated with modules up to 16MB in size, so 4 of those hits 64MB easily.

          Later motherboards used 72-pin SIMM slots which support much larger module sizes. These don't have any particular restrictions on slot count but 4 slots was pretty common.

          • (Score: 2) by Reziac on Wednesday October 26 2022, @03:04AM

            by Reziac (2489) on Wednesday October 26 2022, @03:04AM (#1278485) Homepage

            Earliest I've seen 72pin SIMMs was on a genuine IBM 286-10MHz. It also had onboard IDE.

            16mb 30pin SIMMs were insanely expensive. In early 1995 I paid $400 for four 4MB SIMMs for a 486, and that was enough of a bargain to drive 140 miles in L.A. traffic to pick them up. 16mb modules weren't just 4x more costly, more like 10x more costly.

            --
            And there is no Alkibiades to come back and save us from ourselves.
        • (Score: 1) by ShovelOperator1 on Wednesday October 26 2022, @08:45AM

          by ShovelOperator1 (18058) on Wednesday October 26 2022, @08:45AM (#1278517)

          In 486's RAM, you have a span from 4MB (FPUless 486SX-33) to maybe 48MB (if board has 72-pin SIMMs, DX4-100), but it's a beefed-up configuration. These embedded systems are usually 8-16MB and typical home system of that era had 8MB.
          4MB 30-pin SIMM is a rarity and always was.
          72-pin SIMMs have been introduced by IBM in their 2/386 computers like PS/2 or PS/1, but there are really a few non-IBM 386 boards with it - it started to be extensively used with mid-late 486.
          So Linux with 500MB requirement built for 486 is not practically usable.

    • (Score: 3, Informative) by Freeman on Tuesday October 25 2022, @09:35PM

      by Freeman (732) Subscriber Badge on Tuesday October 25 2022, @09:35PM (#1278426) Journal

      The Author rightly pointed to the likes of Tiny Core Linux. While Tiny Core Linux isn't terribly user-friendly. It certainly can make a 486 feel blazingly fast, to a certain degree.

      "Tiny Core Linux 13 Released: Needs Just 46MB of RAM, 50MB of Disk" https://www.tomshardware.com/news/tiny-core-linux-13-released [tomshardware.com]

              RAM: minimum 46MB, recommended 128MB
              CPU: minimum Intel 486DX processor, recommended Intel Pentium 2
              Storage: minimum 50MB to install (uses 28MB on disk when installed, no apps), recommended storage depends on the apps you want to install and run

      Part of the black magic that is Tiny Core Linux is the fact that the entire OS is loaded into RAM. Which makes the UI very responsive. Sure, even with such a small OS as Tiny Core Linux, you do have the likes of Firefox/Chrome that suck down tons of RAM and are literally larger than the core of the OS they are running from. Still, if someone wanted to use a 486 with internet and a usable browser. There are possible options. K-Meleon (project is very much a passion project with serious longevity issues) and Palemoon (seems like it might actually work with a 486) are about the only options. Beyond something like Lynx, which to be honest isn't much of a browser. It could do in a pinch though, depending on your use case. Looking at Tiny Core's tcz supported applications. I see epiphany (probably the web browser), pale moon, firefox, and chromium. So, if you wanted a fairly responsive system on an old laptop, that you don't mind tinkering with A Lot. Tiny Core could be usable for that. Though, I might suggest using something totally different, if all you want is to consume youtube content or the like. Like a RaspberryPi with a supported OS and modern browser. While it may not be a great experience, it certainly will be more likely to just work. In the event that you want to use that old laptop to play dos games or the like. Tiny Core Linux may just be the ticket. It has packages for DOSBox and WINE. Depending on how powerful of a computer you are using, DOSBox is the more likely of the two to be useful.

      --
      Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
  • (Score: 2) by SomeGuy on Tuesday October 25 2022, @10:38PM (1 child)

    by SomeGuy (5632) on Tuesday October 25 2022, @10:38PM (#1278445)

    Back when it was released, I tried loading the original RedHat Linux 5.0 on my old 486. I believe that even had a 486-100 overdrive in it. That wasn't something I would have called usable even back then. That reminds me, I even tried Windows 95, OS/2, and other OSes on that machine and kept reverting to DOS.

    Recently trying some current 32-bit Linux distros on an Athlon XP was almost as unusable. I'd be more thrilled if I knew 32-bit support for this era of machine wasn't going to rot and disappear.

    • (Score: 2) by Reziac on Wednesday October 26 2022, @03:09AM

      by Reziac (2489) on Wednesday October 26 2022, @03:09AM (#1278486) Homepage

      I had RH6 on my P233... it was painfully slow. RH5 on a DX4-100 sounds like a new and exciting sort of masochism. :)

      Puppy linux runs fine on a 20 year old laptop with 340mb RAM (yes, a weird amount, because of onboard 8mb modules) but I can't imagine anything modern on it.

      --
      And there is no Alkibiades to come back and save us from ourselves.
  • (Score: 4, Funny) by jb on Wednesday October 26 2022, @02:13AM (2 children)

    by jb (338) on Wednesday October 26 2022, @02:13AM (#1278478)

    Instead of dropping i486 support, they should be adding i286 support. After all, ancient though it is, the venerable i286 is still the most recent Intel CPU to be altogether immune to spectre class vulnerabilities...

    • (Score: 2) by DannyB on Thursday October 27 2022, @07:15PM (1 child)

      by DannyB (5839) Subscriber Badge on Thursday October 27 2022, @07:15PM (#1278818) Journal

      What if you had a beowulf cluster of these?

      --
      How often should I have my memory checked? I used to know but...
      • (Score: 2) by jb on Friday October 28 2022, @01:59AM

        by jb (338) on Friday October 28 2022, @01:59AM (#1278890)

        What if you had a beowulf cluster of these?

        A nice thought ... but the electricity bill would be quite scary.

(1)