What Happens If Russia Shuts The Door On Their Leaky ISS Module?

There was a particularly tense moment aboard the International Space Station earlier this month, with NASA directing their astronauts to secure themselves in the Dragon capsule and prepare for a potential return to Earth while their Russian counterparts engaged in what we now know to have been some impromptu demolition work on their side of the orbiting complex.

Despite objections from their American partners, Roscosmos had given their cosmonauts the go-ahead to drill and cut into the walls of the Zvezda module — one of the core components of the ISS which has been in orbit since 2000 — to try and identify and ultimately repair persistent leaks that have been venting the Station’s atmosphere out into space for several years. We may never know the exact nature of the behind-the-scenes communication that went on between the two space agencies, but in the end the Russians abandoned their plan and NASA’s personnel were told to resume their normal duties.

But where do things go from here? Although it’s true the International Space Station is entering its final years, the mission isn’t over yet, and that means the two countries need to continue to work together if they hope to get any science done in the time they have left.

At this point there hasn’t been any official word from either agency, but sources that wish to remain anonymous have been dropping hints, and that’s got the rumors swirling. With the understanding that anything is still possible, at this point it looks like Russia is going to abandon any further attempts to repair the leak and instead seal off the crippled compartment of the Zvezda module. This won’t solve all the problems, and in fact will create some new ones. But if that’s what it will take to keep the peace with NASA until Station operations wind down, it’s apparently a bargain they’re willing to make.

Continue reading “What Happens If Russia Shuts The Door On Their Leaky ISS Module?”

Ask Hackaday: What Ever Happened To The Hero Nerd?

Knowing absolutely nothing about you other than the fact that you’re currently reading Hackaday, I can predict with a high degree of certainty that we’re both fond of at least a few of the same movies. That’s not to say they’re necessarily our favorite works of art. Indeed, in some cases they may even be objectively bad films. But the memory of them has stuck with us — and by extension nearly everyone else in the hacker and maker community — for decades.

Even if you don’t remember all the little details, you’ll never forget the names: movies like WarGames, Ghostbusters, Back to the Future, and Short Circuit. Stories that showed smart people using their intellect and a bit of cobbled together hardware to triumph over the bad guys. The tech wasn’t always believable, sometimes it was downright farcical. But they made it seem real, and by the end of the story when they won the day using brains and a soldering iron rather than fists or a gun, the minutia of how it all worked wasn’t really that important anyway.

It’s not a stretch to say that films such as these helped put many of us on a path towards science and technology. For those with an interest in more cerebral pursuits, seeing a scientist or an engineer save the day was hugely influential. How many engineers got their start watching Scotty frantically eke just a bit more power out of the Enterprise?

But as we recently discussed some of these classic movies behind the scenes here at Hackaday, it struck us that all of the best examples we could come up with were now 20, 30, or even 40 years old. That’s not to say there aren’t a few contemporary standouts, but they mostly seem to be biopics or other historical dramatizations which don’t quite scratch the same itch. Even so, none of them appear to have had the cultural impact necessary to stand the test of time in the same way their predecessors have.

So where have all of Hollywood’s heroic nerds gone, and what does it mean for future generations if these niche role models are no longer represented?

Continue reading “Ask Hackaday: What Ever Happened To The Hero Nerd?”

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

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)”

Picking A CRC

You send a file, but how do you know it arrived intact? In other words, how do you know that it didn’t get cut off, garbled, or changed somehow? Simplistically, you could just add up all the bytes in the file — a checksum — and send that along with the file. You compute the checksum when you know the file is good, and the receiver can compare the checksum to see if they match.

However, a simple addition doesn’t catch certain classes of errors, which is why there are better checksum algorithms that, for example, wrap the carry bit around or otherwise modify files with common errors so they produce different checksums. There are two problems with checksums. First, no matter how much you modify the algorithm, the chances that two files produce the same checksum are pretty high. Especially with common error patterns.

For example, assume a very simple algorithm that simply adds the bytes and discards any carry. If a file contains 0x80, 0x80, those numbers essentially cancel each other out. If you replace them with 0, 0, you’ll get the same checksum. To some degree, using anything other than a second copy of the entire file will have this problem — some corruption goes undetected — but you want to minimize the number of times that happens.

The other problem is that a checksum by itself doesn’t let you correct anything. You know the data is bad, but you don’t know why. If you think about it, the simplest checksum is a parity bit on a byte: odd parity is simply summing all the bits together. If the parity bit doesn’t match, you know the byte is bad, but you don’t know why. Any even number of errors goes undetected, but I am sure one-, three-, five-, or seven-bit errors will get caught.

