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
I am also curious how SmolBSD micro VMs compare to unikernels as the benefits/use cases sound similar
What are the differences?
Compared to say MirageOS, you have access to a "full" unix system. So anything that is available on NetBSD is also available on smolBSD. It's also very easy to use, I tried it and managed to set up a small portable development environment in 5 minutes. You can use SmolBSD to build a full-blown OS should you want to, or just use it to build and distribute an app like you would with docker. It can also be used if you have a serverless-like workload where you need to spin up VMs extremely fast.
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
> 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.
For those who want to check it out now: there is documentation but for the nitrosshd documentation. The sshd service works the same, minus nitro of course.
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.
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.
Very cool. Love the mascot icon
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.
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:)
Does it do a minimisation of system calls and libc endpoints?
This is soooo good for people who like BSD or who just want to build an OS.