I don't agree with "readable," though. For a simple set of key-values, yes. Once you get into complicated structures, other file formats express the semantics much better.
I think there are many facets to readability. For example, YAML is frequently held up as much easier for humans to read than JSON, but even after many years of reading and writing YAML in various domains, no other format causes me anywhere near as much trouble.
With JSON, I can format the string as I feel makes sense for that specific data structure, while YAML forces me to into specific indentation patterns, and it still causes me to question every time whether the dashes in arrays should be indented or not. And since people frequently template YAML, the strict indentation has caused a bunch of issues for no good reason, including production outages (sure, shouldn't happen with good practices, but there are so many places without good practices!).
Because JSON syntax generally has only one way to represent each data type and almost every data type uses explicit start and end signifiers (except floats and bools, both of which are short and clearly stand out), it's easy to know what the context of every character is both while reading linearly, and when jumping to specific points. Meanwhile YAML has multiple ways to express almost anything, and frequently the only way to tell the current context is to read ahead before jumping back. This is especially terrible for strings due to optional delineation, because almost every bare text could be a keyword (as demonstrated by the Norway problem).
I know this is not most people's experience, but that's because readability is subjective.
If you have a complex configuration you are doing it wrong... Spend some time thinking about you really want and turn it into a simple key-value setup. JSON should feel like it is overpowered and bloated for your needs. (I'd still use JSON because you can find a parser and editor that can handle it, but it should feel overpowered for your needs)
the connection I'm making is that both sit on the same interface: the CUDA driver api (module load, launch, memcpy).
the paper is about compiling kernels using safe rust instead of CUDA C++, what I did is reimplement the other side of it using rust for the calls from inside a VM get forwarded over vsock to the host driver via api-remoting.
I've put some effort to integrate it to my agentic workflow. The problem, however, with docker in smolvm: it work-ish (there is example), but quite hacky.
Another problem which I wasnt able to solve - persistent image without Dockerfile. CloudInit will be ideal.
Documention at this moment in an early stage.
Overall, its a great project but for me was simpler just use Virtual Machine Manager (libvirt GUI).
I wish all luck to the maintainers, but probably DX-wise I will prefer to have more granular or predictable controls (eg micro cloud from Canonical).
Yep - similar in some ways but headed towards different directions.
I am building a virtual machine to simplify/replace container infra. Ex. we run containers inside of linux VM's even in the `cloud`, resulting in managing both the vm, and the containers.
But smol machines is a lightweight, portable VM that you can package into a single portable .smolmachine file to be rehydrated on any platform, kind of like how containers are used for today.
Sandboxing happens to be a feature of virtual machines, so we are alike in being used for sandboxing.
I have a solution based on Nix that can be used to generate reproducible container images: https://github.com/nothingnesses/agent-images . It lets you customise which agents, harnesses, or any other packages you want included in the VM and it uses `agent-box` for sandboxing.
It's a batteries included alternative to firecracker with a couple of new ideas tossed into the mix i.e. portable like a container (bake into a single file and rehydrate the vm anywhere), dynamic resource allocation, etc.
I'm using a container. The risk isn't exactly "agent leverages 0-day against you to steal all your data" but more "agent mistakenly though $HOME was theirs and deleted it" so as long as you "copy data in > copy data out" without bind-mounting or automatically sync files, container works just fine for "isolating" them.
I've tried both incus and firecracker. Both seem to work well after initial script setup. I've got the impression that firecracker should be a fairly safe option for such use cases.
Well for starters, all the single binaries I made of various distros a month ago, simply don't work anymore for no obvious reason. Trying to execute the process silently exits after about 10 seconds with a 0 exit code and no output, shell or anything at all, and no errors. I have absolutely no idea what to do now.
I don't think that's necessarily lazy, it's just efficient
reply