Software Development

835 Articles

Haiku Isn’t Just For X86 Anymore, Boots On ARM In QEMU

April 15, 2026 by 11 Comments

Ever since it was called OpenBeOS, Haiku has targeted the x86 platform. That makes good sense: it’s hard enough maintaining a niche system on ubiquitous hardware. But x86 isn’t the only game in town anymore. Apple’s doing very well on ARM, Linux runs on oodles of ARM SBCs, and even Windows uh, exists, on that architecture, so why not Haiku? That’s what [smrobtzz] figured, and thanks to his work you can now run Haiku on ARM, in QEMU.

There’s no image available as yet — you still need to bootstrap your own from a working system, and ironically that system cannot be Haiku. [smrobtzz] apparently used MacOS, which makes sense as his ultimate goal is apparently to go where only Aishi Linux has gone before and boot Haiku on his M1 MacBook. There had been previous efforts to get Haiku going on Raspberry Pi hardware, which seems logical considering how lightweight the operating system is, but they’re apparently nowhere near booting either. QEMU is a good start.

Interestingly, according to the ports page, Haiku is “functional” on both RISC V QEMU and the now-discontinued HiFive Unmatched SBC. We don’t seem to have covered it, but that milestone happened five year ago. Given how most RISC V boards currently available are a bit slow for modern desktop Linux, Haiku would likely be a breath of fresh air. The BeOS-descended system might be single user, but it’s snappy.

We reported a couple of years back that Haiku was daily-drivable on x86 ,it’s only gotten better since then, assuming you choose the right hardware. Hardware support is always the hard part about alternative OSes, but Haiku users are absolutely spoiled compared to fans of MorphOS, which still only runs on G4 or G5 PowerPC, and even then not only some hardware.

A 6502 All In The Data

April 15, 2026 by 11 Comments

Emulating a 6502 shouldn’t be that hard on a modern computer. Maybe that’s why [lasect] decided to make it a bit harder. The PG_6502 emulator uses PostgreSQL. All the CPU resources are database tables, and all opcodes are stored procedures. Huh.

The database is pretty simple. The pg6502.cpu table has a single row that holds the registers. Then there is a pg6502.mem table that has 64K rows, each representing a byte. There’s also a pg6502.opcode_table that stores information about each instruction. For example, the 0xA9 opcode is an immediate LDA and requires two bytes.

The pg6502.op_lda procedure grabs that information and updates the tables appropriately. In particular, it will load the next byte, increment the program counter, set the accumulator, and update the flags.

Honestly, we’ve wondered why more people don’t use databases instead of the file system for structured data but, for us, this may be a bit much. Still, it is undoubtedly unique, and if you read SQL, you have to admit the logic is quite clear.

We can’t throw stones. We’ve been known to do horrible emulators in spreadsheets, which is arguably an even worse idea. We aren’t the only ones.

New Linux Kernel Rules Put The Onus On Humans For AI Tool Usage

April 14, 2026 by 17 Comments

It’s fair to say that the topic of so-called ‘AI coding assistants’ is somewhat controversial. With arguments against them ranging from code quality to copyright issues, there are many valid reasons to be at least hesitant about accepting their output in a project, especially one as massive as the Linux kernel. With a recent update to the Linux kernel documentation the use of these tools has now been formalized.

The upshot of the use of such Large Language Models (LLM) tools is that any commit that uses generated code has to be signed off by a human developer, and this human will ultimately bear responsibility for the code quality as well as any issues that the code may cause, including legal ones. The use of AI tools also has to be declared with the Assisted-by: tag in contributions so that their use can be tracked.

When it comes to other open source projects the approach varies, with NetBSD having banished anything tainted by ‘AI’, cURL shuttering its bug bounty program due to AI code slop, and Mesa’s developers demanding that you understand generated code which you submit, following a tragic slop-cident.

Meanwhile there are also rising concerns that these LLM-based tools may be killing open source through ‘vibe-coding’, along with legal concerns whether LLM-generated code respects the original license of the code that was ingested into the training model. Clearly we haven’t seen the end of these issues yet.

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

April 13, 2026 by 43 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 16 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” →