Software Development

849 Articles

Skip The Embedded Filesystem With The TAR-like UTFS Format

June 17, 2026 by No comments

If you need to store some data on a resource-constrained embedded platform, the prospect of dragging in a dependency for something like FAT filesystem access to flash or other storage medium can seem rather daunting. Not only is your binary size now significantly larger, the overhead of these filesystems is also not insignificant as they were not really designed for this type of environment. Here [Drew Gaylo]’s UTFS format is an interesting alternative to just writing raw binary data to said storage medium.

As explained in the accompanying introduction article, the basic idea is similar in scope but very much slimmed down compared to the venerable Tape ARchive (TAR) format, hence the Micro (µ) Tar File System name. The provided UTFS implementation is quite small, spanning two source files in C99 with zero heap usage. Targeting a custom store medium requires implementing one read and one write function to match the underlying platform.

A couple of examples are also provided, covering using the built-in Flash of a SAMD20 MCU and the EEPROM of an ATmega328. Compared to raw binary data that’d have to be fully rewritten, UTFS allows for sections of the storage to be accessed as files and thus updated in-place.

A Brief History Of Unix Commands On Windows: CoreUtils (Again)

June 16, 2026 by 14 Comments

If you use Windows today and type ls, cat, grep, or awk in a terminal, there is a good chance something useful will happen. That was not always true. For most of the history of personal computing, Unix/Linux and Windows lived on opposite sides of a cultural border. Unix people had pipes, small composable tools, shell scripts, make, sed, awk, grep, tar, and the idea that everything was a file. Windows people had drive letters, backslashes, COMMAND.COM or cmd.exe, and an API that did not care much about what POSIX thought.

Yet there has always been a demand for Unix tools on Windows. Some of it came from programmers who wanted the same build scripts everywhere. Some came from administrators who missed grep and awk. Some came from companies trying to port big Unix applications to NT without rewriting them all. The result is a long, strange history of Unix-on-Windows layers, toolkits, compromises, and almost-but-not-quite compatibility.

Easy?

The simplest version of the problem sounds trivial. How hard can cat be? Open a file, copy bytes to standard output, done. Writing ls is a little more work, but Windows has directory APIs. Common commands like cp, mv, rm, mkdir are not very mysterious. Even pipes are not foreign to Windows. A lot of the everyday Unix command set can be ported as ordinary Win32 console programs with some path handling and enough patience.

But not all of Unix or Linux translates cleanly to Windows. The big issue is fork(). On Unix, a process can clone itself. The child gets a copy of the parent’s address space, open file descriptors, environment, signal state, and so on. Modern kernels make this efficient with copy-on-write memory, but the programming model is old and deeply baked into Unix. Shells use it constantly. Servers use it. Build systems use it. Scripting languages assume it exists, or at least that the surrounding environment behaves as though it does.

Windows process creation is different. Windows has CreateProcess(), which starts a new program. That is a perfectly reasonable model, but it is not fork() (more like fork()+exec()). If you are just launching notepad.exe, no problem. If you are trying to implement a POSIX shell that forks, redirects file descriptors, adjusts the environment, and then starts another program, the mismatch is extreme and you’ll have to do some strange things to fake things out.

One of the early commercial answers was the MKS Toolkit, originally from Mortice Kern Systems. MKS gave Windows users a pile of familiar commands, shells, and development tools. It was not just ls and friends; it included things like ksh, vi, grep, find, awk, make, and many of the utilities needed to move scripts and build procedures between Unix and Windows. The current PTC MKS documentation still describes it in exactly that spirit: Unix shells and hundreds of commands for interoperability with Windows.

MKS was attractive because it treated Windows as Windows. You were not necessarily pretending your machine was a Unix workstation. You were getting a Unix-flavored toolbox that could operate in a Windows environment. For many people, that was enough. You could write scripts, process text, drive builds, and avoid learning three different syntaxes for the same job.

Continue reading “A Brief History Of Unix Commands On Windows: CoreUtils (Again)” →

The Y2K Bug In BSD 2.11 That Survived 2000

June 15, 2026 by 14 Comments

A year before the arrival of the brand-new 21st century, the Year 2000 Bug was predicted to grind modern society to a halt and ensure that at the dawn of the year 2001, there’d be nothing left but the smoldering wreck of once great societies. Thanks to the concerted efforts of countless engineers, software developers, and many others, we were left with mostly just silly glitches, with one of these surviving bugs apparently just discovered, as [Van Heusden] reported on an NTPd bug in BSD 2.11.

To be fair, it is a pretty obscure one, as the demonstration involves BSD 2.11 on a PDP-11/70 from 1975, so it’s probably not something that still sees much use outside retrocomputing enthusiast circles. In the blog post, the demonstration involves connecting a specific adapter by Traconex, capable of receiving WWV/WWVH time signals, and setting it up for use by the NTPd prior to running the ntpd -a any -d -d -d -d command.

Continue reading “The Y2K Bug In BSD 2.11 That Survived 2000” →

yserver screenshot demonstrating compiz comptibility

Why Not Yserver? It’s Xserver, But Rust-y.

June 14, 2026 by 21 Comments

If you’re not into Wayland as a display manager, it seems like your options are slowly dwindling. Xorg isn’t exactly a hotbed of activity, and the one fork everyone knows about is best known as a political lightning rod. Luckily, Rust developers can apparently never see a tool without pulling it into their heavily oxidized bucket of crabs, so we now have another option: the creatively named yserver, released under the MIT license by [joske].

