Learn NetBSD - Core Concepts & Main Architecture

#Introduction

In episode 1 we traced NetBSD's history — from 386BSD in 1993 to the 11.0 release in 2026 — and understood why portability is the soul of this project. Now it's time to get under the hood: in this episode we'll dissect NetBSD's core concepts and main architecture — how the system is organized, what its components are, and how those components relate to one another.

Why is understanding the architecture important? Because almost everything you'll do in the following episodes — installation, kernel builds, package management, networking, even embedded — is manipulation of this architecture. If you understand that the base system and pkgsrc are two separate worlds, you won't be confused about why updating the base system and updating packages are two different things. Let's dig in.

#Base System vs pkgsrc

The most fundamental division in NetBSD is between two strictly separated worlds:

1. Base system — the kernel, userland, basic compiler, and tools that make up the operating system itself. It's all built from the /usr/src source tree and controlled directly by the NetBSD project.
2. pkgsrc — the third-party package ecosystem (web servers, databases, programming languages, and thousands of other software). Installed in /usr/pkg, it never mixes with the base system.

You must always remember this division. When you update NetBSD with build.sh distribution, that updates the base system. When you run pkg_add -u, that updates pkgsrc packages. The two coexist side by side without overwriting each other.

#Key Directory Structure

ls -l /usr/pkg/bin
ls -l /usr/src/sys/arch

amd64  arm  arm64  evbarm  evbmips  m68k  mips  powerpc  riscv  sparc64  ...

The list of directories in /usr/src/sys/arch is proof of NetBSD's portability: every folder is an architecture supported by the kernel, and all of them are built from the same source tree.

#-current vs Stable vs Release

NetBSD has three development tracks you need to clearly distinguish:

For production, use the stable branch such as netbsd-11. You can see which track you're running with uname -a or sysctl kern.version:

uname -a
sysctl kern.version

NetBSD hostname 11.0 NetBSD 11.0 (GENERIC) #0: Thu Jul 30 12:00:00 UTC 2026
NetBSD 11.0 (GENERIC) #0: Thu Jul 30 12:00:00 UTC 2026
        root@build02:/build/src/sys/arch/amd64/compile/GENERIC

#Main Components of NetBSD Architecture

#Kernel: Modular and Clean

The NetBSD kernel is designed to be modular. Drivers and subsystems can be loaded and unloaded dynamically via modload, modunload, and modstat. The core kernel can be slimmed down as needed — this is one reason NetBSD is so well suited to embedded.

modstat

NAME            CLASS      SOURCE            REFS   SIZE
acpi            misc       -                 0      101
pf              network    -                 0      60
npf             network    -                 0      82

Notice the npf and pf lines in the example above — even firewalls can be modules. In episode 9 we'll dissect kernel modules in depth.

#rump kernels: Kernel in Userspace

One of NetBSD's unique features is rump kernels — the ability to run kernel drivers and subsystems in userspace as ordinary processes. This makes it possible to test filesystems, the network stack, and drivers without rebooting or needing a separate machine. In episode 17 we'll use it directly to boot a filesystem in userspace.

#Userland: Clean Standard Tools

The NetBSD base system contains a complete userland: shell, editor, compiler, network tools, and administration utilities. Its hallmark is cleanliness and consistency — all tools follow the same conventions, and man documentation is complete. Whenever in doubt, read the man page:

man sysctl

#Build System: make & build.sh

NetBSD is a source-based system. The entire base system is built with build.sh — a script that orchestrates the toolchain, kernel, and userland in one flow. This sets it apart from systems that only ship prebuilt binaries. The flow looks roughly like this:

In episode 10 we'll run this entire flow. What matters now is understanding that NetBSD gives you the ability to build the entire system from source — with no closed secrets.

#sysctl: Window into the Kernel

sysctl is the doorway to reading and setting kernel parameters at runtime. Almost all NetBSD tuning goes through this tool, and you'll use it across many episodes — from checking the kernel version to configuring security.

sysctl hw.model
sysctl kern.ostype
sysctl net.inet.ip.forwarding

hw.model = Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
kern.ostype = NetBSD
net.inet.ip.forwarding = 0

#Daily Workflow

Now that you understand the architecture, let's lay out the typical workflow of a NetBSD user:

1. Install the base system with sysinst (episode 3).
2. Install packages with pkg_add or build from pkgsrc (episode 4).
3. Manage users, services, filesystems, and network (episodes 5-8).
4. Customize the kernel and build your own system (episodes 9-10).
5. Secure the system with npf, SSH hardening, and PaX (episodes 12-15).
6. Exploit the unique features: rump, NVMM, and portability (episodes 17-20).

#Closing

In this episode 2, you've dissected NetBSD's main architecture: the strict division between the base system and pkgsrc, the -current/stable/release development flow, and the core components such as the modular kernel, rump kernels, the build.sh build system, and sysctl.

Key takeaways:

• The base system and pkgsrc are two separate worlds — updating each works differently.
• Use the stable branch (like netbsd-11) for production.
• The NetBSD kernel is modular — manage it with modload, modunload, and modstat.
• rump kernels let kernel/drivers run in userspace.
• build.sh is the path to full control: you can build the entire system from source.

In the next episode, episode 3, we'll begin the real hands-on journey: installing NetBSD with sysinst — from partitioning the disk with fdisk and disklabel, choosing the right sets, to a successful first boot. Get your VM ready, because we're really going to type! See you in episode 3!