NetBSD Planet

I’ve talked again recently about my frustrations with certain Linux desktop fans directing their ire not at commercial software companies that are making the lives of people who don’t have a choice that much worse, but instead towards… the people who’s lives they’re making that much worse. Even if you think you’re in the right, it’s not how one wins friends and influences people, as a certain Dale Carnegie would have said.

But I have taken pains to point out in such posts that my reservations about the abrasive attitude of some amateur Linux users doesn’t extend to their underlying OS of choice. This I think is worth underscoring from time to time, just as it’s important not to blame electronic victims.

Linux on the desktop is awesome for me for a bunch of reasons, many of which are shared with FreeBSD and NetBSD, my favourite OSs. But the one reason I want to discuss here specifically is permissions. And for once I’m not talking about chmod(1), or chown(1), or chattr(1).

Rebooting my FreeBSD machine into Fedora to play a game with Clara last week made me realise something that seems so obvious in retrospect, but I only just recognised. I don’t need permission to use this computer. I turn it on, and use whatever I want, however I want.

When I install certain software for people, or OSs at work, there’s infrastructure in place to ensure you have permission to use it. There are product keys, serial numbers, activation servers, per seat or per core licensing, price lists full of complicated SKUs, and more. In some cases entire additional layers of hosting are required to install, activate, report, and track this stuff; hosting that could be put towards something technically productive instead.

It’s not even just regarding a proof of purchase, this administrative overhead often extends over the lifetime of your install. Your machine needs to be phoning home to somewhere, it needs permission to download and use certain features, it’s regularly polled to ensure it’s operating as the vendor likes, and so on. Your machine has to be in the system. Or in other words, it needs permission.

Linux isn’t entirely free of this concept either. My home Fedora partitions need permission to access an update server to remain secure, for example. But that’s a process I ultimately have agency over; I could potentially swap that repo out for something else if I wanted. Point is, I don’t need to seek permission from the Fedora Project, or the FreeBSD Foundation, and the NetBSD Foundation, to use this computer. I install them, I use them, and I update them.

That perceived lack of control, or the need to request permission, is what has made macOS feel increasingly alien to me of late, and what has made Windows feel downright hostile in a way that’s hard to put into words. I’ve talked before about feeling more like a guest on Macs thesedays, and how cleaning up a Windows machine has gone from removing OEM bloatware to disabling core features of the OS.

These OSs have always presented a Faustian bargain to an extent, but whether it’s Apple forcefully and quietly re-enabling toxic features, or Windows predictably requiring new installs and accounts to be registered with a Microsoft profile, it’s been amped up to 11 of late. Yes it’s always been bad, but now it’s worse.

On my FreeBSD desktop, my NetBSD laptops, my Fedora game machine, or any of my servers, this is an absolute non issue. I can turn my PC on, and be answerable to nobody. I don’t need to report in. I don’t need permission to unlock the door, so to speak. I just start them, and go about my day.

I can’t tell you how relieved this makes me.

By Ruben Schade in Sydney, 2025-03-31.

Hi! I've been trying to get Netbsd to boot on this card. It's the latest version of the card where the SPI chip has been removed. I have tried every way I can think of, both bootable image spesific for this board and generic arm64 with u-boot from pkgin. The HW is ok. I can boot other os images. Anyone got this running with NetBSD?

I love virtual machines! They’re a computer, in my computer. They let me tinker, test, and build things, then blow them away and start from scratch. We can even run different architectures on our computers, albeit with a performance penalty. We can emulate an entire machine from scratch, or use hypervisors to expose the underlying virtualisation support of our host machine to make mini machines. My love of VMs is what got me my current job. VMs! They’re great!

But I started using VMs out of… wait for it… nostalgia. I got an iMac DV for Xmas in 1999 that came with a copy of Connectix Virtual PC. In spite of the fact I had a perfectly functional HP PC on my desk, I tinkered with DOS, OS/2, the x86 version of BeOS, and Windows for Workgroups using the Mac because Virtual PC was so much fun. It wasn’t the first desktop virtualisation software package, but it was the first I tried that made the entire field approachable to tinkerers. I needed my first hard drive upgrade because of that software, something I’m sure my parents were thrilled about.

Anyway, rambling introductions aside, my love of this tech has persisted to this day. I run a NetBSD server at home with Xen, and FreeBSD with bhyve. Until recently I had VMware ESXi as well to keep my skills current, before it was Broadcom’d. Even FreeBSD jails scratch that itch to an extent tools like Docker simply don’t. There’s probably a post about that waiting to be written.

And on my Mac laptop, since at least 2006, I’ve have a series of different emulators and hypervisors for running all the things I care about. Some of the disk images for these VMs are older than the hosts that run them, and have been carried from machine to machine for years. A few are older than the computers they emulated were when I first made the VMs, which is ridiculous to contemplate.

But while I’ve had a regimented and structured approach to dealing with server VMs for years—in no small part thanks to the majesty that is OpenZFS—my approach to desktop VMs has always been a mess. Over the last few years I stopped using graphical tools for my retrocomputer and small VMs in lieu of directly writing scripts and configs for QEMU, 86box, and the like. But these were all mixed into an amorphous folder of disk images and configs. I was always losing track of what disk image went with what, what configs were the current ones, and what scripts needed to be invoked. And as for driver disks and other obscure notes? Fuhgeddaboutit.

In what must come as the most painfully obvious solution known to engineers everywhere, I created a little structure for these VMs and standardised on launch scripts! It looks like this:

.
├── 86box Commodore PC 30 III
│   ├── config.cfg
│   ├── disks/
│   ├── docs/
│   ├── hdd.img
│   └── launch.sh
[...]
├── QEMU NetBSD sparc64
│   ├── disks/
│   ├── docs/
│   ├── hdd.img
│   └── launch.sh
[...]
└── launch.sh

Each virtual machine has its own directory, with a configuration file for the chosen emulator, a disks folder for installation images or drivers, a docs folder for PDFs and notes pertaining to it, one or more boot disk images, and a launch script with a consistent name. The launch script calls the appropriate emulator, either with command like flags as is the case with QMEU, or to reference a config file for 86box. Finally, the root launch script merely lists the directories by name, so I can launch their launch scripts.

Including installation media, docs, and the launch scripts in little bundles like this has been massive for collecting my thoughts and learnings about this stuff, rather than having to go into my notes elsewhere, or remembering what specific driver I downloaded in my massive archive is the appropriate one. My next silly extension is to have an installation media folder separately, and use symlinks.

Anyway! A bit of a shaggy-dog story for this one, but it was fun. Turns out being organised is useful, dontchaknow.

By Ruben Schade in Sydney, 2025-03-22.

Done early!

• Other Networks: A Radical Technology Sourcebook.  For pre-order, and excerpts are available.  I think this is a unique book; catch the limited print while you can.  (via)
• Vim Spellcheck Cheat Sheet.
• NetBSD on Raspberry Pi!
• State of virtualizing the BSDs on Apple Silicon.
• From ACS to Altair: The Rise of the Hobby Computer.
• Walter Bright’s Classic Empire, Empire Deluxe, and original author Walter Bright.  (incidentally, original available as a port/pkg/port)
• Standalone Digital Scratch Instrument.
• Debugging aids for pf firewall rules [on FreeBSD].  For reference.
• Free MWL excerpts/books.  (via)
• If you’re going to GDC, there’s a Roguelike Celebration meetup on the 18th.
• UNIX advertisements.  (via)  From that page:

There was a time in the mean old days of Windows where it was a basic requirement to reformat and reinstall it periodically, lest the performance and reliability go to absolute crap. Maybe the way I used machines made the situation more acute, but I always found reinstalling Windows and/or DOS made whatever machine running it feel faster, and would result in fewer crashes. I’ve raised this on social media before, and it wasn’t an uncommon practice.

