A Linux Power User Puts SteamOS To Work

January 12, 2026 by Bryan Cockfield 40 Comments

The line between a Linux user and a Linux power user is a bit gray, and a bit wide. Most people who install Linux already have more computer literacy than average, and the platform has long encouraged experimentation and construction in a way macOS and Windows generally aren’t designed for. Traditional Linux distributions often ask more of their users as well, requiring at least a passing familiarity with the terminal and the operating system’s internals especially once something inevitably breaks.

In recent years, however, a different design philosophy has been gaining ground. Immutable Linux distributions like Fedora Silverblue, openSUSE MicroOS, and NixOS dramatically reduce the chances an installation behaves erratically by making direct changes to the underlying system either impossible or irrelevant.

SteamOS fits squarely into this category as well. While it’s best known for its console-like gaming mode it also includes a fully featured Linux desktop, which is a major part of its appeal and the reason I bought a Steam Deck in the first place. For someone coming from Windows or macOS, this desktop provides a familiar, fully functional environment: web browsing, media playback, and other basic tools all work out of the box.

As a Linux power user encountering an immutable desktop for the first time, though, that desktop mode wasn’t quite what I expected. It handles these everyday tasks exceptionally well, but performing the home sysadmin chores that are second nature to me on a Debian system takes a very different mindset and a bit of effort. Continue reading “A Linux Power User Puts SteamOS To Work” →

Bose SoundTouch Smart Speakers Get An Open Source Lifeline

January 9, 2026 by Maya Posch 10 Comments

After initially announcing that Bose will completely turn off all ‘smart’ features in its SoundTouch series of speaker products, the company has seemingly responded to the wave of unhappy feedback with a compromise solution. Rather than the complete shutdown and cut-off that we reported on previously, Bose will now remove cloud support as its servers shut down, but the SoundTouch mobile app will get an update that gets truncated to just the local support functions. Bose also made the SoundTouch Web API documentation available as a PDF document.

The shutdown date has also been extended from the original February 18 to May 6th of this year. Although these changes mean that the mobile app can no longer use music services, features like grouping speakers and controlling playback will keep working. Features such as presets which were cloud-based will naturally stop working.

With the web API documentation made public it remains to be seen how helpful this will be. From a quick glance at the PDF documentation it appears to be a typical REST API, using HTTP on port 8090 on the SoundTouch device, with an SGML-style tag system to format messages. In so far as the community hasn’t already reverse-engineered this API it’s at least nice to have official documentation.

Different Algorithms Sort Christmas Lights

December 29, 2025 by Bryan Cockfield 10 Comments

Sorting algorithms are a common exercise for new programmers, and for good reason: they introduce many programming fundamentals at once, including loops and conditionals, arrays and lists, comparisons, algorithmic complexity, and the tradeoff between correctness and performance. As a fun Christmas project, [Scripsi] set out to implement twelve different sorting algorithms over twelve days, using Christmas lights as the sorting medium.

The lights in use here are strings of WS2812 addressable LED strips, with the program set up to assign random hue values to each of the lights in the string. From there, an RP2040-based platform will step through the array of lights and implement the day’s sorting algorithm of choice. When operating on an element in the array the saturation is turned all the way up, helping to show exactly what it’s doing at any specific time. When the sorting algorithm has finished, the microcontroller randomizes the lights and starts the process all over again.

For each of the twelve days of Christmas [Scripsi] has chosen one of twelve of their favorite sorting algorithms. While there are a few oddballs like Bogosort which is a guess-and-check algorithm that might never sort the lights correctly before the next Christmas (although if you want to try to speed this up you can always try an FPGA), there are also a few favorites and some more esoteric ones as well. It’s a great way to get some visualization of how sorting algorithms work, learn a bit about programming fundamentals, and get in the holiday spirit as well.

How Wind Nearly Took Down Boulder NTP

December 29, 2025 by Fenix Guthrie 28 Comments

NTP is one of the most interesting and important, but all too forgotten, protocols that makes the internet tick. Accurate clock synchronization is required for everything ranging from cryptography to business and science. NTP is closely tied around a handful of atomic clocks, some in orbit on GPS satellites, and some in laboratories. So the near-failure of one such atomic clock sparked a rather large, and nerdy, internet debate.

On December 17, 2025, the Colorado front range experience a massive wind storm. The National Center for Atmospheric Reassure in Boulder recorded gusts in excess of 100 mph (about 85 knots or 160 kph). This storm was a real doozy, but gusts this strong are not unheard of in Boulder either. That is no small reason the National Renewable Energy Laboratory (now the National Laboratory of the Rockies) has a wind turbine testing facility in the neighborhood.

Continue reading “How Wind Nearly Took Down Boulder NTP” →

