This year we challenged the Hackaday community to develop Shitty Simple Supercon Add-Ons (SAO) that did more than just blink a few LEDs. The SAO standard includes I2C data and a pair of GPIO pins, but historically, they’ve very rarely been used. We knew the talented folks in this community would be able to raise the bar, but as they have a tendency to do, they’ve exceeded all of our expectations.

As we announced live during the closing ceremony at the 2024 Hackaday Supercon, the following four SAOs will be put into production and distributed to all the attendees at Hackaday Europe in Spring of 2025.

Best Overall: SAO Multimeter

For the “Best Overall” category, we only intended to compare it with the other entries in the contest. But in the end, we think there’s a strong case to be made that [Thomas Flummer] has created the greatest SAO of all time. So far, anyway.

This add-on is a fully functional digital multimeter, with functions for measuring voltage, resistance, and continuity. The design is a pure work of art, with its structure combining stacked PCBs and 3D printed parts. There’s even tiny banana plugs to connect up properly scaled probes. Incredible.

In the documentation [Thomas] mentions there are additional functions he didn’t have time to include in the firmware, such as modes to analyze the I2C and GPIO signals being received. Now that it’s been selected for production, we’re hoping he’ll have the time to get the code finished up before its European debut.

Fun: Etch sAo Sketch

This SAO recreates the iconic art toy in a (hopefully) non-trademarked way, with a 1.5″ inch 128 x 128 grayscale OLED display and a pair of trimpots capped with 3D printed knobs. Drawing is fun enough, but the nostalgia really kicks in when you give it a good shake — the onboard LIS3DH 3-axis accelerometer picks up the motion and wipes the display just like the real thing.

Created by [Andy Geppert], this SAO isn’t just a pretty face. Flipping it over shows an exceptionally clever technique for connecting the display board to the main PCB. Tiny metal balls (or “alignment spheres” if you want to get fancy) mate up with the mounting holes on the OLED board and center it, and a touch of solder locks it all in place.

Fine Art: Bendy SAO

While this wacky, waving, inflatable, arm-flailing SAO might look like the sort of thing that would be outside of a used car dealership, but creator [debraansell] managed to shrink it down so the point that it’s reasonable to plug into your badge. More or less.

There are several fascinating tricks at work here, from lighting the PCB from the back using side-firing LEDs to the integrated slip rings. If this one didn’t look so good, it would have been a strong contender for the “Least Manufacturable” Honorable Mention.

Functional: Vectrex SAO

Creating a replica of the Vectrex at SAO scale would have been an impressive enough accomplishment, but [Brett Walach] took this one all the way and made it playable.

The display is a 7 x 10 Charlieplexed LED matrix, while the “joystick” is implemented with a 1-button capacitive touch sensor. A PIC16F886 microcontroller runs the simplified version of Scramble, and there’s even a speaker for era-appropriate audio.

But that’s not all! This SAO was also designed to be hacked — so not only is all the hardware and software open source, but there’re various jumpers to fiddle with various settings and an I2C control protocol that lets you command the action from the badge.

Honorable Mentions

As usual, this contest had several Honorable Mentions categories — while we would have loved to put all of these SAOs into production, there’s only so much we can do before now and Spring.

[Jeremy Geppert]’s SAO LoRa Walkie Talkie was a judge favorite, for its simple good looks and the extra functionality that it brings to the table. [Scorch Works]’s SAO Infinity Mirror was absolutely beautiful to see in person, and makes a fantastic display when many of them get together. And [MakeItHackin]’s Skull of Fate SAO not only looked super when its eyes scan the room, but it could read your future as well!

Best Communication:

Using I2C to get SAOs to talk to the badge (or each other) was a big part of this contest, but we were also on the lookout for entries which helped facilitate badge-to-badge communications.

The Badge Tag NFC SAO from [Thomas Flummer] is a perfect example of both — it uses the NXP NTAG I2C Plus to provide 2K of read-write storage that can be accessed either internally through the I2C bus by the badge, or externally by an NFC device such as a smartphone. Modeled after a traditional conference name tag, this SAO was designed to make it easier for sharing your contact info with others during a busy con.

Infrared Communication SAO by [Alec Probst] brings infrared communications to the party, while looking like a classic TV remote. Though the original idea was to get this working in conjunction with the badge to act as a sort of TV-B-Gone, it ended up being used as part of a laser tag game during Supercon.

The GAT Nametag SC8 from [true] tackles communication on a more human level by providing a digital name tag for your badge. This compact board’s secret trick is the ability to make sure your name is legible no matter what its orientation thanks to a LIS2DW12 accelerometer that can detect the SAO’s orientation relative to the ground. RGB LEDs catch the viewer’s eye, but it’s the incredible firmware with seemingly endless options for text styling and tweaks that really set this build apart.

Light Show:

There’s little question that Featuring You! from [Nanik Adnani] is a perfect entry for this category. Nominally, it’s a little arrow you can write your name on and use a name tag. But power it up and you can dazzle anyone standing too close with its array of marching white LEDs. In a particularly nice touch, the circuit is implemented with only discreet components — no microcontroller.

The reDOT_RGB from [Alex] is a tiny 5×7 RGB LED matrix with a minuscule ATtiny816 MCU around the back to control the show. At just 8 x 11 mm, it’s hard to overstate just how tiny this SAO is.

While on the subject of tiny boards, the
Persistence of Vision POV Display is another entry not much larger than the SAO connector itself. Using a row of five tiny white LEDs and a ADXL345 accelerometer, [Michael Yim] is able to write text in mid-air thanks to the gullibility of the human eye.

Least Manufacturable:

Simple Add-Ons are essentially an art form, so it’s not surprising to find that they don’t often lend themselves to mass production. Several of the entries this yeah would be a real challenge to make in large numbers, but the one that really keeps us up at night is the ultra tiny smart SAO from [Alex].

This board is designed to fit inside the space between four header pins. Thanks, but no thanks.

Raising the Bar

