Knowing What’s Possible

May 3, 2025 by Elliot Williams 13 Comments

Dan Maloney and I were talking on the podcast about his memories of the old electronics magazines, and how they had some gonzo projects in them. One, a DIY picture phone from the 1980s, was a monster build of a hundred ICs that also required you to own a TV camera. At that time, the idea of being able to see someone while talking to them on the phone was pure science fiction, and here was a version of that which you could build yourself.

Still, we have to wonder how many of these were ever built. The project itself was difficult and expensive, but you actually have to multiply that by two if you want to talk with someone else. And then you have to turn your respective living rooms into TV studios. It wasn’t the most practical of projects.

But amazing projects did something in the old magazines that we take a little bit for granted today: they showed what was possible. And if you want to create something new, you’re not necessarily going to know how to do it, but just the idea that it’s possible at all is often enough to give a motivated hacker the drive to make it real. As skateboard hero Rodney Mullen put it, “the biggest obstacle to creativity is breaking through the barrier of disbelief”.

In the skating world, it’s seeing someone else do a trick in a video that lets you know that it’s possible, and then you can make it your own. In our world, in prehistoric times, it was these electronics magazines that showed you what was possible. In the present, it’s all over the Internet, and all over Hackaday. So when you see someone’s amazing project, even if you aren’t necessarily into it, or maybe don’t even fully understand it, your horizons of what’s possible are nonetheless expanded, and that helps us all be more creative.

Keep on pushing!

From Good Enough To Best

April 26, 2025 by Elliot Williams 24 Comments

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.

Vibing, AI Style

April 19, 2025 by Elliot Williams 49 Comments

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.

Biting Off More Than I Can Chew

April 12, 2025 by Elliot Williams 36 Comments

Earlier this year, I bought one of those K40-style laser machines that was listed at a ridiculously low price, and it arrived broken. Well, let me qualify that: the laser tube and the power supply work perfectly, but that’s about the best you can say about it.

On first power-up, it made a horrible noise, the Y-axis was jammed, the X-axis was so off-square that it was visibly apparent, and it turned out that as I fixed one of these problems after the other, that it was just the tip of the iceberg. The Y-axis was jammed because the belts were so tight that they made the motor bind. Replacing them, because they were simply too short, got the stage moving, but it didn’t engage the endstops. Fixing those revealed that the motor was stepped wrong, and flipping the pins in the connector finally got it homing in the right direction. Full disassembly and reassembly steps required at each stage here.

The X-axis just needed adjustment, but the opto on its endstop had been completely crushed by a previous failed homing, and I had to desolder and resolder in a new one. (Keep your junkbox well stocked!) With the machine working, it became obvious that the driver board was barely usable. It accelerates horribly jerkily, which makes the motors skip and stall. It had to be run artificially slowly because it couldn’t make the corners. So I put in a new motor controller board that handles Gcode and does legitimate acceleration ramps.

Movement mostly fixed, it was time to align the laser. Of course, the optical path is all messed up, they forgot the o-ring that holds the focusing lens in place, and the thing keeps powering down randomly. This turns out to be because of the aiming red laser pointer, which has a positive case, which is shorting through the single wrap of electrical tape that “insulates” it from the machine’s frame. When this shorts, the motor driver board browns out. Lovely!

Once I was finally able to start aligning the beam, I discovered that the frame is warped out of plane. The simple solution is to take it all apart again and shim it until it’s flat, but I just haven’t had the time yet. I’m not beaten, but it’s been eating up hours after hours on the weekends, and that time is scarce.

I love DIY, and I love taking a machine apart in order to understand it. Once. But I’m now on my tenth or twelfth unmounting of the motion stage, and frankly, it’s no fun any more. It would have been quicker, if maybe not cheaper, to have built this machine entirely from scratch. At least for the moment, I’ve bitten off more than I have time to chew.

Ask Hackaday: What’s A Sun-Like Star?

April 10, 2025 by Al Williams 20 Comments

Is a bicycle like a motorcycle? Of course, the answer is it is and it isn’t. Saying something is “like” something else presupposes a lot of hidden assumptions. In the category “things with two wheels,” we have a winner. In the category “things that require gasoline,” not so much. We’ve noticed before that news stories about astronomy often talk about “sun-like stars” or “Earth-like planets.” But what does that really mean? [Paul Gilster] had the same questions, if you want to read his opinion about it.

[Paul] mentions that even textbooks can’t agree. He found one that said that Centauri A was “sun-like” while Centauri B was sometimes considered sun-like and other times not. So while Paul was looking at the examples of press releases and trying to make sense of it all, we thought we’d just ask you. What makes a star like our sun? What makes a planet like our planet?

Continue reading “Ask Hackaday: What’s A Sun-Like Star?” →

Contagious Ideas

March 29, 2025 by Elliot Williams 10 Comments

We ran a story about a wall-mounted plotter bot this week, Mural. It’s a simple, but very well implemented, take on a theme that we’ve seen over and over again in various forms. Two lines, or in this case timing belts, hang the bot on a wall, and two motors drive it around. Maybe a servo pulls the pen in and out, but that’s about it. The rest is motor driving and code.

We were thinking about the first such bot we’ve ever seen, and couldn’t come up with anything earlier than Hektor, a spray-painting version of this idea by [Juerg Lehni]. And since then, it’s reappeared in numerous variations.

Some implementations mount the motors on the wall, some on the bot. There are various geometries and refinements to try to make the system behave more like a simple Cartesian one, but in the end, you always have to deal with a little bit of geometry, or just relish the not-quite-straight lines. (We have yet to see an implementation that maps out the nonlinearities using a webcam, for instance, but that would be cool.) If you’re feeling particularly reductionist, you can even do away with the pen-lifter entirely and simply draw everything as a connected line, Etch-a-Sketch style. Maslow CNC swaps out the pen for a router, and cuts wood.

What I love about this family of wall-plotter bots is that none of them are identical, but they all clearly share the same fundamental idea. You certainly wouldn’t call any one of them a “copy” of another, but they’re all related, like riffing off of the same piece of music, or painting the same haystack in different lighting conditions: robot jazz, or a study in various mechanical implementations of the same core concept. The collection of all wall bots is more than the sum of its parts, and you can learn something from each one. Have you made yours yet?

(Fantastic plotter-bot art by [Sarah Petkus] from her write-up ten years ago!)

TrapC: A C Extension For The Memory Safety Boogeyman

March 11, 2025 by Maya Posch 52 Comments

In the world of programming languages it often feels like being stuck in a Groundhog Day-esque loop through purgatory, as effectively the same problems are being solved over and over, with previous solutions forgotten and there’s always that one jubilant inventor stumbling out of a darkened basement with the One True Solution™ to everything that plagues this world beset by the Unspeakable Horror that is the C programming language.

As the latest entry to pledge its fealty at the altar of the Church of the Holy Memory Safety, TrapC promises to fix C, while also lambasting Rust for allowing that terrible unsafe keyword. Of course, since this is yet another loop through purgatory, the entire idea that the problem is C and some perceived issue with this nebulous ‘memory safety’ is still a red herring, as pointed out previously.

In other words, it’s time for a fun trip back to the 1970s when many of the same arguments were being rehashed already, before the early 1980s saw the Steelman language requirements condensed by renowned experts into the Ada programming language. As it turns out, memory safety is a miniscule part of a well-written program.

Continue reading “TrapC: A C Extension For The Memory Safety Boogeyman” →