Yalo – Lisp OS running on bare metal x86-64 hardware
In this technical retrospective (2014), @agumonkey shares practical architectural lessons learned from running, scaling, or migrating production software under lean constraints.
Core Principles for Independent Builders:
Defaulting to simpler architectures (such as monolithic frameworks, SQLite, or managed VPS) prevents early engineering bankruptcy.
Evaluating true compute and egress costs reveals that high cloud bills can often be slashed by 80%+ through judicious re-platforming.
Code you write at 2 AM as a solo engineer must be easy to debug six months later without complex microservice dependencies.
Community Debate Themes:
HN engineers debated the tradeoffs between cloud convenience and raw server economics, database indexing strategies, and resisting premature architectural complexity.
CATEGORY Frugal Engineering →
HISTORICAL ERA Cloud & Mobile Era (2014–2019)
COMMUNITY SCORE 192 points
TOTAL DISCUSSIONS 39 comments
I wouldn't raise my hopes too much.
Of course he's creating his own LISP dialect, no doubt with the purpose of "fixing" few of the myriad of artificial percieved non-problems of Common Lisp and its ancestry. ( * )
I'll be one happy nerd if this turns out to be anything but yet another crock of ---- layered on top of an idiotic architecture, but given the vanishing fraction of sane people amongst todays "hackers" (I can't make those quotes big enough), I'm very much in doubt. Show of hands, everyone: who actually believes that this thing is being designed from the beginning with the purpose of total inspectability and modifiability?
( * ) I'm not saying that Common Lisp doesn't have problems; for instance, the interactivity and debugging support of todays Common Lisp implementations is pathetic compared to the Genera and friends. I'm saying that the actual problems are so far beyond the casual idiot's horizon that he tends to make up problems he can actually understand (parentheses! archaic naming! standard too big! blah blah blah blah blah!).
This seems like a cool start for a project but it may be a bit premature to share it and call it a "Lisp OS running on x86_64", because at this point it doesn't run any lisp code or run on x86_64.
Basically all it is at this point is a stage 1 bootloader in 16 bit real mode that prints out "REPL>". It does detect the CPU type and verify that it can enter long mode (64 bit mode) but never actually enters long mode.
I find it awkward that there's so much hype on HN and twitter and tons of people starring and forking it but it is rather evident that not many people actually read the code and see what it does. It seems like this project has got a few recent commits, though (after a hiatus of a few years) so there might be some progress happening.
However, what is very cool about this project is the way that it is written, basically Lisp macros that implement a single pass x86_64 assembler.
Let's hope that this project gets the love and the attention it needs to actually grow into a proper Lisp OS.
This is incredibly similar to an assembler I wrote in Scheme, almost a decade ago. I was using Bochs and even unit testing with NASM.
I think people are going to be disappointed, if they can even get this to run in Bochs. About the only "Lisp OS" thing here is the REPL, which looks like it's incomplete anyway. Movitz is ahead of it by a bit, since it at least has, IIRC, a working compiler and possibly a driver or two.
But nothing we have today is anywhere close to what people think of, when they think "Lisp OS". However, I've used Genera, and I'd really caution people about getting this romanticized view of it. There are still many good ideas there, but Linux and OS X today are not the Unix of 1980. We've come a long way.
Excitedly tried it out, but I get this error on both 32-bit and 64-bit ubuntu:
``` $ git clone https://github.com/whily/yalo ↗ $ cd yalo/cc $ ./lnasdf $ sbcl --version SBCL 1.0.58 $ sbcl * (require 'asdf) * (asdf:oos 'asdf:load-op 'cc) * (cc:write-kernel "floppy.img") #: match-instruction: unsupported instruction (JC NO-BGA-ERROR)
``` Also, I'd love to hear more about Ink. I'm not sure where it is in such a tiny codebase.
I'm the original author (not OP), and I'm quite surprised that the project was starred by so many people in github and discussed in HN. The project was originally hosted in Google Code, and I decided to migrate to github last night.
As many of your have already commented: the project is only at very very initial stage, with an assembler written in Common Lisp, and a 16 bit bootloader. Currently I can only describe it as a toy.