Our hope this year was to elevate the Simple Add-On from a decorative piece of flair to something functional, and potentially, even useful. The results were incredible, and while we can only pick four winners this time around, every entry helped push the state-of-the-art forward in its own way. It’s hard to imagine how the SAO envelope can be pushed any further, but we can’t wait to find out.

A popular expression in the Linux forums nowadays is noting that someone “uses Arch btw”, signifying that they have the technical chops to install and use Arch Linux, a distribution designed to be cutting edge but that also has a reputation of being for advanced users only. Whether this meme was originally posted seriously or was started as a joke at the expense of some of the more socially unaware Linux users is up for debate. Either way, while it is true that Arch can be harder to install and configure than something like Debian or Fedora, thanks to excellent documentation and modern (but optional) install tools it’s no longer that much harder to run than either of these popular distributions.

For my money, the true mark of a Linux power user is the ability to install and configure Gentoo Linux and use it as a daily driver or as a way to breathe life into aging hardware. Gentoo requires much more configuration than any mainline distribution outside of things like Linux From Scratch, and has been my own technical white whale for nearly two decades now. I was finally able to harpoon this beast recently and hope that my story inspires some to try Gentoo while, at the same time, saving others the hassle.

A Long Process, in More Ways Than One

My first experience with Gentoo was in college at Clemson University in the late ’00s. The computing department there offered an official dual-boot image for any university-supported laptop at the time thanks to major effort from the Clemson Linux User Group, although the image contained the much-more-user-friendly Ubuntu alongside Windows. CLUG was largely responsible for helping me realize that I had options outside of Windows, and eventually I moved completely away from it and began using my own Linux-only installation. Being involved in a Linux community for the first time had me excited to learn about Linux beyond the confines of Ubuntu, though, and I quickly became the type of person featured in this relevant XKCD. So I fired up an old Pentium 4 Dell desktop that I had and attempted my first Gentoo installation.

For the uninitiated, the main thing that separates Gentoo from most other distributions is that it is source-based, meaning that users generally must compile the source code for all the software they want to use on their own machines rather than installing pre-compiled binaries from a repository. So, for a Gentoo installation, everything from the bootloader to the kernel to the desktop to the browser needs to be compiled when it is installed. This can take an extraordinary amount of time especially for underpowered machines, although its ability to customize compile options means that the ability to optimize software for specific computers will allow users to claim that time back when the software is actually used. At least, that’s the theory.

It didn’t work out too well for me and my Dell, though, largely because Dell of the era would put bottom-basement, obscure hardware in their budget computers which can make for a frustrating Linux experience even among the more user-friendly distributions due to a general lack of open-source drivers. I still hold a grudge against Dell for this practice in much the same way that I still refuse to use Nvidia graphics cards, but before I learned this lesson I spent weeks one summer in college with this Frankensteined computer, waiting for kernels and desktop environments to compile for days only to find out that there was something critical missing that broke my installations. I did get to a working desktop environment at one point, but made a mistake with it along the way and decided, based on my Debian experiences, that re-installing the operating system was the way to go rather than actually fixing the mistake I had made. I never got back to a working desktop after that and eventually gave up.

This experience didn’t drive me away from Gentoo completely, though. It was always at the back of my mind during any new Linux install I performed, especially if I was doing so on underpowered hardware that could have benefited from Gentoo’s customization. I would try it occasionally again and again only to give up for similar reasons, but finally decided I had gained enough knowledge from my decades as a Debian user to give it a proper go. A lot has changed in the intervening years; in the days of yore an aspiring Gentoo user had to truly start at the ground up, even going as far as needing to compile a compiler. These days only Gentoo developers take these fundamental steps, providing end users with a “Stage 3” tarball which contains the core needed to install the rest of Gentoo.

Bringing Out The Best of Old Hardware

And I do have a piece of aging hardware that could potentially benefit from a Gentoo installation. My mid-2012 Macbook Pro (actually featured in this article) is still a fairly capable machine, especially since I only really need a computer these days for light Internet browsing and writing riveting Hackaday articles. Apple long ago dropped support for this machine in macOS meaning that it’s no longer a good idea to run its native operating system. In my opinion, though, these older, pre-butterfly Macs are still excellent Linux machines aside from minor issues like finding the correct WiFi drivers. (It also can’t run libreboot, but it’s worth noting that some Macs even older than mine can.) With all of that in mind I got to work compiling my first Linux kernel in years, hoping to save my old Macbook from an e-waste pile.

There’s a lot expected of a new Gentoo user even with modern amenities like the stage 3 tarball (and even then, you have to pick a stage file from a list of around 50 options), and although the handbooks provided are fairly comprehensive they can be confusing or misleading in places. (It’s certainly recommended to read the whole installation guide first and even perform a trial installation in a virtual machine before trying it on real hardware.) In addition to compiling most software from source (although some popular packages like Firefox, LibreOffice, and even the kernel itself are available as precompiled binaries now), Gentoo requires the user to configure what are called USE flags for each package which specify that package’s compile options. A global USE flag file is also maintained to do things like build GNOME, Bluetooth, even 32-bit support into every package, while specific package USE flags are maintained in other separate files. For example, when compiling GIMP, users can choose which image formats they want their installation of GIMP to support. There’s a second layer of complexity here too as certain dependencies for packages can be “masked” or forbidden from being installed by default, so the user will also need to understand why certain things are masked and manually unmask them if the risk is deemed acceptable.

One thing that Gentoo has pioneered in recent years is the use of what it calls distribution kernels. These are kernel configurations with sane defaults, meaning that that they’ll probably work for most users on most systems on the first try. From there, users can begin tweaking the kernel for their use case once they have a working installation, but they don’t have to do that leg work during the installation process anymore. Of course, in true Gentoo fashion, you can still go through the process of configuring the kernel manually during the install if you choose to.