People invent better error-checking codes by devising schemes that can promise they can detect a certain number of bit flips and, at least in some cases, correct them. One of these is the cyclic redundancy check (CRC). It is easy to think of the CRC as a “strong checksum,” but it actually works differently. What’s more, there isn’t just a single CRC algorithm. You have to select or design a particular algorithm based on your needs. Most people pick a “named” implementation like CCITT or Ethernet and assume it must be the best. It probably isn’t.

A CRC is a checksum in the broad sense: you feed it a message, and it gives you a small value that you append, store, or compare later. But unlike a simple additive checksum, a CRC is based on polynomial division over GF(2), which is a fancy way of saying “divide using XOR instead of carries.” That detail matters. It gives CRCs very strong guarantees against common classes of errors, provided you choose the right polynomial for the job. That’s the key. You must choose the right polynomial.

Continue reading “Picking A CRC”

A Peek Inside The Secret Lagercrantz Suitcase Radio

What counts as portable is somewhat a matter of opinion, especially over the years. [Helge Fykse] has a portable spy radio of Swedish origin. For its time, it was considered very portable, crammed into a good-sized suitcase.

You can see the large crystal that sets the transmit frequency and a key to send Morse code. The receiver has a VFO, so it was more agile. Based on the regenerative knob, it appears the receiver was of the regenerative type. The suitcase had its own battery, and with tubes, it could probably put out some kind of signal if connected to anything metal, like bedsprings, a clothesline, or anything. There was a lightbulb to let you see when you were transmitting maximum power.

Speaking of tubes, there were five inside, two for the transmitter and three for the receiver. The radio had storage for spare tubes, and the agent could maintain the radio in the field.

You not only get a peek inside the suitcase, but a look at the schematic. The radio is a model of simplicity, but we are certain it did its job.

We love looking at exotic spy gear, especially radios.

Continue reading “A Peek Inside The Secret Lagercrantz Suitcase Radio”

NASA Announces Artemis III Crew And Ambitious Goals

When the Artemis lunar program was first conceived, the third mission would have seen astronauts step foot on the Moon for the first time since Apollo 17 in 1972. But as hard as getting into space is, a sojourn to our nearest celestial neighbor is even more mindbogglingly complex, and so earlier this year it was announced that actually landing on the Moon would be pushed out to the fourth mission.

In turn Artemis III would take a page out of the Apollo 9 playbook and test out rendezvous and docking procedures with commercial landers while operating in the relative safety of low Earth orbit. Moving the target date for the landing a few years down the road gave all involved parties a little more breathing room, but it also provided a valuable opportunity to gain insight into the performance of the vehicles and systems ahead of the critical moment. In the original timeline, the first time Orion would attempt to dock with the lander would have been just before descending to the lunar surface — leaving precious little time to troubleshoot should anything go wrong.

Yesterday NASA held a press conference to update the public on their progress towards the planned 2027 launch of Artemis III, which included the long-awaited announcement of the crew that will kick the tires on the next-generation lunar landers being developed by SpaceX and Blue Origin

Continue reading “NASA Announces Artemis III Crew And Ambitious Goals”

Powering Up A Pluggable Module From The 1948 IBM 604 Electronic Calculator

In that awkward transition phase between electromechanical accounting systems used in the 1940s and the introduction of fully digital computers we find systems such as the IBM 604 Electronic Calculator, advertised for accounting, calculating and engineering tasks. While not capable of complex instructions, loops and other advanced features, it did use an interesting modular architecture with easily swappable modules containing a vacuum tube and associated components. Recently [Ken Shirriff] took a poke at one of these and even powered it up.

This kind of pluggable system would become a staple of computer systems, as they enabled the use of modules or cards with specific functions that could be swapped and combined at will to increase system flexibility, lower costs and make repairs a snap. For the IBM 604 a total of about 1250 vacuum tubes were used, apparently all of which were found on these pluggable modules.

The module that [Ken] got his hands on has a thyratron tube, which is effectively a high current switch and rectifier. In the short demonstration video you can see it being used to switch a lamp on and off, with further details explained in the article.

Despite being rather limited in its functionality and limited by the punch card input and output speed, the IBM 604 was still a smashing commercial success with over 5600 units produced. A transistorized prototype version with 2200 transistors and 95% less power usage was created in 1954 that formed the basis for the IBM 608, the world’s first commercial all-transistorized calculator.

The 608 didn’t last too long, however, as at that point the breakneck pace of semiconductor technology meant that any newly released product was already obsolete by the time it hit the market. Despite this, fundamentals like pluggable modules would keep showing up over and over, ranging from the 1950s Bendix G-15 to even modern day systems, including PCs with pluggable RAM and expansion cards as well as mainframes where hot swapping of even entire CPU modules is just another feature.

Continue reading “Powering Up A Pluggable Module From The 1948 IBM 604 Electronic Calculator”