Thesedays, I have FreeBSD and NetBSD servers and hosts that have file creation dates old enough that they could learn how to drive and drink, though hopefully not both concurrently. Linux as well. I’ve been shocked to discover an old FreeBSD jail, or a NetBSD Xen VM, or even an old Debian services box that’s still kicking around a decade or more after I initially made it. This also isn’t unusual; I suspect much of the modern Web would immediately collapse if abandoned servers in cupboards were taken offline! Also if all my trans and queer friends were to suddenly abandon their infosec posts, for what it’s worth.

Desktops though are a different story. For one thing, desktop and workstation have entirely different spellings to servers. For whatever reason I’ve continued to wipe and reinstall my machines every year. I don’t entirely know why, as will be evident by point three here:

• It forces the machine to not have too much state. In other words, there aren’t any hidden surprises or things I haven’t accounted for outside my backup routine. This helps to ensure I keep my data safe, because I don’t have a choice.

• Desktops and laptops are subjected more to the rigours of the real world than servers, and as such, (A) accumulate more random stuff, and (2) carry a greater risk for said randomness to cause problems. My servers aren’t getting constant updates for terrible video conferencing software that rhymes with Beams.

• On desktop Linux where I run games with an NVIDIA card (something I hope to replace with a Radeon or Arc card one day) it fixes accumulated bugs. I’ve never had an issue with the binary blob drivers on FreeBSD, but they spook penguins. Maybe its another of those licencing kernel things which I don’t want to get into here.

• On the BSDs, it gives me that fresh linen feeling. It’s almost certainly not necessary.

My rule of thumb, or whatever digits I’m using to enter commands, is to always do clean installs in lieu of upgrades. When another macOS update comes, I reinstall on the previously newer version (I’m tired of being an Apple beta tester). For FreeBSD that’s a major point release. And so on.

We run these machines every day of our lives. They let us play games, do our jobs, and are a source of tinkering for those of us who grew up loving this stuff. Wiping may no longer be strictly required, but it makes these daily interactions nicer. So why not?

Now if only I could back up my brain, perform a clean reinstall, and only copy back memories and knowledge that are useful. I really don’t need to remember the names of a bunch of celebrities, or how to use an awful oven in a rental that I’ve long since moved out from. Or I dunno, maybe remembering a crass actor and the fact this oven needed to have its temperature dial turned twenty degrees further than it should made me into the person I am today! That’s a scary thought.

By Ruben Schade in Sydney, 2025-03-15.

Both @matdevdug and my own work Mac laptop reminded me of something recently. A mood, and a feeling, so far gone from my current state of mind that it feels like an age ago. We used to look foward to Mac OS X releases!

I literally used to take my SLR down to Apple retailers in Singapore to document each launch, as I did here for Leopard in 2007. Wait bummer, a bunch of those photos from that time period no longer work. I’d better fix that. When I was studying in Adelaide, I’d call up Apple in Crows Nest in Sydney to secure my preorder for the next release, with money that I should probably have been spending on trifling things like food.

New Mac OS X releases were a big deal, because you felt like you were getting something. Each release introduced a new feature that was legitimitely useful, or refined the UI in a meaningful way, or let us do something on our Mac we couldn’t do when we bought it. It felt like, in the most literal sense, an upgrade. We’d chuckle at Apple telling Microsoft to “start their photocopiers” when a new release launch, much as Android blatenely aped iOS for many years. Windows was ubiquitous. The Mac was special.

I think macOS Yosemite was the last release I can remember by name and version number. Thesedays, my Macs spam me with these messages, and I feel either indifference or mild dread:

I suppose part of this comes down to getting older, and having different expectations for what my Macs will need to do. Gone are the days where I’d spend all night tinkering and building software for my Apple machines. They’re now for “work”, which means I have precious time to be tinkering, upgrading, and potentially breaking something. Time spent doing this could be better allocated basically anywhere else.

My inclination now is to assume all new releases have features I don’t need or care about. The few times I have checked out an info page, it’s about AI or some other nonsense that most of us don’t care about or want. When there is a substantiative change, like System Preferences becoming System Settings, the execution was so horrendus that I felt the opposite of imposter syndrome for my own designs for the first time in years. Wow, my designs suck, but at least I did a better job than that!

Truthfully though—as opposed to all those other times!?—my heart and mind left the platform many years ago for greener pastures. This was much a push as it was a pull; Fedora on the desktop makes a decent game machine, as does FreeBSD a workstation, and NetBSD a laptop OS. They now have features I miss when I go back to my Mac. Likewise, Tim Apple isn’t the same as Apple Computer Inc, and especially so under the new administration. They lost their software quality mojo years ago, and I’m increasingly convinced they’ve since lost their soul. I don’t relish in this; it sucks.

The Mac is still a vastly better platform than Windows for “work”, and I feel nothing but relief every time I stroll by those PC laptops in electronics stores, with their flimsy plastic construction, terrible screens, and whatever a Copilot is. But it’s still a bit sad that the high water mark for the Mac is now firmly in the past.

Upgrades are a disruptive but necessary evil to ensure one gets security patches, and another bank of switches to toggle off. That’s it.

By Ruben Schade in Sydney, 2025-03-11.

For decades, Linux and BSD have stood as two dominant yet fundamentally different branches of the Unix-like operating system world. While Linux distributions, such as Debian, Ubuntu, and Fedora, have grown to dominate the open-source ecosystem, BSD-based systems like FreeBSD, OpenBSD, and NetBSD have remained the preferred choice for those seeking security, performance, and licensing flexibility. But what if you could combine the best of both worlds—Debian’s vast package ecosystem with FreeBSD’s robust and efficient kernel?

Enter Debian GNU/kFreeBSD, a unique experiment that merges Debian’s familiar userland with the FreeBSD kernel, offering a hybrid system that takes advantage of FreeBSD’s technical prowess while maintaining the ease of use associated with Debian. This article dives into the world of Debian GNU/kFreeBSD, exploring its architecture, installation, benefits, challenges, and real-world applications.

↫ George Whittaker

More of a list of upsides and downsides than an actual in-depth article, but that doesn’t make it any less interesting. There’s a variety of attempts out there to somehow marry the Linux and BSD worlds, and each of them takes a unique approach. I’m not sure the Debian userland with a FreeBSD kernel is the way to go, though, and it seems I’m not alone – Debian GNU/kFreeBSD was officially dropped from Debian in 2015 or so, and after a flurry of unofficial activity in 2019, it was discontinued completely in 2023 due to a lack of activity and developer interest. Odd that the source article doesn’t mention that.

If you’re still interested in a combination of Linux and BSD, I’d keep an eye on Chimera Linux instead. It’s very actively developed, focuses on portable code by supporting many architectures, and its developers are veterans in this space. I have my eye on Chimera Linux as my future distribution of choice.

I stopped developing pkgsrc with CVS.

Quick bit of background: NetBSD is still using CVS as its version control system. The decision to move to something else has been taken long ago, but the switch has not happened as of today.

Working with CVS is painful for many reasons. For instance, there is no way to see your local changes without waiting several minutes for a cvs up -n. A full tree update (cvs up) churns for quite a while before it even starts updating any files.

Back when Java was still a new programming language, Sun had the idea of building a computer specifically designed for Java, unique processor running byte-code as its native machine code and all. This whole endeavour proved to be more complicated than Sun had hoped, and as such, they eventually abandoned the idea of a Java processor in favour of plain SPARC. When the JavaStation shipped, it was a regular SPARC workstation without a hard drive, running something called JavaOS from flash memory.

