This is seriously awesome. I take special care to upvote these kinds of projects, as they embody the hacker spirit: hack something that has never been done before in an awesome way, and to hell with practical value!
What does ELKS have in common with Linux? Will it emulate 32-bit for the user-land? If not, I guess it's not binary compatible. So ELKS is not Linux itself (FAQ says so) and it won't run Linux apps? I don't see how they're related...
All that's left is that pesky 32-bit CPU & MMU requirement. Well the AVR has no MMU and is 8-bit. To conquer this obstacle, I wrote an ARM emulator.
So technically it's Linux running on a 32-bit "macro", just one which happens to be implemented in some seriously inefficient manner.
There are some real ports of Linux for "limited" architectures, like uClinux (supporting few 32-bit micros, including some MMU-less ones) and ELKS (for 16-bit x86 CPUs).
This project is "only" a cool ARM emulator with software DRAM controller, which BTW proves again that Linux doesn't fit onto 8-bit micros.
> which BTW proves again that Linux doesn't fit onto 8-bit micros.
How in the world does it "prove" that, when not only does it "fit", it fits in addition to an emulator? I don't see that it only runs _under_ an emulator proves any such thing.
While this is obviously a "hah, you think it's impossible? I'll show you," type achievement, and running Linux on an 8-bit is never going to be more than a curiosity, it's a neat proof of concept and could trivially be made much faster (through a hybrid approach: a lot of the Linux code could likely be ported quite easily, and a lot of it could probably also be jit'ed relatively easily (especially kernel-land - a special purpose jit whose only purpose is to jit the kernel would be vastly easier than a general purpose jit, not least because you can take a boatload of shortcuts (e.g. manual translation) in cases where a simple/trivial jit doesn't do well.
I think it's a fascinating solution - people have talked about doing ports to limited systems without MMU's etc. before, and it has usually meant severe tradeoffs that means lots of userland won't work (e.g. vfork instead of fork). This is a d'oh moment in that the "solution" if your goal is only to get a port running (rather than for it to be practically usable) has stared us in the face "forever" (there's been virtualization solutions using emulated CPU's since before Linux was around).
This project is "only" a cool ARM emulator with
software DRAM controller, which BTW proves again that
Linux doesn't fit onto 8-bit micros.
But it does, for practical purposes. I'll try to put into context with a practical story -
There's a global apocalypse happening tomorrow.
There's a sealed bunker beneath my author's house that will survive. It contains one of these microcontrollers, a keyboard, specifications for a daisy wheel printer that hooks into the debug port and a big stack of paper, and a row of bicycles connected to a alternator to power it all.
There is a post-it note stuck to the controller that says "pwd; /usr/bin/ls; cd /; /usr/bin/ls; man man; man ls; man ed;".
Decades from now and by chance, Benedictine monks will build a monastery, and the bunker will be within its generous grounds. In time they will discover the bunker, and take turns getting fit while others they learn to use the system. They're a disciplined, careful bunch, particularly around commands like rm.
Out of concern for the reliability of storage media, one of the hackers will set up a RAM disk and migrate the system over to this. The abbot will declare that pedalling is a leisure activity so that they system will never again need to reboot.
Though their diligence, the art of unix hacking will live on.
A thousand years later, an opaque glass bottle will break free of the ocean, and wash up on a beach. Bizarrely, it will contain well-preserved code printouts from an entry in the 2013 7-day roguelike competition. It will be marked up in pen, to highlight the author's flamboyant use of obscure system calls, particularly those that are specific to the linux kernel. A convenient novelty of the game is that (unlike rogue) it is one-dimensional - a player can walk left or right on a line, and a new line prints out each time they move.
A copy of the source will eventually find its way to the monks - still pedaling furiously to keep their RAM disk alive - as they take an interest in anything that refers to linux. They will type in the code, and then throw it at a compiler. It will all work. This is the last computer left on the planet, and the reason that the code can be compiled to run on the computer with no modifications is because - for practical purposes - it's linux that's running on this 8-bit micro.
I'm considering trying to get this to compile on Emscripten. It's so self-contained that I think it will be fairly unproblematic. Emscripten's 64-bit math emulation surely won't be needed.
Does anyone know if a ARM emulator in JavaScript exists already?
Microcontrollers currently supported by uClinux cost >$5.
One interesting option to reduce the cost is to use a new microcontroller , the psoc 4(starting $1, 32 bit) which includes programmable logic, which might enable implementing the dram interface in hardware and to achieve good memory performance.
> There are some real ports of Linux for "limited" architectures, like uClinux (supporting few 32-bit micros, including some MMU-less ones) and ELKS (for 16-bit x86 CPUs).
But is it actually Linux, or something that was based on Linux but is now so divergent as to be its own kind of thing?
"Oh, it's Linux. It doesn't have most of the APIs, including the ones 99+% of the application software depends on, most of the code is gone, what's left has been greatly re-written, and it will never contribute code back into the mainline kernel."
It's the Ship of Theseus: "This is the original ship. Every plank has been replaced at least once, the sails are all new, and all of the rope was replaced last month."
So you're saying you can't compile Linux to an 8-bit CPU, but you can run an emulator of a much larger chip on that CPU and run linux on that? Are you sure?
Second this. And this probably also speaks a lot for Linux - okay, he emulated a supported system, but given the problems that one sometimes experience when trying to run the same application on different machines with slightly different hardware or software installed, I find it quite amazing that Linux actually boots on this device.
He's more on the side of genius, but less on the side of practical. I think he'd do really well if he tried a startup with someone who could help push him in the direction of building things with more practical use.
It takes about 2 hours to boot to bash prompt ("init=/bin/bash" kernel command line). Then 4 more hours to boot up the entire Ubuntu ("exec init" and then login). Starting X takes a lot longer.
I was puzzled at first when I saw the license. Who would be interested in this commercially?
Then I realized the interesting thing isn't to run Linux, but some other more lightweight code that depends on the 32 bit arm architecture, but would run just fine on an 8-but micro, performance-wise.
Awesomely cool project, but I was somewhat dismayed by the choice of GNOME, as GNOME is quite bloated and a smaller window manager, instead of a DE, seems to make more sense while not detracting from usability.
hahaha, this comment is hilarious. The guy got an 8-bit tiny little 55 cent chip (8 bits means an isntruction is between 0-255) to slowly crawl its way through pretending to be a real mdoern CPU by pretending to execute a real modern desktop CPU instruction every few cycles.
He got it to starting up x in a day and you're like, "Cool project bro but I'm dsmayed by the choice of GNOME".
saying it, "detracts from usability." this is just hilarious.
I don't think there's any graphical usability whatsoever, as the only output is a serial line. He only mentioned X and GNOME to emphasize the fact that it can be started.
Given a choice between the fun of 8-bit programming and the stodgy functionalism of a mere OS? hmmm... let me think. (1MHz @ 4 cycles/instruction = 250K instructions.)
[+] [-] jwr|13 years ago|reply
[+] [-] DanBC|13 years ago|reply
I remember when "getting linux working on a laptop" was thought to be tricky.[1]
ELKS was a linux distribution for old small machines. It was supposed to run on an 8086, and use just 512 KB (not MB) for ram. (http://web.archive.org/web/19990117003949/http://www.uk.linu...)
(http://en.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset)
Wow, still sort of live. (http://elks.sourceforge.net/)
[1] Here's a 2003 FAQ which gives some nice details of the problems people faced then. (http://www.faqs.org/docs/Linux-HOWTO/Laptop-HOWTO.html)
[+] [-] TheBoff|13 years ago|reply
[+] [-] iso8859-1|13 years ago|reply
[+] [-] idupree|13 years ago|reply
[+] [-] joelhaasnoot|13 years ago|reply
[1] http://en.wikipedia.org/wiki/Toshiba_T1100
[+] [-] tmzt|13 years ago|reply
It seems not to be in IA.
[+] [-] qb45|13 years ago|reply
So technically it's Linux running on a 32-bit "macro", just one which happens to be implemented in some seriously inefficient manner.
There are some real ports of Linux for "limited" architectures, like uClinux (supporting few 32-bit micros, including some MMU-less ones) and ELKS (for 16-bit x86 CPUs).
This project is "only" a cool ARM emulator with software DRAM controller, which BTW proves again that Linux doesn't fit onto 8-bit micros.
[+] [-] vidarh|13 years ago|reply
How in the world does it "prove" that, when not only does it "fit", it fits in addition to an emulator? I don't see that it only runs _under_ an emulator proves any such thing.
While this is obviously a "hah, you think it's impossible? I'll show you," type achievement, and running Linux on an 8-bit is never going to be more than a curiosity, it's a neat proof of concept and could trivially be made much faster (through a hybrid approach: a lot of the Linux code could likely be ported quite easily, and a lot of it could probably also be jit'ed relatively easily (especially kernel-land - a special purpose jit whose only purpose is to jit the kernel would be vastly easier than a general purpose jit, not least because you can take a boatload of shortcuts (e.g. manual translation) in cases where a simple/trivial jit doesn't do well.
I think it's a fascinating solution - people have talked about doing ports to limited systems without MMU's etc. before, and it has usually meant severe tradeoffs that means lots of userland won't work (e.g. vfork instead of fork). This is a d'oh moment in that the "solution" if your goal is only to get a port running (rather than for it to be practically usable) has stared us in the face "forever" (there's been virtualization solutions using emulated CPU's since before Linux was around).
[+] [-] cturner|13 years ago|reply
There's a global apocalypse happening tomorrow.
There's a sealed bunker beneath my author's house that will survive. It contains one of these microcontrollers, a keyboard, specifications for a daisy wheel printer that hooks into the debug port and a big stack of paper, and a row of bicycles connected to a alternator to power it all.
There is a post-it note stuck to the controller that says "pwd; /usr/bin/ls; cd /; /usr/bin/ls; man man; man ls; man ed;".
Decades from now and by chance, Benedictine monks will build a monastery, and the bunker will be within its generous grounds. In time they will discover the bunker, and take turns getting fit while others they learn to use the system. They're a disciplined, careful bunch, particularly around commands like rm.
Out of concern for the reliability of storage media, one of the hackers will set up a RAM disk and migrate the system over to this. The abbot will declare that pedalling is a leisure activity so that they system will never again need to reboot.
Though their diligence, the art of unix hacking will live on.
A thousand years later, an opaque glass bottle will break free of the ocean, and wash up on a beach. Bizarrely, it will contain well-preserved code printouts from an entry in the 2013 7-day roguelike competition. It will be marked up in pen, to highlight the author's flamboyant use of obscure system calls, particularly those that are specific to the linux kernel. A convenient novelty of the game is that (unlike rogue) it is one-dimensional - a player can walk left or right on a line, and a new line prints out each time they move.
A copy of the source will eventually find its way to the monks - still pedaling furiously to keep their RAM disk alive - as they take an interest in anything that refers to linux. They will type in the code, and then throw it at a compiler. It will all work. This is the last computer left on the planet, and the reason that the code can be compiled to run on the computer with no modifications is because - for practical purposes - it's linux that's running on this 8-bit micro.
[+] [-] iso8859-1|13 years ago|reply
reginaldo (a guy who posted his emulator (jslm32) last time this was on HN) actually uses uClinux on LatticeMico32.
[1]: https://github.com/ubercomp/jslm32
I'm considering trying to get this to compile on Emscripten. It's so self-contained that I think it will be fairly unproblematic. Emscripten's 64-bit math emulation surely won't be needed.
Does anyone know if a ARM emulator in JavaScript exists already?
[+] [-] ippisl|13 years ago|reply
One interesting option to reduce the cost is to use a new microcontroller , the psoc 4(starting $1, 32 bit) which includes programmable logic, which might enable implementing the dram interface in hardware and to achieve good memory performance.
[+] [-] derleth|13 years ago|reply
But is it actually Linux, or something that was based on Linux but is now so divergent as to be its own kind of thing?
"Oh, it's Linux. It doesn't have most of the APIs, including the ones 99+% of the application software depends on, most of the code is gone, what's left has been greatly re-written, and it will never contribute code back into the mainline kernel."
It's the Ship of Theseus: "This is the original ship. Every plank has been replaced at least once, the sails are all new, and all of the rope was replaced last month."
[+] [-] NewAccnt3|13 years ago|reply
[+] [-] NewAccnt|13 years ago|reply
[deleted]
[+] [-] sigkill|13 years ago|reply
[+] [-] danbruc|13 years ago|reply
[+] [-] jmtame|13 years ago|reply
[+] [-] renanbirck|13 years ago|reply
[+] [-] jared314|13 years ago|reply
https://news.ycombinator.com/item?id=3767410
[+] [-] iso8859-1|13 years ago|reply
[1]: https://github.com/ysangkok/linux-on-an-8-bit-microcontrolle...
[+] [-] icebraining|13 years ago|reply
[+] [-] deweerdt|13 years ago|reply
[+] [-] iso8859-1|13 years ago|reply
[+] [-] glabifrons|13 years ago|reply
[+] [-] JulianMorrison|13 years ago|reply
[1] http://www.rifters.com/real/2009/01/iterating-towards-bethle...
[+] [-] geon|13 years ago|reply
Then I realized the interesting thing isn't to run Linux, but some other more lightweight code that depends on the 32 bit arm architecture, but would run just fine on an 8-but micro, performance-wise.
Any idea what that use case might be?
[+] [-] afreak|13 years ago|reply
[+] [-] signalsignal|13 years ago|reply
[+] [-] qb45|13 years ago|reply
http://support.microsoft.com/kb/138349
[+] [-] glabifrons|13 years ago|reply
[+] [-] wazoox|13 years ago|reply
[+] [-] sigkill|13 years ago|reply
[+] [-] aquadrop|13 years ago|reply
[+] [-] ams6110|13 years ago|reply
[+] [-] me2i81|13 years ago|reply
[+] [-] D9u|13 years ago|reply
[+] [-] andthen22|13 years ago|reply
He got it to starting up x in a day and you're like, "Cool project bro but I'm dsmayed by the choice of GNOME".
saying it, "detracts from usability." this is just hilarious.
[+] [-] blaabjerg|13 years ago|reply
[+] [-] iso8859-1|13 years ago|reply
[+] [-] dmitrygr|13 years ago|reply
- dmitrygr
[+] [-] teeja|13 years ago|reply
[+] [-] iso8859-1|13 years ago|reply