NetBSD Planet

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.

I did one of those terminal surveys! As in, a survey about using terminals, not a survey that’s terminal. Some of the answers are below. I didn’t include duplicate questions, or ones where the answer is just a “yes”.

How long have you been using the terminal?

21+ years (… yikes)

Which shells do you use?

ksh, sh, csh (in that order).

Do you use your system’s default shell?

No, I changed it (except when running as root/toor).

What OS do you use a Unix terminal on?

FreeBSD, Linux, macOS, NetBSD, illumos.

What Terminal emulators do you use?

Terminal.app, Konsole, rxvt, Xfce Terminal.

Do you use a terminal-based editor?

vim/neovim/vi, (also mg, and have been known to use mc).

Do you customise your terminal’s colour scheme?

Yes, I use a theme (admittedly I used to do much more).

If your terminal get messed up, what do you do?

Run stty sane (though I have this aliased to cls, because DOS habits die hard).

What terminal settings do you customise?

PATH, environment variables, alias, the prompt (I like having two lines), custom functions.

Do you use job control?

No. (I used to, but now I only really use tmux and tabs).

Do you manage your files using the terminal, or a GUI file manager?

Mostly GUI (I also use GUI file managers as media organisers. The terminal is useful for bulk processing, syncing directories, and remote uploads).

Which of these environment variables have you set intentionally?

PATH, MANPATH, EDITOR, VISUAL, LANG, LC_ALL, PAGER (and CLICOLOR on FreeBSD).

Do you use vi mode in your shell?

No (but I use vi-style keybindings elsewhere).

How do you navigate files in less?

j/k to scroll (also spacebar to move down large areas).

How do you use pipes?

tee to save output, pv to see progress, xargs to parallelise (I definitely need to get better at xargs, and awk).

Do you use a terminal multiplexer?

tmux, screen (eventually want to move all to tmux, but muscle memory is a powerful thing).

What’s the most frustrating thing about using the terminal for you?

(Scripts and examples that assume you use bash, you have it installed, or that sh is an alias of bash).

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

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.

I’ve talked before about how I think NetBSD is “boring”, and that it’s among the highest forms of praise I can give tech as a sysadmin and architect. But I’ve never elaborated why that is.

The opposite of being bored is to be surprised, and that’s not something a sysadmin desires when building, maintaining, scaling, troubleshooting, upgrading, or even replacing a complex system… especially when you’re woken up at 03:30 by a monitoring server. That’s also why the phrase work doing what you love and you never work a day again in your life is an empty platitude of nonsense. But I digress.

Boring tech behaves in predictable ways. It’s a well trodden path others have evaluated, optimised, troubleshooted, and understood. Using tech that has been subjected to all those people hours of use means you’re less likely to run into edge cases, unexpected behaviour, or attributes and features that lack documentation or community knowledge. In other words, when something goes wrong, can you turn to someone or something?

Likewise, tech (generally) doesn’t exist in a vacuum. It interacts with other components and systems, some of which are even conveniently under our control, sometimes. Multiply out the potential for surprises by the number of components and their relative maturity, and your head can start to spin.

This isn’t to say there isn’t room for innovation, or that staying put is a guaranteed recipe for success. What it does teach is that it pays to make informed decisions, and that often times the understood, reliable, boring tech will get you there over something new, shiny or propped up with marketing spin. The number of people I’ve talked with who’ve replaced complicated K8s clusters with a few VMs and seen massive improvements in reliability, cost, and uptime would make some people at the Orange Peanut Gallery more than a little perturbed, for example.

There have been talks about this, perhaps most famously by Dan McKinley. But there’s been some pushback to this idea, which is intriguing. Robert Roskam:

I used to agree with this. Now I don’t think so any more. You should prefer “boring” tech, and boring should be read as has been around for a while and therefore is well understood.

Ubiquity is a bad test for well-understood technology. Age as a test for ubiquity is also bad.