Aside from compiling a kernel, Gentoo also requires the user to make other fundamental choices about their installation during the install process that most other major distributions don’t. Perhaps the biggest one is that the user has to choose an init system, the backbone of the operating system’s startup and service management systems. Generally most distributions decide for you, with most larger distributions like Debian, Fedora, and Arch going with systemd by default. Like anything in the Linux world, systemd is controversial for some, so there are alternatives with OpenRC being the one with the most acceptance in the Gentoo world. I started out with OpenRC in my installations but found a few pieces of software that I use regularly don’t play well with it, so I started my build over and now use systemd. The user also can select between a number of different bootloaders, and I chose the tried-and-true Grub seeing no compelling reason to change at the moment.

In addition, there’s no default desktop environment, so you’ll also need to choose between GNOME, KDE, XFCE, any other desktop environment, or among countless window managers. The choice to use X or Wayland is up to you as well. For what it’s worth, I can at least report that GNOME takes about three times as long to compile as the kernel itself does, so keep that in mind if you’re traveling this path after me.

It’s also possible you’ll need to install a number of drivers for hardware, some of which might be non-free and difficult to install in Gentoo while they might be included by default in distributions like Ubuntu. And, like everything else, they’ll need to be compiled and configured on your machine as well. For me specifically, Gentoo was missing the software to control the fans on my MacBook Pro, but this was pretty easy to install once I found it. There’s an additional headache here as well with the Broadcom Wi-Fi cards found in older Macs, which are notoriously difficult pieces of hardware to work with in the Linux world. I was eventually able to get Wi-Fi working on my MacBook Pro, but I also have an 11″ MacBook Air from the same era that has a marginally different wireless chipset that I still haven’t been able to get to work in Gentoo, giving me flashbacks to my experience with my old Dell circa 2007.

This level of granularity when building software and an overall installation is what gives Gentoo the possibility for highly optimized installations, as every package can be configured for the user’s exact use case for every package down to the kernel itself. It’s also a rolling release model similar to Arch, so in general the newest versions of software will be available for it as soon as possible while a Debian user might have to wait a year or two for the next stable release.

A Few Drawbacks

It’s not all upside, though. For those without a lot of Gentoo experience (including myself) it’s possible to do something like spend a day and a half compiling a kernel or desktop environment only to find out a critical feature wasn’t built, and then have to spend another day and a half compiling it again with the correct USE flags. Or to use the wrong stage file on the first try, or realize OpenRC won’t work as an init system for a specific use case, or having Grub inscrutably be unable to find the installation. Also, don’t expect Gentoo to be faster out-of-the-box than Debian or Fedora without a customization effort, either; for me Gentoo was actually slower than Debian in my benchmarks without a few kernel and package re-compiles. With enough persistence and research, though, it’s possible to squeeze every bit of processing power out of a computer this way.

Personally, I’m not sure I’m willing to go through the amount of effort to migrate my workstations (and especially my servers) to Gentoo because of how much extra configuration is required for often marginal performance gains thanks to the power and performance capabilities of modern hardware. Debian Stable will likely remain my workhorse for the time being for those machines, and I wouldn’t recommend anyone install Gentoo who doesn’t want to get into the weeds with their OS. But as a Linux hobbyist there’s a lot to be said for using other distributions that are a little more difficult to use than Debian or even Arch, although I’d certainly recommend using a tool like Clonezilla to make backups of your installation from time to time so if you do make the same mistakes I made in college you can more easily restore your system. For me, though, I still plan to keep Gentoo on my MacBook Pro since it’s the machine that I tinker with the most in the same way that a classic car enthusiast wants to keep their vehicle on the road and running as well as it did when it was new. It also lets me end forum posts with a sardonic “I use Gentoo, btw” to flex on the Arch users, which might be the most important thing of all.

Cameras are a funny rabbit hole to fall down as a hacker, because we have well over a century of items to pick and choose from, a lot of which can be had for relative pennies. In my case I have more of them than I’d care to mention, mostly film cameras and 8mm movie cameras, but there are one or two that are entirely different. My first interest in electronics came through PAL televisions, so it’s hardly surprising that along the way I’ve also acquired more than one chunky old tube-based video camera. These devices are now long ago supplanted by their solid state replacements, but they retain a fascination for me as the mirror of the CRT-based TV sets I know so well. It’s time for a fascinating descent into the world of analogue video.

Electrons chasing light, chasing electrons

The basic mode of operation behind all but some of the very earliest electronic camera tubes is that an electron gun paints its raster of electrons onto a light-sensitive target, and the current flowing through the electron beam varies in proportion to the light at each particular point on the target. This can be used to create a voltage, which when combined with the various sync pulses makes a video signal that would be understood by a monitor. The various different types of tubes have names such as Iconoscope, Emitron, or Vidicon, and while the main differences between those various types of tube lie in the combination of materials and design of their targets. Successive generations of tube made improvements to sensitivity and noise performance, first combining photoemissive layers with electron multiplying layers to amplify the video signal in much the same way as a photomultiplier tube does, and then using photoconductive targets to vary the conductivity of the target depending on the light at a particular point.

Time for some real cameras

The tube camera I’ve owned the longest is probably the best to have the lid off and see its internals, it’s an RCA security camera from the mid 1980s. Very sturdily built in the USA, mine is the 625-line version for the European market. Opening it up there’s another echo of the CRT monitor, with the same deflection and signal panels you’d find at the other end of the chain. On top is a sync generator panel, which is far more than a simple pair of oscillators. Instead it’s stuffed with circuitry to produce the full standard sync timings with odd and even fields. Lifting out the sync panel reveals the tube, in this case a vidicon with a photoconductive target, encased in its magnetic focus and deflection coils. This is a monochrome camera, so everything is pretty easy to understand.

When a colour analogue video camera is explained, it usually starts with a diagram of a light path with a couple of bean splitters and a set of filters to supply red, green, and blue images to three different tubes. This produced those high quality broadcast images, but at the expense of significant expense and complexity. As colour home video equipment appeared in the 1970s there appeared a demand for single-tube colour cameras, and to that end the manufacturers came up with a variety of similar tubes with RGB stripe filters over their targets. A couple of these cameras have come my way, both of which have Panasonic Newvicon tubes. These differentiate between red, green, and blue parts of the image by their amplitudes, and while the image is definitely colour, I’d be lying if I said it was broadcast quality.

