From the «says Linux» department:
Feed: The Register
Title: Linus Torvalds suggests the 80486 architecture belongs in a museum, not
the Linux kernel
Author: Simon Sharwood
Date: Tue, 25 Oct 2022 02:56:25 -0400
Link: https://go.theregister.com/feed/www.theregister.com/2022/10/25/486_support_linux_kernel_ending/

Ancient hardware deserves ancient kernels, but cannot justify consuming
developers' valuable time

Linux boss Linus Torvalds has contemplated ending support for the i486 processor
architecture in the Linux kernel.…

--
Usenet: antisocial media

Am 25.10.2022 um 12:33:56 Uhr schrieb Retrograde:

> Ancient hardware deserves ancient kernels, but cannot justify
> consuming developers' valuable time
>
> Linux boss Linus Torvalds has contemplated ending support for the
> i486 processor architecture in the Linux kernel.…

Most Linux distributions provide only support for i686, that was the
Pentium Pro. I cannot even imagine how it is possible to run a 486 with
enough RAM (256 MB) to boot the current kernel.

Marco Moock <mo01@posteo.de> wrote:
> Am 25.10.2022 um 12:33:56 Uhr schrieb Retrograde:
>
>> Ancient hardware deserves ancient kernels, but cannot justify
>> consuming developers' valuable time
>>
>> Linux boss Linus Torvalds has contemplated ending support for the
>> i486 processor architecture in the Linux kernel.?
>
> Most Linux distributions provide only support for i686, that was the
> Pentium Pro. I cannot even imagine how it is possible to run a 486
> with enough RAM (256 MB) to boot the current kernel.

The i486 chip family supported 32 bit physical addresses (which allow
for 4G of RAM per process) and 46 bit logical virtual addresses (which
would allow for a lot more than 4G of RAM for the system) [1].

Granted, nearly all boards containing a 486 would not allow insertion
of enough physical ram chips to get anywhere near 4G of physical RAM,
much less 2^46 bytes of ram, but I'd bet there were some i486 boards
back in the day (more likely to be server class than desktop class)
that did allow for a lot more than 256MB of RAM.

[1] https://en.wikipedia.org/wiki/I486

Rich <rich@example.invalid> wrote:
> Marco Moock <mo01@posteo.de> wrote:
>> Am 25.10.2022 um 12:33:56 Uhr schrieb Retrograde:
>>
>>> Ancient hardware deserves ancient kernels, but cannot justify
>>> consuming developers' valuable time
>>>
>>> Linux boss Linus Torvalds has contemplated ending support for the
>>> i486 processor architecture in the Linux kernel.?
>>
>> Most Linux distributions provide only support for i686, that was the
>> Pentium Pro. I cannot even imagine how it is possible to run a 486
>> with enough RAM (256 MB) to boot the current kernel.
>
> The i486 chip family supported 32 bit physical addresses (which allow
> for 4G of RAM per process) and 46 bit logical virtual addresses (which
> would allow for a lot more than 4G of RAM for the system) [1].
>
> Granted, nearly all boards containing a 486 would not allow insertion
> of enough physical ram chips to get anywhere near 4G of physical RAM,
> much less 2^46 bytes of ram, but I'd bet there were some i486 boards
> back in the day (more likely to be server class than desktop class)
> that did allow for a lot more than 256MB of RAM.

There's also at least one DIY board which supports up to 4GB of
RAM, the Full Size S100 80486 Board:
http://www.s100computers.com/My%20System%20Pages/80486%20Board/80486%20CPU%20Board.htm

--
__ __
#_ < |\| |< _#

Marco Moock <mo01@posteo.de> wrote:
> Am 25.10.2022 um 12:33:56 Uhr schrieb Retrograde:
>
>> Ancient hardware deserves ancient kernels, but cannot justify
>> consuming developers' valuable time
>>
>> Linux boss Linus Torvalds has contemplated ending support for the
>> i486 processor architecture in the Linux kernel....
>
> Most Linux distributions provide only support for i686, that was the
> Pentium Pro. I cannot even imagine how it is possible to run a 486 with
> enough RAM (256 MB) to boot the current kernel.

Where did you get 256MB from? I've booted a current Linux kernel
with much less. Indeed the router that I'm connecting through for
posting this only has 32MB of RAM and "uname -a" tells me:

Linux OpenWrt 5.10.138 #0 SMP Sat Sep 3 02:55:34 2022 mips GNU/Linux

(yes I know 32MB RAM isn't officially supported by OpenWRT
anymore, but it works anyway)

I believe the limit might be around the 16MB area, though maybe 8MB
is still possible with an extremely small initrd image.

--
__ __
#_ < |\| |< _#

Retrograde <fungus@amongus.com.invalid> wrote:
> Link: https://go.theregister.com/feed/www.theregister.com/2022/10/25/486_support_linux_kernel_ending/
>
> Ancient hardware deserves ancient kernels, but cannot justify consuming
> developers' valuable time
>
> Linux boss Linus Torvalds has contemplated ending support for the i486 processor
> architecture in the Linux kernel....