Since JavaOS is, of course, long gone, what can you do with JavaStation today? Well, you apparently can run NetBSD on it, but it’s quite an ordeal. The JavaStation needs to boot from the network using a combination of RARP, NFS, and more, and surprisingly, this entire setup, including the computer acting as the ‘server’ for the JavaStation, is well-documented and supported by NetBSD. Once you’ve gone through all the steps, you’ll end up with a JavaStation running the latest release of NetBSD, which is pretty cool.

Obviously there is still a lot to do; as you can see postfix isn’t happy, and the swapfile security needs tightening up for a start. But we do now have a functional NetBSD system running on a vintage network computer!

↫ Old Fart’s Almanac

NetBSD’s continued support for the most arcane of hardware will never cease to amaze me.

We are happy to announce that The NetBSD Foundation will participate in Google Summer of Code 2025!

Would you like to contribute to NetBSD and/or pkgsrc in the next months? Google Summer of Code is a great chance for that!

You can find a list of possible projects at Google Summer of Code project page. Of course, you can also propose your own!

Please reach us via #netbsd-code IRC channel on Libera.Chat and/or via mailing lists.

If you are more interested about Google Summer of Code please also check official homepage at g.co/gsoc.

Looking forward to a great Summer!

Last December I wrote a meandering post describing the challenges with Mini-ITX builds. While the form factor lets you build in beautiful little cases like my old NCASE M1, there are financial, thermal, and feature compromises that may prove limiting, especially when it comes to upgrades and future expansion. You’re essentially engineering yourself into one of eight physical case corners, albeit cute ones.

I’m not sure if I was trying to convince myself or you, now that I’ve read it back. Because as I’ve learned with cameras again recently, the best choice isn’t always the… best choice. Or more specifically, what you might measure “best” against may not be the same as what other people choose. Nobody knows your circumstances, priorities, and tastes better than you, despite what others may assert by decrying your preferences as illogical.

But I’ll admit I left something out of that Mini-ITX post: I’d bought a larger Micro-ATX case. I was still using my Mini-ITX Ryzen board inside, but at least I had a future upgrade path that was more flexible, cost effective, and had a greater ceiling for active cooling like radiators and fans. It was bigger, easier to build in, and made rational sense. It was even beautiful in its own right, with its light wood accents and rounded edges. Maybe I’ll do a post about it at some point.

Alas, then I’d look over at that little NCASE M1 I bought in 2016 and gave to Clara last year, and everything came back. I loved how little space it took up on the desk, how precisely everything fit, and that minimal design language. Deep down inside I realised I still wanted something that matched. So I pounced when I saw a Dan/Lian-Li A4-H2O at a steep discount at a local distributor.

Pictured below is the beautiful but large A3-mATX (left), the new A4-H2O (centre), and Clara’s NCASE M1 (right):

The history of Dan and NCASE is beyond the scope of this post, but the family resemblance is undeniable. The A4-H2O and the M1 both use aluminium panels with tool-less snaps that attach to a black inner frame. They’re lightweight but surprisingly rigid. And while the fit and finish aren’t at the level of an Apple Mac Pro of yore, it hits that similar aesthetic I love.

The A4-H2O employs a “sandwich” layout, similar to the older Dan A4-SFX I talked about back in the day. For those unfamiliar, sandwich layouts are delicious. They generally consist of a central bracket upon which everything is mounted, and which serves to split the case in two. This helps isolate the two hottest components of a gaming PC—the CPU and the graphics card—into their own thermal zones, and permits the case to be shrunk horizontally while still supporting the same hardware. A riser cable is used to connect the graphics card in the second chamber across to the motherboard in the first, as this diagram from Lian-Li demonstrates:

The name A4-H2O also highlights its specific use case. I’m currently using the same slim CPU air cooler as I was in the Fractal Ridge for now, but my aim is to use the recommended 240 mm liquid-cooled AIO radiator and fans mounted to the top when finances permit. This may be overkill for my older 65 watt Ryzen 5700X, but that higher thermal ceiling opens up a whole class of mid-tier CPUs that I wouldn’t have been game to put into other cases of a similar size. A 5800X3D, or some 9000-series AMD silicon? Who knows!

The case design also came with a couple of other unexpected surprises. Because the graphics card is mounted vertically against the case, the fans can pull in fresh air directly. Despite this case having less than half the volume of the Micro-ATX case it’s replacing, the GPU actually runs cooler and quieter here. Thanks to some clever layout decisions, I also found tidy cable management was easier in this than cases twice the size, despite what some YouTube channels suggested.

I had my entire machine moved across to the A4-H2O within twenty minutes. Mini-ITX cases can be painful owing to their their tight tolerances, but this was surprisingly easy. About the only thing that caused mild frustration was the CPU power cable for the motherboard, which I had to detach and move to a closer port on the SFX power supply for it to reach.

It’s probably too obvious to state, but Mini-ITX isn’t for everyone. Being a FreeBSD and NetBSD desktop user—heck, even Linux to be honest—forces you to be a bit more deliberate with your part choices, and it’s the same with builds like this. As I said in that original Mini-ITX post, I can only do this because I have an Antec 300 in the other room with half a dozen hard drives, almost as many SSDs, and all our home server stuff. That lets this machine be my cute little workstation and game PC, in a case that now matches my beloved NCASE M1 of yore.

If you have a mid-tier CPU, a 3-slot or smaller graphics card, a plan to use an AIO for liquid cooling, and enjoy that perforated aluminium aesthetic of these sorts of cases, I can’t recommend the A4-H2O highly enough. The NCASE M2 may be a better fit if you deviate even slightly from this “Goldilocks” configuration, but otherwise I think this looks, feels, and acts more like a true NCASE M1 successor.

I was lucky I was able to scoop one up on special, because they’re getting harder to find in Australia. I’m not sure if they’re about to be discontinued, but I’d keep an eye out if you’re interested.

By Ruben Schade in Sydney, 2025-02-25.

While SPARC may no longer be supported by the main Illumos project, it still works and is still viable. This page brings together a variety of information regarding Illumos on SPARC, not necessarily limited to Tribblix.

↫ Tribblix website

It seems running Tribblix – and other Illumos-based distributions – on SPARC is still possible, but there are some serious limitations anyone who has tried to use even slightly older operating systems will be fairly familiar with. For instance, since there’s no Rust for Illumos on SPARC, Firefox and other applications that use it are not available, and Tribblix in particular no longer builds Pale Moon (or LibreOffice). Rust is available on Solaris 11, though, so it may be possible to bring it to Illumos. In a similar vein, Go also isn’t available for SPARC either.

As far as hardware support goes, it’s a bit of a mixed bag, as systems that should work do, in fact, not, and even systems that do work run into a very familiar problem: graphics card support is a big issue. This is a problem plaguing X.org on any outdated or sidelined architecture, and it seems Illumos is also affected. Obviously, this greatly reduces the usefulness of Illumos on workstations, but is less of an issue on servers. You’ll run into the same problem when trying to run NetBSD, OpenBSD, or Linux in, say, PA-RISC hardware.

Of course, the problem is both a lack of people interested in and capable of contributing to keeping stuff running on older architectures, further spurred on by a dwindling supply of hardware available at reasonable prices. Sad, but there isn’t much that can be done about it.

NetBSD consistently appears unable to install a bootx64.efi file on my home built computer and is never able to boot after a fresh install. My work around is to boot from a Linux live USB pen drive and install reFind. However, I am not really into cludges and am wondering if after an install, it is possible to exit to the shell and get the bootx64.ef file created / moved / installed to where it is supposed to reside, somewhere in the /boot/EFI location before rebooting to the fresh NetBSD install…

Hello,

I was given an old motherboard as a gift from my sister. I like tuning and upgrading old hardware. I added more memory, a more powerful processor, an SSD, and so on.

I enjoy studying operating systems, so I decided to install multiple ones: Fedora, FreeBSD, NetBSD, DragonFlyBSD, and Haiku.

