Regretfully: $3,000 Worth Of Raspberry Pi Boards

September 20, 2025 by Al Williams 53 Comments

We feel for [Jeff Geerling]. He spent a lot of effort building an AI cluster out of Raspberry PI boards and $3,000 later, he’s a bit regretful. As you can see in the video below, it is a neat build. As Jeff points out, it is relatively low power and dense. But dollar for dollar, it isn’t much of a supercomputer.

Of course, the most obvious thing is that there’s plenty of CPU, but no GPU. We can sympathize, too, with the fact that he had to strip it down twice and rebuild it for a total of three rebuilds. One time, he decided to homogenize the SSDs for each board. The second time was to affix the heatsinks. It is always something.

With ten “blades” — otherwise known as compute modules — the plucky little computer turned in about 325 gigaflops on tests. That sounds pretty good, but a Framework Desktop x4 manages 1,180 gigaflops. What’s more is that the Framework turned out cheaper per gigaflop, too. Each dollar bought about 110 megaflops for the Pis, but about 140 for the Framework.

Continue reading “Regretfully: $3,000 Worth Of Raspberry Pi Boards” →

Forgotten Internet: The Story Of Email

September 17, 2025 by Al Williams 25 Comments

It is a common occurrence in old movies: Our hero checks in at a hotel in some exotic locale, and the desk clerk says, “Ah, Mr. Barker, there’s a letter for you.” Or maybe a telegram. Either way, since humans learned to write, they’ve been obsessed with getting their writing in the hands of someone else. Back when we were wondering what people would do if they had a computer in their homes, most of us never guessed it would be: write to each other. Yet that turned out to be the killer app, or, at least, one of them.

What’s interesting about the hotel mail was that you had to plan ahead and know when your recipient would be there. Otherwise, you had to send your note to their home address, and it would have to wait. Telegrams were a little better because they were fast, but you still had to know where to send the message.

Early Days

An ad from the 1970s with a prominent Telex number

In addition to visiting a telegraph office, or post office, to send a note somewhere, commercial users started wanting something better at the early part of the twentieth century. This led to dedicated teletype lines. By 1933, though, a network of Teletype machines — Telex — arose. Before the Internet, it was very common for a company to advertise its Telex number — or TWX number, a competing network from the phone company and, later, Western Union — if they dealt with business accounts.

Fax machines came later, and the hardware was cheap enough that the average person was slightly more likely to have a fax machine or the use of one than a Telex.

Continue reading “Forgotten Internet: The Story Of Email” →

Retro X86 With 486Tang

September 14, 2025 by Al Williams 4 Comments

Tang FPGA boards are affordable, and [nand2mario] has been trying to get an x86 core running on one for a while. Looks like it finally worked out, as there is an early version of the ao486 design on a Tang FPGA board using a Gowin device. That core’s available on the MiSTer platform, which emulates games using an Altera Cyclone device.

Of course, porting something substantial between FPGA architectures is not trivial. In addition, [nand2mario] made some changes. The original core uses DDR3 memory, but for the Tang and the 486, SDRAM makes more sense. The only problem is that the Tang’s SDRAM is 16 bits wide, which would imply you need two cycles per 32-bit access. To mitigate this, the memory system runs at twice the main clock frequency. Of course, that’s kind of double data rate, but not in the same way as DDR memory.

Continue reading “Retro X86 With 486Tang” →

Everything You Ever Wanted To Know About The Manhattan Project (But Were Afraid To Ask)

September 12, 2025 by Al Williams 34 Comments

There have been plenty of books and movies about how the Manhattan Project brought together scientists and engineers to create the nuclear bomb. Most of them don’t have a lot of technical substance, though. You know — military finds genius, genius recruits other geniuses, bomb! But if you want to hear the story of the engineering, [Brian Potter] tells it all. We mean, like, all of it.

If you’re looking for a quick three-minute read, you’ll want to give this a pass. Save it for a rainy afternoon when you can settle in. Even then, he skips past a lot of what is well known. Instead, he spends quite a bit of time discussing how the project addressed the technical challenges, like separating out U235.

