Linked by Thom Holwerda on Mon 8th Jan 2018 22:48 UTC, submitted by teco.sb
Linux

What is the oldest x86 processor that is still supported by a modern Linux kernel in present time?

I asked the above quiz question during the Geekcamp tech conference in Nov 2017 during my emcee role. The theoretical answer as you can glean from the title of this post is the 486 which was first released in 1989. I determined that fact from this article where support for the 386 was dropped in Dec 2012.

To get you interested, here is the result of my effort.

Cool project.

Order by: Score:
Not just the kernel
by whartung on Mon 8th Jan 2018 23:59 UTC
whartung
Member since:
2005-07-06

The problem here is that along with the vast expansion of computing resources over time, the kernel and user land have both, like a gas, expanded to fill the usable space.

I mean, honestly, "64MB minimum, 1GB suggested". The "suggested" memory is SIXTEEN TIMES the minimum values? We're talking night and day here.

Of course, Back In The Day, Linux (and BSD et al) booted "just fine" on our crummy 486 (and 386) machines. Back in The Day, NeXTSTEP booted and ran (reasonably) well in 8MB on at 25Mhz 68040. It certainly ran much better on 20MB of RAM. But this was a full boat graphic environment running PostScript (not know for being "cheap" or frugal).

Of course the old workstations with their simple GUI shells (Suntools, early X) ran with even smaller amounts of memory. Sun 3/50 had, at most, 4MB of RAM. And, no, it was not renowned as a speed demon. But it's ran Unix just fine.

So, not to reminisce about the "good ol days", but just to point out that simply having a kernel that will run on the processor is but one aspect of the whole. It's the entire system that you need to be concerned about.

I imagine if you grabbed a FreeBSD v3 or v4, it would "work just fine" as they were more contemporary of the hardware at the time. I only cite BSD simply because it's a single, coherent whole of kernel and user land. No doubt you could find a suitable Linux kernel, I just don't know where you'd find a related user land (outside of downloading old InfoMagic Slackware CD images perhaps).

Reply Score: 3

RE: Not just the kernel
by project_2501 on Tue 9th Jan 2018 00:17 UTC in reply to "Not just the kernel"
project_2501 Member since:
2006-03-20

I imagine some of the older operating systems would be extremely zippy today as they'd fit entirely in a CPU's level2 cache!

Reply Score: 5

RE: Not just the kernel
by unclefester on Tue 9th Jan 2018 00:30 UTC in reply to "Not just the kernel"
unclefester Member since:
2007-01-13

Windows 3.1, NT or OS/2 would be running in seconds on this hardware. It would be blazing fast as well.

Reply Score: 3

RE: Not just the kernel
by tidux on Tue 9th Jan 2018 01:51 UTC in reply to "Not just the kernel"
tidux Member since:
2011-08-13

Damn Small Linux would work well on that. A 2.4.x kernel, last updates in 2008, 50MB live CD. The transition from 2.4 to 2.6 is the inflection point where Linux deliberately stopped supporting extremely old or slow configurations, which is why the 2.4 series got patches for ages.

Reply Score: 5

RE[2]: Not just the kernel
by unclefester on Tue 9th Jan 2018 02:59 UTC in reply to "RE: Not just the kernel"
unclefester Member since:
2007-01-13

Damn Small Linux would work well on that. A 2.4.x kernel, last updates in 2008, 50MB live CD. The transition from 2.4 to 2.6 is the inflection point where Linux deliberately stopped supporting extremely old or slow configurations, which is why the 2.4 series got patches for ages.


Even DSL has hardware requirements more than order of magnitude higher than Window 3.1 [released in December 1993].

Reply Score: 3

RE[3]: Not just the kernel
by tidux on Tue 9th Jan 2018 23:28 UTC in reply to "RE[2]: Not just the kernel"
tidux Member since:
2011-08-13

And Windows 3.1 was crashy garbage.

Reply Score: 1

But why?
by Veto on Tue 9th Jan 2018 07:08 UTC in reply to "Not just the kernel"
Veto Member since:
2010-11-13

I love these "Because I can!" articles ;-)

Reply Score: 1

RE: Not just the kernel
by agentj on Tue 9th Jan 2018 08:11 UTC in reply to "Not just the kernel"
agentj Member since:
2005-08-19

So what they ran on hardware which even beggar wouldn't want for free today ? They were:
* crappy compilers where even x++ and ++x made difference on generated code
* GUI with post stamp size resolutions
* no features whatsoever
* loading of anything slow as hell - applications took ages to start
* full of bugs which could destroy everything
* easily exploitable by a high school student
* one process could easily crash whole OS
* filesystems which died on hard reset
* no support for anything more complex that WAV, BMP and AVI
* error handling next to none
* opening file via network ? Never heard of
* no or poor encryption - anyone could access any data
* no serious multi user support
* no data isolation
* poor or no multithreading support
* poor or no multi-CPU support
* dependencies on chip timings
* people crying how Windows is bad because you can't install interrupt handler or access I/O ports directly from user space
* low speed bus interfaces such as ISA or PCI
... etc.

You can choose either features+security or running on ancient hardware.

Edited 2018-01-09 08:14 UTC

Reply Score: 4