I first partitioned the SSD into 8 partitions (plus two for GRUB boot) using GParted on a USB drive (GPT scheme).

lsblk command in Fedora:

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 1G 0 part /boot
├─sda3 8:3 0 155.3G 0 part /
├─sda4 8:4 0 155.3G 0 part
├─sda5 8:5 0 155.3G 0 part
├─sda6 8:6 0 155.3G 0 part
├─sda7 8:7 0 155.3G 0 part
└─sda8 8:8 0 154.3G 0 part
zram0 252:0 0. 1.9G 0 disk [SWAP]
I installed the operating systems in the following order:
Partition 3: Fedora 40
Partition 4: FreeBSD 14.2
Partition 5: NetBSD 10
Partition 6: DragonFlyBSD 6.4.0
Partition 7: (still empty, possibly Amiga-like OS)
Partition 8: Haiku R5
Installing Fedora, FreeBSD, and Haiku was easy.
The problem started with the NetBSD installation.

I had to enter the shell and use dkctl to complete the installation.

After that, I tried installing DragonFlyBSD, but the installer does not recognize the GPT scheme; it only sees the entire SSD as a single unpartitioned disk.

gdisk /dev/sda command in Fedora:

Number Start (sector) End (sector) Size Code Name
1 40 2087 1024.0 KiB EF02
2 2088 2099239 1024.0 MiB 8300 boot
3 2099240 327688231 155.3 GiB 8300 Fedora
4 327688232 653275175 155.3 GiB A503 FreeBSD
5 653275176 978862119 155.3 GiB A902 NetBSD
6 978862120 1304449063 155.3 GiB 8300 DragonFlyBSD
7 1304449064 1630036007 155.3 GiB A503 Amiga-Like
8 1630036008 1953523751 154.3 GiB EB00 Haiku

I searched on ChatGPT 😁 and found these steps:

I first started FreeBSD and formatted partition /dev/ada0p6:

newfs -U -O1 -L DragonFlyBSD /dev/ada0p6

Then, I downloaded the DragonFlyBSD image:

curl -O http://mirror-master.dragonflybsd.org/iso-images/dfly-x86_64-6.4.0_REL.img.bz2

I decompressed the package:

bzip2 -dk dfly-x86_64-6.4.0_REL.img.bz2

I mounted the /dev/ada0p6 partition:

mount /dev/ada0p6 /mnt

I copied the image file to the mounted partition and then unmounted it:

cp dfly-x86_64-6.4.0_REL.img /mnt
umount /mnt

I restarted the system and booted from a USB drive with the DragonFlyBSD installer.
In the shell, I created a new directory dflydsk in /mnt, mounted the partition I wanted to use at /mnt/dflydsk, and created a virtual device for the DragonFlyBSD installer image stored in /mnt/dflydsk:

mount -t ufs /dev/ad4s5 /mnt/dflydsk
vnconfig vnd0 /mnt/dflydsk/dfly-x86_64-6.4.0_REL.img

I created another directory dflyimg in /mnt and mounted the virtual device at /mnt/dflyimg:

mount -t ufs /dev/vnd0s2 /mnt/dflyimg

I copied the contents of /mnt/dflyimg to /mnt/dflydsk:

cpdup -vv /mnt/dflyimg /mnt/dflydsk

After that, I used chroot to set the root password and edit fstab.

Finally, I configured Fedora's GRUB in the 40_custom file with:

nano /etc/grub.d/40_custom

...

menuentry "DragonflyBSD" {
insmod part_gpt
insmod ufs1
set root=(hd0,gpt6)
kfreebsd /boot/loader
}

...

And I loaded with:

grub2-mkconfig -o /boot/grub2/grub.cfg

Well, I think I described the steps as accurately as possible—maybe a mistake here and there, but that's the gist of it.

However, when I booted, I got this screen:

Am I doing everything correctly? If not, what do I need to change?

Recently i read "Boring tech is mature, not old" https://rubenerd.com/boring-tech-is-mature-not-old/ and" If It Ain't Broke, Don't Fix It" came to mind so I asked AI to give me summary of BSD family of operating system which resonates with similar thought. So following blog post is what A.I. wrote about:

In a world obsessed with the shiny and new, where constant updates and feature creep are often lauded as progress, there's a quiet corner of the tech world that holds a different philosophy. A philosophy that values stability, reliability, and a pragmatic approach to computing: "If it ain't broke, don't fix it."
This isn't some Luddite manifesto against innovation. Far from it. It's the bedrock upon which the BSD family of operating systems – FreeBSD, OpenBSD, NetBSD, and others – has been built, maintained, and thrived for decades.
Think about it. In your life, what are the things you truly rely on? The sturdy tools in your shed? The classic car that starts reliably every morning? The time-tested recipes passed down through generations? These aren't things you constantly tinker with just for the sake of it. You value them precisely because they work, consistently and dependably.
This is the essence of the BSD approach. While the tech world races to embrace the latest buzzwords and fleeting trends, BSD systems stand firm, grounded in a philosophy of considered evolution, not reckless revolution.

Stability as a Feature, Not a Bug:

For BSD, "if it ain't broke" isn't just a catchy phrase; it's a guiding principle. It translates into operating systems renowned for their rock-solid stability. We're talking about systems that can run for years, not just months, without needing reboots or constant patching for the latest "critical vulnerability of the week."
This isn't achieved by ignoring progress. BSD developers are incredibly skilled and actively contribute to the cutting edge. But they do so with a deliberate, meticulous approach. New features and changes are rigorously tested, scrutinized, and integrated only when they are proven to be robust, beneficial, and truly necessary.

The Power of Predictability:

In today's world of unpredictable software updates that can break functionality, disrupt workflows, and force you to relearn familiar interfaces, the predictability of BSD is a breath of fresh air. You know what you're getting. You know it will work. You know it will continue to work reliably for the long haul.
This predictability is invaluable, especially for those who rely on their systems for critical tasks – from powering internet infrastructure and academic research to serving as the backbone of embedded devices and secure servers. Downtime is not an option, and the BSD family delivers.

Focused Innovation, Not Feature Bloat:

"If it ain't broke" doesn't mean stagnation. BSD systems do evolve, but they do so with purpose. Innovation in the BSD world is often focused on enhancing core functionalities, improving security, and refining performance, rather than chasing after every trendy feature that might be fashionable for a moment but ultimately add complexity and potential instability.
This focused approach results in systems that are lean, efficient, and remarkably secure. OpenBSD, for example, is famous for its proactive security posture, constantly auditing code and implementing mitigations to prevent vulnerabilities before they even become a problem. This isn't about reacting to fires; it's about fireproofing the building from the start.

For the Pragmatic and the Practical:

The "If it ain't broke, don't fix it" ethos of BSD resonates deeply with those who value practicality over hype, reliability over novelty, and substance over style. It's for the engineers, the researchers, the system administrators, and anyone who needs an operating system that just works, quietly and reliably, without constant fuss or drama.
In a world where technology is often driven by the relentless pursuit of "new," the BSD family reminds us of the enduring value of "good." Good design, solid engineering, and a commitment to building systems that are not just cutting-edge, but also dependable, stable, and built to last.
So, the next time you're faced with the endless cycle of updates, feature changes, and potential disruptions in your tech life, consider taking a step back and asking yourself: "Is it really broken? Or am I just fixing something that works perfectly well already?"
Perhaps it's time to embrace the wisdom of "If it ain't broke, don't fix it," and explore the powerful, reliable world of the BSD family. You might just find exactly what you've been looking for: a system that simply works, allowing you to focus on your tasks, your projects, and your goals, rather than constantly wrestling with your operating system. Because sometimes, the best innovation is simply building things that are built to last, and built to serve – reliably, consistently, and without unnecessary tinkering.

