Yes, I am aware that I am interrupting our self-hosting PL/0 compiler series but I think it will be worth it. Earlier today, I got the J language system running on OpenBSD. I find it important to write these up, because it helps me preserve my own knowledge of what I did and hopefully it will help others porting languages to their favorite *BSD.
This is a guide on installing and running NetBSD for the Alpha CPU architecture on QEMU, including a GUI (X11 via VNC). It requires you to patch and compile QEMU yourself. It was never possible, until now, to run an actual operating system easily with QEMU Alpha, so this is amazing! It is very cool that Jason Thorpe is putting in so much effort on the QEMU side, as all but one patch is upstream already. Alpha emulation has always been a niche of a niche, so seeing this improve in QEMU is wonderful. OpenVMS does not boot yet since many more things are missing on the QEMU side, but who knows what the future might bring? Maybe even Windows NT for Alpha will boot on QEMU one day?
Since our previous report, there has been significant progress on support for riscv64:
There’s now a web page for the platform, with details of (broadened) hardware support (for those lucky/deserving enough to have hardware, of course).
As always, thanks to those involved!
helloSystem, a project that gives FreeBSD a user interface reminiscent of macOS, hit the 0.5 landmark with a new build last week.
The 0.5 release is based on FreeBSD 12.2 and is progressing nicely. The release notes show a number of important fixes like “sudo su works now”, “fix wrong font sizes” and “fix menu and desktop on multi-monitor setups”.
There is also a note that “all helloDesktop core components build on Linux now,” raising the possibility of a Linux version in future, and that helloDesktop can be used with an alternative window manager, KWin, instead of OpenBox.
Changes in the core utilities include “spatial mode” in Filer, which means that folders open in a new window. This is on by default but can be configured in Preferences. Filter also has a new Go To menu, a context menu for opening files as root, new keyboard shortcuts, and shows file volumes on the desktop. Windowshading has been introduced, which collapses a window to just its title bar when the title bar is double-clicked.
A side effect of the whole freenode kerfluffle is that I’ve been looking at IRCD again. IRC, is of course a very weird and interesting place, and the smaller community of people who run IRCDs are largely weirder and even more interesting.
However, in that community of IRCD administrators there happens to be a few incorrect systems programming opinions that have been cargo culted around for years. This particular blog is about one of these bikesheds, namely the kqueue vs epoll debate.
You’ve probably heard it before. It goes something like this, “BSD is better for networking, because it has kqueue. Linux has nothing like kqueue, epoll doesn’t come close.” While I agree that epoll doesn’t come close, I think that’s actually a feature that has lead to a much more flexible and composable design.
I’ve been a NetBSD developer for three years and it’s been my primary operating system for a long time too - on everything: routers, laptops, Raspberry Pis, PowerPC mac minis, Vortex86 embedded boards, and servers.
I’ve recently been using FreeBSD a lot at work. We have a lot of servers and embedded boards running it, and I was given the option of installing anything I wanted on my workstation. I chose FreeBSD to maintain a separation of BSDs between my work and home life ;)
I thought I’d write a little bit about some differences that stand out to me. Since everyone that knows me well knows that typical use cases like web hosting aren’t really my jam, and I’m more of an embedded, audio, and graphics person, maybe I can offer a more uncommon perspective.
NetBSD’s pkgsrc package manager is the best thing since sliced bread. Like everything the NetBSD maintainers touch, it’s high quality, well documented, predictable, and portable to a fault. I use it everywhere I can, from my macOS and FreeBSD laptops to remote Linux machines. This has lead people on social networks to ask me why, and to give examples.
The biggest reason comes down to what I call digital hygeine, best described by Merlin Mann as “not storing compost in your vegetable crisper”. There’s value in disambiguating personal tools and applications from what is required to run the system, because updating one set shouldn’t impact the other.
Here’s a fun one. I’ve been messing around with an OpenBSD 6.9 image to see just how well my existing code works on a non-Linux environment. Once in a while, I find something unusual and interesting, like a difference in what is supported, and discover a “Linuxism” (or really a “glibcism” in most cases) as a result.
Tonight, however, was not one of those. It was something else brought to us by the folks at Google who put together gtest and gmock, two C++ libraries for testing and mocking libraries, respectively.
The OpenBSD system has this available via their ports system, so you can just “pkg_add gtest” and you’ll get gtest+gmock 1.8.0p3 on your machine, ready to go. Trouble is, it’s not quite right in the head if you do dynamic linking and put both into your binary. Sometimes, it’ll crash with a delightful message about a double-free. If you then only link against gtest (and not also gmock), it won’t crash.
For most of the 2010s, the OpenBSD base system has been stuck with GCC 4.2.1. It was released in July 2007, imported into the OpenBSD source tree in October 2009, and became the default compiler on the amd64, i386, hppa, sparc64, socppc and macppc platforms in OpenBSD 4.8, released in November 2010. As specified in the commit message during import, this is the last version released under the GPLv2 license.
OpenBSD was not the only operating system sticking to GCC 4.2.1 for licensing reasons, FreeBSD did the same, and Mac OS X as well.
DragonFly version 6.0 is the next step from the 5.8 release series in 2020. This version has a revamped VFS caching system, various filesystem updates including HAMMER2, and a long list of userland updates.
It may sometimes seem difficult to believe but FreeBSD has been around for almost 30 years, with its initial release in 1993. It has evolved tremendously over the years, with the involvement of a great community, who have contributed to its continuous development and fine tuning. This great community that puts its shoulder to the development of FreeBSD consists of three groups: committers, contributors, and users.
If users only run FreeBSD systems, contributors are those who submit patches for consideration. Committers are the ones who assess these patches and decide what goes in and what doesn’t. Or, in more simple terms, committers are developers with read and write access to the FreeBSD repositories. In this article, we will take a look of the strengths that make FreeBSD a trustworthy choice of OS.
While FreeBSD and OpenBSD both switched to using LLVM/Clang as their base system compiler, NetBSD picked a different path and remained with GCC and binutils regardless of the license change to GPLv3. However, it doesn’t mean that the NetBSD project endorses this license, and the NetBSD Foundation’s has issued a statement about its position on the subject.
Realistically, NetBSD is more or less tied to GCC, as it supports more architectures than the other BSDs, some of which will likely never be supported in LLVM.
When it rains it pours. After making a splash with D,1 I remembered that some time ago I began an attempt to bring the GNU Modula-2 compiler to OpenBSD. Because why not? Modula-2 is a language that exists and has compiler implementations. I guess my goal is to bring all the languages and compilers to OpenBSD. And as always, there are lessons to be learned. So let’s learn some.
One thing I’ve always wanted to do is support Tor by running a public relay. However, I didn’t have a machine to dedicate to it. All of my normal systems hold data I don’t want to expose to Tor (ssh keys, browser sessions, etc.) Now that FreeBSD has initial support for the Raspberry Pi 3, I can now run an inexpensive Tor relay. At the same time, I could use it to create a special Tor network at home. All data transmitted over the network destined for the public Internet would go through Tor first.
Since I prefer HardenedBSD over normal FreeBSD, that’s what we’ll be setting up in this article. Though this article focuses on using the HardenedBSD on the RPI3, the concepts apply equally to FreeBSD or HardenedBSD on any architecture.
Step 1 was getting my hands on Raspbian. Step 2 was running OpenBSD on the Raspberry Pi 3 Model B. I had quite a few try & fails but it booted, installed and ran properly in the end. Full story follows.