There are a few assumptions here:

• Boring should be read as something being around for a while. I wouldn’t necessarily agree with that. I’ve been a DBA, and I never in a million years would call Oracle “boring”. It’s fiendishly complicated and difficult to maintain, and commands above-average salaries in part for that reason. A sign saying “there be Ellison dragons” isn’t boring, it’s frankly terrifying.

• Ubiquity is a test for “boringness”. He’s right here; while age gives something an opportunity to become ubiquitous, it’s not a guarantee. I’d look to the BSDs here; I’d consider them boring, but they’re not exactly widely deployed compared to Penguins.

• Boring should be read as well-understood. That’s true. Time gives something more of a chance of being well-understood, until suddenly it doesn’t and nobody is around with sufficient knowledge and inclination to maintain your COBOL stack. At that stage, I’d say you have a decidedly un-boring issue on your hands.

I’d conclude by suggesting boring tech isn’t old, but mature. Maturity not just in the software, but its documentation, community, and track record. Age is often used as an analogue for maturity, but it’s not the same thing. Otherwise I’d be more mature than my Zoomer friends, and I very much doubt that to be the case. #BIRDISTHEWORD.

This is why I don’t hesitate to call NetBSD boring, and why I say that’s a compliment.

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

Hello,

I have a Blue and White Macintosh G3 with a Sonnet Tempo PCI IDE controller card attached to a UDMA hard disk.

Currently, the drive mounts in NetBSD 10.1 as a wd UDMA disk.

However, I noted that when I boot into MacOS 8.6, the drive is seen as SCSI.

How might I also mount this drive as SCSI or ATAPI in NetBSD?

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.

We’ve got a new Dillo release for you this weekend!

We added SVG support for math formulas and other simple SVG images by patching the nanosvg library. This is specially relevant for Wikipedia math articles.

We also added optional support for WebP images via libwebp. You can use the new option ignore_image_formats to ignore image formats that you may not trust (libwebp had some CVEs recently).

↫ Dillo website

This release also comes with some UI tweaks, like the ability to move the scrollbar to the left, use the scrollbar to go back and forward exactly one page, the ability to define custom link actions in the context menu, and more – including the usual bug fixes, of course. Once the pkgsrc bug on HP-UX I discovered and reported is fixed, Dillo is one of the first slightly more complex packages I intend to try and build on HP-UX 11.11.

The news of this slipped me by last year, but I just saw OpenWrt has their own hardware now, based on the BananaPi:

OpenWrt One is based on the MediaTek Filogic 820 SoC and has WiFi 6, dual-band, 3×3/2×2, 1x 2.5Gbit WAN, 1x 1Gbit LAN, 1GB DDR4 RAM, 256 MiB NAND, 16 MiB NOR (for recovery), M.2 SSD, USB-C Serial console and USB 2.0.

You can buy the bare board, or a BananaPi-style industrial blue case.

As mentioned in the tech specs, it even has an M.2 slot, and MikroTik MikroBUS. At least one of these places it ahead of the best Raspberry Pi, as does its external antenna support.

I’ve been after a small box I can configure and pass onto friends and family who aren’t technical, and are still running the garbage, insecure routers their service providers gave them in 2012. This might be it? I might to get one to try.

As an aside, I still mistype OpenWrt as OpenWRT. I spend too much time running FreeBSD, NetBSD, and OpenZFS, evidently. Hey, I could start calling this blog RubenERD!

That reminds me, I’d also love to see if I could get a small box running FreeBSD or NetBSD for a wireless access point and router. I know ipf(8) and FreeBSD’s flavour of pf(8) more than anything else, and just enough FreeBSD ipfw(8) to be dangerous.

By Ruben Schade in Sydney, 2025-01-18.

Now, if you have been following the development of EndBASIC, this is not surprising. The defining characteristic of the EndBASIC console is that it’s hybrid as the video shows. What’s newsworthy, however, is that the EndBASIC console can now run directly on a framebuffer exposed by the kernel. No X11 nor Wayland in the picture (pun intended).