Only Known Copy Of UNIX V4 Recovered From Tape

December 29, 2025 by Maya Posch 43 Comments

UNIX version 4 is quite special on account of being the first UNIX to be written in C instead of PDP-11 ASM, but it was also considered to have been lost to the ravages of time. Joyfully, we can report that the more than fifty year old magnetic tape that was recently discovered in a University of Utah storeroom did in fact contain the UNIX v4 source code. As reported by Tom’s Hardware, [Al Kossow] of Bitsavers did the recovery by passing the raw flux data from the tape read head through the ReadTape program to reconstruct the stored data.

Since the tape was so old there was no telling how much of the data would still be intact, but fortunately it turned out that the tape was not only largely empty, but the data that was on it was in good nick. You can find the recovered files here, along with a README, with Archive.org hosting the multi-GB raw tape data. The recovered data includes the tape file in SimH format and the filesystem

Suffice it to say that you will not run UNIX v4 on anything other than a PDP-11 system or emulated equivalent, but if you want to run its modern successors in the form of BSD Unix, you can always give FreeBSD a shot.

Cloudflare’s Outages And Why Cool Kids Test On Prod

December 28, 2025 by Maya Posch 44 Comments

Every system administrator worth their salt knows that the right way to coax changes to network infrastructure onto a production network is to first validate it on a Staging network: a replica of the Production (Prod) network. Meanwhile all the developers who are working on upcoming changes are safely kept in their own padded safety rooms in the form of Test, Dev and similar, where Test tends to be the pre-staging phase and Dev is for new-and-breaking changes. This is what anyone should use, and yet Cloudflare apparently deems itself too cool for such a rational, time-tested approach based on their latest outage.

In their post-mortem on the December 5th outage, they describe how they started doing a roll-out of a change to React Server Components (RSC), to allow for a 1 MB buffer to be used as part of addressing the critical CVE-2025-55182 in RSC. During this roll-out on Prod, it was discovered that a testing tool didn’t support the increased buffer size and it was decided to globally disable it, bypassing the gradual roll-out mechanism.

This follows on the recent implosion at Cloudflare when their brand-new, Rust-based FL2 proxy keeled over when it encountered a corrupted input file. This time, disabling the testing tool created a condition in the original Lua-based FL1 where a NIL value was encountered, after which requests through this proxy began to fail with HTTP 500 errors. The one saving grace here is that the issue was detected and corrected fairly quickly, unlike when the FL2 proxy fell over due to another issue elsewhere in the network and it took much longer to diagnose and fix.

Aside from Cloudflare clearly having systemic issues with actually testing code and validating configurations prior to ‘testing’ on Prod, this ought to serve as a major warning to anyone else who feels that a ‘quick deployment on Prod’ isn’t such a big deal. Many of us have dealt with companies where testing and development happened on Staging, and the real staging on Prod. Even if it’s management-enforced, that doesn’t help much once stuff catches on fire and angry customers start lighting up the phone queue.

Libxml2 Narrowly Avoids Becoming Unmaintained

December 23, 2025 by Maya Posch 56 Comments

In an excellent example of one of the most overused XKCD images, the libxml2 library has for a little while lost its only maintainer, with [Nick Wellnhofer] making good on his plan to step down by the end of the year.

XKCD's dependency model — Modern-day infrastructure, as visualized by XKCD. (Credit: Randall Munroe)

While this might not sound like a big deal, the real scope of this problem is rather profound. Not only is libxml2 part of GNOME, it’s also used as dependency by a huge number of projects, including web browsers and just about anything that processes XML or XSLT. Not having a maintainer in the event that a fresh, high-risk CVE pops up would obviously be less than desirable.

As for why [Nick] stepped down, it’s a long story. It starts in the early 2000s when the original author [Daniel Veillard] decided he no longer had time for the project and left [Nick] in charge. It should be said here that both of them worked as volunteers on the project, for no financial compensation. This when large companies began to use projects like libxml2 in their software, and were happy to send bug reports. Beyond a single Google donation it was effectively unpaid work that required a lot of time spent on researching and processing potential security flaws sent in.

Of note is that when such a security report comes in, the expectation is that you as a volunteer software developer drop everything you’re working on and figure out the cause, fix and patched-by-date alongside filing a CVE. This rather than you getting sent a merge request or similar with an accompanying test case. Obviously these kind of cases seems to have played a major role in making [Nick] burn out on maintaining both libxml2 and libxslt.

Fortunately for the project two new developers have stepped up to take over as maintainers, but it should be obvious that such churn is not a good sign. It also highlights the central problem with the conflicting expectations of open source software being both totally free in a monetary fashion and unburdened with critical bugs. This is unfortunately an issue that doesn’t seem to have an easy solution, with e.g. software bounties resulting in mostly a headache.