Here in 2024 there’s very little reason to use a tube camera unless as I am you are seeking a partcular aesthetic, That said, they remain a fun and forgotten piece of consumer electronics to experiment with, so pick one up and have a play should you see one. Looking at the whole system of both camera and monitor it’s possible to see the beauty of analogue television, in the way that every part of the system exists in perfect synchronisation. Imagine the TV sets of a whole country tuned to the same channel, and all synchronised to within a fraction of a microsecond, and you’ll see what I mean even though the idea of everyone watching the same show together is now more than faintly ridiculous.

If this has tickled your fancy, here’s more from the PAL coalface.

Header: Kyle Senior, CC BY-SA 4.0.

The name BeOS is one which tends to evoke either sighs of nostalgia or blank stares, mostly determined by one’s knowledge of the 1990s operating system scene. Originally released in 1995 by Be Inc., it was featured primarily on the company’s PowerPC-based BeBox computers, as well as being pitched to potential customers including Apple, who was looking for a replacement for MacOS. By then running on both PowerPC and x86-based systems, BeOS remained one of those niche operating systems which even the free Personal Edition (PE) of BeOS Release 5 from 1998 could not change.

As one of the many who downloaded BeOS R5 PE and installed it on a Windows system to have a poke at it, I found it to be a visually charming and quite functional OS, but saw no urgent need to use it instead of Windows 98 SE or 2000. This would appear to have been the general response from the public, as no BeOS revival ensued. Yet even as BeOS floundered and Be Inc. got bought up, sold off and dissected for its parts, a group of fans who wanted to see BeOS live on decided to make their own version. First called OpenBeOS and now Haiku, it’s a fascinating look at a multimedia-centric desktop OS that feels both very 1990s, but also very modern.

With the recent release of the R1 Beta 5 much has been improved, which raises the interesting question of how close Haiku is to becoming a serious desktop OS contender.

Writing A Haiku

Although some parts of BeOS (e.g. Tracker and Deskbar UI components) were open sourced with BeOS R5, for the most part the code of the Haiku project has been written from scratch. What helped a lot here was that even beyond the modular hybrid kernel the entire architecture of BeOS focused on modularity, allowing these developers in the early 2000s to gradually create new components to replace the proprietary ones in BeOS while testing them for regressions and bugs.

Even so, it took until September 2009 for the first Alpha release to be published, following eight years of intensive work. The first Beta came nine years later, at the end of September 2018, by which time support for x86_64 systems had also been added. This created an interesting inflection point, as only the 32-bit x86 version is fully binary compatible with BeOS R5, while the 64-bit version merely has compatible APIs. Unless you intend to run proprietary BeOS software this is probably not much of a concern, of course.

Currently, the Haiku project describes the OS as an ‘easy to use and lean open source operating system’, rather than limiting itself to being merely a way to run 1990s BeOS applications. The implications of this are covered in the general FAQ on the Haiku website along with a whole range of other common questions. The tl;dr is that while Haiku grew out of BeOS, its focus is mostly on maintaining BeOS’s unified vision for the desktop OS experience, which is why merely putting another skin around the Linux kernel would not have worked.

This drive to keep Haiku as a spiritual successor to BeOS can be seen in this and many other aspects, from its general appearance, to the name. Within BeOS the use of haiku (Japanese short-form poetry) was quite common, in particular in its NetPositive web browser error messages, such as:

Sites you are seeking
From your path they are fleeing
Their winter has come.

So What Does It Do?

Inevitably, when someone is confronted with Yet Another Open Source OS (YAOSO), the first question that comes to mind is what it does that another OS does not. After all, there are so many hobby OSes out there, all too often merely written to promote one’s pet language like Zig, Dart, NodeJS, Rust, D or another collection of letters that may or may not be infuriating to search for on the Internet. All of these OSes will tend to have a GUI, a file & internet browser, maybe someone has ported Tux Racer and some other bits of Linux userland, but with less functionality than the average Linux distribution these OS projects mostly spend a lot of time coming to terms with being less relevant than BeOS R5 and OS/2 Warp still are in the 2020s.

Here Haiku of course is a far cry from a hobby OS. Its kernel is inspired by the NewOS kernel, written by a former Be Inc. employee, it uses C++ and even GCC 2.x in places for that BeOS compatibility, but for new code you will be using a current C++ toolchain. You find the same GUI-centric user interface as BeOS had, though in the Terminal application you quickly find that it’s as familiar as any Linux or BSD shell, a pattern which persists in its POSIX compatibility. Meanwhile the overall user experience feels familiar to both old-school BeOS users and the average Windows user.

Although this is decidedly a personal matter, Haiku for me is a breath of fresh air compared to Yet Another Linux Distro (YALD) in the user interface consistency and the sheer snappiness. Booting Haiku takes seconds before you’re on the desktop, and the whole experience is that of a nimble single-user desktop system, rather like something such as Windows 98, except even faster and less crash-y. As for what it does when you’re on the desktop, it of course has the usual assortment of web browsers, office applications, multimedia players and editors, but as said earlier all of that is rather beside the point when the real question is whether you can use it as a daily driver.

This was also the point of a recent video by the Action Retro channel on YouTube, in which Haiku as a daily driver OS is attempted and found to be working quite well, even with video hardware acceleration in the Beta 4 release not implemented yet. My own experiences this year with Beta 4 and 5 mostly confirm this take, albeit mostly from the experience of a software developer doing some serious application porting.

Basically, how badly does Haiku break when you try to use it as a serious OS and port FFmpeg and Qt5-based applications to it?

No YALD, Just Haiku