All this attention over one branch of a mailing-list discussion
might be a bit much.

Anyway, I believe the 486 is also the only x86 CPU that has a
fully-functional open-source FPGA implementation available, so it's
still potentially useful for people who want to implement hardware
that's as open-source as physically possible. If they don't want to
use RISC-V.

The original project is here, though development seems to be dead.
It runs a modified version of Tiny Core Linux, which still supports
the 486:
https://github.com/alfikpl/ao486

This seems to be where current development is happening:
https://github.com/MiSTer-devel/ao486_MiSTer

Also, the Vortex86 SoCs are still being manufactured, though it's
noted in the mailing list that the current models are fully i586
compatible.

https://en.wikipedia.org/wiki/Vortex86

Odds are that 99% of the people buying those are actually planning
to run an old OS on them though.

--
__ __
#_ < |\| |< _#

Am Tue, 25 Oct 2022 14:17:06 -0000 (UTC)
schrieb Rich <rich@example.invalid>:

> Granted, nearly all boards containing a 486 would not allow insertion
> of enough physical ram chips to get anywhere near 4G of physical RAM,
> much less 2^46 bytes of ram, but I'd bet there were some i486 boards
> back in the day (more likely to be server class than desktop class)
> that did allow for a lot more than 256MB of RAM.

Do you have some examples that support more?
I can of course believe that for i686 (Pentium Pro), but for i486 it
sounds uncommon.
486 came out in 1989, but was manufactured until 2007 (I assume as a
replacement or for embedded systems).
I know that Heidelberg printing systems had some boards for i486 to
show it to their visitors, but I dunno if their new machines still use
them.

Am 26 Oct 2022 07:58:20 +1000
schrieb not@telling.you.invalid (Computer Nerd Kev):

> Where did you get 256MB from?

My own experiments with Linux distributions like Debian. 386 MiB works
pretty fine.

> I've booted a current Linux kernel with much less. Indeed the router
> that I'm connecting through for posting this only has 32MB of RAM and
> "uname -a" tells me:
>
> Linux OpenWrt 5.10.138 #0 SMP Sat Sep 3 02:55:34 2022 mips GNU/Linux

Is that the normal kernel or did they removed all features a router
doesn't need?
Then it sounds normal, but I cannot believe that it is possible to boot
a distribution with additional software like systemd or daemon services
with 32 MiB.

Marco Moock <mo01@posteo.de> wrote:
> Am 26 Oct 2022 07:58:20 +1000
> schrieb not@telling.you.invalid (Computer Nerd Kev):
>
>> Where did you get 256MB from?
>
> My own experiments with Linux distributions like Debian. 386 MiB works
> pretty fine.

Distros like Debian aren't really targeting the low end, or at
least not this deep into it. Besides OpenWrt, Tiny Core is another
example that caters to the very low-end, but with a more
general-purpose scope (though it specifies 46MB minimum RAM). Then
there's the recent Floppinux disk, though it's not a full distro.

>> I've booted a current Linux kernel with much less. Indeed the router
>> that I'm connecting through for posting this only has 32MB of RAM and
>> "uname -a" tells me:
>>
>> Linux OpenWrt 5.10.138 #0 SMP Sat Sep 3 02:55:34 2022 mips GNU/Linux
>
> Is that the normal kernel or did they removed all features a router
> doesn't need?

It's the Linux kernel, but as with all distros they select which
features are enabled when the kernel is compiled. Many features
that a distro like Debian has enabled are likely to be disabled,
and this may cause things like /dev interfaces used by specific
software to be unavailable.

But in general it would run the vast majority of software.
There are packages for big programs like Apache, Dovecot, and
ffmpeg, though I'm sure they wouldn't run very well on my router
hardware.

> Then it sounds normal, but I cannot believe that it is possible to boot
> a distribution with additional software like systemd or daemon services
> with 32 MiB.

OpenWrt doesn't use Systemd, but it has dbus (though they also have
their own more lightweight alternative (ubus) that they use in the
base system) so you could build pretty much whatever daemon-type
program you want. Besides the default daemons I just run pppd for
my USB mobile broaband modem, and vsftpd for FTP/SFTP.

It all works fine, except that as kernels get bigger it takes
longer to boot with each upgrade (likely much more to do with the
speed of the CPU and onboard flash than the RAM).

--
__ __
#_ < |\| |< _#

Marco Moock <mo01@posteo.de> wrote:
> Am Tue, 25 Oct 2022 14:17:06 -0000 (UTC)
> schrieb Rich <rich@example.invalid>:
>
>> Granted, nearly all boards containing a 486 would not allow
>> insertion of enough physical ram chips to get anywhere near 4G of
>> physical RAM, much less 2^46 bytes of ram, but I'd bet there were
>> some i486 boards back in the day (more likely to be server class
>> than desktop class) that did allow for a lot more than 256MB of RAM.
>
> Do you have some examples that support more?
> I can of course believe that for i686 (Pentium Pro), but for i486 it
> sounds uncommon.

