This is an awesome guide and I appreciate it including ZFS.
One thing I'm curious about is the deletion of this file:
var/db/man.db
I don't have first-hand experience with NetBSD but their online documentation seems pretty great. Does that also translate to the manpages? How could man.db be preserved for a read-only system?
I'm toying with the idea of using NetBSD as a server for some fundamental network services. My goal is a scenario where I get Bus Factor'd and whoever takes over says:
The previous guy left, but we should be able to run with this for now. At first we were worried, but it turned out to be just a self-contained Unix system. The thing hasn't been rebooted in 20 years, but the documentation's complete enough for ChatGPZ to understand it. Keep in mind this doesn't support Nuralink, so we'll have to dig out the old keyboard. Don't forget the USB-D adaptor.
* In an alternative future, NetBSD will be ported to Nuralink.
man pages will still work, the man command will be a bit slower.
The reason is that that file is quite big, so if you're using a small embedded device you could use most of your ram just to store that file.
Good article imho. Read-only with "ramdisk" (volatile memory
filesystems) is a much overlooked defence. I am amazed at the number
of IoT devices I've picked up in second hand stores that are loaded
with state, secrets and PII. I got a GPS device with a large company's
entire delivery address book, and a VoIP phone containing another
company's entire internal voice network with names, office numbers,
and personnel notes.
Put this stuff into a capacitor backed volatile disk with the main OS
running from non-volatile. Set the current drain so that it stays for
at most 7-14 days after power is removed.
I expect most IoT devices run from read-only boot devices. From a device management/performance/eMMC wear perspective, it's really the only way to go. That said, many devices will store state in a separate filesystem, which is a completely different issue. :/
The SDF Public Access Unix System [1] might be the primary use case by the sheer number of users on a NetBSD cluster. :-)
https://sdf.org/?status shows how many active users there currently are.
I have counted user home directories with the fish shell as follows:
dbohdan@ryo ~> count /arpa/*/*/* /udd/*/*
27718
According to `stat -f %m%t%N`, 7519 users have had their home directory modified in 2024.
Outside of SDF, BSD and retrocomputing enthusiasts use NetBSD on their personal systems and servers.
The portability and architecture attract some C and low-level hackers.
You can get an idea for how individual users run NetBSD, especially on modern hardware, by browsing https://www.unitedbsd.com/.
UnitedBSD is a forum that acts as a hub for NetBSD users.
Look into rump kernels; NetBSD is an interesting vehicle for research into virtualisation, micro VMs, also device drivers (the framework is said to be very elegant). I was also surprised to find out how simple it is to cross-compile the kernel from a different OS.
You can also look into pkgsrc; NetBSD is its parent project and pkgsrc remains very portable across many "alien" operating systems, from QNX to macOS.
NetBSD was also forked into, and retains many similarities with OpenBSD (the latter is pretty decent for both server & workstation; it is also my favourite OS of all time, even if I don't get to daily drive it). I'd like to give NetBSD a proper try in this area to get my own opinion.
I run a mail server on NetBSD. It’s refreshing to see how little is running on a NetBSD after booting it for the first time. I’ve also been tinkering with NetBSD on Raspberry Pi Zero devices; the built-in support for various add-ons over GPIO (eg, owtemp sensors) is surprisingly good.
Yes, mid weight embedded (bigger than RTOS, smaller than big embedded like commercial storage appliances) is probably its remaining commercial niche and it doesn't have the current marquee usages that FreeBSD has in various products and infrastructures but I think one of the longest running is at IIJ.
The 10.0 release is a massive improvement on modern hardware.
It's worth a look, for learning purposes if nothing more, as it is pretty clean and accommodating of research like the linked article.
One thing I'm curious about is the deletion of this file:
I don't have first-hand experience with NetBSD but their online documentation seems pretty great. Does that also translate to the manpages? How could man.db be preserved for a read-only system?I'm toying with the idea of using NetBSD as a server for some fundamental network services. My goal is a scenario where I get Bus Factor'd and whoever takes over says:
* In an alternative future, NetBSD will be ported to Nuralink.reply