While I am not sure how enthusiastic I am about swapping the Windows-style taskbar (incidentally replicated by most Linux GUIs) for the BeOS-style Deskbar, or the BeOS window decorations, you do get used to these differences. To get started with porting software you ideally use the pkgman package manager, which is reminiscent of FreeBSD’s pkg (and ports, incidentally). As I found out earlier this year when I ported my FFmpeg-based NymphCast project to Haiku, the OS is a lot closer to FreeBSD than Linux in many respects, including its file stat handling. This means no hacky lstat64() as on 64-bit dirty Linux platforms.

The whole string of dependencies required by the NymphCast project were all present and easily installed with pkgman, with the next challenge being that Haiku does not follow the Linux or BSD filesystem conventions. This is not unexpected, as it’s a desktop OS with absolutely no need to pretend that it dates back to an era when PDP-8s roamed the Earth. Instead it’s a multimedia-focused OS from the 1990s, with a filesystem that has a lot of added meta-data features, and a layout for installed applications and development files that is mostly non-confusing.

The only real showstoppers that I came across during the porting of NymphCast was a lack of IPv6 support in Haiku, and stability issues in Beta 4, but switching to Beta 5 (nightly) and improving IPv6 handling in my code fixed this. Running through the compilation and installation procedure again on Beta 5 recently, I encountered no stability issues, just an issue (#6400) in the SDL2 package for Haiku that makes SDL2-based applications still somewhat of a no-go until the responsible hack gets fixed, at least from how I understand the issue.

For fun, I also tried building the Qt5-based NymphCast Player client in Haiku R1 Beta 5, which succeeded with absolutely zero issues. This application ran fine, connected to NymphCast server and media server instances running elsewhere on the network just fine, allowing me to control them as I would have on any other OS. How perfectly boring.

Is It Boring Enough?

In the question of whether an OS can be a daily driver I feel that there’s a lot being implied. When I consider my own OS preferences, having used MS-DOS, Win3.x, Win9x, Win2k, etc., as well as desktop Linux since SuSE Linux 6.3 in ’99, the BSDs, OS X and MacOS (post-OS X), I feel strongly that a good daily driver OS is one that is so utterly boring and Just Works that you spend as little time as possible thinking about the OS, while maximizing the time you are productive, have fun playing games, being online, and so on.

Windows has become more and more boring in this regard until Windows 7, when it began to tailspin with Windows 8 and is with Windows 11 less functional than Windows 3.11, or Windows 9x during the delightful winmodem days. Similarly OS X/MacOS decided to lock down the OS with its rootless ‘feature’, among other unpopular decisions with power users and developers. Combined with the many bugs in MacOS (e.g. in its printer spool that existed since at least 10.4), I was happy to move to Windows 10, which is only infuriating due to the horrid Flat Design Language and completely unnecessary Settings app.

Although 1998 was supposed to be the Year of the Linux Desktop, the fact remains that Linux as a desktop OS is not boring, but a constant exercise in troubleshooting the window manager, desktop environment, audio subsystem, a kernel module that vanished after a kernel upgrade, an uncooperative driver, hunting down a non-existent driver for a new WiFi dongle and so on. This is why I use Linux on an almost daily basis, but run a Windows desktop system.

When it pertains to Haiku, I feel that there’s some real potential for it to become as boring as Windows 2000, or even Windows XP or 7. I will be using Haiku more the coming months and likely years as it matures towards Release 1, along with ReactOS and similar open source OSes that strive to provide the user with the most boring and pleasantly unremarkable desktop experience possible.

So far in this series, we’ve talked about man-made byproducts — Fordite, which is built-up layers of cured car enamel, and Trinitite, which was created during the first nuclear bomb test.

But not all byproducts are man-made, and not all of them are basically untouchable. Some are created by Mother Nature, but are nonetheless dangerous. I’m talking about fulgurites, which can form whenever lightning discharges into the Earth.

It’s likely that even if you’ve seen a fulgurite, you likely had no idea what it was. So what are they, exactly? Basically, they are natural tubes of glass that are formed by a fusion of silica sand or rock during a lightning strike.

Much like Lichtenberg figures appear across wood, the resulting shape mimics the path of the lightning bolt as it discharged into the ground. And yes, people make jewelry out of fulgurites.

Lightning Striking Again

Lightning is among the oldest observed phenomena on Earth. You probably know that lightning is just a giant spark of electricity in the atmosphere. It can occur between clouds, the air, or the ground and often hits tall things like skyscrapers and mountaintops.

Lightning is often visible during volcanic eruptions, intense forest fires, heavy snowstorms, surface nuclear detonations, and of course, thunderstorms.

In lightning’s infancy, air acts as an insulator between charges — the positive and negative charges between the cloud and the ground. Once the charges have sufficiently built up, the air’s insulating qualities break down and the electricity is rapidly discharged in the form of lightning.

When lightning strikes, the energy in the channel briefly heats up the air to about 50,000 °F, which is several times the surface of the Sun. This makes the air explode outward. As the shock wave’s pressure decreases, we hear thunder.

Of Sand and Rock and Other Stuff

Fulgurites, also known as fossilized lightning, don’t have a fixed composition: they are composed of whatever they’re composed of at the time of the lightning strike. Four main types of fulgurites are officially recognized: sand, soil, caliche (calcium-rich), and  rock fulgurites. Sand fulgurites can usually be found on beaches or in deserts where clean sand devoid of silt and clay dominates. And like those Lichtenberg figures, sand fulgurites tend to look like branches of tubes. They have rough surfaces comprised of partially-melted grains of sand.

When sand fulgurites are formed, the sand rapidly cools and solidifies. Because of this, they tend to take on a glassy interior. As you might imagine, the size and shape of a fulgurite depends on several factors, including the strength of the strike and the depth of the sand being struck. On average, they are 2.5 to 5 cm in diameter, but have been found to exceed 20 cm.

Soil fulgurites can form in a wide variety of sediment compositions including clay-, silt-, and gravel-rich soils as well as leosses, which are wind-blown formations of accumulated dust. These also appear as tubaceous or branching formations, vesicular, irregular, or a combination thereof.

Calcium-rich sediment fulgurites have thick walls and variable shapes, although it’s common for multiple narrow channels to appear. These can run the gamut of morphological and structural variation for objects that can be classified as fulgurites.

Rock fulgurites are typically found on mountain peaks, which act as natural lightning rods. They appear as coatings or crusts of glass formed on rocks, either found as branching channels on the surface, or as lining in pre-existing fractures in the rock. They are most often found at the summit or within several feet of it.

Fact-Finding Fulgurites

Aside from jewelry and such, fulgurites’ appeal comes in wherever they’re found, as their presence can be used to estimate the number of lightning strikes in an area over time.

Then again there’s some stuff you may not necessarily want to use in jewelry making. Stuff that can be found in the dark, dank corners of the Earth. Stay tuned!

Probably not too many people around the world celebrated November 1st, 2023, but on this momentous date FreeBSD celebrated its 30th birthday. As the first original fork of the first complete and open source Unix operating system (386BSD) it continues the legacy that the Berkeley Software Distribution (BSD) began in 1978 until its final release in 1995. The related NetBSD project saw its beginnings somewhat later after this as well, also forking from 386BSD. NetBSD saw its first release a few months before FreeBSD’s initial release, but has always followed a different path towards maximum portability unlike the more generic nature of FreeBSD which – per the FAQ – seeks to specialize on a limited number of platforms, while providing the widest range of features on these platforms.

This means that FreeBSD is equally suitable for servers and workstations as for desktops and embedded applications, but each platform gets its own support tier level, with the upcoming version 15.x release only providing first tier support for x86_64 and AArch64 (ARMv8). That said, if you happen to be a billion-dollar company like Sony, you are more than welcome to provide your own FreeBSD support. Sony’s Playstation 3, Playstation 4 and Playstation 5 game consoles namely all run FreeBSD, along with a range of popular networking and NAS platforms from other big names. Clearly, it’s hard to argue with FreeBSD’s popularity.

Despite this, you rarely hear people mention that they are running FreeBSD, unlike Linux, so one might wonder whether there is anything keeping FreeBSD from stretching its digital legs on people’s daily driver desktop systems?

In The Beginning There Was UNIX

Once immortalized on the silver screen with the enthusiastically spoken words “It’s a UNIX system. I know this.”, the Unix operating system (trademarked as UNIX) originated at Bell Labs where it initially was only intended for internal use to make writing and running code for systems like the PDP-11 easier. Widespread external use started with Version 6, but even before that it was the starting point for what came to be known as the Unix-based OSes:

After FreeBSD and NetBSD forked off the 386BSD codebase, both would spawn a few more forks, most notable being OpenBSD which was forked off NetBSD by Theo de Raadt when he was (controversially) removed from the project. From FreeBSD forked the Dragonfly BSD project, while FreeBSD is mostly used directly for specific applications, such as GhostBSD providing a pleasant desktop experience with preconfigured desktop and similar amenities, and pfSense for firewall and router applications. Apple’s Darwin that underlies OS X and later contains a significant amount of FreeBSD code as well.

Overall, FreeBSD is the most commonly used of these OSS BSDs and also the one you’re most likely to think of when considering using a BSD, other than OS X/MacOS, on a desktop system.

Why FreeBSD Isn’t Linux

The Linux kernel is described as ‘Unix-like’, as much like Minix it does not directly derive from any Unix or BSD but does provide some level of compatibility. A Unix OS meanwhile is the entirety of the tools and applications (‘userland’) that accompany it, something which is provided for Linux-based distributions most commonly from the GNU (‘GNU is Not Unix’) project, ergo these Linux distributions are referred to as GNU/Linux-based to denote their use of the Linux kernel and a GNU userland. There is also a version of Debian which uses GNU userland and the FreeBSD kernel, called Debian GNU/kFreeBSD, alongside a (also Unix-like) Hurd kernel-based flavor of Debian (Debian GNU/Hurd).

In terms of overall identity it’s thus much more appropriate to refer to ‘Linux kernel’ and ‘GNU userland’ features in the context of GNU/Linux, which contrasts with the BSD userland that one finds in the BSDs, including modern-day MacOS. It is this identity of kernel- and userland that most strongly distinguishes these various operating systems and individual distributions.

These differences result in a number of distinguishing features, such as the kernel-level FreeBSD jail feature that can virtualize a single system into multiple independent ones with very little overhead. This is significantly more secure than a filesystem-level chroot jail, which was what Unix originally came with. For other types of virtualization, FreeBSD offers bhyve, which can be contrasted with the kernel-based virtualization machine (KVM) in the Linux kernel. Both of these are hypervisor/virtual machine managers that can run a variety of guest OSes. As demonstrated in a comparison by Jim Salter, between bhyve and KVM there is significant performance difference, with bhyve/NVMe on FreeBSD 13.1 outperforming KVM/VirtIO on Ubuntu 22.04 LTS by a large margin.

What this demonstrates is why FreeBSD for storage and server solutions is such a popular choice, and likely why Sony picked FreeBSD for its customized Playstation operating systems, as these gaming consoles rely heavily on virtualization, as with e.g. the PS5 hypervisor.

OpenZFS And NAS Things

A really popular application of FreeBSD is in Network-Attached Storage (NAS), with originally FreeNAS (now TrueNAS) running the roost here, with iXsystems providing both development and commercial support. Here we saw some recent backlash, as iXsystems announced that they will be adding a GNU/Linux-based solution (TrueNAS SCALE), while the FreeBSD-based version (TrueNAS CORE) will remain stuck on FreeBSD version 13. Here The Register confirmed with iXsystems that this effectively would end TrueNAS on FreeBSD. Which wouldn’t be so bad if performance on Linux wasn’t noticeably worse as covered earlier, and if OpenZFS on Linux wasn’t so problematic.

Unlike with FreeBSD where the ZFS filesystem is an integral part of the kernel, ZFS on Linux is more of an afterthought, with a range of different implementations that each have their own issues, impacting performance and stability. This means that TrueNAS on Linux will be less stable, slower and also use more RAM. Fortunately, as befits an open source ecosystem, an alternative exists in the form of XigmaNAS which was forked from FreeNAS and follows current FreeBSD fairly closely.

So what is the big deal with ZFS? Originally developed by Sun for the Solaris OS, it was released under the open source CDDL license and is the default filesystem for FreeBSD. Unlike most other filesystems, it is both the filesystem and volume manager, which is why it natively handles features such as RAID, snapshots and replication. This also provides it with the ‘self-healing’ ability where some degree of data corruption is detected and corrected, without the need for dedicated RAID controllers or ECC RAM.

For anyone who has had grief with any of the Ext*, Reiserfs or other filesystems (journaled or not) on Linux, this probably sounds pretty good, and its tight integration into FreeBSD again explains why it’s it’s such a popular choice for situations where data integrity, performance and stability are essential.

FreeBSD As A Desktop

It’s probably little surprise that FreeBSD-as-a-desktop is almost boringly similar to GNU/Linux-as-a-desktop, running the Xorg server and one’s desktop environment (DE) of choice. Which also means that it can be frustratingly broken, as I found out while trying to follow the instructions in the FreeBSD handbook for setting up Xfce. This worked about as well as my various attempts over the years to get to a working startx on Debian and Arch. Fortunately trying out another guide on the FreeBSD Foundation site quickly got me on the right path. This is where using GhostBSD (using the Mate DE by default) is a timesaver if you want to use a GUI with your FreeBSD but would like to skip the ‘deciphering startx error messages’ part.

After installation of FreeBSD (with Xfce) or GhostBSD, it’s pretty much your typical desktop experience. You got effectively the same software as on a GNU/Linux distro, with FreeBSD even providing binary (user-space) compatibility with Linux and with official GPU driver support from e.g. NVidia (for x86_64). If you intend to stick to the desktop experience, it’s probably quite unremarkable from here onwards, minus the use of the FreeBSD pkg (and source code ports) package manager instead of apt, pacman, etc.

Doing Some Software Porting

One of my standard ways to test out an operating system is to try and making some of my personal open source projects run on it, particularly NymphCast as it takes me pretty deep through the bowels of the OS and its package management system. Since NymphCast already runs on Linux, this should be a snap, one would think. As it turns out, this was mostly correct. From having had a play with this on FreeBSD a few years ago I was already aware of a few gotchas, such as the difference between GNU make and BSD make, with the former being available as the gmake package and command.

Another thing you may want to do is set up sudo (also a package) as this is not installed by default. After this it took me a few seconds to nail down the names of the dependencies to install via the FreeBSD Ports site, which I added to the NymphCast dependencies shell script. After this I was almost home-free, except for some details.

These details being that on GhostBSD you need to install the GhostBSD*-dev packages to do any development work, and after some consulting with the fine folks over at the #freebsd channel on Libera IRC I concluded that using Clang (the system default) to compile everything instead of GCC would resolve the quaint linker errors, as both apparently link against different c++ libraries (clang/libc++ vs gcc/libstdc++).

This did indeed resolve the last issues, and I had the latest nightly of NymphCast running on FreeBSD 14.1-RELEASE, playing back some videos streaming from Windows & Android systems. Not that this was shocking, as the current stable version is already up on Ports, but that package’s maintainer had make similar tweaks (gmake and use of clang++) as I did, so this should make their work easier for next time.

FreeBSD Is Here To Stay

I’ll be the first to admit that none of the BSDs really were much of a blip on my radar for much of the time that I was spending time with various OSes. Of course, I got lured into GNU/Linux with the vapid declarations of the ‘Year of the Linux Desktop’ back in the late 90s, but FreeBSD seems to always have been ‘that thing for servers’. It might have been just my fascination with porting projects like NymphCast to other platforms that got me started with FreeBSD a few years ago, but the more you look into what it can do and its differences with other OSes, the more you begin to appreciate how it’s a whole, well-rounded package.

At one point in time I made the terrible mistake of reading the ‘Linux From Scratch’ guide, which just reinforced how harrowingly pieced together Linux distributions are. Compared to the singular code bases of the BSDs, it’s almost a miracle that Linux distributions work as well as they do. Another nice thing about FreeBSD is the project structure, with no ‘Czar for life’, but rather a democratically elected core leadership. In the 30-year anniversary reflection article (PDF) in FreeBSD Journal the way this system was created is described. One could say that this creates a merit-based system that rewards even newcomers to the project. As a possible disadvantage, however, it does not create nearly the same clickbait-worthy headlines as another Linus Torvalds rant.

With widespread industry usage of FreeBSD and a strong hobbyist/enthusiast core, it seems fair to say that FreeBSD’s future looks brighter than ever. With FreeBSD available for easy installation on a range of SBCs and running well in a virtual machine, it’s definitely worth it to give it a try.

Even if you are relatively young, you can probably think back on what TV was like when you were a kid and then realize that TV today is completely different. Most people watch on-demand. Saturday morning cartoons are gone, and high-definition digital signals are the norm. Many of those changes are a direct result of the Internet, which, of course, changed just about everything. Ham radio is no different. The ham radio of today has only a hazy resemblance to the ham radio of the past. I should know. I’ve been a ham for 47 years.

You know the meme about “what people think I do?” You could easily do that for ham radio operators. (Oh wait, of course, someone has done it.) The perception that hams are using antique equipment and talking about their health problems all day is a stereotype. There are many hams, and while some of them use old gear and some of them might be a little obsessed with their doctor visits, that’s true for any group. It turns out there is no “typical” ham, but modern tech, globalization, and the Internet have all changed the hobby no matter what part of it you enjoy.

Radios

One of the biggest changes in the hobby has been in the radio end. Hams tend to use two kinds of gear: HF and VHF/UHF (that’s high frequency, very high frequency, and ultra-high frequency). HF gear is made to talk over long distances, while VHF/UHF gear is for talking around town. It used to be that a new radio was a luxury that many hams couldn’t afford. You made do with surplus gear or used equipment.

Globalization has made radios much less expensive, while technological advances have made them vastly more capable. It wasn’t long ago that a handy-talkie (what normal folks would call a walkie-talkie) would be a large purchase and not have many features. Import radios are now sophisticated, often using SDR technology, and so cheap that they are practically disposable. They are so cheap now that many hams have multiples that they issue to other hams during public service events.

Because these cheap ($20-$40) radios often use SDR, they can even be hacked. These radios aren’t typically the highest quality if you are used to repurposed commercial gear, but when you can replace the radio for $20, it hardly matters.

HF radios are a different story. Thanks to software-defined radio, superpowerful computers, and FPGAs, even relatively inexpensive HF radios have features that would have seemed like magic when I first got my license.

While some hams like to build gear or use simple or older gear, modern transceivers, like the IC-7300 from Icom shown here, have incredible RF filtering done in software, spectrum analyzers, and scopes built in. The 7300, by the way, isn’t considered a “top of the line” radio by any means. But it has features that would have been a dream on a state of the art unit before the advent of DSP.

Having these kind of tools changes how you operate. In the old days, you’d tune around to see if you could hear anyone. Now, glancing at the screen will show you all the signals on a band and how strong they are. Touch one, and you tune it in immediately. Digital noise reduction is very helpful these days with so much interference, and, of course, you can control the whole thing from a PC if you want to.

The receivers are exceptional compared to what even a high-end radio would offer a few decades ago. Specialized filters used to be expensive and limited in options. Now, you can design any filter you want on the fly and it will be nearly perfect.

Granted, these radios aren’t in the impulse buy category like the handheld radios. Still, you can find them new for around $1,000 and used for less. There are also other similar radios for much less. Just as you can buy imported handheld VHF and UHF radios, there are imported HF radios that put out a lower wattage (20 watts vs 100 watts is typical). These still have plenty of features, and you can get them for about half the cost of the name-brand 100W rigs. [K4OGO] has a video (see below) about several popular radios in that price range and you’ll notice that many of them have similar displays.

Digital Modes

Paradoxically, you might not need as hot a receiver, or as big of an antenna, or as much power as you might think. Hams have long known that voice communication is inefficient. Morse code could be the earliest form of digital radio communication, allowing a proficient operator to copy signals that would never make a voice contact. However, hams have also long used other digital modes, including TeleType, which is more convenient but less reliable than a good Morse code operator.

That changed with computer soundcards. Your computer can pull signals out of a hash that you would swear was nothing but noise. Modern protocols incorporate error detection and correction, retries, and sophisticated digital signal processing techniques to pull information from what appears to be nowhere.

What kind of sound card do you need? Almost any modern card will do it, but if you have the Icom IC-7300 pictured above, you don’t need one. It turns out, it is a sound card itself. When you plug it into a PC, it offers audio in and out for ham radio programs. It can even send IQ signals directly to the PC for common SDR programs to work with.

Some digital modes are conversational. You can use them like you might a radio-based chat room to talk to people you know or people you’ve just met. However, some modes are more specialized and optimized to make and confirm contact.

Computer Logging

There was a time when every ham had a log book — a notebook to write down contacts — and a stack of QSL cards. Operators would exchange cards in the mail to confirm contact with each other. Many of the cards were interesting, and collecting enough cards could earn an award (for example, working all 50 US states or over 100 foreign countries).

Things are different now. Many people use a computer to track their contacts. While you could just use a spreadsheet, there are many ways to log and — more importantly — share logs online.

The advantage is that when you make a contact and enter into the system, it can match your entry up with your partner’s entry and immediately confirm the contact. This isn’t perfect, because there are several systems people use, but it is possible to interoperate between them. No more waiting for the mail.

DX and Propagation

I mentioned that having a display of the entire ham band changes how you operate. But there is even more help out there. Many people enjoy working rare foreign stations or special event stations held at parks or historical locations. These days, if you hear a station like that on the air, you can report it on the Internet so other people can find them. In some cases, the operator will report themselves, even.

Suppose you want to make contact with someone in Kenya because you haven’t done it, and you are working towards an award that counts how many countries you’ve contacted. Instead of searching endlessly, you can simply watch the Internet for when a station from that country appears. Then turn on your radio, use the digital tuning to go exactly to their frequency, and try your luck.

Of course, radio propagation isn’t foolproof. But you can use beacons to determine how propagation is near you. There are many tools to manipulate the beacon data to better understand radio conditions. In fact, if you use digital modes or Morse code, you can find out who’s hearing you on the Internet, which can be very useful.

Why Not You?

Some old hams say the Internet is ruining ham radio. I say it is changing ham radio just like it has changed virtually everything else. Some of those changes aren’t that drastic anyway. For years, people chasing awards, trying to work long distances, or participating in contests have very short contacts. You typically would exchange your name, location, and how strong your signal is and then make way for the next person to make contact. The digital mode FT8 automates all that. It is true that it isn’t very personal, but those kinds of contacts were never personal to start with.

What’s more is that you don’t have to use any of this if you don’t want to. I operate a lot of Morse code with no mechanical assistance. If I hear a big pileup, I might go look at the computer to see who has been spotted on that frequency. But I don’t have to. I could figure it out the old-fashioned way.

Hams work with advanced signal processing software, satellites, moon bounce, support communities, design antennas, foster school education, work during disasters, and push the envelope on microwave communication. No matter what your interests, there’s something you’ll enjoy doing. For many years now, you don’t even have to pass a test for Morse code, so if you didn’t want to learn the code, you don’t have to.

In many ways, hams were the original hackers, and you might be surprised by how many hackers you know who are hams already. I don’t know what ham radio will look like in the year 2100, but I know it will be pushing the limits of technology, somehow.