News: 1610384593

As long as platform does not get any new specific hardware gadget, is there is need for a change when all CPU/board specific stuff already is there ?

Using already cited example: Does something prevent last kernel version working on powerpc/amigaone ? (assuming of course that involved devices are still operational)

Pehaps we are starting to see systems that become stable enough to not actually need updates!

Pretty much. The only thing I worry about with the older stuff is folks discovering security issues ... and even then, I only worry about it if the gear isn't airgapped, which is rare for this class of computing.

I've been segregating my older systems from the outside world since Meltdown/Specter popped up and where the fix was worse than the disease in terms of performance. Looking at this list, and the fact that I still have working systems on the list mentioned in the article, it's time to archive functional distributions for those machines.

Time to move on for Linux, yes, but keep an archived history around, too.

And you worry about IR35 of course Jake!

The only thing Linux is good for is old PCs that won't run windows.

Also nice on, funnily enough, Microsoft Azure servers.

Android, set top boxes, servers, game consoles, POS systems, TVs, desktop and laptop systems. I could go on, I know you were trolling however I wanted to answer anyway.

As well as any PC with less than 8GB of RAM and/or a spinning rust drive.

I know. I've been a penguin botherer since '96.

(fishhook detected)

Realistically, Linux _OWNS_ embedded.

Well, large-ish embedded anyway.

Not the small stuff.

>>>Not the small stuff<<<

Examples of 'small stuff' that are windows only please!!

Who said anything about Windows? When it comes to embedded, the small stuff is often too small to boot MS-DOS 1.0 ...

Bad troll. No cookie.

"The only thing Linux is good for is old PCs that won't run windows."

You're not playing this game correctly. You wait for a thread about Microsoft, then you drop in the name of whatever hipster distro you are using that week whilst making sure you get in a few digs about slurping as well as whatever fail Microsoft was apologising for in the first place.

@Timto

My new Ryzen based gaming PC would disagree with you.

While I admit, there are some limitations to Linux gaming. Not being stuck in an hour long required update when all you want is to blow some (Virtual) stuff up, makes it all worthwhile.

I don't like Linux much - it's mostly the asinine case sensitive filesystem that irks me. So, my choice, I don't run Linux on any of my computers.

Yet, oddly enough, I have more copies of Linux running in the house than everything else added together.

Let's see. The broadband router. A WiFi media sharer gizmo. The backup router. The manageable hub. My PVR. Two different IPcams. My tablet, and mobile phone. And frankly I wouldn't be surprised if the printer (WiFi, built in web server, blah blah) didn't run it as well.

Tablet and phone are Android. PVR is a stripped down Debian (from the dark ages). Most of the rest are the standard combo of very minimal Linux and Busybox.

So, we're all still waiting for the year of Linux on the desktop, meanwhile it has quietly taken over pretty much everything else that has a little more processing oomph than your average washing machine... Where it sits, peacefully, and just gets shit done without all the drama.

That's what Linux is good for.

"Others volunteered their time in maintaining kernel support for entries in Bergmann's lists."

Thank you for volunteering. To qualify for consideration please send us a picture of you next to your computer and with its cpu showing, so that we can know you can actually do testing on the platform, rather than just testing our patience.

Am I to understand that there are still 486s that are in working order ?

Wow. That brings me back.

486? Newbie!

I've got a contract for LSI-11s still cranking out machine parts[0] ... Just renewed the support contract for "one more year". Again. It's been over 30 years since I took over when the manufacturer went belly-up ... Easy money never gets old.

[0] Granted, they are not running Linux.

In lockdown last year I rebuilt my old 486SX25 and got Gentoo running on it (admittedly, I did the compiling on a "modern" Pentium 4 and moved the disk across). Why? Just to see if I could. It took an hour to boot and wasn't really useful for much though, so I went to Windows 3.1 to play Heretic.

Last I checked, people are still making 486-based CPUs for things like the PC101 platform and other stuff that's mostly for embedded systems.

changing a hardware design might be difficult. But new designs should _DEFINITELY_ use something else [like ARM].

The question is whether or not these legacy systems have any new development or need for security patches...

But it's worth pointing out that, on platforms that can use both 32-bit and 64-bit [most x86 and ARM64], the 32-bit code is probably going to be a little bit faster, and a little bit smaller, due to 64-bits vs 32-bits for memory addresses. Abandoning 32-bit support in its entirety would be a MISTAKE.