But how? The answer lies in NetBSD’s flexible wscons framework, and this article dives into what it takes to render graphics on a standard Unix system. I’ve found this exercise exciting because, in the old days, graphics were trivial (mode 13h, anyone?) and, for many years now, computers use framebuffer-backed textual consoles. The kernel is obviously rendering “graphics” by drawing individual letters; so why can’t you, a user of the system, do so too?

↫ Julio Merino

This opens up a lot of interesting use cases and fun hacks for developers to implement in their CLI applications. All the code in the article is – as usual – way over my head, but will be trivial for quite a few of you.

The mentioned EndBASIC project, created by the author, Julio Merino, is fascinating too:

EndBASIC is an interpreter for a BASIC-like language and is inspired by Amstrad’s Locomotive BASIC 1.1 and Microsoft’s QuickBASIC 4.5. Like the former, EndBASIC intends to provide an interactive environment that seamlessly merges coding with immediate visual feedback. Like the latter, EndBASIC offers higher-level programming constructs and strong typing.

EndBASIC’s primary goal is to offer a simplified and restricted DOS-like environment to learn the foundations of programming and computing, and focuses on features that quickly reward the learner. These include a built-in text editor, commands to manipulate the screen, commands to interact with shared files, and even commands to interact with the hardware of a Raspberry Pi.

↫ EndBASIC website

Being able to run this on a machine without having to load either X or Wayland is a huge boon, and makes it accessible fast on quite a lot of hardware on which a full X or Wayland setup would be cumbersome or slow.

Clara and I had the brilliant idea of checking out a new Japanese restaurant two suburbs over last night for dinner. It was a bit of a walk, but absolutely worth it. Teriyaki salad with sesame sauce, and a small bowl of miso… wow. The way to my heart is hugs, Arabica, and simple but tasty Asian food.

We’re into year two of our 10,000 steps a day challenge (!!!), so naturally we decided to walk home instead of catching the train. There was a light drizzle, but we were in high spirits having recharged our Japanese batteries again. It was cool but not cold, the tree-lined roads were quiet, and we could hear all those wonderful Australian birds. There’s nothing else like it in the world.

Then it started. Lightning in the distance so bright it lit up the night. It was continuous and unrelenting, as though it was striking the Earth every other second. The wind hit soon after; a gust so strong it nearly knocked us over, and made mincemeat of our golf umbrella. And then… the rain.

We were near a small office building, so we rushed into its undercover car park for shelter. We looked back and saw the street lights illuminating the near horizontal lashings of water; a continuous steam that was only growing in intensity. Trees and poles were swaying to an extent I didn’t think possible. The faint sounds of sirens, the tinkling of glass, and the flickering of lights. Fun.

Singapore had some violent storms, but the strongest I ever experienced was while travelling with Clara in Hong Kong a few years ago. We were in transit to Kansai, but decided to spent a few days there. It was the monsoon season, and I don’t think I’ve ever been that drenched in public outside a pool before. Umbrellas are useless against that violent, swirling wind and rain. I still remember making it back to the hotel absolutely soaked through, and having to go buy waterproof shoes the following day!

Back in the present, we agreed this was almost as violent. We kept peeking back outside the relative safety of the undercover car park, hoping the water and wind would eventually subside, and we could go home. Unfortunately, it was not to be. Half an hour passed, and we agreed we had no choice.

We left the comforting refuge of the empty, quiet car park and sprinted out as carefully as we could to the intersection across from our home. It took less than ten seconds for our clothes to be saturated, which immediately became bone-chillingly cold with the howling wind! The rain drops hitting my face actually hurt, as though we were being shot at. I could barely hear what Clara was saying.

