The NetBSD project's official blog, covering releases, kernel work, reproducible builds, virtualization, security, and rump kernels.
Commenters cite it for NetBSD's reproducible builds since 2017, rump kernels and anykernels, and updates on X.org and the wifi stack.
Current Xorg has Glamor, using OpenGL to accelerate the 2D ops of X11. There is also Zink, OpenGL-over-Vulkan for the rare case of Vulkan without native OpenGL.
OTOH, there are people willing to add support for old hardware that probably can't run Vulkan, or even OpenGL, and sometimes they manage to upstream that code. With your "bsder" nick, the following example seems relevant.
https://blog.netbsd.org/tnf/entry/x_org_on_netbsd_the [search "PowerPC"]
Some old X11 coders still work on it, or make suggestions to improve it.
https://lists.x.org/archives/xorg/2024-April/061644.html
https://keithp.com/x-ideas/
But such initiatives lack the "new shiny bling" factor, which seems to be a must nowadays to be a "success". It's the curse of "mostly done, mostly maintenance" projects in a world where breaking ground looks better in a CV than polishing and oiling the machinery others crafted.
Rump kernels are something quite different from containers or jails. They provide just enough of the kernel interface to a kernel device or filesystem driver to allow that driver to be linked in with other code to form a user-space process. If this sounds a lot like FUSE to you, you're onto something: NetBSD's user-space filesystem layer, puffs, is based on rump architecture, and there are at least two FUSE API wrappers for puffs.
Where it gets interesting is when application code is linked together with all the rump kernel code the application needs, forming a unikernel. See Antti Kantee, "An Internet-Ready OS From Scratch in a Week", http://blog.netbsd.org/tnf/entry/an_internet_ready_os_from
"Also known as rump kernels a name inspired by the infamous purge of royalists from Parliament following the English Civil War this process involves creating a fork of an existing kernel codebase and manually purging it of the components deemed unnecessary to the target unikernel."
That appears to come from the FAQ on Github for "rumprun" dated 2015.
Rump kernels were introduced in NetBSD in 2009. It was an described then as an acronym for runnable userspace meta programs.
https://blog.netbsd.org/tnf/entry/runnable_userspace_meta_programs_in
I have not used rumprun for Linux but I still use the rump utilities included with NetBSD.
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.
Of course https://wiki.netbsd.org/tutorials/clang/
Though NetBSD is a bit behind on switching to the LLVM toolchain, here's a recent update https://blog.netbsd.org/tnf/entry/final_report_on_clang_lld
Meanwhile FreeBSD (on amd64, i386, armv6/7, aarch64) has been buildable with clang since some point in 9.x (2012-13), comes with clang only since 10.0 (01.2014), and since 12.0 the bootstrap linker on amd64/i386/armv7 is LLD (which was the case on aarch64 from the beginning iirc)
> When … wifi cards stopped having good blob support it became less tenable. Maybe that all improved after I jumped ship.
The work to modernize the wifi stack has been underway since 2020. There was an update on it in 2021.[1] Based on the wiki, this work is still happening.[2] But they can probably use help.
[1] https://blog.netbsd.org/tnf/entry/wifi_project_status_update
[2] https://wiki.netbsd.org/Converting_drivers_to_the_new_wifi_stack/