“Updated ZFS. This is the first release with ZFS usable for daily use, but there is no support for booting from ZFS nor using ZFS as root filesystem yet”
OpenBSD will probably never use ZFS; they like clean code that they can understand and control as completely as possible, and ZFS is a monster of a codebase that replaces whole chunks of the system with its own.
Without going too far in to the politics of GNU/Linux, it's a bit messy. All the distros are different from each other, plus they're changing so rapidly that a book about one version is much less useful for managing another (think Ubuntu 14 -> 16, or Ubuntu 16 -> 18).
Also, while GNU/Linux is generally portable, many of the things you learn about Ubuntu will be different on what you'd run on a Raspberry Pi, or an UltraSPARC, or on a PowerPC.
NetBSD is the same OS on all the hardware it supports, so the system consistently does what it does regardless of where it's run. If you want to develop on a desktop and deploy on a Pi, for example, you'll have a much easier time with NetBSD :)
Well. Given the smaller user base the *BDSs are good candidates for a very low footprint secure OS installation. In our org we use an openbsd instance to run our low traffic but extremely secure master database. The system really spartan and has a very low footprint. It is sufficiently different from Linux that the casual automated attack wont work. Things like NetBSD are a useful starting point to getting an OS up and running on a new architecture. This happens quite frequently in research settings.
I don't now what goes into the day-to-day maintenance at sdf.org, but they are able to provide public access to a NetBSD system without any major security breaches. The lore there is that before the switch from Linux to NetBSD security was a mess. Of course they made the change almost 20 years ago, so things probably are different today.
sdf.org is interesting because it is one of the few services running a multi-user capable OS - and using it that way. I donated to them years ago, primarily for the complementary email address, and in setting that up I was poking around in the shell - that was the first I'd seen 'who' return a list active sessions that weren't me.
If you want a simpler system that is easy to understand, NetBSD is a pretty good choice. The source is almost entirely in a single repository for you to read, and you need a single command to build a boot-able release (you can even build it on other OSes and architectures). It's a level of familiarity with the inner workings of a system that is hard to express.
It has pretty decent support for ARM boards so that's the best hardware for trying it out, or not-too-recent x86 hardware. Another use case people have is using esoteric old machines like m68k and VAX, which NetBSD still supports with release builds.
Using it as a daily driver (I do) requires some tinkering on the initial setup, and people have mentioned it gives a vibe of using Gentoo, and that certainly has a market. But it's very easy to keep using the same setup you've had for years.
Most proprietary software doesn't support NetBSD, but if you were the type using primarily FOSS anyway, you might have all you need.
I don't know much about system development, but aren't most x86 platforms extremely backwards compatible? Would an OS that is not adopted to the latest CPU not load at all, or just wouldn't use that CPU to the fullest potential?
Especially in the case of NetBSD and OpenBSD, it's nice to SSH into a system, run ps, and be able to identify on sight every single running process. It's easy to know what everything is, and more importantly, why it's there. That's a beautiful starting position for building other systems even when you're not trying to boot it on a toaster oven.
I’d say BSD (esp Net and Open, as mentioned above), just don’t run as many processes, by design. BSDs are *nix, like Linux, but with their own traditions. If you, familiar with Linux, sat down at a NetBSD box, you’d be able to easily get around like a little girl[0]. You wouldn’t find systemd, though, you’d see a “wheel” group, your login shell might not be bash. The BSDs just decorate their houses differently than Linux[1].
I'd say it depends on the Linux distribution. Things like Ubuntu would be much like mentioned [1], packing just about everything¹, while on something like openwrt you would probably recognize or easily find out the function of all userspace processes - I counted 13 on my router.
It doesn't help that linux (kernel and userspaces) tends to resemble chaotic patchwork more¹ than a reasonably designed system.
Of course you are correct; “Linux” is a big landscape, and descriptions of instances run the gamut (eg: OpenWRT vs Ubuntu). When I was writing above I had (eg) Red Hat or Ubuntu in mind.
NetBSD is a great system for learning Unix. It lets you deep dive into certain topics because you have to. I learned to use Unix with NetBSD in the 2000. Only problem: find hardware for it. If you do not have a Raspberry Pi, your PC should not be brand new ideally (3-4 years is a good starting point).
Be careful about labeling yourself with technology X, it can reinforce identity/religious tribalism/biases/limitations.
If you want to:
- Try out a different flavor of BSD derived from BSD 4.3 Reno before NetBSD forked to OpenBSD.
- Run a modern version of Xen as dom0 (the host). I found around the time of 6.1 that Xen on NetBSD worked better and was simpler than FreeBSD's installation. Maybe things have changed.
- Learn something new.
- Also, like FreeBSD, it supports ZFS.
It's often used by numerous small, independent ISPs for their core infrastructure when they need a little more flexibility than OpenBSD. OpenBSD is great for certain use-cases.
We run our tests on different platforms, for example the native debugging and emulation, where platform differences can play the role. And we run them on every commit, to prevent regressions.
For example, the emulation and debugger depends on the platform, so running debugging tests on CI helps us to improve and refactor corresponding code without much hassle.
But I need a NetBSD expert to come in and put on the finishing touch: making the filesystem resize to fill the available space on the qcow2. Without this, the image cannot build a new version of itself which isn't smaller than the host image, leading to image shrinkage over time and eventual breakitude.
cd /etc/rc.d/
ftp http://bxr.su/raw/NetBSD/distrib/utils/embedded/files/resize_disklabel
chmod +x resize_disklabel
The `resize_disklabel` script does handle `fdisk`, too. If it doesn't work for your usecase, might want to provide the output of running `/etc/rc.d/resize_disklabel` manually, together with `fdisk` and `disklabel` outputs, too.
P.S. BTW, you probably don't want to run `resize_root onestart` once the system is running multiuser — it passes `-y` to `resize_ffs`, which causes temporary filesystem corruption if the filesystem is running in `rw` mode.
Aye, but that doesn't seem to work. Check out the genimg script - it's already trying to set up resize_root. I've also tried resize_disklabel without success. What this needs isn't another well-meaning HN comment trying to debug by proxy - I need someone who knows how NetBSD works to get their hands dirty and get it done.
NetBSD is probably my favorite BSD. I like its focus on simplicity and portability. I also like pkgsrc a lot more than ports. I appreciate that pkgsrc is portable beyond BSD, too - Minix uses it. Nice work, folks :)
I remember hacking on MINIX 2 (which is an entirely different (and tiny) codebase) in the university's Intro to OSes course to speed up the keyboard repeat rate on the physical MINIX PCs in the computer lab. Interestingly, the course now uses FreeBSD.
Wow, really? I built an Oracle cluster on Compellent spindles and was pretty impressed with its tiering. Had no idea NetBSD was involved, very cool. I was actually using Force10 switches in the storage fabric IIRC.
> Reworked SATA subsystem, now supporting multiple commands in transit (NCQ),
Well, that's more than a decade overdue. It looks like they added a NVMe driver in 8.0 that's not shockingly primitive, so I wonder why SATA was lagging so far behind.
To this day NetBSD doesn't deliver binary security updates in a timely manner. Not in the base system and not for packages. Even OpenBSD manages to do this nowadays.
If there is even a patch at all, it is delivered in source form only. Users are supposed to build the binaries for themselves. That's anachronistic in the year 2020.
Building from source consumes not only time but also energy. When everyone talks about saving energy and reducing carbon footprint, source based systems where every user is supposed to build binaries from sources are a not only a waste of time but are also contributing to the climate crisis.
Contributing to the climate crisis seems like a stretch. Bitcoin obviously uses a lot of power and contributes to the climate crisis. Building OSes from source is just a hobby for most people, and probably doesn't register as a particularly environmentally intensive one compared to even reading paperback books.
I have a huge soft spot for NetBSD because it was my first BSD and first foray into kernel work. The more alarming issue affecting Open and Net is that commodity computer architecture has wildly changed in the past 10 years. A late 1980s style locks and CVs approach to SMP is only good for a handful of cores. Consequently, if you run one of these on what are becoming standard desktop class systems like Ryzen, you are throwing away a great deal of performance (and therefore energy efficiency). Basically modern computers look a lot like an HP SuperDome or whatever from 2000 which is wild and inconvenient for programmers, but reality. FreeBSD (HEAD) is now generally competent on something like an Epyc or multi-socket intel box, and there isn't much left to eek out on an 16-thread laptop.
I funded and helped stabilize a technology called Epoch Reclamation into FreeBSD that can be thought of like a cleaner version of Linux' RCU at least for tracking object liveness. One of the most interesting things I've seen go into FreeBSD recently is a further improvement on that, a novel form of safe memory reclamation directly in UMA: https://reviews.freebsd.org/D22586. This is really exciting because for instance RCU suffers from time of use to time to free issues in Linux, and this new holistic approach really does not for fast turnover workloads.
NetBSD does have a form of SMR called pserialize(9), but ignoring some of the algorithmic weaknesses it also has a lot of global or oversized locks in critical subsystems like the VFS and network stack that turn it into a fairly non-SMP friendly system let alone consideration for different memory latencies like NUMA.
A lot of these ideas from FreeBSD can be copied into Net and Open but the code bases have diverged greatly where it's not some simple forklift (for instance Net and Open use a similar kernel memory allocation that is totally different than Free).
Out of the 3 major BSD, FreeBSD targets for high number of software supports, OpenBSD targets for security which both seems to have a reason to adopt, but NetBSD targets for wide hardware support but is there other reason people have to adopt NetBSD these days?
Never tried NetBSD ever since I tried FreeBSD nearly 20 years back and OpenBSD several times since then.
64 comments
[ 3.0 ms ] story [ 122 ms ] threadGrateful for this
[0] https://mail-index.netbsd.org/current-users/2020/02/14/msg03...
It can be a bit refreshing to use something where there is a reasonably well-documented "correct" tool to use.
Also, while GNU/Linux is generally portable, many of the things you learn about Ubuntu will be different on what you'd run on a Raspberry Pi, or an UltraSPARC, or on a PowerPC.
NetBSD is the same OS on all the hardware it supports, so the system consistently does what it does regardless of where it's run. If you want to develop on a desktop and deploy on a Pi, for example, you'll have a much easier time with NetBSD :)
Unless you’re defending against zero days (unlikely) an up to date Linux box must surely be more secure?
It has pretty decent support for ARM boards so that's the best hardware for trying it out, or not-too-recent x86 hardware. Another use case people have is using esoteric old machines like m68k and VAX, which NetBSD still supports with release builds.
Using it as a daily driver (I do) requires some tinkering on the initial setup, and people have mentioned it gives a vibe of using Gentoo, and that certainly has a market. But it's very easy to keep using the same setup you've had for years.
Most proprietary software doesn't support NetBSD, but if you were the type using primarily FOSS anyway, you might have all you need.
I don't know much about system development, but aren't most x86 platforms extremely backwards compatible? Would an OS that is not adopted to the latest CPU not load at all, or just wouldn't use that CPU to the fullest potential?
I had always assumed (probably ignorantly) that BSD basically runs all of the same or similar processes to a similarly featured Linux distro.
[0] https://youtu.be/URVS4H7vrdU
[1] https://youtu.be/B19a2i3HnJM
It doesn't help that linux (kernel and userspaces) tends to resemble chaotic patchwork more¹ than a reasonably designed system.
¹ exaggeration
If you want to:
- Try out a different flavor of BSD derived from BSD 4.3 Reno before NetBSD forked to OpenBSD.
- Run a modern version of Xen as dom0 (the host). I found around the time of 6.1 that Xen on NetBSD worked better and was simpler than FreeBSD's installation. Maybe things have changed.
- Learn something new.
- Also, like FreeBSD, it supports ZFS.
It's often used by numerous small, independent ISPs for their core infrastructure when they need a little more flexibility than OpenBSD. OpenBSD is great for certain use-cases.
Here's the UNIX family tree:
https://blog.codinghorror.com/content/images/uploads/2009/06...
[1] https://man.sr.ht/builds.sr.ht/compatibility.md
[1] https://github.com/radareorg/radare2
https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/images/...
But I need a NetBSD expert to come in and put on the finishing touch: making the filesystem resize to fill the available space on the qcow2. Without this, the image cannot build a new version of itself which isn't smaller than the host image, leading to image shrinkage over time and eventual breakitude.
* http://bxr.su/n/distrib/utils/embedded/files/resize_disklabe...
* http://bxr.su/n/etc/rc.d/resize_root
You can fetch it raw, it seems to work great:
The `resize_disklabel` script does handle `fdisk`, too. If it doesn't work for your usecase, might want to provide the output of running `/etc/rc.d/resize_disklabel` manually, together with `fdisk` and `disklabel` outputs, too.P.S. BTW, you probably don't want to run `resize_root onestart` once the system is running multiuser — it passes `-y` to `resize_ffs`, which causes temporary filesystem corruption if the filesystem is running in `rw` mode.
I remember hacking on MINIX 2 (which is an entirely different (and tiny) codebase) in the university's Intro to OSes course to speed up the keyboard repeat rate on the physical MINIX PCs in the computer lab. Interestingly, the course now uses FreeBSD.
I hope MINIX 4 or a similar project would:
- use seL4 as the kernel
- also be a Type-1 hypervisor (like Xen or ESXi)
- BSD-derived userland (as MINIX 3)
- port FreeBSD's Linux binary compatibility
Well, that's more than a decade overdue. It looks like they added a NVMe driver in 8.0 that's not shockingly primitive, so I wonder why SATA was lagging so far behind.
To this day NetBSD doesn't deliver binary security updates in a timely manner. Not in the base system and not for packages. Even OpenBSD manages to do this nowadays. If there is even a patch at all, it is delivered in source form only. Users are supposed to build the binaries for themselves. That's anachronistic in the year 2020.
Building from source consumes not only time but also energy. When everyone talks about saving energy and reducing carbon footprint, source based systems where every user is supposed to build binaries from sources are a not only a waste of time but are also contributing to the climate crisis.
I funded and helped stabilize a technology called Epoch Reclamation into FreeBSD that can be thought of like a cleaner version of Linux' RCU at least for tracking object liveness. One of the most interesting things I've seen go into FreeBSD recently is a further improvement on that, a novel form of safe memory reclamation directly in UMA: https://reviews.freebsd.org/D22586. This is really exciting because for instance RCU suffers from time of use to time to free issues in Linux, and this new holistic approach really does not for fast turnover workloads.
NetBSD does have a form of SMR called pserialize(9), but ignoring some of the algorithmic weaknesses it also has a lot of global or oversized locks in critical subsystems like the VFS and network stack that turn it into a fairly non-SMP friendly system let alone consideration for different memory latencies like NUMA.
A lot of these ideas from FreeBSD can be copied into Net and Open but the code bases have diverged greatly where it's not some simple forklift (for instance Net and Open use a similar kernel memory allocation that is totally different than Free).
I don't know, what does NetCraft say?
Does NetBSD run on Hot Grits yet?
* NVMM — hypervisor compatible with QEMU. https://news.ycombinator.com/item?id=19622590. http://blog.netbsd.org/tnf/entry/from_zero_to_nvmm.
* KASLR — kernel address-space layout randomisation. https://news.ycombinator.com/item?id=15769457. http://blog.netbsd.org/tnf/entry/the_strongest_kaslr_ever.
Both were done by the same person, BTW, who also found a serious bug in OpenBSD's VMM hypervisor earlier today, too — https://news.ycombinator.com/item?id=22336962.
Never tried NetBSD ever since I tried FreeBSD nearly 20 years back and OpenBSD several times since then.