Four methods were considered for that task. Creating sufficient amounts of plutonium was also a problem. Producing a pound of plutonium took 4,000 pounds of uranium. When you had enough material, there was the added problem of getting it together fast enough to explode instead of just having a radioactive fizzle.

There are some fascinating tidbits in the write-up. For example, building what would become the Oak Ridge facility required conductors for electromagnets. Copper, however, was in short supply. It was wartime, after all. So the program borrowed another good conductor, silver, from the Treasury Department. Presumably, they eventually returned it, but [Brian] doesn’t say.

There’s the old story that they weren’t entirely sure they wouldn’t ignite the entire atmosphere but, of course, they didn’t. Not that the nuclear program didn’t have its share of bad luck.

Debugging Vs Printing

September 11, 2025 by Al Williams 26 Comments

We’ll admit it. We have access to great debugging tools and, yes, sometimes they are invaluable. But most of the time, we’ll just throw a few print statements in whatever program we’re running to better understand what’s going on inside of it. [Loop Invariant] wants to point out to us that there are things a proper debugger can do that you can’t do with print statements.

So what are these magical things? Well, some of them depend on the debugger, of course. But, in general, debuggers will catch exceptions when they occur. That can be a big help, especially if you have a lot of them and don’t want to write print statements on every one. Semi-related is the fact that when a debugger stops for an exception or even a breakpoint, you can walk the call stack to see the flow of code before you got there.

In fact, some debuggers can back step, although not all of them do that. Another advantage is that you can evaluate expressions on the fly. Even better, you should be able to alter program flow, jumping over some code, for example.

So we get it. There is more to debugging than just crude print statements. Then again, there are plenty of Python libraries to make debug printing nicer (including IceCream). Or write your own debugger. If gdb’s user interface puts you off, there are alternatives.

Everything In A Linux Terminal

September 10, 2025 by Al Williams 49 Comments

Here at Hackaday Central, we fancy that we know a little something about Linux. But if you’d tasked us to run any GUI program inside a Linux terminal, we’d have said that wasn’t possible. But, it turns out, you should have asked [mmulet] who put together term.everything.

You might be thinking that of course, you can launch a GUI program from a terminal. Sure. That’s not what this is. Instead, it hijacks the Wayland protocol and renders the graphics as text. Or, if your terminal supports it, as an image. Performance is probably not your goal if you want to do this. As the old saying goes, “It’s not that the dog can sing well; it’s that the dog can sing at all.”

If, like us, you are more interested in how it works, there’s a write up explaining the nuances of the Wayland protocol. The article points out that Wayland doesn’t actually care what you do with the graphical output. In particular, “… you could print out the graphics and give them to a league of crochet grandmas to individually tie together every single pixel into the afghan of legend!” We expect to see this tested at an upcoming hacker conference. Maybe even Supercon.

We generally don’t like Wayland very much. We use a lot of hacks like xdotool and autokey that Wayland doesn’t like. We also think people didn’t understand X11’s network abilities until it was too late. If you think of it as only a video card driver, then you get what you deserve. But we have to admit, we are humbled by term.everything.

The Android Linux Commander

September 9, 2025 by Al Williams 7 Comments

Last time, I described how to write a simple Android app and get it talking to your code on Linux. So, of course, we need an example. Since I’ve been on something of a macropad kick lately, I decided to write a toolkit for building your own macropad using App Inventor and any sort of Linux tools you like.

I mentioned there is a server. I wrote some very basic code to exchange data with the Android device on the Linux side. The protocol is simple:

All messages to the ordinary Linux start with >
All messages to the Android device start with <
All messages end with a carriage return

Security

You can build the server so that it can execute arbitrary commands. Since some people will doubtlessly be upset about that, the server can also have a restrictive set of numbered commands. You can also allow those commands to take arguments or disallow them, but you have to rebuild the server with your options set.

There is a handshake at the start of communications where Android sends “>.” and the server responds “<.” to allow synchronization and any resetting to occur. Sending “>#x” runs a numbered command (where x is an integer) which could have arguments like “>#20~/todo.txt” for example, or, with no arguments, “>#20” if you just want to run the command.

If the server allows it, you can also just send an entire command line using “>>” as in: “>>vi ~/todo.txt” to start a vi session.

Continue reading “The Android Linux Commander” →