What does HackerNews think of elks?

It might run ELKS https://github.com/jbruchon/elks

Not possible with real Linux, the CPU on the Furby is too limited while the smallest Linux out there still requires some more resources. Some small size Linux-like OSes do exist though: one commenter suggested Lunix (which I didn't know, thanks for the link), and a slightly bigger one is ELKS which runs on old MMU-less x86 CPUs. I managed to run it on a 8088 industrial PC ages ago.

https://github.com/jbruchon/elks

I should have a Furby buried somewhere; now that I think of it, it may be the right platform to stick a bigger brain into, make it wireless so that it could be connected to the home IoT network then signal events or alerts.

I successfully run ELKS on a Flytech Carry 1 industrial computer.

https://github.com/jbruchon/elks

http://elks.sourceforge.net/ (old Sourceforge page)

https://vinc.prv.pl/text/299e3ed5-320.html

I've built an 8088 replica (Sergey's Xi 8088) and I'm having great fun with ELKS.

https://github.com/jbruchon/elks

ELKS is a Linux subset designed for the 8088, along with a complete toolchain (gcc-ia16). It's also actively maintained and comes with QEMU images and a dockerfile for fast, reproducible builds.

Best to test it on live hardware, it's more rewarding and more fun a toy Unix than xv6.

edit: typos

32 bit aren't a problem, RAM however could be. I've run Debian on 32 bit Atom netbooks with 1 Gig RAM without problems. Using light desktop environments such as XFCE or smaller ones would allow also 512MB RAM or even less. Years ago I successfully run Debian + LXDE desktop on one of those toy Win-CE Chinese laptops with just 128MB RAM. CPU was a WM8505 clocked at a whopping 300MHz. And then there's ELKS Linux which would work on 8086 CPUs too which I successfully run on a industrial PC many moons ago. https://github.com/jbruchon/elks

Extremely small systems aside, it can run fine on decently equipped laptops or netbooks. Surfing the web with a full featured browser such as Firefox or using heavy apps such as LibreOffice without having the system swap too much would likely require no less than 2 Gigs or more, but if you do network maintenance using command line tools, even the smallest netbook with half a Gig RAM becomes an useful tool to keep in the bag along with bigger laptops.

More to the point, the real world doesn't run entirely on Real Computers.

It happens again and again:

There's a plateau of Real Computers, where Real People do Real Work, because they wouldn't deign to deal with the oddities and lack of performance peasants put up with on their Bitty Boxes.

Then something nasty happens, and those Bitty Boxes become more capable without becoming correspondingly more expensive. All of a sudden, the companies selling Real Computers no longer have a value proposition: Their stuff may not be hugely more capable, but at least it's massively more expensive!

Eventually, not even the Real People can continue to ignore the fact the Toys are smoking them in every benchmarkable metric aside from cool factor.

It happened to DEC when minicomputers fell to PCs, and it happened to Sun and SGI when the "workstation" category got folded into the "somewhat-more-expensive-than-usual PC" category.

Linux originally ignored the extreme low-end PCs, but in 1991, it was pretty clear than 16-bit x86 CPUs were more trouble than they were worth in the Unix-like world and it wasn't a good move to mutilate the kernel to fit on a kind of system which was rapidly becoming obsolete. However, Linux is not ignoring the current Bitty Boxes, the SBCs which can run the kernel with no compromises once you navigate the weirdness of ARM-based hardware.

(Yes, there is a project to run Linux on 16-bit x86 chips and other MMU-less CPUs. It's called ELKS and it was never very active.)

https://github.com/jbruchon/elks

Great insights!

Your comment also made me wonder what actually happened to ELKS. Last I checked (many years ago, apparently), it seemed abandoned. But development has started again in 2014, and still seems ongoing: https://github.com/jbruchon/elks

Should play with it some time, maybe in an 8086 emulator.

EDIT: By the way:

I forgot to mention this in my other comment:

> The core of it is a smart linker/loader which allows code and data segments to be loaded, patched together on the fly, and dropped on demand. All data is relocatable, allowing it to be rearranged or swapped out.

Early Windows on early XTs did that, too! With all sorts of crazy hacks to make it happen [1]. I don't know how it compared to what GEOS did, though.

[1] https://blogs.msdn.microsoft.com/oldnewthing/20110316-00/?p=... and many other articles on that site can send you down a deep rabbit hole.

A shrunk version of Linux can run on 8088 CPUs too. https://github.com/jbruchon/elks But the problem here isn't to put this or that OS in place of Minix but rather to get rid of that completely for good. Different licensing also wouldn't help at all: behind those people are the ones who actually write the laws; it would require 10 minutes of their time to make an exception for terrorism or child porn motivated surveillance.

Well, the ELKS[1][2] project has been working on a 16bit port on and off since the late 90s. At one point Alan Cox[3] was an active contributor.

[1] http://elks.sourceforge.net/

[2] https://github.com/jbruchon/elks

[3] https://en.wikipedia.org/wiki/Alan_Cox

8086 Linux still exists; people are working on it:

https://github.com/jbruchon/elks

But it's still pretty unstable. If you have a spare 8086 and want a Unixoid, go look up Minix 2 (not 3). It's not very comfortable on a 8086 with 640kB, but it works. Proper filesystem, processes, Bourne shell, the lot. It even has a self-hosted C compiler. You can get real work done on it (slowly).

https://www.minix-vmd.org/pub/minix/2.0.2/

Later versions really want a 286, but that gives you proper memory protection too.

Of course, if you want any processes bigger than 64kB code / 64kB data, you need to upgrade to Minix 386.