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.

Biting Off More Than I Can Chew

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?

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

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

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”

Open Source Hardware, How Open Do You Want It To Be?

In our wider community we are all familiar with the idea of open source software. Many of us run it as our everyday tools, a lot of us release our work under an open source licence, and we have a pretty good idea of the merits of one such document over another. A piece of open source software has all of its code released under a permissive licence that explicitly allows it to be freely reproduced and modified, and though some people with longer beards take it a little too seriously at times and different flavours of open source work under slightly different rules, by and large we’re all happy with that.

When it comes to open hardware though, is it so clear cut?  I’ve had more than one rant from my friends over the years about pieces of hardware which claim to be open-source but aren’t really, that I think this bears some discussion.

Open Source Hardware As It Should Be Done

To explore this, we’ll need to consider a couple of open source hardware projects, and I’ll start close to home with one of my own. My Single 8 home movie cartridge is a 3D printable film cartridge for a defunct format, and I’ve put everything necessary to create one yourself in a GitHub repository under the CERN OHL. If you download the file and load it into OpenSCAD you can quickly create an STL file for your slicer, or fiddle with the code and make an entirely new object. Open source at its most efficient, and everyone’s happy. I’ve even generated STLs ready to go for each of the supported ISO values. Continue reading “Open Source Hardware, How Open Do You Want It To Be?”

Be Careful What You Ask For: Voice Control

We get it. We also watched Star Trek and thought how cool it would be to talk to our computer. From Kirk setting a self-destruct sequence, to Scotty talking into a mouse, or Picard ordering Earl Grey, we intuitively know that talking to a computer is better than typing, right? Well, computers talking back and forth to us is no longer science fiction, and maybe we aren’t as happy about it as we thought we’d be.

We weren’t able to pinpoint the first talking computer in fiction. Asimov and van Vogt had talking computers in the 1940s. “I, Robot” by Eando Binder, and not the more famous Asimov story, had a fully speaking robot in 1939. You could argue that “The Machine” in E. M. Forster’s “The Machine Stops” was probably speaking — the text is a little vague — and that was in 1909. The robot from Metropolis (1927) spoke after transforming, but you could argue that doesn’t count.

Meanwhile, In Real Life

In real life, computers weren’t as quick to speak. Before the middle of the twentieth century, machine-generated speech was an oddity. In 1779, a mechanical contrivance by Wolfgang von Kempelen, famous for the mechanical Turk chess-playing automaton, could form simple words. By 1939, Bell Labs could do even better speech synthesis electronically but with a human operator. It didn’t sound very good, as you can see in the video below, but it was certainly expressive.

Continue reading “Be Careful What You Ask For: Voice Control”