Software Development

840 Articles

They Weren’t Joking: Gentoo WAS Ported To GNU Hurd

April 13, 2026 by 46 Comments

Long ago, in the aftermath of the UNIX wars, three kernels emerged from the rubble: BSD, Linux, and Hurd. BSD, being UNIX, was held back by legal wrangling in the aftermath of the wars, and that allowed Linux to pull ahead to a pole position it still enjoys to this day. BSD has its following, of course, but Hurd? GNU Hurd seemed destined to languish… until April 1st, 2026, when the Gentoo Linux distribution was ported to the Free Software Foundation’s kernel.

It turns out, they weren’t actually joking. The joke part was that they were moving fully to the Hurd kernel, away from Linux– you can absolutely still run Gentoo with the Linux kernel, and make no mistake, that’s still the default and best-supported option. Options are good, though, and the Gentoo team has decided that it’s time to add some options to the kernel space, and give the Hurd some time in the sun.

Unlike the Linux kernel, which follows closely the monolithic UNIX framework– and the BSD-Unix kernel, which is Unix–GNU Hurd is a microkernel architecture, based originally on the Mach kernel. In that, it’s rather like MacOS. Unlike MacOS, given its roots in the Free Software Foundation, GNU Hurd is 100% free and open source. There are advantages to a microkernel architecture– it keeps drivers out of kernel space so a dodgy WiFi adapter can’t crash your system, for example– but the big disadvantage is, of course, drivers. Both Linux and BSD drivers can be ported, but that takes work and many of them have not been.

Still, now that Microsoft has become a major contributor to the Linux kernel, we could see a lot of the old-school Linux users who talk about “win-doze” and still spell Microsoft with a dollar sign being tempted to join the Hurd. If that appeals to you and you’re not into Gentoo, Debian has quietly let you install with the Hurd kernel for years now. It’s either that or embrace BSD and escape the chaos vortex.

The big three aren’t the only POSIX kernels out there, of course– there’s even one written entirely in Rust, for the die hard rustaceans amongst you.

Kiki Is The Unknown Array Language

April 11, 2026 by 12 Comments

Kiki bills itself as the “array programming system of unknown origin.” We thought it reminded us of APL which, all by itself, isn’t a bad thing.

The announcement post is decidedly imaginative. However, it is a bit sparse on details. So once you’ve read through it, you’ll want to check out the playground, which is also very artistically styled.

If you explore the top bar, you’ll find the learn button is especially helpful, although the ref and idiom buttons are also useful. Then you’ll find some examples along with a few other interesting tidbits.

Continue reading “Kiki Is The Unknown Array Language” →

USB, Abstracted

April 9, 2026 by 16 Comments

Modern technology builds on abstractions. Most application programmers today don’t know what a non-maskable interrupt is, nor should they have to. Even fewer understand register coloring or reservation stations for instruction scheduling, and fewer still can explain the physics behind the transistors in the CPU. Sometimes tech starts out where you need to know everything (programming a bare-metal microprocessor, for example) and then evolves to abstraction. That’s where [WerWolv] wants to get you for writing USB code using the recent post USB for Software Developers.

Many USB tutorials assume you want to know about the intricacies of protocol negotiation, information about the hardware layer, and that you are willing to write a Linux kernel module to provide a driver. But thanks to abstraction, none of this has been absolutely necessary for many use cases for a long time.

While the post focuses on Linux, there is libusb for Windows. We presume the same principles would apply, more or less.

Continue reading “USB, Abstracted” →

So Expensive, A Caveman Can Do It

April 6, 2026 by 17 Comments

A few years back a company had an ad campaign with a discouraged caveman who was angry because the company claimed their website was “so easy, even a caveman could do it.” Maybe that inspired [JuliusBrussee] to create caveman, a tool for reducing costs when using Claude Code.

The trick is that Claude, like other LLMs, operates on tokens. Tokens aren’t quite words, but they are essentially words or word fragments. Most LLM plans also charge you by the token. So fewer tokens means lower costs. However, LLMs can be quite verbose, unless you make them talk like a caveman.

Continue reading “So Expensive, A Caveman Can Do It” →