It felt like we were standing there, totally exposed to the elements at that fscking intersection for an age, but eventually the light gave us permission to cross. We sauntered across in our sopping clothes, and made our way across the pavement and up the stairs to our building. There’s certainly a sense of freedom about splashing into puddles and not caring about your shoes, because they’re already so waterlogged they’re more rain than foot.

We threw all our clothes off into the spare bathroom and cranked up the dehumidifier! To my surprise, I saw small nicks in my face right where the water had hit. Validation! But also, ow? How is that possible?

I unmounted my FreeBSD ZFS pools and NetBSD cgd stores, then turned off and unplugged our computers and Hi-Fi gear. I’d lived through enough electrical storms back home that I didn’t want to risk it. Alas, I’d also wired the floor lamps into the same board as the PlayStations which was now disconnected, so we didn’t have much light. Oh well, it definitely added to the mood. Alas, our poor little pot plant outside was knocked off his perch, though fortunately he was still in one piece.

Phew. If that Hong Kong monsoon was the most violent storm I’d ever been in, this came in second. Wowza.

By Ruben Schade in Sydney, 2025-01-16.

This has come up a few times, but Steven G. Harms was the latest to ask. Not that I need an excuse to write about BSD, mind!

I ran tcsh(1) from base as my shell for most of my time as a handsome—or not—FreeBSD user. I prefer the C-style syntax for dotfile configuration and scripting, even if its use was “widely considered harmful”. I just found it more natural to read and write, though I’ve also said that about Perl, so take that how you will.

I’m also a firm believer in getting good at the defaults. Until recently, tcsh(1) was the default shell for root, meaning you were guaranteed to be dropped to it if you were tasked with logging into a FreeBSD machine somewhere. That is, unless someone changed the shell, hopefully to something else from base lest the ports system break! Ask me how a younger and more reckless Ruben learned that the hard way.

I’m glad I spent the time learning the muscle memory for basic loops and other structures in tcsh(1), just as I took the time to learn nvi back in the day. It sucks being in a situation where you have to fix something, and are stymied by an unfamiliar environment or set of tools you can’t easily use. This is also why I’m a fan of rational, reasonable defaults, but that’s a post for another time.

Today, I use two different shells depending on context. I use plain sh(1) for servers and remote machines that I won’t otherwise be regularly interacting with because, again, it’s now the default. Scripts written against this are also easier to be made portable, so I can run them on NetBSD, illumos, or Linux. If I do need to something more complicated, I still have tcsh(1) to fall back on (though I find myself reaching for it less and less now, which is bittersweet).

(Thanks to dear Internet friend Tim Chase—gah not Jim!—for pointing out that I meant “remote” there, not “remove”! Me, make a spelling mistake on my blog? That’s unpossible).

For regular interactive use on desktops and laptops on FreeBSD, NetBSD, and even Penguins though, I use the Portable OpenBSD Korn Shell, or oksh(1). This is the variant of ksh(1) on OpenBSD, and its default shell. It’s fast, well documented, implements the subset of interactive features I actually use, and is easily customised with dotfiles using years of ksh(1) examples. It’s another tool alongside OpenSSH, LibreSSL, and doas(1) from OpenBSD I benefit from, even though I don’t run the OS. I hope to add their permissive-licenced Game of Trees and openrsync(1) to that list at some point too.

Nothing too exotic I suppose, but it works great for me :).

By Ruben Schade in Sydney, 2025-01-12.

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.

Launched in 1998, the 380Z was one very fine ThinkPad. It was the last ThinkPad to come in the classic bulky and rectangular form factor. It was also one of the first to feature a huge 13.3″ TFT display, powerful 233MHz Pentium II, and whopping 160 megs of RAM.

I recently stumbled upon one in perfect condition on eBay, and immediately thought it’d be a cool vintage gadget to put on the desk. I only wondered if I could still use it for some slow-paced, distraction-free coding, using reasonably modern software.

↫ Luke’s web space

You know where this is going, right?

