3 ms·

Couple of things spring to mind: - didn't check if nixos uses it, but coreutil has a single binary mode (like busybox, a single binary is built and symlinks or

Couple of things spring to mind: - didn't check if nixos uses it, but coreutil has a single binary mode (like busybox, a single binary is built and symlinks or hardlinks are used to provide all the commands); that might save some space - instead of trying to strip down the system, maybe go the other way around: only include the command you need with its closure? closure computation is done in a few places (apparmor profile or systemd.confinement come to mind) and it should be possible to just copy whatever your server binary needs, your kernel (since microVM and not container), and run the binary directly as init (maybe with a simple wrapper that hardcodes network or whatsnot) good luck!

pxc 2y ago
> - didn't check if nixos uses it, but coreutil has a single binary mode (like busybox, a single binary is built and symlinks or hardlinks are used to provide all the commands); that might save some space It does. If you have coreutils from Nixpkgs installed you can check this with basename "$(realpath "$(which ls)")" If you see 'ls', you're looking at separate binaries. If you see 'coreutils', it's a symlink to a singular 'coreutils' binary.
yjftsjthsd-h 2y ago
> go the other way around I'm not sure about just the one closure since the result needs to boot, but more generally that looks reasonable if your use case fits. There's a couple efforts, IIRC, mostly centered around router firmware where "real" nixos doesn't fit, ex. https://gti.telent.net/dan/liminix https://gti.telent.net/dan/liminix
hamandcheese 2y ago
2 is very interesting to me. I'd love to see an example of a "scratch" vm build, in a similar spirit to scratch docker builds. Assume I have all my software and kernel built, what is the minimal filesystem that will boot? How much easier can it get when I am only targeting a VM?
- rkeene2 2y ago
  This might be something you're interested in: https://appfs.rkeene.org/web/dir?ci=trunk&name=build/qemu https://appfs.rkeene.org/web/dir?ci=trunk&name=build/qemu It's for running AppFS inside a VM on QEMU. It uses a statically linked Tcl (which AppFS is written in) to bring the system up.

pxc 2y ago

> - didn't check if nixos uses it, but coreutil has a single binary mode (like busybox, a single binary is built and symlinks or hardlinks are used to provide all the commands); that might save some space It does. If you have coreutils from Nixpkgs installed you can check this with basename "$(realpath "$(which ls)")" If you see 'ls', you're looking at separate binaries. If you see 'coreutils', it's a symlink to a singular 'coreutils' binary.

yjftsjthsd-h 2y ago

> go the other way around I'm not sure about just the one closure since the result needs to boot, but more generally that looks reasonable if your use case fits. There's a couple efforts, IIRC, mostly centered around router firmware where "real" nixos doesn't fit, ex. https://gti.telent.net/dan/liminix https://gti.telent.net/dan/liminix

hamandcheese 2y ago

2 is very interesting to me. I'd love to see an example of a "scratch" vm build, in a similar spirit to scratch docker builds. Assume I have all my software and kernel built, what is the minimal filesystem that will boot? How much easier can it get when I am only targeting a VM?

rkeene2 2y ago
This might be something you're interested in: https://appfs.rkeene.org/web/dir?ci=trunk&name=build/qemu https://appfs.rkeene.org/web/dir?ci=trunk&name=build/qemu It's for running AppFS inside a VM on QEMU. It uses a statically linked Tcl (which AppFS is written in) to bring the system up.