Software Development

847 Articles

The Y2K Bug In BSD 2.11 That Survived 2000

June 15, 2026 by 3 Comments

A year before the arrival of the brand-new 21st millennium, 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 20 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.

How To Let Everyone Keep A Secret

May 28, 2026 by 22 Comments

Someone calls you at work and says, “Don’t tell anyone, but…” If you are like most people, there are one or two people you will pass it along to with the same admonishment. In fact, they are probably repeating it from someone else, and you are on their list of two people. So for really big secrets, you need a way to spread the secret out so that no one has any real information about the secret, but a certain number of people together can decode it. As [neeaj] explains in a recent post about Shamir’s Secret Sharing, [Adi Shamir] (the S in RSA encryption) devised a way to do this very well in 1979, and the core concept is very easy to understand.

The explanation works with geometry. The equation for a line is y=mx+b, where m is the slope and b is the y-intercept (that is, where the line touches the y-axis when X is 0. An infinite number of lines cross the Y axis at, for example, 10. The line y=3x+10 does, and so does the line y=-1.41x+10. You can’t guess the b value from just the slope, because any slope will satisfy the equation.

Continue reading “How To Let Everyone Keep A Secret” →

Linux Distributions And Who Is Responsible For The Software

May 27, 2026 by 58 Comments

The topic of downstream and upstream is an important one in the Linux ecosystem, where from one base distribution you can go many layers of distros deep before even looking at all the other base distributions. Within that veritable jungle you get questions about who is responsible for packaging software, where to report bugs found with a specific application, as well as what ‘LTS’ truly means in a consumer context. These and other points are raised in a recent video by [Brodie Robertson], with many examples of things going tragically wrong.

There’s a good argument to be made that ultimately it is the distro that is responsible for the software that they provide via their repositories. As [Brodie] shows in the video, there are a few cases where an ‘LTS’ distro uses an old version of some software that contains a bug that has been fixed a while ago, so reporting it to the developer is rather pointless, while the distro maintainers should fix it with backporting of patches or updating the version.

From an end user experience this also makes the most sense, as in the end they just want to have the Windows experience of downloading a proverbial installer, clicking through whatever dialogs pop and have working software. If the software is provided via the distro, it is their responsibility, the same way that you contact the developer if you get a DEB or RPM from a GitHub project page and it doesn’t work.

This current Linux Chaos Vortex can be called a major issue when e.g. FreeBSD has no such upstream/downstream issues, with cross-platform installers being basically impossible on Linux ever since the Linux Standard Base effort died.

Perhaps Linux will get a distroless future, however, which may finally herald that Year of the Linux Desktop.

Continue reading “Linux Distributions And Who Is Responsible For The Software” →