If you like this, I'd also suggest reading on "Rumpkernels", which are also based on NetBSD. The core idea is (simplified): let's implement the kernel API in userspace so that we can take kernel-level components and run them as part of an application.
Rumpkernels then allow, for example, taking all file system drivers in the kernel and running them in userspace without having to rewrite all of the file system tricky logic. Think of "mtools" if you ever used them, but by reusing existing FAT code. Or making it trivial to create disk images from userspace without having to have special kernel primitives nor root access.
And also, they allow taking a userspace application and packaging it with the minimum set of drivers required to run "bare metal". Which is what the SSH example in the smol page brought to mind. See https://github.com/rumpkernel/wiki/wiki/Repo%3A-rumprun
This looks like a lot of fun. I've been trying to help folks understand how to make use of Firecracker - what it is, when to use it and how to tie its various low-level parts together. Unlike Docker - microVMs tend to need a lot more hands-on knowledge up front.
I tried out smolBSD - the build and boot speed were impressive - as was the hint at a patch that boot time will be reduced from 100ms to 10ms. That's neat - in my experience adding systemd to a modern Linux Kernel pushes Firecracker up to 1-2s.
This smolBSD idea reminds me of unikernels and also of LinuxKit.
The documentation for smolBSD is a great start and could be so much better - for instance - the SSH example shows no way to configure an authorized SSH key or how to log in. The port-map to the host for the open port is also not mentioned.
I'm sure the author knows how to do these things - but even reading around in the repo, it wasn't clear. So hoping he'll improve on this if he's listening.
If anyone's interested in the Linux equivalent of this - check out my blog post on building a Linux microVM from a container [1] and video talk on Firecracker/Linux with Richard Case that led much of the work on Weave Ignite/Flintlock [2]
(All?) the BSDs are a kernel and userland as a single release. They don't have to worry about not breaking some program that someone might have compiled 5 years ago.
They still try not to break things, because you might be running a new kernel with old userland (this is part of the typical upgrade process), or you may have 3rd party programs that were compiled some time ago. I'm only familiar with FreeBSD; statically linked programs are usually good because old syscalls are typically maintained for a long time, dynamically linked programs will tend to be ok if you install the compat libraries.
There's been errors and exceptions of course.
I think the real benefit is they don't have to worry about people trying to run new userland with old kernels; that's explicitly not supported and stuff in base usually doesn't worry too much about it. So if netstat needs a new kernel interface to be faster, the netstat binary in the new release may not work with old kernels, c'est la vie.
Wow, this looks like it will be a lot of fun to play with. As dazzawazza stated, very nice innovation going on. BSD deserves so much more love and attention!
I have no idea about the technical details but I suspect the comparison you’re making isn't that relevant. As I understand it this is just a project that happens to be based on NetBSD, and given enough work you could probably do the same for FreeBSD.
If you like this, I'd also suggest reading on "Rumpkernels", which are also based on NetBSD. The core idea is (simplified): let's implement the kernel API in userspace so that we can take kernel-level components and run them as part of an application.
Rumpkernels then allow, for example, taking all file system drivers in the kernel and running them in userspace without having to rewrite all of the file system tricky logic. Think of "mtools" if you ever used them, but by reusing existing FAT code. Or making it trivial to create disk images from userspace without having to have special kernel primitives nor root access.
And also, they allow taking a userspace application and packaging it with the minimum set of drivers required to run "bare metal". Which is what the SSH example in the smol page brought to mind. See https://github.com/rumpkernel/wiki/wiki/Repo%3A-rumprun
there is also this: https://mirage.io which does something similar.
This looks like a lot of fun. I've been trying to help folks understand how to make use of Firecracker - what it is, when to use it and how to tie its various low-level parts together. Unlike Docker - microVMs tend to need a lot more hands-on knowledge up front.
I tried out smolBSD - the build and boot speed were impressive - as was the hint at a patch that boot time will be reduced from 100ms to 10ms. That's neat - in my experience adding systemd to a modern Linux Kernel pushes Firecracker up to 1-2s.
This smolBSD idea reminds me of unikernels and also of LinuxKit.
The documentation for smolBSD is a great start and could be so much better - for instance - the SSH example shows no way to configure an authorized SSH key or how to log in. The port-map to the host for the open port is also not mentioned.
I'm sure the author knows how to do these things - but even reading around in the repo, it wasn't clear. So hoping he'll improve on this if he's listening.
If anyone's interested in the Linux equivalent of this - check out my blog post on building a Linux microVM from a container [1] and video talk on Firecracker/Linux with Richard Case that led much of the work on Weave Ignite/Flintlock [2]
[1] https://actuated.com/blog/firecracker-container-lab [2] https://www.youtube.com/watch?v=CYCsa5e2vqg
I'm really enjoying some of the innovation in the BSD space at the moment.
BSD space has always been ahead in some ways. They can move more freely forward.
(All?) the BSDs are a kernel and userland as a single release. They don't have to worry about not breaking some program that someone might have compiled 5 years ago.
They still try not to break things, because you might be running a new kernel with old userland (this is part of the typical upgrade process), or you may have 3rd party programs that were compiled some time ago. I'm only familiar with FreeBSD; statically linked programs are usually good because old syscalls are typically maintained for a long time, dynamically linked programs will tend to be ok if you install the compat libraries.
There's been errors and exceptions of course.
I think the real benefit is they don't have to worry about people trying to run new userland with old kernels; that's explicitly not supported and stuff in base usually doesn't worry too much about it. So if netstat needs a new kernel interface to be faster, the netstat binary in the new release may not work with old kernels, c'est la vie.
There was a presentation at Fosdem 2025 about this work: https://archive.fosdem.org/2025/schedule/event/fosdem-2025-5...
Wow, this looks like it will be a lot of fun to play with. As dazzawazza stated, very nice innovation going on. BSD deserves so much more love and attention!
I was thinking about the smallest ssh server possible, and this looks interesting. I will try it later.
I was thinking an alternative to Talos or Flatcar Linux where you can have a thin hypervisor or container host.
Isn't FreeBSD already pretty small? I wonder what the LoC difference is between Smol, NetBSD and FreeBSD.
Edit: NetBSD is 7.3m LoC, FreeBSD is 9m.
For a small FreeBSD there is NanoBSD: https://docs.freebsd.org/en/articles/nanobsd
I have no idea about the technical details but I suspect the comparison you’re making isn't that relevant. As I understand it this is just a project that happens to be based on NetBSD, and given enough work you could probably do the same for FreeBSD.
ps. NetBSD supports like 40 different cpu architectures from the same source code:)
Very cool. Love the mascot icon
Does it do a minimisation of system calls and libc endpoints?