NetBSD Archive
All that to say, I find that NetBSDs philosophy aligns with mine. The OS is small and cozy, and compared to many minimal Linux distributions, I found it faster to setup. Supported hardware is automatically picked up, for my Thinkpad T480s almost everything (except the trackpad issue I solved above) worked out of the box, and it comes with a minimal window manager and display manager to get you started. It is simple and minimal but with sane defaults. It is a hackable system that teaches you a ton. What more could you want? ↫ Marc Coquand I spent quite some time using OpenBSD earlier this year, and I absolutely, positively loved it. I can’t quite put into words just how nice OpenBSD felt, how graspable the configuration files and commands were, how good and detailed the documentation, and how welcoming and warm the community was over on Mastodon, with even well-known OpenBSD developers taking time out of their day to help me out with dumb newbie questions. The only reason I eventually went back to Fedora on my workstation was performance. OpenBSD as a desktop operating system has some performance issues, from a slow file system to user interface stutter to problematic Firefox performance, that really started to grind my gears while trying to get work done. Some of these issues stem from OpenBSD not being primarily focused on desktop use, and some of them simply stem from lack of manpower or popularity. Regardless, nobody in the OpenBSD community was at all surprised or offended by me going back to Fedora. NetBSD seems to share a lot of the same qualities as OpenBSD, but, as the linked article notes, with a focus on different things. Like I said yesterday, I’m looking to building and testing a system entirely focused on tiled terminal emulators and TUI applications, and I’ve been pondering if OpenBSD or NetBSD would be a perfect starting point for that experiment.
NetBSD 10 was released recently, so a lot of people are experimenting with it and writing down their thoughts. I’ve got two of those for you today, to help you in case you, too, want to install NetBSD 10 and play around with, or just use, it. First, what if you want to install NetBSD 10 on a UEFI system, but with full disk encryption in case your device gets stolen? It turns out there are countless guides for installing with full-disk encryption on MBR-based systems, but once you use UEFI – as you should be – things get a lot more complicated. The NetBSD installer is apparently rather basic, and a better solution is to drop to a shell and install NetBSD that way instead, and even then, full disk encryption with UEFI is actually not possible, as it seems the root file system – where the operating system itself resides – cannot be encrypted. The restriction is in the root file-system. It needs to be in plain-text and in a regular partition. It seems to me that rootfs in CGD or LVM is not well supported. ↫ vsis.online This seems like something the NetBSD team may need to take a look at, since full disk encryption should be an easy option to choose, even, or especially in 2024, on UEFI systems. Such encryption is easily achieved on Linux or Windows systems, and it seems odd to me that NetBSD is lagging behind a bit here. In the meantime, the linked guide will be a good jumping-off point for those of you interested in going a similar route. The second article I want to highlight concerns NetBSD 10 on the Pinebook Pro, the inexpensive ARM laptop that normally ships with Linux. It turns out there’s a NetBSD 10 image for this device, so installation is quite a bit more straightforward than the more exotic setup I mentioned earlier. It seems most of the hardware works quite well out of the box, with the inly exception being the on-board Wi-Fi, which the author addressed with a USB W-Fi dongle. Other than that, NetBSD is running well on the Pinebook Pro for the author, which is great to read since that makes this cheap device a great starting point for people interested in running NetBSD.
The NetBSD project seems to agree with me that code generated by “AI” like Copilot is tainted, and cannot be used safely. The project’s added a new guideline banning the use of code generated by such tools from being added to NetBSD unless explicitly permitted by “core“, NetBSD’s equivalent, roughly, of “technical management”. Code generated by a large language model or similar technology, such as such as GitHub/Microsoft’s Copilot, OpenAI’s ChatGPT, or Facebook/Meta’s Code Llama, is presumed to be tainted code, and must not be committed without prior written approval by core. ↫ NetBSD Commit Guidelines GitHub Copilot is copyright infringement and open source license violation at an industrial scale, and as I keep reiterating – the fact Microsoft is not training Copilot on its own closed-source code tells you all you need to know about what Microsoft thinks about the legality of Copilot.
NetBSD 10 and NetBSD 9.4 were only recently released, leaving one final branch to receive what will be its last update: NetBSD 8.3. NetBSD 8.0 was originally released in 2018, so this final release marks six years of updates, which is a good track record, especially now that two newer main releases are available to choose from. With 8.3 being the final release, this means no more regular or security updates, pkgsrc no longer supports the 8.0 branch either – so yeah, time to upgrade. NetBSD 8.3 brings various updates and bug fixes for libX11, xterm, tmux, and httpd, and the root name servers and time zone data have been updated to their latest iterations as well. There’s of course a full list of changes to peruse through if you want to know every little detail that’s changed. You can update your installation in-place, of course, or download the installation media for 8.3 from one of the many mirrors.
The big question – does all this have a future? The good news is that all new hardware has generic support in X. Someone writes either a modesetting kernel driver or a classical wsdisplay kernel driver and they will be automatically supported by the associated drivers in X. The bad news is that to have applications running we require access to a larger open source ecosystem, and that ecosystem has a lot of churn and is easily distracted by shiny new squirrels. The process of upstreaming stuff to X.Org is an ongoing process, but it’s likely we’ll run into things that will never be suitable for upstream. ↫ Nia Alarie on the NetBSD blog I had no idea NetBSD did such heavy customisations of its X.Org implementation, many of which have never made their way upstream. The project also maintains support for several older GPUs, uses its own input driver, and more – it’s quite impressive.
Hot on the heels of NetBSD 10.0 comes NetBSD 9.4, a minor release in the previous release branch. NetBSD 9.4 is primarily a bug and security fix release, however, there are some new features, such as support for more MegaRAID controllers, ZTE MF112 and D-Link DWM222 USB 3G modems, and improved CPU feature detection for newer AMD/Intel devices. All users of netbsd-9 should upgrade if they are not following the stable branch. ↫ NetBSD 9.4 release announcement A very important note here is that the version of OpenSSL in NetBSD 9.4 is no longer supported unless you have a support contract with OpenSSL. They suggest upgrading to NetBSD 10.0, or to use OpenSSL from pkgsrc.
SmolBSD is a tiny BSD UNIX (NetBSD) system creation tool, primarily aimed at building modern, lightweight, fast micro VMs. SmolBSD can start a service in (way) under a second, giving it the ability to be used as a virtualized container, thus reducing attack surface and actually isolating workflows. ↫ SmolBSD website Neat.
NetBSD 10.0 has been released, and it brings a lot of improvements, new features, and fixes compared to the previous release, 9.3. First and foremost, there are massive performance improvements when it comes to compute and filesystem-bound applications on multicore and multiprocessor systems. NetBSD 10.0 also brings WireGuard support compatible with implementations on other systems, although this is still experimental. There’s also a lot of added support for various ARM SoCs and boards, including Apple’s M1 chip, and there’s new support for compat_linux on AArch64, for running Linux programs. Of course, there’s also a ton of new and updated drivers, notably the graphics drivers which are now synced to Linux 5.6, bringing a ton of improvements with them. This is just a small sliver of all the changes, so be sure to read the entire release announcement for everything else.
When I used OpenBSD, I was a big fan of bsd.rd: a kernel that includes a root file system with an installer and a few tools. When I invariably did something bad to my root file system, I could use that to repair things. bsd.rd is also helpful for OS updates. And there is only a single file involved. On NetBSD however, there is usually no netbsd.rd kernel installed, or even available by default. The facility is there, it’s just not standard. To be fair, there are a number of architectures that use kernels with a ramdisk for installation. Recently, I have been toying with NetBSD on an Orange Pi 5. This is a 64-bit ARM board, using the evbarm-aarch64 architecture. I am booting from an SD card (details in a followup post) but once booted, the kernel does not see the card any more, only the NVMe SSD. So my thoughts went back to bsd.rd and I decided that I want one! Such a kernel seems like a very useful tool to have, so if you’re running NetBSD – this guide will help you add it to your toolbox.
NetBSD continues using the FFS file-system by default while it’s offered ZFS support that has been slowly improving — in NetBSD-CURRENT is the ability to use ZFS as the root file-system if first booting to FFS, for example. There may be another modern file-system option soon with an effort underway to port DragonFlyBSD’s HAMMER2 over to NetBSD. The GitHub repository has the code if you’re up for contributing.
NetBSD 9.3 has made it into the wild. Aside from many bug fixes, 9.3 includes backported improvements to suspend and resume support, various minor additions of new hardware to existing device drivers, compatibility with UDF file systems created on Windows 10, enhanced support for newer Intel Gigabit Ethernet chipsets, better support for new Intel and AMD Zen 3 chipsets, support for configuring connections to Wi-Fi networks using sysinst(8), support for wsfb-based X11 servers on the Commodore Amiga, and minor performance improvements for the Xen hypervisor. A solid set of improvements for a point release.
In this post, we’ll look at implementing a simple character device driver as a kernel module in NetBSD. Once it is loaded, userspace processes will be able to write an arbitrary byte string to the device, and on every successive read expect a cryptographically-secure pseudorandom permutation of the original byte string. IF you’ve always wanted to learn how to write a NetBSD driver, here’s a great starting point.
The NetBSD Project is pleased to announce NetBSD 9.2, the second update of the NetBSD 9 release branch. It represents a selected subset of fixes deemed important for security or stability reasons since the release of NetBSD 9.1 in October 2020, as well some enhancements backported from the development branch. It is fully compatible with NetBSD 9.0. I’m not even remotely well-versed enough in NetBSD to make heads or tails of the changelog, but it seems like there’s quite a few notable ones in there.
In this article, I will walk through the early kernel initialization process, defining the meaning of this term. System initialization is a broad topic that ranges from the platform’s hardware design all the way up to typical functions of an operating system such as handling I/O operations. It is not possible to cover the entire topic adequately within the scope of an article. In this first part I will describe the well-known AMD64: 64-bit platform. I am going to highlight a very interesting part of the initialization process the early initialization of the kernel. Later, I will compare it with ARM64. In both cases I will discuss the topic in the context of NetBSD, the operating system known for its portability. Some light reading.
Related to yesterday’s post about NetBSD switching to ctwm: After I posted about the new default window manager in NetBSD I got a few questions, including “when is NetBSD switching from X11 to Wayland?”, Wayland being X11’s “new” rival. In this blog post, hopefully I can explain why we aren’t yet! The short answer? Wayland is too Linux-specific to be easily ported or adapted to NetBSD, so don’t expect it any time soon.
For more than 20 years, NetBSD has shipped X11 with the “classic” default window manager of twm. However, it’s been showing its age for a long time now. In 2015, ctwm was imported, but after that no progress was made. ctwm is a fork of twm with some extra features – the primary advantages are that it’s still incredibly lightweight, but highly configurable, and has support for virtual desktops, as well as a NetBSD-compatible license and ongoing development. Thanks to its configuration options, we can provide a default experience that’s much more usable to people experienced with other operating systems. The ctwm website has more information for those interested.
The NetBSD Project is pleased to announce NetBSD 9.0, the seventeenth major release of the NetBSD operating system. This release brings significant improvements in terms of hardware support, quality assurance, security, along with new features and hundreds of bug fixes. Support for the ARM architecture seems to be a major pillar of this new release.
The NetBSD Project is pleased to announce NetBSD 8.0, the sixteenth major release of the NetBSD operating system.
This release brings stability improvements, hundreds of bug fixes, and many new features.
Major changes are a rework of the USB stack and the addition of USB 3.0 support and Spectre and Meltdown mitigations.
Clear, concise introduction. I like it.
A new SUNXI evbarm kernel has appeared recently in NetBSD -current with support for boards based on the Allwinner H3 system on a chip (SoC). The H3 SoC is a quad-core Cortex-A7 SoC designed primarily for set-top boxes, but has managed to find its way into many single-board computers (SBC). This is one of the first evbarm ports built from the ground up with device tree support, which helps us to use a single kernel config to support many different boards.
