Image

Ask Hackaday: Do You Curb Shop Components?

I’m not proud. When many of us were kids, we were unabashedly excited when trash day came around because sometimes you’d find an old radio or — jackpot — an old TV out by the curb. Then, depending on its size, you rescued it, or you had your friends help, or, in extreme cases, you had to ask your dad. In those days, people were frugal, so the chances of what you found being fixable were slim to none. If it was worth fixing, the people would have probably fixed it.

While TVs and radios were the favorites, you might have found other old stuff, but in those days, no one was throwing out a computer (at least not in a neighborhood), and white goods like refrigerators and washing machines had very little electronics. Maybe a mechanical timer or a relay, but that’s about it.

Continue reading “Ask Hackaday: Do You Curb Shop Components?”

Image

For The Fun Of It

I was off at the Chaos Communication Congress last weekend, and one of the big attractions for one who is nerdily inclined is seeing all of the personal projects that everyone brings along with them. Inevitably, someone would ask me what my favorite is. Maybe it’s my decision paralysis, maybe it’s being forced to pick a favorite child on the spot, or maybe it’s just that I’m not walking around ranking them, but that question always left me drawing a blank.

But after a week of thinking about it, I’m pretty sure I know why: I don’t actually care what I think of other peoples’ projects! I’m simply stoked to talk to everyone who brought anything, and bathe in the success and failure, hearing about the challenges that they saw coming, and then the new challenges they met along the way. I want to know what the hacker thinks of their project, what their intention was, and how their story went. I’m just a spectator, so I collected stories.

The overwhelming, entirely non-surprising result of listening to a couple hundred hackers talk about their projects? They’re all doing it for the fun of it. Simply for the grins. And that held equally well for the supremely planned-out and technical projects as well as their simpler I-bought-these-surplus-on-eBay-one-night relatives. “We were sitting around and thought, wouldn’t it be fun…” was the start of nearly every story.

That’s what I absolutely love about our community: that people are hacking because it makes them happy, and that the amazing variety of projects suggests an endless possibility for hacker happiness. It’s hard to come away from an event like that without being energized. Some of that comes from the sharing of ideas and brainstorming and hanging out with like-minded folks, but what I find most important is simply the celebration of the joy of the project for its own sake.

Happy hacking!

Image

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.

Image

Surviving The RAM Apocalypse With Software Optimizations

To the surprise of almost nobody, the unprecedented build-out of datacenters and the equipping of them with servers for so-called ‘AI’ has led to a massive shortage of certain components. With random access memory (RAM) being so far the most heavily affected and with storage in the form of HDDs and SSDs not far behind, this has led many to ask the question of how we will survive the coming months, years, decades, or however-long the current AI bubble will last.

One thing is already certain, and that is that we will have to make our current computer systems last longer, and forego simply tossing in more sticks of RAM in favor of doing more with less. This is easy to imagine for those of us who remember running a full-blown Windows desktop system on a sub-GHz x86 system with less than a GB of RAM, but might require some adjustment for everyone else.

In short, what can us software developers do differently to make a hundred MB of RAM stretch further, and make a GB of storage space look positively spacious again?

Continue reading “Surviving The RAM Apocalypse With Software Optimizations”

Image

Retrocomputing: Simulacrum Or The Real Deal?

The holidays are rapidly approaching, and you probably already have a topic or two to argue with your family about. But what about with your hacker friends? We came upon an old favorite the other day: whether it “counts” as retrocomputing if you’re running a simulated version of the system or if it “needs” to run on old iron.

ImageThis lovely C64esque laptop sparked the controversy. It’s an absolute looker, with a custom keyboard and a retro-reimagining-period-correct flaptop design, but the beauty is only skin deep: the guts are a Raspberry Pi 5 running VICE. An emulator! Horrors!

We’ll admit to being entirely torn. There’s something about the old computers that’s very nice to lay hands on, and we just don’t get the same feels from an emulator running on our desktop. But a physical reproduction like with many of the modern C64 recreations, or [Oscar Vermeulen]’s PiDP-8/I really floats our boat in a way that an in-the-browser emulation experience simply doesn’t.

Another example was the Voja 4, the Supercon 2022 badge based on a CPU that never existed. It’s not literally retro, because [Voja Antonics] designed it during the COVID quarantines, so there’s no “old iron” at all. Worse, it’s emulated; the whole thing exists as a virtual machine inside the onboard PIC.

ImageBut we’d argue that this badge brought more people something very much like the authentic PDP-8 experience, or whatever. We saw people teaching themselves to do something functional in an imaginary 4-bit machine language over a weekend, and we know folks who’ve kept at it in the intervening years. Part of the appeal was that it reflected nearly everything about the machine state in myriad blinking lights. Or rather, it reflected the VM running on the PIC, because remember, it’s all just a trick.

So we’ll fittingly close this newsletter with a holiday message of peace to the two retrocomputing camps: Maybe you’re both right. Maybe the physical device and its human interfaces do matter – emulation sucks – but maybe it’s not entirely relevant what’s on the inside of the box if the outside is convincing enough. After all, if we hadn’t done [Kevin Noki] dirty by showing the insides of his C64 laptop, maybe nobody would ever have known.

Image

User Serviceable Parts

Al and I were talking on the podcast about the Home Assistant home automation hub software. In particular, about how devilishly well designed it is for extensibility. It’s designed to be added on to, and that makes all of the difference.
That doesn’t mean that it’s trivial to add your own wacky control or sensor elements to the system, but that it’s relatively straightforward, and that it accommodates you. If your use case isn’t already covered, there is probably good documentation available to help guide you in the right direction, and that’s all a hacker really needs. As evidence for why you might care, take the RTL-HAOS project that we covered this week, which adds nearly arbitrary software-defined radio functionality to your setup.

And contrast this with many commercial systems that are hard to hack on because they are instead focused on making sure that the least-common-denominator user is able to get stuff working without even reading a single page of documentation. They are so focused on making everything that’s in-scope easy that they spend no thought on expansion, or worse they actively prevent it.

Of course, it’s not trivial to make a system that’s both extremely flexible and relatively easy to use. We all know examples where the configuration of even the most basic cases is a nightmare simply because the designer wanted to accommodate everything. Somehow, Home Assistant has managed to walk the fine line in the middle, where it’s easy enough to use that you don’t have to be a wizard, but that you can make it do what you want if you are, and hence it got spontaneous hat-tips from both Al and myself. Food for thought if you’re working on a complex system that’s aimed at the DIY / hacker crowd.

Image

Ask Hackaday: Solutions, Or Distractions?

The “Long Dark” is upon us, at least for those who live north of the equator, and while it’s all pre-holiday bustle, pretty lights, and the magical first snow of the season now, soon the harsh reality of slushy feet, filthy cars, and not seeing the sun for weeks on end will set in. And when it does, it pays to have something to occupy idle mind and hands alike, a project that’s complicated enough to make completing even part of it feel like an accomplishment.

But this time of year, when daylight lasts barely as long as a good night’s sleep, you’ve got to pick your projects carefully, lest your winter project remain incomplete when the weather finally warms and thoughts turn to other matters. For me, at least, that means being realistic about inevitabilities such as competition from the day job, family stuff, and the dreaded “scope creep.”

It’s that last one that I’m particularly concerned with this year, because it has the greatest potential to delay this project into spring or even — forbid it! — summer. And that means I need to be on the ball about what the project actually is, and to avoid the temptation to fall into any rabbit holes that, while potentially interesting and perhaps even profitable, will only make it harder to get things done.

Continue reading “Ask Hackaday: Solutions, Or Distractions?”