From Good Enough To Best

It was probably Montesquieu who coined the proto-hacker motto “the best is the mortal enemy of the good”. He was talking about compromises in drafting national constitutions for nascent democracies, of course, but I’ll admit that I do hear his voice when I’m in get-it-done mode and start cutting corners on a project. A working project is better than a gold-plated one.

But what should I do, Monte, when good enough turns out to also be the mortal enemy of the best? I have a DIY coffee roaster that is limping along for years now on a blower box that uses a fan scavenged in anger from an old Dust Buster. Many months ago, I bought a speed-controllable and much snazzier brushless blower fan to replace it, that would solve a number of minor inconveniences with the current design, but which would also require some building and another dive into the crufty old firmware.

So far, I’ve had good enough luck that the roaster will break down from time to time, and I’ll use that as an excuse to fix that part of the system, and maybe even upgrade another as long as I have it apart. But for now, it’s running just fine. I mean, I have to turn the fan on manually, and the new one could be automatic. I have only one speed for the fan, and the new one would be variable. But the roaster roasts, and a constant source of coffee is mission critical in this house. The spice must flow!

Reflecting on this situation, it seems to me that the smart thing to do is work on smoothing the transitions from good enough to best. Like maybe I could prototype up the new fan box without taking the current one apart. Mock up some new driver code on the side while I’m at it?

Maybe Montesquieu was wrong, and the good and the best aren’t opposites after all. Maybe the good enough is just the first step on the path toward the best, and a wise man spends his energy on making the two meet in the middle, or making the transition from one to the other as painless as possible.

Hackaday Podcast Ep 318: DIY Record Lathe, 360 Degree LIDAR, And 3D Printing Innovation Lives!

This week Elliot Williams was joined by fellow Europe-based Hackaday staffer Jenny List, to record the Hackaday Podcast as the dusk settled on a damp spring evening.

On the agenda first was robotic sport, as a set of bipedal robots competed in a Chinese half-marathon. Our new Robot overlords may have to wait a while before they are fast enough chase us meatbags away, but it demonstrated for us how such competitions can be used to advance the state of the art.

The week’s stand-out hacks included work on non-planar slicing to improve strength of 3D prints. It’s safe to say that the Cartesian 3D printer has matured as a device, but this work proves there’s plenty more in the world of 3D printing to be developed. Then there was a beautiful record cutting lathe project, far more than a toy and capable of producing good quality stereo recordings.

Meanwhile it’s always good to see the price of parts come down, and this time it’s the turn of LIDAR sensors. There’s a Raspberry Pi project capable of astounding resolution, for a price that wouldn’t have been imaginable only recently. Finally we returned to 3D printing, with an entirely printable machine, including the motors and the hot end. It’s a triumph of printed engineering, and though it’s fair to say that you won’t be using it to print anything for yourself, we expect some of the very clever techniques in use to feature in many other projects.

The week’s cant-miss articles came from Maya Posch with a reality check for lovers of physical media, and Dan Maloney with a history of x-ray detection. Listen to it all below, and you’ll find all the links at the bottom of the page.

Still mourning the death of physical media?  Download an MP3 and burn it to CD like it’s 1999!

Continue reading “Hackaday Podcast Ep 318: DIY Record Lathe, 360 Degree LIDAR, And 3D Printing Innovation Lives!”

This Week In Security: XRP Poisoned, MCP Bypassed, And More

Researchers at Aikido run the Aikido Intel system, an LLM security monitor that ingests the feeds from public package repositories, and looks for anything unusual. In this case, the unusual activity was five rapid-fire releases of the xrpl package on NPM. That package is the XRP Ledger SDK from Ripple, used to manage keys and build crypto wallets. While quick point releases happen to the best of developers, these were odd, in that there were no matching releases in the source GitHub repository. What changed in the first of those fresh releases?

The most obvious change is the checkValidityOfSeed() function added to index.ts. That function takes a string, and sends a request to a rather odd URL, using the supplied string as the ad-referral header for the HTML request. The name of the function is intended to blend in, but knowing that the string parameter is sent to a remote web server is terrifying. The seed is usually the root of trust for an individual’s cryptocurrency wallet. Looking at the actual usage of the function confirms, that this code is stealing credentials and keys.