And by installer, I mean the file called "netbsd" on the install ISO for MacPPC?

I have a problem with the default installer and I need to set some kernel flags for "wd".

I compiled my own version of GENERIC_MD with this flag set.

But when I try to boot off my file, I get an error about "no file system for md0"

Not sure what to do here 🙂

You might think the world of Linux distributions is a rather boring, settled affair, but there’s actually a ton of interesting experimentation going on in the Linux world. From things like NixOS with its unique packaging framework, to the various immutable distributions out there like the Fedora Atomic editions, there’s enough uniqueness to go around to find a lid for every pot. Oasis Linux surely falls into this category. One of its main unique characteristics is that it’s entirely statically linked.

All software in the base system is linked statically, including the display server (velox) and web browser (netsurf). Compared to dynamic linking, this is a simpler mechanism which eliminates problems with upgrading libraries, and results in completely self-contained binaries that can easily be copied to other systems.

↫ Oasis GitHub page

That’s not all it has to offer, though. It also offers fast and 100% reproducible builds, it’s mostly ISO C conformant, and it has minimal bootstrap dependencies – all you need is a “POSIX system with git, lua, curl, a sha256 utility, standard compression utilities, and an x86_64-linux-musl cross compiler”. The ISO C-comformance is a crucial part of one of Oasis’ goals: to be buildable with cproc, a small, very strict C11 compiler. It has no package manager, but any software outside of Oasis itself can be installed and managed with pkgsrc or Nix.

Another important goal of the project is to be extremely easy to understand, and its /etc directory is honestly a sight to behold, and as the project proudly claims, the most complex file in there is rc.init at a mere 16 lines. The configuration files are indeed incredibly easy to understand, which is a breath of fresh air compared to the archaic stuff in commercial UNIX or the complex stuff in modern Linux distributions that I normally deal with.

I’m not sure is Oasis would make for a good, usable day-to-day operating system, but I definitely like what they’re putting down.

Update: there’s a fork called heirloom-ng that is actually still somewhat maintained and contains some more changes and modernisations compared to the old version.

The Heirloom Project provides traditional implementations of standard Unix utilities. In many cases, they have been derived from original Unix material released as Open Source by Caldera and Sun.

Interfaces follow traditional practice; they remain generally compatible with System V, although extensions that have become common use over the course of time are sometimes provided. Most utilities are also included in a variant that aims at POSIX conformance.

On the interior, technologies for the twenty-first century such as the UTF-8 character encoding or OpenType fonts are supported.

↫ The Heirloom Project website

I had never heard of this before, but I like the approach they’re taking. This isn’t just taking System V tools and making them work on a modern UNIX-like system as-is; they’re also improving by them adding support for modern technologies, without actually changing their classic nature and the way old-fashioned users expect them to work. Sadly, the project seems to be dead, as the code hasn’t been altered since 2008. Perhaps someone new is willing to take up this project?

As it currently stands, the tools are available for Linux, Solaris, Open UNIX, HP-UX, AIX, FreeBSD, NetBSD, and OpenBSD, but considering how long the code hasn’t been touched, I wonder if they still run and work on any of those systems today. They also come in various different versions which comply with different variants of the POSIX standard.

As you might be aware of, I am working on a minimal BSD/UNIX system called smolBSD. It is based on the NetBSD operating system, and its main target is virtual machines, more specifically microvms. This system is capable of fully booting the OS in less than one second using a specially trimmed kernel along with small, specialized root systems.
I was stunned to learn (but am I wrong?) that this work does not seem to have an equivalent, not even in the Linux world. FreeBSD Firecracker support sure permits to boot a kernel is about the same time my NetBSD hacked kernel does, but there’s no work around s slim and task dedicated root filesystem.

Quirky, just like I want it.

• Why is editing PDFs so prevalent?
• A Suitably Bizarre Start of the Year 2025.
• Naming Quarters.  I think fortnights and sennights are underutilized timeframes, incidentally.
• pkgsrc-2024Q4 is out.
• Tellico, collection management software.  (via)
• Some of the original BeOS icons reimagined in Blender.  (via)
• Cray 1 Supercomputer Performance Comparisons With Home Computers Phones and Tablets. (via)
• The next leap second is at least a year away.
• Copyright-free images.  A vast amount of images available.

Your unrelated music link of the week: Where to Start With Tempa, The Label That Invented Dubstep.

Make, as arcane as a build tool can be, may still be a good first fit for certain scenarios. “Heresy!”, you say, as you hear a so-called “Bazel expert” utter these words.

The specific problem I’m facing is that I need to glue together the NetBSD build system, a quilt patch set, EndBASIC’s Cargo-based Rust build, and a couple of QEMU invocations to produce a Frankenstein disk image for a Raspberry Pi. And the thing is: Make allows doing this sort of stitching with relative ease. Sure, Make is not the best option because the overall build performance is “meh” and because incremental builds are almost-impossible to get right… but adopting Bazel for this project would be an almost-infinite time sink.

Anyway. When using Make in this manner, you often end up with what’s essentially a “command dispatcher” and, over time, the number of commands grows and it’s hard to make sense of which one to use for what. Sure, you can write a README.md with instructions, but I guarantee you that the text will get out of sync faster than you can read this article. There is a better way, though.

This report was written by Diviyam Pat as part of Google Summer of Code 2024.

This summer I worked on NetBSD's kernel test framework to cover root device discovery and root file system selection. This area of the kernel is not very well documented and program flow has to be determined by reading the code.

I would also like to tell you about my early interactions with the project, let me start with project findings.

Why NetBSD?

Google Summer of Code 2024 is not my first time applying to GSoC. My first time was in 2022, in my first year of college. I have been fascinated with newer Windows versions since my Intel Core Duo i3 days as every new Windows version used to bring new changes and features, from Windows XP to Vista to 8.1 and then to 10 (cosmetic only) but was very heavy on my PC's memory usage that was upwards of 60% leaving very little room for applications and games.

My Intel i3 would be enough for it. This experience made me decide I wanted my project to be in the operating system space. I ventured into all OS projects on the Google Summer of Code website. Gentoo, Debian but that didn't turn out well. I then decided to explore BSDs. The community seemed friendlier, more responsive, and active in helping beginners. I started mailing all the mentors about my interests (I realized I should have done a lot more work before mailing them, it shows more dedication towards the project.)

Christoph explained the project in great detail to me, helped me with getting started and guided me through the hard parts of the project.

Project Details

Root device and file-system selection is made during the later stages of the boot process by the kernel. The kernel config file defines candidates for the root device and the kernel selects one after validating those options. If no options are defined, the auto config subroutines handle configuration. Head over to my docs for more details here. This functionality is handled primarily by the function setroot in file kern_subr.c. It also calls specialized functions for a number of cases. Our task was to add ATF tests for this function and some other functions that assist setroot. This part of the kernel works, and it has worked for over 30 years but the code is rather complex to read and there is no documentation. The only way to understand it is to read the code.

At any given stage when any condition fails the fallback option is to ask the user manually for the device. Thus this part of the kernel rarely needs attention. There are some global functions used in conditions inside setroot: rootspec, bootspec, etc. These variables are either set through the config file or through other machine-dependent kernel functions like findroot etc. We need to manually set them in our test cases and also need to stub kernel functions used by setroot and other functions. We wanted to make these test cases use 'vnd' devices, but we ran into bugs, and Christoph was trying to fix them. Therefore we had to resort to stubbing. We validate the global variables. We also test the tftproot_dhcpboot function that loads the contents of a memory disk device from a TFTP server and uses that as root device. Devices are represented by the device_t struct which is populated by the kernel. We mock this behavior through the create_device function and use this in the test programs. User input is handled by stubbing the cngetsn function. Global variables and arguments are set to test values in the body of the test cases and the function being tested is called. The test file is divided into 3 parts: 1) setroot_root, 2) setroot_ask, and 3) tftproot_dhcp. In the file kern_subr.c setroot() calls these functions but here we test them independently