But abandoning support for older processors... I guess they could just let the people who actually USE them submit patches themselves. THEN the cost of maintaining the legacy hardware vs maintaining support in the kernel might change something down the road [and devs can spend more time working on things that are more relevant to most of the Linux implementations].

sorta reminds me of the 80:20 or 90:10 [or whatever] rule, about 80% of the code taking 20% of the effort, and the other 20% taking 80% of the effort, usually supporting features that are used a fraction of the time, but taking up WAY too many resources to do it. Just a concept, but seems to be accurate In My Bombastic Opinion.

The 486 and 386 embedded boards probably aren't being updated to the lastest Linux kernel anyway.

They are either getting custom security fixes to the 10year old kernel they are using - or more likely everyone has forgotten that there is a computer in that grey box at all

When I was in uni, early 90's, I bought a 286 for a Digital Systems class project from an electronics corner shop - they had them a drawer full of them, and they were cheap as chips :)

I guess Kids nowadays might buy 486 for similar projects, although I reckon ARM should be more in fashion

These days we have the Raspberry Pi family. No need for big cumbersome 486s.

I have a 486 board around someplace, a DX66 if I remember correctly. Big slab of brown ceramic (is it ceramic? never been brave enough to drop it to see what happens) that's maybe 2/3rds of the size of the entire Pi board, and that's just the processor.

"never been brave enough to drop it to see what happens"

A huge explosion, be careful!

Nah, you'll need a hammer to break that thing.

Happy memories - I had a good old DX2 66MHz back in the mid-90s. Seemed incredibly fast at the time, compared to the 386 that preceded it. It certainly ran 4k demos (remember those?) very nicely!

"But it's worth pointing out that, on platforms that can use both 32-bit and 64-bit [most x86 and ARM64], the 32-bit code is probably going to be a little bit faster, and a little bit smaller, due to 64-bits vs 32-bits for memory addresses."

No. It's worth pointing out the "little smaller" part, but the "little faster" part is almost always dead wrong. If you write something and compile it to a 32-bit instruction set, anything you use that's larger than 32 bits must be chopped up to fit into 32-bit only operations on the CPU. Some may have 64-bit registers, but if the major operations can only handle 32 bits of that at a time, you have to do some more math to put the pieces back together. In 64-bit instruction sets, you can use values that are double the length. Some instruction sets implementing 64-bit operations also have some ability to natively handle 128-bit values. A lot of programs use things that can't fit into 32-bit registers. Long integers, double-precision floating points, etc. Even more use things that can't fit into 64-bit registers either, so they still need chopping, but they need half as much chopping as when they have to be used in 32-bit ones. If a single operation can do what four were needed for before, the processing is faster. If the operation can use two registers when it would have needed three, the program doesn't have to do as many cache and memory requests. Recompiling standard code for 64-bit is likely to make it faster, at the minor cost of increased binary size.

64bit also has greater memory costs. A number of years ago I ran some tests, I configured 2 identical bare bones Ubuntu server VMs running Apache, one 32 bit and one 64 bit. The 32bit system used 170MB RAM while the 64bit system used 270MB.

That's true, but before you go to the conclusion that that's generally applicable, let's discuss what that was. Pointers are twice as long. So a program that uses pointers (all of them) needs more memory to store them. However, most programs don't hold most of their important data in pointers, so that's not a large increase. One program does store most of its data in pointers: the operating system. In order for process-specific memory to work, the OS needs a big table of real pointers and virtual pointers. The OS has a lot of other tables containing pointers too, but the memory tables are among the largest. So it can be generally assumed that a 64-bit operating system is going to use a lot more memory than a 32-bit one, but a 64-bit user-level program probably won't have a similarly-sized increase in memory usage. When operating on a memory-restricted system, the increased usage may mean that the performance hit of a 32-bit OS is necessary.

Short form - you just have to try it both ways and see.

Long form - 64 bit code has access to more registers and that gives the optimizer more chances to do something clever. Fewer memory transfers, which is a nice speedup, can lead to less cache poisoning, which is a really nice speedup. After the 64 bit transition in the early 2000s, it took a while for the compiler writers to catch up but now it's barely even a decision. 64 bit implementations of mmap() can speed up your I/O maybe 5%. On the other hand, yes, if memory is in really short supply then you want to avoid paging and swapping no matter what you have to do.