Writing An Open-World Engine For The Nintendo 64

March 29, 2026 by 7 Comments

Anyone who has ever played Nintendo 64 games is probably familiar with the ways that large worlds in these games got split up, with many loading zones. Another noticeable aspect is that of the limited drawing distance, which is why even a large open area such as in Ocarina of Time‘s Hyrule Field has many features that limit how far you can actually see, such as hills and a big farming homestead in the center. Yet as [James Lambert] demonstrates in a recent video, it’s actually possible to create an open world on the N64, including large drawing distances.

As explained in the video, the drawing distance is something that the developer controls, and thus may want to restrict to hit certain performance goals. In effect he developer sets where the far clipping plane is set, beyond which items are no longer rendered. Of course, there are issues with just ramping up the distance to the far clipping plane, as the N64 only has a 15-bit Z-buffer, after which you get ‘Z fighting’, where render order becomes an issue as it’s no longer clear what is in front of what.

One fix is to push the near clipping plane further away from the player, but this comes with its own share of issues. Ergo [James] fixed it by doing two render passes: first all the far-away objects with Z-buffer disabled, and then all the nearby objects. These far-away objects can be rendered back-to-front with low level-of-detail (LoD), so this is relatively fast and also saves a lot of RAM, as the N64 is scraping by in this department at the best of times.

In the video the full details of this rendering approach, as well as a new fog rendering method, are explained, with the code and such available on GitHub for those who wish to tinker with it themselves. [James] and friends intend to develop a full game using this engine as well, so that’s definitely something to look forward to.

Continue reading “Writing An Open-World Engine For The Nintendo 64” →

Reconstructed SC62015 Opcode Reference For Sharp Pocket Computers

March 26, 2026 by 4 Comments

Pocket computers like Sharp’s 8-bit computing marvels were a big part of the 1980s, providing super-portable processing power to anyone who wanted a bit more than what something like a scientific calculator could provide at the time. These days they are mostly just a collector’s item for retrocomputing enthusiasts, which also means that a lot of the knowledge about how to program the CPUs in them is at risk of being lost.

This is why [gikonekos] decided to combine as much knowledge they can glean from official documentation into a reference project on GitHub for the SC62015 equipped Sharp pocket computers like the PC-E550.

Generally you’d program in Sharp’s dialect of BASIC on these computers, such as the ‘PLAY3’ program that [gikonekos] recently unearthed from a November 1993 copy of ‘Pocket Computer Journal’ using which you can create polyphonic tunes. This only unlocks a small part of what the hardware can do, of course, so having a full opcode reference like this is important.

While still a work in progress, it’ll eventually contain the full opcode and register tables, addressing modes, instruction summaries and of course a full accounting of how all of this was reconstructed. As the original Sharp documentation wasn’t released to the public, providing these scans is also not a goal, especially not under any kind of free license.

A cursory search reveals an instruction table for the PC-E500 from 1995 by [Andrew Woods], so documenting this is not a new thing, although at the time these Sharp pocket PCs didn’t count as ‘retro systems’ yet.

Forgetfulino Puts Back Up Of Source Inside The Binary

March 18, 2026 by 25 Comments

How often have you pulled out old MCU-based project that still works fine, but you have no idea where the original source code has gone? Having the binary image and the source code as separate things to keep track of usually isn’t a problem, but there’s something to be said for adding the source — and documentation — to this image if you have some flash to spare. This is basically what the Forgetfulino Arduino library by [Nader Al Khatib] does.

Essentially, the library compresses the source files and assigns it to be burned onto the flash alongside the binary. There is also a bit of code added to the firmware so that this code can be retrieved via the serial port at any time, negating the need for a firmware dump and manual disassembly. For ease of use, the library has an Arduino IDE extension that automates the process. The basic idea could also be adapted to different environments should anyone wish to take up the challenge.

You probably wouldn’t want debug builds to feature this additional payload as writing it to flash will eat up time and write cycles. But for a release build that will be put out in the (literal) field for a few years or even decades, it could be very convenient. After all, you never know when that Git repository that you relied on might go AWOL.