SmolBSD – build your own minimal BSD system

birdculture 258 points smolbsd.org

−

jmmv

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

−

signa11

there is also this: https://mirage.io which does something similar.

−

indigodaddy

Mirage looks _vastly_ more complicated to use/implement (than smolbsd).

−

signa11

it provides an environment to create bespoke applications running exclusively on h/w, so not surprising at all.

−

pjmlp

Both are part of Unikernels as another approach on how to design OSes.

http://unikernel.org/projects/

−

anentropic

I am also curious how SmolBSD micro VMs compare to unikernels as the benefits/use cases sound similar

What are the differences?

−

myaccountonhn

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.

−

alexellisuk

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

−

myaccountonhn

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.

−

dazzawazza

I'm really enjoying some of the innovation in the BSD space at the moment.

−

hoppp

BSD space has always been ahead in some ways. They can move more freely forward.

−

SoftTalker

(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.

−

jmmv

BSDs do not break backwards compatibility (at least from what I know from FreeBSD and NetBSD). You _can_ disable backwards compatibility via kernel-level options and by not installing certain distribution sets -- but the default is to remain backwards compatible.

What being a kernel+userland helps with is in implementing features end-to-end: if you have to change how a certain aspect of the network configuration happens, you can do the kernel changes and the userlevel changes in unison. Which explains why you have a unique set of network tools, great documentation, a simple build system that can upgrade the machine...

−

toast0

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.

−

metadat

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.

−

iberator

ps. NetBSD supports like 40 different cpu architectures from the same source code:)

−

hnarn

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.

−

kryptiskt

For a small FreeBSD there is NanoBSD: https://docs.freebsd.org/en/articles/nanobsd

−

SpecialistK

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!

−

erredois

I was thinking about the smallest ssh server possible, and this looks interesting. I will try it later.

−

INTPenis

I was thinking an alternative to Talos or Flatcar Linux where you can have a thin hypervisor or container host.

−

kirito1337

This is soooo good for people who like BSD or who just want to build an OS.

−

shoobiedoo

Very cool. Love the mascot icon

−

hommelix

There was a presentation at Fosdem 2025 about this work: https://archive.fosdem.org/2025/schedule/event/fosdem-2025-5...

−

ggm

Does it do a minimisation of system calls and libc endpoints?