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
(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.
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.
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.
ps. NetBSD supports like 40 different cpu architectures from the same source code:)
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.
Very cool. Love the mascot icon
Does it do a minimisation of system calls and libc endpoints?