NetBSD 9.0(netbsd.org)
netbsd.org
NetBSD 9.0
https://netbsd.org/releases/formal-9/NetBSD-9.0.html
11 comments
“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”
Grateful for this
Grateful for this
ZFS boot is being worked on at this moment[0] - hopefully it bears fruit. I don’t know, if this were successful, if it would be backported to 9.
[0] https://mail-index.netbsd.org/current-users/2020/02/14/msg03...
[0] https://mail-index.netbsd.org/current-users/2020/02/14/msg03...
OpenBSD next, please!
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.
Wow, this looks like huge news for NetBSD. Not too in tune with the BSD ecosystem, but this sounds great for ARM servers.
I am a Linux user. What would be a good reason for me to try out NetBSD? Honest question.
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.
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.
> not-too-recent x86 hardware
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 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?
CPU isn't the problem. Peripherals (GPU, network/WLAN cards, storage controllers, ...) are.
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'm unfamiliar with BSD. Are you saying there are significantly fewer processes on BSD to be aware of when looking through ps?
I had always assumed (probably ignorantly) that BSD basically runs all of the same or similar processes to a similarly featured Linux distro.
I had always assumed (probably ignorantly) that BSD basically runs all of the same or similar processes to a similarly featured Linux distro.
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].
[0] https://youtu.be/URVS4H7vrdU
[1] https://youtu.be/B19a2i3HnJM
[0] https://youtu.be/URVS4H7vrdU
[1] https://youtu.be/B19a2i3HnJM
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.
¹ exaggeration
It doesn't help that linux (kernel and userspaces) tends to resemble chaotic patchwork more¹ than a reasonably designed system.
¹ exaggeration
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.
yeah, distros like archlinux have pretty thin base install and I always rejoy watching htop process list fit onto a third of the screen
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.
This smells of security through obscurity to me.
Unless you’re defending against zero days (unlikely) an up to date Linux box must surely be more secure?
Unless you’re defending against zero days (unlikely) an up to date Linux box must surely be more secure?
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.
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 :)
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 :)
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.
Here's the UNIX family tree:
https://blog.codinghorror.com/content/images/uploads/2009/06...
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...
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).
[deleted]
I am waiting for NetBSD to be available in SourceHut CI[1]. We already use it for FreeBSD and OpenBSD jobs, missing only one major OS - NetBSD.
[1] https://man.sr.ht/builds.sr.ht/compatibility.md
[1] https://man.sr.ht/builds.sr.ht/compatibility.md
Please help! The image is almost complete:
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.
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.
It should be doable with the following rc.d configuration:
* 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:
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.
resize_disklabel=YES
resize_root=YES
* 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:
cd /etc/rc.d/
ftp http://bxr.su/raw/NetBSD/distrib/utils/embedded/files/resize_disklabel
chmod +x resize_disklabel
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.
The resize_root script wouldn't do anything if the fdisk and disklabel aren't adjusted (provided it's not a raw filesystem file that's being resized as in http://wiki.netbsd.org/amazon_ec2/build_your_own_ami/ page), so it's kind of expected that it doesn't work all by itself, and that https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/images/... is wrong.
You should be able to create a vnd that's larger than the host filesystem if you don't fill it.
Why ? What are the benefits of using that ?
radare2 [1] is a portable tool and should work everywhere, like you expect to do the same from GDB, for example.
[1] https://github.com/radareorg/radare2
[1] https://github.com/radareorg/radare2
There is a radare2 package in pkgsrc, I presume it works.
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.
You still haven't explained what you want to do and why I (as a NetBSD developer) should be interested.
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.
Sourcehut makes it easy to run CI for a lot of platforms at once. Helping it support netbsd helps developers target netbsd easily.
NetBSD impresses by it’s broad platform support and low memory usage. You can boot a whole os with less ram usage than some programs.
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 :)
MINIX 3.x :)
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
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
Ever heard of https://genode.org/ ?
SmartOS (a Solaris/Illumos derivative) also uses pkgsrc, in my limited experience it’s very nice.
Force10 network switches (owned by Dell now) use NetBSD for their FTOS and have for quite some time. Just thought I'd throw that out there.
Their compellent storage arrays did as well at one point. Not sure if they still do.
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.
There was an Article "Are the BSDs dying" (https://www.csoonline.com/article/3250653/is-the-bsd-os-dyin...) where it us said, that NetBSD has the lowest code quality of all BSD variants. It also finishes last when it comes to security updates.
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.
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).
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).
NetBSD publishes updated builds of src daily, you can just update to them. No idea about the frequency of package rebuilds but they definitely happen.
[deleted]
> There was an Article "Are the BSDs dying"
I don't know, what does NetCraft say?
Does NetBSD run on Hot Grits yet?
I don't know, what does NetCraft say?
Does NetBSD run on Hot Grits yet?
Don't see anyone mention these rather notable features of NetBSD 9.0:
* 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.
* 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.