RE[2]: Not just the kernel
by unclefester on Wed 10th Jan 2018 01:52 UTC in reply to "RE: Not just the kernel"
unclefester Member since:
2007-01-13

So what they ran on hardware which even beggar wouldn't want for free today ? They were:
* crappy compilers where even x++ and ++x made difference on generated code
* GUI with post stamp size resolutions
* no features whatsoever
* loading of anything slow as hell - applications took ages to start
* full of bugs which could destroy everything
* easily exploitable by a high school student
* one process could easily crash whole OS
* filesystems which died on hard reset
* no support for anything more complex that WAV, BMP and AVI
* error handling next to none
* opening file via network ? Never heard of
* no or poor encryption - anyone could access any data
* no serious multi user support
* no data isolation
* poor or no multithreading support
* poor or no multi-CPU support
* dependencies on chip timings
* people crying how Windows is bad because you can't install interrupt handler or access I/O ports directly from user space
* low speed bus interfaces such as ISA or PCI
... etc.

You can choose either features+security or running on ancient hardware.


Back in the 1990s they had CRT monitors up to QXGA (2048x1536) resolution. The software was quite snappy on decent hardware and NT, OS/2 and the unixes were all rock solid. Security wasn't really an issue because computers weren't normally exposed to external networks.

There were no MP3s or high-res videos in 1993 so playback wan't an issue.

Edited 2018-01-10 02:00 UTC

Reply Score: 3

RE: Not just the kernel
by bassbeast on Tue 9th Jan 2018 15:31 UTC in reply to "Not just the kernel"
bassbeast Member since:
2007-11-11

Hell you wanna talk about back in the day remember BeOS or OS/2 Warp? It was amazing what those OSes could do with itty bitty amounts of CPU and RAM.

I ran an OS/2 system for the longest time simply because of how much more snappy and responsive it was compared to anything MSFT was putting out, it wasn't until tools came out that allowed you to easily strip all the garbage from Win9X and it became hard to find programs to run on OS/2 that I finally moved over to Windows.

But while it is a fun exercise just to see what Linux will run on allow me to be the first to say I'm damned glad that today we have so much horsepower that many of use don't have to give a crap about whether a program or even OS has some bloat. I remember having to worry about every bit of memory and hard drive space when I was working on video and having to plan out when I could afford to have my system tied up for many hours when doing rendering, its so much nicer now to be able to fire up a game like War Thunder or the free copy of Assassin's Creed 4 that Ubisoft gave out while my system renders video in the background on my AMD octocore or to not care about what amount of RAM the two are using because with 16GB its highly unlikely I'm gonna run out.

So while its fun to to see "how low can you go" I'm damned glad I don't have to even mess with anything less than a quad with 8GB anymore, its just so much nicer now.

Reply Score: 3

Deja vu
by ameasures on Tue 9th Jan 2018 08:46 UTC
ameasures
Member since:
2006-01-09

Have a 486 system here and so tackled this issue a while ago. Serious kudos to them for getting a modernish Linux up and running.

My solution was to get OpenBSD on there and it ran fine, yes slow, but fine (caveat - 4 years ago). The drawback was that the relevant graphics drivers had, I think, been retired. GUI is nice and all but I wasn't going there with that box.

Just now I have Cubieboard-1 which offers me five year old Android, four year old Cubian and an up to date OpenBSD in headless mode. Sort of feels familiar.

One final thought: a number of my usage profiles for older machines have been swallowed by the likes of VMWare and docker. A shame but probably reduces the carbon footprint.

Edited 2018-01-09 08:53 UTC

Reply Score: 2

RE: Deja vu
by r00kie on Tue 9th Jan 2018 15:59 UTC in reply to "Deja vu"
r00kie Member since:
2009-12-10

I have a Cubieboard2 and I'm running a modern linux (as in everything is the latest stable version) in headless mode, given that the changes from Cubieboard1 to Cubieboard2 are not that big you can most probably also run a modern linux in headless mode.

Reply Score: 2

RE[2]: Deja vu
by ameasures on Wed 10th Jan 2018 00:31 UTC in reply to "RE: Deja vu"
ameasures Member since:
2006-01-09

... given that the changes from Cubieboard1 to Cubieboard2 are not that big you can most probably also run a modern linux in headless mode.

Am not sure how big the difference is between the A10 and A20 processors, but big enough that everywhere offers different images for each release. You might be right tho'.

Reply Score: 2

v7 sparc unfortunately removed
by rener on Sat 13th Jan 2018 11:57 UTC
rener
Member since:
2006-02-27

support for vintage v7 SPARC; with software assisted mmu and no integer hardware device (only divide-step) was removed from the linux kernel recently. last kernel just at the crossing of 3.0: https://www.instagram.com/p/BdKbXxlnW_i/
40 MHz, 16 MB RAM

Edited 2018-01-13 11:58 UTC

Reply Score: 1

Thank goodness for the Linux ecosystem.
by slobu on Sat 13th Jan 2018 15:28 UTC
slobu
Member since:
2008-01-07

I was able to install Linux Mint based on Debian on my EduBook. This thing has no PAE or cmov and only 512mb RAM. Still works!

Forced upgrades? Not on my watch!

Reply Score: 1