Also worth mentioning that in the case of the ARM (not familiar with others), there are twice as many registers in the 64 bit world, so while you may lose a little in the memory requirements, you ought to gain a good amount in the speed department, especially with a load/store architecture like ARM where more registers is a good thing.

"The question is whether or not these legacy systems have any new development or need for security patches..."

It may be more of a question as to whether legacy CPU architectures are constraining modern kernel designs.

Maybe a slightly silly example, but what if the kernel designers wanted to run kernel modules in a virtual environment? That implies CPUs which support virtualization. As best I can tell, most modern CPUs do support virtualization, but most of these older ones do not.

A re-architecture of the kernel to support virtual modules would certainly be hampered if they also had to support pre-virtualized CPUs. That might mean a ton of new development on very old CPUs to compatibly no-op all the new stuff.

And didn't something similar happen with 80286s that lacked a flat memory model? The contortions kernels had to go thru to deal with a segmented architecture and a flat memory architecture must have been horrendous. I'll bet a ton of code was thrown away when a OS dropped 286s.

"As one would expect, there was a chorus of "I'm not dead yet!" responses as well as some in the community pointing out that a lack of updates was not necessarily an indicator of a platform's demise."

Probably both true -- a "mature" platform would eventually not need any updates at all, other than the (usually automatically applied) patches so, like, some kernel structure changes it's name or adds a field, the patch updates that structure's use within the platform-specific code. But this also points towards these users probably getting limited benefits from updating their kernel just because newer ones exist.

And I'm sure a few are using it. Probably not many though!

"Am I to understand that there are still 486s that are in working order ?"

Possibly a few.

That said, 1) Are you running a newer distro on your old system anyway? An old distro is going to ship with an older kernel anyway. 2) Is there any reason for a new kernel? Regarding #1, the 486 for instance, I don't think even a top-of-the-line 486 board held more than 128MB of RAM, and (support for your actual CPU aside), you are not going to be running Ubuntu 20.04 or something in that; the Itanic does of course hold plenty of RAM. Bringing me to #2: These CPUs are not receiving updates anyway, so security updates for the platform are probably moot (if there were security flaws in a 486... well, lets go with the Itanic, it's far more complicated and so likely to have flaws compared to a 486... these platforms probably do not have developers looking for or fixing flaws anyway given the lack of activity on them.) Also, I like to have an up-to-date kernel for hardware support, but a 486 or Itanium is not going to be having someone drop like a NVidia RTX1080 or something in it.

I just recently kludged up the Ubuntu HWE 5.8.0-36 kernel so I could build it for Ubuntu 18.04 -- both 64-bit and 32-bit version --- I have one 32-bit system still running Ubuntu 11.04 with MythTV, and have been regularly updating it's kernel (I actually needed a newer one for a newer TV tuner card so I started booting it off the Ubuntu 18.04 kernel several years ago.) No drama, I turned of the "propolice" security system (since ubuntu 11.04 had about 1/8th the propolice security settings it needs with a newer kernel a lot of stuff broke until I turned it off... luckily not sudo and the text editor 8-) ) but THAT IS IT -- X and the entire rest of the Ubuntu 11.04 system boots 100% fine on an Ubuntu 20.04 HWE kernel! (I also updated the kernel to 5.8.0-xx on my other 32-bit system, just serving files with Ubuntu 18.04, "just because.") But, that said, I can guarantee you nobody is shoving a brand-new PCI-E video card or some new TV tuner into a 486 or an Itanium!

There's something to be said about treating the kernel like a BSP "Board Support Product" (the term often used for embedded systems), once you have a kernel that supports every bit of hardware on the system and is feature complete for your use, it's nice from an aesthetic standpoint to know you can potentially install newer kernels, but kind of irrelevant from a practical standpoint; even if there's newer distro available (everything available for your CPU but the kernel)... which AFAIK there is not for 486 or Itanium, other that building something like "Linux From Scratch" and I'm not even sure if that's supported.... you generally CAN run a newer distro with older kernel!

> ... once you have a kernel that supports every bit of hardware on the system and is feature complete for your use, it's nice from an aesthetic standpoint to know you can potentially install newer kernels, but kind of irrelevant from a practical standpoint ...