The releases were made by a Ripple developer’s account. It’s not clear exactly how the attack happened, though credential compromise of some sort is the most likely explanation. Each of those five releases added another bit of malicious code, demonstrating that there was someone with hands on keyboard, watching what data was coming in.

The good news is that the malicious releases only managed a total of 452 downloads for the few hours they were available. A legitimate update to the library, version 4.2.5, has been released. If you’re one of the unfortunate 452 downloads, it’s time to do an audit, and rotate the possibly affected keys. Continue reading “This Week In Security: XRP Poisoned, MCP Bypassed, And More”

Illustrated Kristina with an IBM Model M keyboard floating between her hands.

Keebin’ With Kristina: The One With The Part Picker

If you do a lot of 3D computer work, I hear a Spacemouse is indispensable. So why not build a keyboard around it and make it a mouse-cropad?

A Spacemouse with an arcing keyboard built around it.
Image by [DethKlawMiniatures] via reddit
That’s exactly what [DethKlawMiniatures] did with theirs. This baby is built with mild steel for the frame, along with some 3D-printed spacers and a pocket for the Spacemouse itself to live in.

Those switches are Kailh speed coppers, and they’re all wired up to a Seeed Xiao RP2040. [DethKlawMiniatures] says that making that lovely PCB by hand was a huge hassle, but impatience took over.

After a bit of use, [DethKlawMiniatures] says that the radial curve of the macro pad is nice, and the learning curve was okay. I think this baby looks fantastic, and I hope [DethKlawMiniatures] gets a lot of productivity out of it.

Continue reading “Keebin’ With Kristina: The One With The Part Picker”

Hackaday Links Column Banner

Hackaday Links: April 20, 2025

We appear to be edging ever closer to a solid statement of “We are not alone” in the universe with this week’s announcement of the detection of biosignatures in the atmosphere of exoplanet K2-18b. The planet, which is 124 light-years away, has been the focus of much attention since it was discovered in 2015 using the Kepler space telescope because it lies in the habitable zone around its red-dwarf star. Initial observations with Hubble indicated the presence of water vapor, and follow-up investigations using the James Webb Space Telescope detected all sorts of goodies in the atmosphere, including carbon dioxide and methane. But more recently, JWST saw signs of dimethyl sulfide (DMS) and dimethyl disulfide (DMDS), organic molecules which, on Earth, are strongly associated with biological processes in marine bacteria and phytoplankton.

Continue reading “Hackaday Links: April 20, 2025”

Vibing, AI Style

This week, the hackerverse was full of “vibe coding”. If you’re not caught up on your AI buzzwords, this is the catchy name coined by [Andrej Karpathy] that refers to basically just YOLOing it with AI coding assistants. It’s the AI-fueled version of typing in what you want to StackOverflow and picking the top answers. Only, with the current state of LLMs, it’ll probably work after a while of iterating back and forth with the machine.

It’s a tempting vision, and it probably works for a lot of simple applications, in popular languages, or generally where the ground is already well trodden. And where the stakes are low, as [Al Williams] pointed out while we were talking about vibing on the podcast. Can you imagine vibe-coded ATM software that probably gives you the right amount of money? Vibe-coding automotive ECU software?

While vibe coding seems very liberating and hands-off, it really just changes the burden of doing the coding yourself into making sure that the LLM is giving you what you want, and when it doesn’t, refining your prompts until it does. It’s more like editing and auditing code than authoring it. And while we have no doubt that a stellar programmer like [Karpathy] can verify that he’s getting what he wants, write the correct unit tests, and so on, we’re not sure it’s the panacea that is being proclaimed for folks who don’t already know how to code.

Vibe coding should probably be reserved for people who already are expert coders, and for trivial projects. Just the way you wouldn’t let grade-school kids use calculators until they’ve mastered the basics of math by themselves, you shouldn’t let junior programmers vibe code: It simultaneously demands too much knowledge to corral the LLM, while side-stepping any of the learning that would come from doing it yourself.

And then there’s the security side of vibe coding, which opens up a whole attack surface. If the LLM isn’t up to industry standards on simple things like input sanitization, your vibed code probably shouldn’t be anywhere near the Internet.

So should you be vibing? Sure! If you feel competent overseeing what [Dan] described as “the worst summer intern ever”, and the states are low, then it’s absolutely a fun way to kick the tires and see what the tools are capable of. Just go into it all with reasonable expectations.