The name, yserver, for the record, is just a placeholder name, but we rather like the simple logic of “Y comes after X” — sure, you could call it X12, but that could imply continuity, and this is a clean break. It’s also not a full reimplementation of the huge, sprawling mess that Xorg has become over the decades. It can’t launch multiple screens and thus lacks full multi-monitor support. So, for now, it may be too bare-bones for some people’s use cases.

As it uses Vulkan, it is limited to relatively modern hardware, but has been tested on Intel, AMD, Nvidia, and Apple chips. The target kernel is good old Linux, but the docs do cover compiling for FreeBSD; just be aware that that’s very much a secondary target. FreeBSD users are probably used to that, though.

On Linux, a standalone DRM/KMS yserver can successfully run not just window managers but full desktops — specifically MATE, Cinnamon, and XFCE, as they’re not on the Wayland bandwagon. It even supports Compiz, in case you missed the cube and wiggly window animations. You can also use yserver via Xwayland or even Xorg. Speaking of Xorg, [joske] has run the X.Org X Test Suite (xts5) against this proposed successor, and it currently scores 66.2%, which seems pretty good considering the project explicitly does not plan to copy all of Xorg’s functionality.

Aside from multiple screens, one thing that would have been neat to see is support for the Asterinas rust-based Linux-compatible kernel — though if that project achieves full Linux compatibility, that may be a non-issue. Even if you aren’t an oxidization enthusiast, you might find reasons to be happy to see more competition in the display-manager market — after all, Wayland Will Never Be Ready For Every X11 User. If Xorg really is destined to the slow death critics predict, perhaps yserver could cover the holdouts.

The Merits Of Comment-Driven Development As Counterweight To TDD

June 11, 2026 by 48 Comments

The world of software has seen many paradigms come and go, all of which were supposed to revolutionize its development. Still, one of the basic tenets in engineering of there being no shortcuts to just doing the work properly also rings true in the field of software engineering: trying to skip ‘nice to haves’ like proper documentation, code formatting, and proper testing inevitably results in developers nervously trying to ignore the looming avalanche of technical and other project debts as they keep piling up.

While Test-Driven Development (TDD) once got praised as the silver bullet, the principle of writing tests before writing code merely postpones the inevitable project collapse. The elephant in the room is that you cannot pass on the basics in engineering and expect to come out fine on the other end. There’s a reason why phrases like “all tests green, successfully failed in production” have become common.

This is where the concept of Comment-Driven Development (CDD) comes into play. What started as a bit of a joke many years ago stuck in my mind and led me to my current approach in software development that tries to effectively mirror solid engineering principles.

Continue reading “The Merits Of Comment-Driven Development As Counterweight To TDD” →

The Winners Of The 2025 Obfuscated C Code Contest

June 9, 2026 by 12 Comments

One of the most exciting challenges available to any software developer is that of writing brilliantly working code that’s so obtuse, so indecipherable, and opaque, that even its own author would struggle to grasp its inner workings after returning to it a year later. While for some this is just how they naturally write code, for others it’s part of the International Obfuscated C Coding Challenge (IOCCC), with 2025’s entrants once again showing their mettle.

The IOCCC judges entries among a range of categories, as it can be hard to otherwise quantify what is the ‘best’ entry, with ground rules limiting what the entry can entail. Generally as long as your code adheres to the C11 standard with a source size of 4,993 bytes or less and final binary size of under 2,503, is accompanied by a GNU-style Makefile and doesn’t turn a judge’s computer into a raging inferno — it should qualify.

Among the winning entries we got fun ones like ‘Most likely to shock’ by [Yusuke Endoh] which generates a Lichtenberg figure in ASCII in the terminal. There are also quite practical ones, such as the ‘Best real emulator’ winner by [Nick Craig-Wood], whose entry is a functional Game Boy emulator. Although not full-featured, it can play a range of real GB ROMs, just do not expect to get any sounds or fancy terminal-based graphics.

Automatic Tutorial Generator Is Perhaps The Best-Case For Vibe Coding

June 9, 2026 by 34 Comments

Quick question: how did you learn to code? It probably wasn’t bribing someone a year or two ahead of you in CS to finish all your homework, but that’s exactly what ‘vibe coders’ are doing — even in class. Odds are, you learned by working through exercises, following tutorials, and doing it yourself. Finding good tutorials isn’t getting any easier in the age of LLMs, and that’s where [Deven Jarvis]’s Lathe comes in: it’s a project to get an LLM to make the tutorial for you. Instead of doing the work for you, it gets the clanker to show you how to do it yourself.

Everyone’s different, so this may not apply to you, but it’s a journey/destination sort of problem. Some people just want a piece of software, and they can vibe code until the oceans dry up and will have no interest in this project. Other people take great joy in learning how to do things; [Deven] is one of those. A good tutorial is a great way to learn, since it artificially softens the learning curve compared to just jumping into a project with a man page or a datasheet.

Of course you’re still faced with the hallucination problem, something [Deven] admits in his excellent write-up. As he points out, the advantage is that you can call whatever model you plug into Lathe on its BS, and try and get a correct answer. Try that on Reddit, or most other places online. Sure, the tutorials aren’t going to match the best human-generated content, and [Deven] admits that. He’s using it for topics (like slicer design) that don’t have easy tutorials online — and sadly, his prediction that nobody is going to bother making good learning resources like they used to when they’ll just be scraped by LLMs is very likely true. It’s not that your options are vibe code or vibe-generated tutorial, but if that’s the direction the world is going, we’ll take the tutorial, thanks.

Getting the LLM to hold your hand through a tutorial might not appeal to the most Butlerian among us, but it’s a big step from that to the full cognitive surrender some people worry about.