This is not accurate most of the time. The overwhelming majority of a Linux "kernel" (i.e., kernel + device drivers + filesystems + IPC support + networking stack + ...) is not the CPU-specific support code. As you'd expect, the overwhelming majority of the bugs are also not in the CPU-specific support code but in the other stuff, and fixing most of them doesn't require changes to CPU-specific support code. This is very likely why there has been little change to the CPU-specific support code for these CPUs: the code that's there works fine and as there aren't any new CPUs being made, there's no need for additions.

But one should not conclude that there's no value in a newer OS on those CPUs. Unless the platform is so minimal that there's absolutely nothing but, say, the CPU core and a single embedded UART or I2C interface in use, it's very likely that the older Linux contains bugs in generic code that's being used on the platform. Whether this is so is of course a question specific to a given platform and the Linux configuration that ships with or is normally used with it, but if the embedded system utilises e.g. IPv4, it's practically certain. All such platforms obtain value from being able to run newer Linuxes, regardless of whether any of the CPU-specific support code changes or needs to change.

There are reasons to cut off support for old hardware, but "the code to support it hasn't changed in a while" is not among them, and the assertion that those platforms can't benefit from newer generic software is almost always wrong. The proper reasons to end support include:

- There are no functioning examples of the hardware in real use. This is a bit weaker than "none exist and are available for testing": if no one wants to use the hardware in anger, the fact that someone somewhere is "willing to test" is irrelevant. In that instance, those users are free to maintain museum forks if desired, but there is no point in maintaining support for something that is of only historical interest. Museum hardware can just as well run museum software. This is about the use of the hardware, not its age: there are models 30 years old that are still in active scientific or revenue use, and there are models only 10 years old of which no examples are ever powered except as curiosities.

- Maintaining the hardware-specific software has become a burden on people working in generic software. Usually this indicates that one or more parts of the system were poorly architected to begin with, but if the hardware itself is also obsolete there may not be anyone willing and able to rewrite the software in a way that allows generic development to proceed.

- The hardware lacks some capability that blocks the development of important general-purpose features. This is unlikely to apply in Linux, where the concept of universal features has never really existed and the idea of true cross-platform functionality is considered largely unimportant.

Assumptions about needing newer and necessarily fatter userland software are largely orthogonal and often wrong. If someone is using the platform in anger and has ample incentive to continue doing so, suitable solutions will be found -- as you have done yourself.

If your business model depends on using processors that are considered archaic you always have the option of maintaining the code yourself or, gasp, creating a branch. If you are a hobbyist parasite (just so you know, mostly, I'm a parasite) then remember it's free as in free speech not free as in beer.

"Free software" means software that respects users' freedom and community. Roughly, it means that the users have the freedom to run, copy, distribute, study, change and improve the software. Thus, "free software" is a matter of liberty, not price. To understand the concept, you should think of "free" as in "free speech," not as in "free beer". We sometimes call it "libre software," borrowing the French or Spanish word for "free" as in freedom, to show we do not mean the software is gratis.

— The Free Software Foundation

Modern kernels won't run on 4megs of RAM anyway.

If you've got a 386 that you need to use for something, the older kernels will still be available, and they still work admirably. I've got 386 based machines running various versions of Linux 2.4 doing useful work in odd corners of the world.

I'd have thought an entry-level 2GB Raspberry Pi would do the job even better - and probably at lower energy cost, so it would even pay its enormous £35 cost back eventually! Mine burns around 3.7W at steady state, running Pi-Hole and providing DNS magic to the whole network.

What am I going to run on this 6502 now?

Don't laugh. [1]8-bit Linux actually exists.

It's kind of slow, though. A couple hours to get a bash prompt from a cold boot, using init=/bin/bash as the kernel command line.

[1] http://dmitry.gr/?r=05.Projects&proj=07.%20Linux%20on%208bit

Whoa, wait... So his idea to get around the need of an MMU was to write an ARM emulator to run on his eight bit processor, and run Linux on that?

Oh man, that's devious.

Obligatory plug for Fuzix, it supports 6502s amongst other 8-bit CPUs but there's no disk image for a 6502-based computer on fuzix.org yet.

It takes less than a couple of hours to boot.

As long as Linux keeps supporting the Motorola 68000 and DEC VAX lines.

Stick BSD on that VAX. Worked for kremvax and moscvax, comrade.

I tried to recompile the kernel on my PDP-11, but estimated it wouldn't finish until 2073 :)