LiteBox is a sandboxing library OS that drastically cuts down the interface to the host, thereby reducing attack surface. It focuses on easy interop of various "North" shims and "South" platforms. LiteBox is designed for usage in both kernel and non-kernel scenarios.
LiteBox exposes a Rust-y nix/rustix-inspired "North" interface when it is provided a Platform interface at its "South". These interfaces allow for a wide variety of use-cases, easily allowing for connection between any of the North--South pairs.
Example use cases include:
- Running unmodified Linux programs on Windows
- Sandboxing Linux applications on Linux
- Run programs on top of SEV SNP
- Running OP-TEE programs on Linux
- Running on LVBS
This might actually be my favourite use: I always thought WSL2 was a kludge, and WSL1 to be somewhat the fulfilment of the "personality modules" promise of Windows NT.
Yup WSL feels closer to the Services for Unix which has been around since NT 4/5.
It was sad to see WSL2 taking the path of least resistance, that decision has always felt TPM driven ("we got unexpected success with WSL and people are asking for more, deliver xxx by Q4! No I don't care _how_ you do it!")
The amount of techno jargon marketing speak in this readme is impressive. I’m pretty well versed in most things computers, but it took me a long time to figure out what the heck this thing is good for. Leave it to Microsoft to try to rename lots of existing ideas and try to claim they’ve invented something amazing when it’s IMHO not all that useful.
Do you have a writeup of how you did it? Both (regular) tooling (radare2? rizin? IDA? ...) and how the LLM did (or did not) use it?
In the little spare time I have, I've been able to reverse engineer the "compressed" file format (ended up being basically a XOR'ed zlib-compressed TAR-like archive), but not much else. I have not used LLMs to help me.
> I changed read/write_file to put contents in the state and presented in the system prompt, same for the agents.md, now working on evals to show how much better this is, because anecdotally, it kicks ass.
Can you detail this a bit more? Do you put the actual contents of the file in the system prompt? Forever?
That matches what I recall too, back when I ran a very cheap integrated intel (at least that's what I recall) card on my underpowered laptop. I posted a few days ago with screenshots of my 2009 setup with awesome+xcompmgr, and I remember it being very snappy (much more so than my tuned Windows XP install at the time). https://news.ycombinator.com/item?id=46717701
57MiB with a couple of applications open. From memory: urxvt running htop, thunar (XFCE file manager) and the Mirage image viewer (which is Python, not otherwise known for efficiency). Screenshot: https://github.com/aktau/awesome/blob/master/screenshots/200...
- 32-bit to 64-bit means all points are double the size. That would account for something.
- Wayland vs X11. I should compare Sway versus X.org+i3.
- General library and system daemon bloat.
> They were using tori primitives for the chain mail, and curve primitives for the clothing. (I.e., the clothing was actually woven out of curve primitives for the threads.)
That sounds mind-blowing. Is this documented anywhere?
See https://devtalk.blender.org/t/jpeg-xl-as-an-intermediate-for.... TLDR is that one of the really interesting things JPEG-XL adds is the ability to have an arbitrary number of non-color channels. The current solution is generally to use separate grayscale images for each extra thing you want to store, which is inefficient since it loses the ability to compress the correlation between the separate channels. Another example usecase would be capturing images at 10 different wavelengths rather than the typical RGB.
(I agree with other commenters' assessment about the importance of the authors complaints, and recommend others checkout the Go memory regions proposal.)
For those interested, here's an article where Miguel Young implements a Go arena: https://mcyoung.xyz/2025/04/21/go-arenas/. I couldn't find references to Go's own experimental arena API in this article. Which is a shame since it'd be if this knowledgeable author traded them off. IIUC, Miguels version and the Go experimental version do have some important differences even apart from the API. IIRC, the Go experimental version doesn't avoid garbage collection. It's main performance benefit is that the Go runtimes' view on allocated memory is decreased as soon as `arena.Free` is called. This delays triggering the garbage collector (meaning it will run less frequently, saving cycles).
LiteBox is a sandboxing library OS that drastically cuts down the interface to the host, thereby reducing attack surface. It focuses on easy interop of various "North" shims and "South" platforms. LiteBox is designed for usage in both kernel and non-kernel scenarios.
LiteBox exposes a Rust-y nix/rustix-inspired "North" interface when it is provided a Platform interface at its "South". These interfaces allow for a wide variety of use-cases, easily allowing for connection between any of the North--South pairs.
Example use cases include:
reply