Comment by helpfulContrib | Hacker News Reader

Comment by helpfulContrib | Hacker News Reader

Parent Full thread

This is so beautiful I could almost weep.

With this, we can proceed - easily! - to attain something I have long wanted: to replace all Linux userspace with Lua-only tooling. Yes, Lua all the things in userspace.

I know, "why would I do that?", well, because there is a thing I've wanted for 40 years of computing, and that is a very, very powerful computer that only requires me to use one (oh, okay, two or three..) languages.

I grew up in computers that booted directly to a single language (BASIC), and would let you do everything you need in that and only that. Imagine replacing all userspace tooling with a lua implementation. Yes, insane! But imagine the development flow once you get some good stuff ported/ffi'ed! Having the kernel interfaces available now, is just .. candy.

I would love to have this for a Linux distro, even experimental, even just as a toy, to boot directly into a LOAD81[1] interface that has a whole lotta new Lunatik in it .. I could imagine pushing LOAD81 very hard into a new OS paradigm with this. Wow!

[1] = antirez' LOAD81, which I have long thought of as a fun way to build a new userspace front-end: https://github.com/antirez/LOAD81.git

One of the main inspirations for Lunatik is the MS Singularity OS [1], which gets rid of kernel/user space division and implements application/process protection by software using programing language resources. The other one is the MIT Exokernel [2], which provides a tiny kernel with almost no abstractions responsible only for safely multiplexing the hardware. Now, imagine a tiny kernel written in C, exposing Lua APIs, responsible mainly for multiplexing HW; and user processes implemented as separate Lua states running on the same address space, protected by language constructs.

[1] https://pdos.csail.mit.edu/6.828/2008/readings/hunt07singula... [2] https://www.classes.cs.uchicago.edu/archive/2019/winter/3310...

https://imgflip.com/i/8njfrr

I've just glanced at LOAD81 now.. pretty good job! thanks for sharing.. I noted your keyboard event handling (using SDL).. we have something very related to this in Lunatik (at the kernel level, of course) [1]. We've a kinda fun script that uses keyboard event handling to implement a "key locker" using Konami code [2].

[1] https://github.com/luainkernel/lunatik?tab=readme-ov-file#no... [2] https://github.com/luainkernel/lunatik?tab=readme-ov-file#ke...

I didn't write LOAD81 - antirez, of redis fame, did! I'm just a huge fan...

But thanks for the further insight into Lunatik - I'm definitely going to be putting it through its paces soon.

The Arcan project[1] has pushed for this for a loooong time and doing some really interesting cutting edge things with it.

Depending on which set of Lua scripts it runs it fills a different role. The first set becomes the display server and window manager. It can then run itself recursively to provide graphical 'apps' (but also X11 ones, Wayland ones, ...).

I run the 'regular' desktop (stacking, tiling, ...) 'durden' right now, but I hope to switch to the more crazy dataflow/zui one (pipeworld[2]) or the VR one (safespaces[3]).

Then it has an additional 'curses like' one for TUIs and CLIs, 'arcan-tui' with a default shell Lash#Cat9[4]. Looking at their recent posts there also seem to be a network story including server-side processing, but I haven't had the time to play with out more than following the examples in the blog so can't say more about that.

EltaninOS[5] is trying to build a distribution around it.

Everything scripted in Lua.

[1] = https://arcan-fe.com [2] = https://arcan-fe.com/2021/04/12/introducing-pipeworld/ [3] = https://arcan-fe.com/2018/03/29/safespaces-an-open-source-vr... [4] = https://arcan-fe.com/2022/10/15/whipping-up-a-new-shell-lash... [5] = https://eltaninos.org/

And while we're at it, let's run the lua interpreter in ring 0 and really get the party going.

Why lua though?

Please refer to Section 3 from [1], this was extensively discussed there.

[1] https://www.netbsd.org/~lneto/dls14.pdf

However, giving you a short answer, we use Lua mainly because it's easy both to extend and to embed. It's implemented as an almost "freestanding" C library. Moreover, it has a considerable small footprint (~250 KB) in comparison to other scripting languages (e.g., Python has a few MB). Moreover, Lua has automatic memory management, fully isolated execution states, protected calls, among other features.

Sounds like he needs to be introduced to Forth.

Lua has much nicer syntax and much higher abstractions than forth, and is similar tiny

Maybe. Debatable. But the point was more that “replace all userspace [and kernelspace] with X” is the raison d'être of many Forths. So many classic Forth systems boot into a Forth environment, extended in Forth by the programmer-user. If that's what he's looking for, there's 55 years of Forth history to delve into.

Reply on news.ycombinator.com