Conclusion

I have worked on enhancing NetBSD's ATF tests to test the root device and file system selection process, testing the setroot function and its dependencies. These tests shall improve coverage of the ATF tests to the setroot function and in general, to root device selection. In the future, contributors can rely on these tests for kern_subr.c's functionality.

I am C++ developer and unfamiliar with script technologies like nodejs etc. I tried to build VS Codium on NetBSD 10.0 from sources 1.96.2 on github, by how-to manual. After running build/build.sh it outputs:

...
+++ ../update_settings.sh
300s/'default': true/'default': false/
sed: -E: No such file or directory
219s/'default': TelemetryConfiguration.ON/'default': TelemetryConfiguration.OFF/
sed: -E: No such file or directory
114s/'default': true/'default': false/
sed: -E: No such file or directory
#

When I look into target directory vscode I am seeing there something like result: vscode/cli/src/bin/code/main.rs How to continue with build to reach binary executable "bin/codium" ? What to do with that main.rs ? I read that it has something with rust ? Can anyone put more light on this to understand what to do ? I don't need to create installation package, it should be sufficient to run VSCodium from target build directory.

I recently picked up an embedded project in which I needed to build a highly customized full system image with minimal boot times. As I explored my options, I came to the conclusion that NetBSD, the often-forgotten BSD variant, was the best viable choice for my project.

One reason for this choice is NetBSD’s build system. Once you look and get past the fact that it feels frozen in time since 2002, you realize it is still one of the most advanced build systems you can find for an OS. And it shows: the NetBSD build system allows you to build the full OS from scratch, on pretty much any host POSIX platform, while targeting any hardware architecture supported by NetBSD. All without root privileges.

Another reason for this choice is that NetBSD was my daily workhorse for many years and I’m quite familiar with its internals, which is useful knowledge to quickly achieve the goals I have in mind. In fact, I was a NetBSD Developer with capital D: I had commit access to the project from about 2002 through 2012 or so, and I have just revived my account in service of this project. jmmv@ is back!

So, strap onto your seats and let’s see how today’s NetBSD build system looks like and what makes it special. I’ll add my own critique at the end, because it ain’t perfect, but overall it continues to deliver on its design goals set in the late 1990s.

The NetBSD project is pleased to announce the first update of the NetBSD 10 release branch NetBSD 10.1! See the release announcement for details.

This release includes 9 months of bug fixes and a few new features after the 10.0 release in March. It also gives those still using older release a good reason to finally update to the NetBSD 10 release branch, even if they avoid dot-zero releases by all means.

If you want to try NetBSD 10.1 please check the installation notes for your architecture and download the preferred install image from the CDN or if you are using an ARM based device from the netbsd-10 builds from the bootable ARM images page.

If you have any issues with installation or run into issues with the system during use, please contact us on one of the mailing lists or file a problem report.

This is my makefile:

CC = gcc
TARGET = target

CFLAGS = -O3 -Wall -Wextra -pedantic

SRCS = $(shell find . -type f -name '*.c')
OBJS = $(patsubst %.c,%.o,$(SRCS))

.PHONY: all clean

all: $(TARGET)

$(OBJS): $(SRCS)
    $(CC) $(CFLAGS) -c $< -o $@

.PRECIOUS: $(TARGET) $(OBJS)

$(TARGET): $(OBJS)
    $(CC) $(OBJS) -o $@

clean:
    -rm -f *.o
    -rm -f $(TARGET)

this is the output message:

gcc  -o target
gcc: fatal error: no input files
compilation terminated.
*** Error code 1

I'm trying to get this to work on NetBSD. What am I doing wrong? Also, I've found that $(SRCS) is just empty, but if I run find . -type f -name '*.c' in the shell on it's own, I do get the desired files. Please help !

I can't understand what "-f" option to find command on NetBSD mean.

Manual: https://man.netbsd.org/find.1 says

-f Specifies a file hierarchy for find to traverse. File hierarchies may also be specified as the operands immediately following the options.

Usage:

find [-H | -L | -P] [-dEhsXx] -f file [file ...] [expression]

find [-H | -L | -P] [-dEhsXx] file [file ...] [expression]

I would expect the two following calls to be equivalent:

home# find ./ -name "*c"
./1.c

home# find -f ./ -name "*c"
find: unknown option -- n
find: unknown option -- a
find: unknown option -- m
find: unknown option -- e
./
./1.c
find: *c: No such file or directory

Instead to make second equivalent I have to run

home# find -f ./ -- -name "*c"
./1.c

Am I missing something?

I have a very old AirPort Extreme, the A1408. Is it possible to install Linux on it, using the AirPort functionally as a hard disk, and then boot from that? I have also heard that AirPorts run NetBSD. Can you boot into that and run commands?

I have not been at EuroBSDCon for a while, unfortunately! My last EuroBSDCon was EuroBSDcon 2017 in Paris, France (and I have also blogged about it)!

I was very excited to come back to EuroBSDCon. Meet again in person with people. Talk in the "hall track"... and, why not!, have some fun and do some shenanigans in the nights! :)

And... definitely it was very nice, instructive and fun!

I have not fully unpacked the bag but it's time to share some notes!

Friday (20/09): arriving in Dublin

I arrived in Dublin on Friday afternoon. After some sightseeing on foot I got lost in the paintings of the National Gallery of Ireland.

I then spent the rest of the evening and night in Porterhouse Temple Bar. I had a tasty soup and garlic bread and several delicious craft beers!

Saturday (21/09): 1st day of conference talks and social event

My hotel was a 40 minutes walk from University College Dublin (UCD). I arrived a bit early for the registration. I then met some other NetBSD folks that I had missed in person since 2018 and met new ones.

View from O'Reilly Hall, University College Dublin.

After the Opening Session that welcomed us, the conference started with the opening keynote Evidence based Policy formation in the EU what Evidence are we Presenting to the EU? by Tom Smyth. Tom Smyth shared his experience on evidence based policy formation in the European Union from a point of a relatively small ISP. EU is open to feedback and as a BSD community we can shape and influence policies.

Flipping Bits: Memory Errors in the Machine, Taylor R Campbell

Taylor talked about bit flips, the memory errors in the machine.

Memory errors caught in the act: corruption of a filename in Riastradh's local machine.

He started sharing a catch of bit flip in a filename corruption on his local machine in NetBSD src repository. A bit flipped and that resulted from external/gpl3/gdb/dist/gdb/testsuite/gdb.linespec/cpls.cc to e\370ternal/gpl3/gdb/dist/gdb/testsuite/gdb.linespec/cpls.cc (In ASCII lower case x is \170 that is 01111000 in binary, while \370 is 11111000, the most significant bit got flipped!).

He also opened several PRs - due to several experienced kernel panics mostly in ZFS - before he realized that it was bad RAM.

As part of the talk a lot of fundamentals concepts and theory behind Error Detection And Correction (EDAC), causes of memory errors, where memory errors can happen, error severity and error persistence were shared.

Taylor then talked and digged in ACPI Platform Error Interface (APEI) that is the standard interface in ACPI that abstract EDAC device registers.

In NetBSD APEI is supported by the apei(4) driver.

The apei(4) driver also exposes a sysctl interface to APEI EINJ (Error INJection) that permit to also inject errors. Using such interface Riastradh live demoed that and trigger a memory error that was corrected and reported by apei(4)!

Riastradh live demoing a memory error using APEI EINJ via apei(4).

The talk was great and super-interesting. Memory errors are also pretty common. Taylor also shared a lot of anecdotes and that make his talk even more fun and interesting!

