ISS Medical Emergency: An Orbital Ambulance Ride

Over the course of its nearly 30 years in orbit, the International Space Station has played host to more “firsts” than can possibly be counted. When you’re zipping around Earth at five miles per second, even the most mundane of events takes on a novel element. Arguably, that’s the point of a crewed orbital research complex in the first place — to study how humans can live and work in an environment that’s so unimaginably hostile that something as simple as eating lunch requires special equipment and training.

Today marks another unique milestone for the ISS program, albeit a bittersweet one. Just a few hours ago, NASA successfully completed the first medical evacuation from the Station, cutting the Crew-11 mission short by at least a month. By the time this article is released, the patient will be back on terra firma and having their condition assessed in California.  This leaves just three crew members on the ISS until NASA’s Crew-12 mission can launch in early February, though it’s possible that mission’s timeline will be moved up.

Continue reading “ISS Medical Emergency: An Orbital Ambulance Ride”

A Linux Power User Puts SteamOS To Work

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

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

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

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

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

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.