I evaluated a bunch of contemporary operating systems, including different variants of BSD and Linux. Usually, the experience was underwhelming in terms of performance, hardware support and stability. Well… except for NetBSD, which gave me such perfectly smooth ride, that I thought it was worth sharing.

↫ Luke’s web space

Yeah, of course it was going to be NetBSD (again). This old laptop, too, can run X11 just fine, with the EMWM that we discussed quite recently – in fact, bringing up X required no configuration, and a simple startx was all it needed out of the box. For web browsing, Dillo works just great, and building it took only about 20 minutes. It can even play some low-fi music streams from the internet, only stuttering when doing other processor-intensive tasks. In other words, this little machine with NetBSD turns out to be a great machine for some distraction-free programming.

Look, nobody is arguing that a machine like this is all you need. However, it can perform certain specific, basic tasks – anything being better than sending it to a toxic landfill, with all the transportation waste and child labour that entails. If you have old laptops lying around, you should think twice about just sending them to “recycling” (which is Western world speak for “send to toxic landfill manned by children in poor countries”), since it might be quite easy to turn it into something useful, still.

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?

After years of inactivity, the Kyua project has graduated as an open source citizen and has a new home under the FreeBSD umbrella!

But uh… wait, what is Kyua and why is this exciting? To resolve confusion and celebrate this milestone, I’d like to revisit what Kyua is, how it came to be, why I stopped working on it for a while, why that was a problem for FreeBSD—and, indirectly, NetBSD—and how Kyua being free software has helped keep it alive.

As usual, partway through a couple weeks in Mallorca, we’re just getting the hang of it. After a few days of only the pool, it’s been pool mornings and beach afternoons. Every day, each kid gets more bold in both. I’ve managed to avoid getting sunburnt so far, though it’s getting harder to stay ahead of the situation. For mealtimes it’s kind of fun to be stuck in a tiny kitchen trying to cook my way out; bedtimes, down a sleepable room due to a broken air conditioner, were less so. My carcass got taken over by mosquitoes, who then rented most of it back to me. In a few days I might be ready to buy them out.

Usually here I’d consider taking a nap when the littles do. Definitely tired enough. But a little solo computer time feels more like what I’m needing: Refactoring some code, backing up some photos, updating pkgsrc stuff, writing posts on my website, that sort of thing.

For this summer vacation we’re hopping around more, which happens to simplify our transatlantic travel days. (Traditionally we’d have connecting flights before arriving anywhere.) One flight into Munich, where we stayed in the area for a few days visiting in-laws. From there a quick hop to Mallorca, the meat in our vacation sandwich. From here a quick-ish hop to Hannover for a week back in the little north-central German village where we lived out the first two years of COVID. Then we’ll drive to Frankfurt to see friends before our return flight to New York. Hopping around like this means we get to see more people and places, in exchange for which we get to find out what happens when kids try to sleep in a wider variety of environments and configurations. So far, sokay.

I wanted to clear all the newsletters items I’ve saved, so you are getting links until my inbox no longer paginates.

• Just Use Postgres for Everything.  (via)
• When web search failed me for Postgres.
• The Future of MySQL is Postgres. (target from previous link)
• From Cloud Chaos to FreeBSD Efficiency.  Or any BSD.   (via)
• Layers and Gateways, a historical view.  Railways vs networks.
• The workstation you wanted in 1990, in your pocket.
• Paul Ceruzzi has a Substack.
• pkgsrc-2024Q2 is out.
• X Window System at 40.  (via)
• Some TENEX history.
• Why shitty robots are the antidote of perfectionism, a video.  Her store has neat stuff.
• Scifiinterfaces.com.  I linked to this in 2013 but it’s still going.  (reminded via)
• Largest old computer I’ve seen a person keep yet.  (via)
• Tiny TV 2.  (via)
• UNLICENSED: Bootlegging As Creative Practice, a book.  (via)
• One Page Dungeon Reviews.  (via)