FLOSS Weekly Episode 854: The Big Daddy Core

This week Jonathan and Ben chat with Jason Shepherd about Ocre and Atym.io! That’s the lightweight WebAssembly VM that lets you run the same containers on Linux and a host of embedded platforms, on top of the Zephyr embedded OS. What was the spark that led to this project’s creation, what does Atym.io bring to the equation, and what are people actually doing with it? Watch to find out!

Continue reading “FLOSS Weekly Episode 854: The Big Daddy Core”

Radio Apocalypse: Survivable Low-Frequency Communication System

In the global game of nuclear brinksmanship, secrets are the coin of the realm. This was especially true during the Cold War, when each side fielded armies of spies to ferret out what the other guy was up to, what their capabilities were, and how they planned to put them into action should the time come. Vast amounts of blood and treasure were expended, and as distasteful as the whole thing may be, at least it kept armageddon at bay.

But secrets sometimes work at cross-purposes to one’s goals, especially when one of those goals is deterrence. The whole idea behind mutually assured destruction, or MAD, was the certain knowledge that swift retaliation would follow any attempt at a nuclear first strike. That meant each side had to have confidence in the deadliness of the other’s capabilities, not only in terms of their warheads and their delivery platforms, but also in the systems that controlled and directed their use. One tiny gap in the systems used to transmit launch orders could spell the difference between atomic annihilation and at least the semblance of peace.

During the height of the Cold War, the aptly named Survivable Low-Frequency Communication System was a key part of the United States’ nuclear deterrence. Along with GWEN, HFGCS, and ERCS, SLFCS was part of the alphabet soup of radio systems designed to make sure the bombs got dropped, one way or another.

Continue reading “Radio Apocalypse: Survivable Low-Frequency Communication System”

Morse Code For China

It is well known that pictographic languages that use Hanzi, like Mandarin, are difficult to work with for computer input and output devices. After all, each character is a tiny picture that represents an entire word, not just a sound. But did you ever wonder how China used telegraphy? We’ll admit, we had not thought about that until we ran into [Julesy]’s video on the subject that you can watch below.

There are about 50,000 symbols, so having a bunch of dots and dashes wasn’t really practical. Even if you designed it, who could learn it? Turns out, like most languages, you only need about 10,000 words to communicate. A telegraph company in Denmark hired an astronomer who knew some Chinese and tasked him with developing the code. In a straightforward way, he decided to encode each word from a dictionary of up to 10,000 with a unique four-digit number.

Continue reading “Morse Code For China”

Pi Compute Modules Make For Compact Cluster

Raspberry Pi clusters have been a favorite project of homelabbers and distributed computing enthusiasts since the platform first launched over a decade ago, and for good reason. For an extremely low price this hardware makes it possible to experiment with parallel computing — something that otherwise isn’t easily accessible without lots of time, money, and hardware. This is even more true with the compute modules, as their size and cost makes some staggering builds possible like this cluster sporting 112 GB of RAM.

The project is based on the NanoCluster, a board that can hold seven compute modules in a form factor which, as [Christian] describes it, is about the size of a coffee mug. That means not only does it have a fairly staggering amount of RAM but also 28 processor cores to work with. Putting the hardware together is the easy part, though; [Christian] wanted to find the absolute easiest way of managing a system like this and decided on gitops, which is a method of maintaining a server where the desired system state is stored in Git, and automation continuously ensures the running environment on the hardware matches what’s in the repository.

For this cluster, it means that the nodes themselves can be swapped in and out, with new nodes automatically receiving instructions and then configuring themselves automatically. Updates and changes made on Git are pushed to the nodes automatically as well and there’s not much that needs to be done manually at all. In much the same way that immutable Linux distributions move all of the hassle of administering a system to something like a config file, tools like gitops do the same for servers and clusters like this, and it’s worth checking out [Christian]’s project to get an idea of just how straightforward it can be now.

Join The The Newest Social Network And Party Like Its 1987

Algorithms? Datamining? Brainrot? You don’t need those things to have a social network. As we knew back in the BBS days, long before anyone coined the phrase “social network”, all you need is a place for people to make text posts. [euklides] is providing just such a place, at cyberspace.online.

It’s a great mix of old and new — the IRC inspired chatrooms, e-mail inspired DMs (“cybermail”) make it feel like the good old days, while a sprinkling of more modern concepts such as friends lists, a real-time feed, and even the late-lamented “poke” feature (from before Facebook took over the world) provide some welcome conveniences.

The pursuit of retro goes further through the themed web interface, as well. Sure, there’s light mode and dark mode, but that’s de rigueur. Threads might not offer a blue-and-white Commodore 64 theme, and you’d have little luck getting Bluesky to mimic the soothing amber glow of a VT-230, but Cyberspace offers that and more.

Continue reading “Join The The Newest Social Network And Party Like Its 1987”

Resurrecting Conquer: A Game From The 1980s

[Juan] describes himself as a software engineer, a lover of absurd humor, and, among other things, a player of Nethack. We think he should add computer game archaeologist to that list. In the 1990s, he played a game that had first appeared on USENET in 1987. Initially called “Middle-earth multiplayer game,” it was soon rebranded with the catchier moniker, Conquer.

It may not seem like a big thing today, but writing multiplayer software and distributing it widely was pretty rare stuff in the late 1980s or early 1990s. In 2006, [Juan] realized that this game, an intellectual predecessor to so many later games, was in danger of being lost forever. The source code was scattered around different archives, and it wasn’t clear what rights anyone had to the source code.

Continue reading “Resurrecting Conquer: A Game From The 1980s”

Wayland’s Never-Ending Opposition To Multi-Window Positioning

There are many applications out there that use more than one window, with every modern-day platform and GUI toolkit offering the means for said application to position each of its windows exactly where it wants, and to restore these exactly in the configuration and location where the user saved it for that particular session. All toolkits but one, that is, for the Wayland project keeps shooting down proposals. Most recently merge request #264 for the ext-zones protocol by [Matthias Klumpp] as it descended into a 600+ comments spree.

This follows on an attempt two years prior with MR#247, which was rejected despite laying out sound reasons why the session protocol of Wayland does not cover many situations. In the breakdown video of the new ext-zones protocol discussion by [Brodie Robertson] the sheer absurdity of this whole situation becomes apparent, especially since KDE and others are already working around the Wayland project with their own extensions such as via KWin, which is being used commercially in e.g. the automotive world.

In a January 2024 blog post [Matthias] lays out many of his reasonings and views regarding the topic, with a focus on Linux desktop application usage from a scientific application perspective. When porting a Windows-, X11- or MacOS application to Wayland runs into compatibility issues that may necessitate a complete rewrite or dropping of features, the developer is more likely to stick to X11, to not port to Linux at all, or to use what eventually will amount to Wayland forks that patch around these missing API features.

Meanwhile X11 is definitely getting very long in the tooth, yet without it being a clean drop-in replacement it leaves many developers and end-users less than impressed. Perhaps the Wayland project should focus more on the needs of developers and end-users, and less about what it deems to be the One True Way?

Continue reading “Wayland’s Never-Ending Opposition To Multi-Window Positioning”