An introduction to GPIO in RPi3B+ and NetBSD, building a wind-speed logger as an application, Dr. Nicola Mingotti

Dr. Nicola Mingotti talk was a great introduction (and more) to Generalized Pin Input Output (GPIO)!

He started really from the start by populating a uSD card and installing and configuring NetBSD on a Raspberry Pi 3 Model B+.

He then introduced GPIO, how the RPi3B+ pin maps to the GPIO number and then we were ready to get our hands on GPIO!

As first exercises he showed how to set a PIN state (on/off) and read a PIN state via gpioctl(8). This can be used respectively to turn a LED on/off and to read the state of a switch.

The second series of exercises looked on how fast gpioctl can be. This is limited for several applications and so Nicola introduced how to write and read pin states in C via ioctl(2). This is much faster and with that we can go from switches to square waves!

To avoid bit-banging and polling respectively gpiopwm(4) and gpioirq(4) can be used. Nicola shared several applications of them, like blinking LED and loopback. (Another possible application, left as an exercise to the reader is the "daemon toggler". The "daemon toggler" starts/stops a daemon (e.g. ntpd(8)) based on the state of a physical switch!)

He then shared a much bigger application a Wind-Speed Logger (AKA WSL). This was used by Nicola in order to evaluate if wind turbines could be installed or not. He also shared how he adjusted an RPi case and built housing for it (the RPi will be outside, needs to cool off so needs some ventilation but at the same time the housing should block rain!)

Nicola showing the sensor used to build the Wind-Speed Logger (WSL).

He concluded the talk on why he used NetBSD.

The talk was really educational. Nicola did a great job in summarizing and providing a lot of references. If you are more interested I suggest to catch up with the video recordings, slides and try to do the exercises in it!

"Hall track" and preparing for the social event

After Nicola's talk I have spent some time in the "hall track" talking with other people and missed a couple of talks (recording should be available so I will hopefully catch up!).

I have then attended Stefano Marinelli's talk Why (and how) we're migrating many of our servers from Linux to the BSDs.

Stefano shared his more than 2 decades old experience with BSD systems and how he made his passion his profession.

He shared his philosophy, experience with clients and why it is important to focus on solving problems.

During the talk he shared also several interesting stories with clients. In one of them to avoid possible bias on BSD systems he migrated client hosts without informing them. A client called alarmed because he noticed a massive performance boost!

His talk was inspiring and you can find more in his I Solve Problems blog post.

After Stefano's talk we gathered to join the social event and took a DART train (Dublin Area Rapid Transit).

Social event: BrewDog Dublin Outpost

The social event was in BrewDog Dublin Outpost.

We were in an area dedicated to EuroBSDCon participants so that we can eat, drink and talk. There was a buffet and we received tickets to grab beers.

Several folks gifted me an handful and I have definitely had a pretty ample beer tasting experience too! :)

I also had a Vegan Spicy Meaty pizza: a pizza with seitan, mushrooms, chilli flakes, fresh red chilli, tomatoes and vegan mozzarella. My italian-pizza-side is usally pretty orthodox and I usually go for a pizza marinara! :) But overall that was actually pretty nice and I really appreciated the topping!

I have staid with a couple of folks until the closure. With Christoph Badura (<bad@>) we walked in the desperate search of grabbing some more food. However, at the end we ended up in The Temple Bar Pub for "only another beer"! We met with some friendly Swedish and Swiss tourists and we started talking about BSD systems at 2:00 AM! The weather was pretty nice (it was always pretty cloudy but there was no rain for the entire conference) and we decided to continue walking back to our hotels. At the end we have walked for a bit less than 9 kilometers from Temple Bar to nearly Booterstown! That was a great walk though and definitely we had no traces of hangovers in the morning! :)

Sunday (22/09): 2nd day of conference talks

I wake up a bit late on Sunday and arrived in UCD at around 12:00 and staid until lunch in the "hall track".

For lunch the vegetarian dish was a vegetarian curry, pretty tasty!

On Sunday we had a longer lunch break also to take a family photo.

EuroBSDCon 2024 family picture. You can find more EuroBSDCon photographs taken by Ollivier Robert at EuroBSDCon 2024 - Dublin, Ireland album.

After lunch I have attended FreeBSD at 30 Years: Its Secrets to Success by Kirk McKusick. In this talk Kirk looked back at 30 years of FreeBSD history (and also more for BSD years!) and what made its success. He talked about a lot of different topics, including leadership, development, importance of adopting ideas and codes from NetBSD and OpenBSD, communication, documentation and project culture. He also shared several interesting statistics and demographic about FreeBSD.

I have then attended Confidential Computing with OpenBSD by Hans-Jörg Höxer. Hans-Jörg introduced concepts about confidential computing, the threat model that it cover and then digged in AMD Secure Encrypted Virtualization (SEV) and how he is using that in OpenBSD vmm(4).

Then I have attended Building an open native FreeBSD CI system from scratch with lua, C, jails & zfs by Dave Cottlehuber. In this talk Dave shared the design and implementation of a Continuous Integration (CI) system focused on FreeBSD technologies but that can be ported also to other BSDs.

The final talk I have attended was SIMD-enhanced libc string functions: how it's done by Robert Clausecker and Getz Mikalsen. In this talk Robert shared how several libc string functions were reimplemented in other to use SIMD techniques on amd64 and arm64. Getz worked on porting such work on arm64 as part of Google Summer of Code 2024 and he shared his work and challenges in porting that. The talk was interesting and micro-benchmarking showed performance increase by factor of 5 on average!

Then I have joined the Closing Session.

There was a wrap up of the conference and some stats about it.

And *drumrolls* the next EuroBSDCon location was announced! EuroBSDCon 2025 will be in Zagreb, Croatia!

After the Closing Session with other NetBSD folks we met again for one last dinner. We met with Andy Doran (<ad@>) and we had some junk food and several beers.

Conclusion

I had not traveled a lot in the last years and I have missed several EuroBSDCon-s and I really regret that! EuroBSDCon 2024 was great: very interesting talks, friendly folks and it was some time that I did not had so much fun!

Dublin was also really nice. All the locals were also very friendly. I hope to come back to both Dublin and Ireland to do some much more sightseeing in a more relaxed pace. Enjoy food, beers, drinks and more. Talk with locals.

I would like to thanks a lot to all the EuroBSDCon organizers for the amazing conference!

I also would like to thanks The NetBSD Foundation that funded my EuroBSDCon registration.

If you have never been to EuroBSDCon and you are curious about BSDs... I strongly suggest to attend either as participant or speaker! Folks are super-friendly, there are a lot of interesting tutorials and talks and I'm pretty sure you will have fun too!

And... if you are still reading until here... thank you too! :)

This report was written by Emmanuel Nyarko as part of Google Summer of Code 2024.

Alternate Queuing has been of great need in the high Performance Computing space since the continuous records of unfair disruption in network quality due to the buffer bloat problem. The buffer bloat problem still persists and not completely gone but modern active queue managements have been introduced to improve the performance of networks.

ALTQ was refactored to basically improve maintainability. Duplicates were handled, some compile time errors were fixed and also performance has been improved too.

This improves the quality of developer experience on maintaining the ALTQ codebase.

The Controlled Delay (CoDel) active queue management has also been integrated into the netbsd codebase. This introduces improvements made in the area of quality of service in the netbsd operating system. CoDel was a research led collaborative work by Van Jacobness and Kathleen Nichols which was developed to manage queues under control of the minimum delay experienced by packets in the running buffer window.

As it stands now, ALTQ in NetBSD is integrated in PF packet filter. I am currently working to integrate it in the NPF packet filter. The code in NetBSD is on the constant pursuit to produce clean and maintainable code.