Larger total RAM size was likely limited to only servers (as it is even
still today), which would make it very uncommon for the rest of us who
would have been buying garden variety clone motherboards, not servers,
at the time.

> 486 came out in 1989, but was manufactured until 2007 (I assume as a
> replacement or for embedded systems). I know that Heidelberg
> printing systems had some boards for i486 to show it to their
> visitors, but I dunno if their new machines still use them.
>

Do I know of a board that supported more than 256MB? -- no. Does it
seem reasonable that a **server** class board very well might have
supported more than 256MB of installed RAM, yes.

Also, in Message-ID: <63585929@news.ausics.net> Computer Nerd Kev
offered an example of a 486 board that supports 4GB of RAM (providing
someone wanted to add enough RAM boards to the system to supply 4GB of
RAM):

> There's also at least one DIY board which supports up to 4GB of
> RAM, the Full Size S100 80486 Board:
> http://www.s100computers.com/My%20System%20Pages/80486%20Board/80486%20CPU%20Board.htm

Here is one that claims support for up to 128MB of RAM (half way to
256MB):
https://theretroweb.com/motherboards/s/intel-classic-pci-i486-alfredo

Computer Nerd Kev <not@telling.you.invalid> wrote:
> Marco Moock <mo01@posteo.de> wrote:
>> Is that the normal kernel or did they removed all features a router
>> doesn't need?
>
> It's the Linux kernel, but as with all distros they select which
> features are enabled when the kernel is compiled. Many features that
> a distro like Debian has enabled are likely to be disabled, and this
> may cause things like /dev interfaces used by specific software to be
> unavailable.

Also keep in mind that the core of the kernel is actually rather small.
Compiling almost everything as a module (instead of directly into the
kernel) and using an initrd to load the initial modules to get booted
will allow booting/operation in quite memory constrained environments.

Standard distros often compile the kernel with a majority of common
drivers directly compiled in, leaving the remainder of uncommon ones as
modules, every "compiled in" driver that could have been a module adds
to the minimum ram the kernel needs to boot and get started.

Rich wrote:
....
> Do I know of a board that supported more than 256MB? -- no. Does it
> seem reasonable that a **server** class board very well might have
> supported more than 256MB of installed RAM, yes.

i know of at least one database oriented machine that had more
than 256MB:

Sequent Computer Systems (in the mid 90s)

"Symmetry 2000/700
The S2000/700 ran either DYNIX/ptx or DYNIX 3. It featured up to 30 25 MHz Intel 80486 processors, each with a 512 KB cache. It also supported up to 384 MB of RAM, up to 85.4 GB of disk storage, and up to 256 direct-connected serial ports."

songbird

Am 26.10.2022 um 13:08:32 Uhr schrieb Rich:

> Standard distros often compile the kernel with a majority of common
> drivers directly compiled in, leaving the remainder of uncommon ones
> as modules, every "compiled in" driver that could have been a module
> adds to the minimum ram the kernel needs to boot and get started.

Thanks, that explains why special operating systems like OpenWRT work
on much less RAM.

Marco Moock <mo01@posteo.de> wrote:
> Am 26.10.2022 um 13:08:32 Uhr schrieb Rich:
>
>> Standard distros often compile the kernel with a majority of common
>> drivers directly compiled in, leaving the remainder of uncommon ones
>> as modules, every "compiled in" driver that could have been a module
>> adds to the minimum ram the kernel needs to boot and get started.
>
> Thanks, that explains why special operating systems like OpenWRT work
> on much less RAM.

The uncompressed size of the MIPS32 Linux kernel 5.10.138 ELF
(vmlinux file (not compressed vmlinuz)) from OpenWrt 22.03.0 is
8.5MB.

The uncompressed size of the x86_64 Linux kernel 4.19.260-1 ELF
from Debian 10 (Buster) is 27MB.

The Debian kernel has 134 modules built-in, but I can't find a copy
of the modules.builtin file for OpenWrt so I can't compare that.
Though there are sure to be fewer modules built into OpenWrt, as
well as fewer other optional features like multi-processor support,
contributing to the smaller size.

It clearly doesn't make the difference that would alone stop Debian
running on a system with 256MB RAM though. Nor would the size of the
compressed initrd image which is 87.5MB uncompressed (only required
to be held in RAM at the initial stage of booting). I'm guessing
that the limit lies with the particulars of init process
(Systemd-based in Debian's case), which of course is an area of
great variation between distros.

Hint: The extract-vmlinux script in the Linux sources is very
helpful for getting an uncompressed kernel out of the vmlinuz
file used at boot.

--
__ __
#_ < |\| |< _#