
NetBSD 9.0 - zdw
https://netbsd.org/releases/formal-9/NetBSD-9.0.html
======
ianai
“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

~~~
corona-chan
OpenBSD next, please!

~~~
yjftsjthsd-h
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.

------
ddevault
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 :)

~~~
anonsivalley652
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

~~~
LargoLasskhyfv
Ever heard of [https://genode.org/](https://genode.org/) ?

------
kyuudou
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.

~~~
tw04
Their compellent storage arrays did as well at one point. Not sure if they
still do.

~~~
kyuudou
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.

------
polyphonicist
I am a Linux user. What would be a good reason for me to try out NetBSD?
Honest question.

~~~
johnklos
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 :)

~~~
dleslie
Especially now that NetBSD can run on an RPi3. It was a bit embarassing that
it could not.

~~~
jmcneill
RPi3 support was present in NetBSD 7.1 and 8.0. NetBSD 9.0 is the first
release where you can run it in 64-bit mode.

------
cnst
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](https://news.ycombinator.com/item?id=19622590). [http://blog.netbsd.org/tnf/entry/from_zero_to_nvmm](http://blog.netbsd.org/tnf/entry/from_zero_to_nvmm).

* KASLR — kernel address-space layout randomisation. [https://news.ycombinator.com/item?id=15769457](https://news.ycombinator.com/item?id=15769457). [http://blog.netbsd.org/tnf/entry/the_strongest_kaslr_ever](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](https://news.ycombinator.com/item?id=22336962).

------
sergiomattei
Wow, this looks like huge news for NetBSD. Not too in tune with the BSD
ecosystem, but this sounds great for ARM servers.

------
acd
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.

------
xvilka
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](https://man.sr.ht/builds.sr.ht/compatibility.md)

~~~
ddevault
Please help! The image is _almost_ complete:

[https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/images/...](https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/images/netbsd)

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.

~~~
cnst
It should be doable with the following rc.d configuration:

    
    
      resize_disklabel=YES
      resize_root=YES
    

The second script is available by default, but the first one is somehow hidden
from general availability:

* [http://bxr.su/n/distrib/utils/embedded/files/resize_disklabe...](http://bxr.su/n/distrib/utils/embedded/files/resize_disklabel)

* [http://bxr.su/n/etc/rc.d/resize_root](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
    

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.

~~~
ddevault
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.

~~~
cnst
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/](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/...](https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master/images/netbsd/genimg)
is wrong.

------
wtallis
> 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.

~~~
unixhero
At least it is now available.

------
mekster
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.

------
harryruhr
There was an Article "Are the BSDs dying"
([https://www.csoonline.com/article/3250653/is-the-bsd-os-
dyin...](https://www.csoonline.com/article/3250653/is-the-bsd-os-dying-some-
security-researchers-think-so.html)) 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.

~~~
theonemind
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.

~~~
kev009
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](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).