I'll also be working to improve quality of service in NetBSD through quality and collaborative research driven by randomness in results. As a research computer scientist, I will be working to propose new active queue managements for the NetBSD operating system to completely defeat the long lasting buffer bloat problem.

More details of the work can be found in my Google Summer of Code 2024 work submission.

I am trying to install, for the first time, NetBSD-10.0-amd64 on HP EliteBook 8570w. After choosing "Install BSD" option installer goes to the booting mode and gets interrupted with an error:

502c0
Stopped in pid 294.294 (init) at            netbsd:breakpoint+0x5: leave
breakpoint() at netbsd:breakpoint+0x5
vpanic() at netbsd:vpanic+0x183
panic() at netbsd:panic+0x3c
cnopen() at netbsd:cnopen+0x104
cdev_open() at netbsd:cdev_open+0x12a
spec_open() at netbsd:spec_open+0x1e0
VOP_OPEN() at netbsd:VOP_OPEN+0x3e
vn_open() at netbsd:vn_open+0x2ec
do_open() at netbsd:do_open+0xc3
do_sys_openat() at netbsd:do_sys_openat+0x74
sys_open() at netbsd:sys_open+0x24
syscall() at netbsd:syscall+0x1fc
--- syscall (number 5) ---
netbsd:syscall+0x1fc
ds            8
es            2
fs            180
gs            4a80
rdi           0
rsi           ffffffff81d88000
rsi           ffffbe8345a54ad0
rbx           0
rdx           1
rcx           ffffffffffffff
rax           800000000000000
r8            0
r9            0
r10           ffffffff818450e0      x86_mem
r11           fffffffe
r12           ffffffff8139af6f      ostype+0x13aa
r13           ffffbe8345a54b18
r14           104
r15           ffff8046d2cbdbc0
rip           ffffffff80235385      breakpoint+0x5
cs            8
rflags        202
rsp           ffffbe8345a54ad0
ss            10
netbsd:breakpoint +0x5: leave

If I continue the system precedes to reboot.

I'm not familiar with bsd tools so please tell me if I left important information.

Notice

I installed FreeBSD and Arch Linux on the same machine and it worked fine.

After several sessions with intense Google searching and trying several angles with ChatGPT, I seem to be at a dead-end, my problem arises when I try to build OpenSSL from source, it seems that the build process wants to link with libcrypto.so located in /lib, but the system supplied version of OpenSSL is ancient, so this fails miserably, since OpenSSL now includes functionality not present in my version of libcrypto.so, specifically QUIC, its failing on safe_muldiv_uint64_t. It seems like a catch-22, and I have absolutely no idea how to break out of this.

Some of the suggestions I have found involved building OpenSSL in a chroot jail, but I think it seems a little excessive?

So I guess my question is: How do I build OpenSSL without linking with /lib/libcrypto.so, but linking with the version of libcrypto from the source package?

Output:

${LDCMD:-cc} -pthread -Wa,--noexecstack -O2 -O3 -pipe -I/usr/include -I/usr/pkg/include  -L/usr/local/lib -L/usr/pkg/gcc7/lib/gcc/x86_64--netbsd/7.5.0 -Wl,-R/usr/pkg/gcc7/lib/gcc/x86_64--netbsd/7.5.0 -Wl,-zrelro -L/usr/lib -Wl,-R/usr/lib -L/usr/pkg/lib -Wl,-R/usr/pkg/lib \
        -o fuzz/quic-srtm-test \
        fuzz/quic-srtm-test-bin-fuzz_rand.o \
        fuzz/quic-srtm-test-bin-quic-srtm.o \
        fuzz/quic-srtm-test-bin-test-corpus.o \
        libssl.a libcrypto.a -pthread
...
apps/libapps.a -lssl -lcrypto -pthread
./libssl.so: undefined reference to safe_muldiv_uint64_t
./libssl.so: undefined reference to safe_mul_uint64_t

-L/usr/lib is specified in the above command executed by the Makefile, and that folder contains libcrypto.o and libssl.o from the system supplied version of OpenSSL,

This is a new installation for a wordpress site that hasn't launched yet.

The memcached process is always at near 100% of cpu usage:

load averages:  1.93,  1.78,  1.83;               up 3+22:29:29                                                                                      21:49:18
31 processes: 28 sleeping, 3 on CPU
CPU states: 59.1% user,  0.0% nice,  4.0% system,  0.0% interrupt, 36.8% idle
Memory: 2069M Act, 1014M Inact, 44K Wired, 175M Exec, 2447M File, 54M Free
Swap: 512M Total, 512M Free / Pools: 279M Used / Network: 23K In, 1K Out

  PID USERNAME PRI NICE   SIZE   RES STATE       TIME   WCPU    CPU COMMAND
 5770 memcache  25    0    70M 3112K CPU/0      19:11 94.58% 94.58% memcached

And memcached-tool /var/run/memcached/memcached_0.sock stats reports

#/var/run/memcached/memcached_0.sock Field         Value
              accepting_conns             1
                    auth_cmds             0
                  auth_errors             0
                        bytes             0
                   bytes_read            21
                bytes_written          4435
                   cas_badval             0
                     cas_hits             0
                   cas_misses             0
                    cmd_flush             0
                      cmd_get             0
                     cmd_meta             0
                      cmd_set             0
                    cmd_touch             0
                  conn_yields             0
        connection_structures             2
        crawler_items_checked             0
            crawler_reclaimed             0
             curr_connections             1
                   curr_items             0
                    decr_hits             0
                  decr_misses             0
                  delete_hits             0
                delete_misses             0
              direct_reclaims             0
               evicted_active             0
            evicted_unfetched             0
                    evictions             0
            expired_unfetched             0
                  get_expired             0
                  get_flushed             0
                     get_hits             0
                   get_misses             0
                   hash_bytes        524288
            hash_is_expanding             0
             hash_power_level            16
                    incr_hits             0
                  incr_misses             0
                     libevent 2.1.12-stable
               limit_maxbytes      67108864
          listen_disabled_num             0
             log_watcher_sent             0
          log_watcher_skipped             0
                 log_watchers             0
           log_worker_dropped             0
           log_worker_written             0
            lru_bumps_dropped             0
          lru_crawler_running             0
           lru_crawler_starts             6
       lru_maintainer_juggles     103444004
            lrutail_reflocked             0
                 malloc_fails             0
              max_connections          1024
                moves_to_cold             0
                moves_to_warm             0
             moves_within_lru             0
                          pid          5770
                 pointer_size            64
               read_buf_bytes         98304
          read_buf_bytes_free         32768
               read_buf_count             6
                 read_buf_oom             0
                    reclaimed             0
         rejected_connections             0
                 reserved_fds            20
           response_obj_bytes         49152
           response_obj_count             1
             response_obj_oom             0
         round_robin_fallback             0
                rusage_system      1.053032
                  rusage_user   1136.463840
        slab_global_page_pool             0
   slab_reassign_busy_deletes             0
     slab_reassign_busy_items             0
  slab_reassign_chunk_rescues             0
slab_reassign_evictions_nomem             0
 slab_reassign_inline_reclaim             0
        slab_reassign_rescues             0
        slab_reassign_running             0
                  slabs_moved             0
              store_no_memory             0
              store_too_large             0
                      threads             4
                         time    1724186947
   time_in_listen_disabled_us             0
            total_connections             4
                  total_items             0
                   touch_hits             0
                 touch_misses             0
          unexpected_napi_ids             0
                       uptime          1177
                      version        1.6.23

Memcached is configure to start with:

# grep memcach /etc/rc.conf
memcached=YES
memcached_jobs="job0"
memcached_job0_args="-a 660 -s /var/run/memcached/memcached_0.sock -m 64 -c 1024"

What might be wrong?