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

Keebin’ With Kristina: The One With The Part Picker

April 21, 2025 by Kristina Panos 4 Comments

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: April 20, 2025

April 20, 2025 by Dan Maloney 8 Comments

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

April 19, 2025 by Elliot Williams 48 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.

Hackaday Podcast Episode 317: Quantum Diamonds, Citizen Science, And Cobol To AI

April 18, 2025 by Al Williams 1 Comment

When Hackaday editors Elliot Williams and Al Williams need a break from writing posts, they hop on the podcast and talk about their favorite stories of the past week. Want to know what they were talking about? Listen in below and find out!

In an unusual twist, a listener sent in the sound for this week’s What’s This Sound competition, so it turns out Elliot and Al were both stumped for a change. See if you can do better, and you might just score a Hackaday Podcast T-shirt.

On the hacking front, the guys talked about what they hope to see as entries in the pet hacking contest, quantum diamonds (no kidding), spectrometers, and several science projects.

There was talk of a tiny robot, a space mouse—the computer kind, not a flying rodent—and even an old-fashioned photophone that let Alexander Graham Bell use the sun like a string on a paper cup telephone.

Things really heat up at the end, when there is talk about computer programming ranging from COBOL to Vibe programming. In case you’ve missed it, vibe coding is basically delegating your work to the AI, but do you really want to? Maybe, if your job is to convert all that old COBOL code.

Want to read along? The links are below. Be sure to leave your robot plans, COBOL war stories, and AI-generated Vibe limerics in the comments!

As always, the human-generated Hackaday Podcast is available as a DRM-free MP3 download.

Continue reading “Hackaday Podcast Episode 317: Quantum Diamonds, Citizen Science, And Cobol To AI” →

This Week In Security: No More CVEs, 4chan, And Recall Returns

April 18, 2025 by Jonathan Bennett 7 Comments

The sky is falling. Or more specifically, it was about to fall, according to the security community this week. The MITRE Corporation came within a hair’s breadth of running out of its contract to maintain the CVE database. And admittedly, it would be a bad thing if we suddenly lost updates to the central CVE database. What’s particularly interesting is how we knew about this possibility at all. An April 15 letter sent to the CVE board warned that the specific contract that funds MITRE’s CVE and CWE work was due to expire on the 16th. This was not an official release, and it’s not clear exactly how this document was leaked.

Many people made political hay out of the apparent imminent carnage. And while there’s always an element of political maneuvering when it comes to contract renewal, it’s worth noting that it’s not unheard of for MITRE’s CVE funding to go down to the wire like this. We don’t know how many times we’ve been in this position in years past. Regardless, MITRE has spun out another non-profit, The CVE Foundation, specifically to see to the continuation of the CVE database. And at the last possible moment, CISA has announced that it has invoked an option in the existing contract, funding MITRE’s CVE work for another 11 months.

Continue reading “This Week In Security: No More CVEs, 4chan, And Recall Returns” →

Supercon 2024: Exploring The Ocean With Open Source Hardware

April 17, 2025 by Tom Nardi 10 Comments

If you had to guess, what do you think it would take to build an ocean-going buoy that could not only survive on its own without human intervention for more than two years, but return useful data the whole time? You’d probably assume such a feat would require beefy hardware, riding inside an expensive and relatively large watertight vessel of some type — and for good reason, the ocean is an unforgiving environment, and has sent far more robust hardware to the briny depths.

But as Wayne Pavalko found back in 2016, a little planning can go a long way. That’s when he launched the first of what he now calls Maker Buoys: a series of solar-powered drifting buoys that combine a collection of off-the-shelf sensor boards with an Arduino microcontroller and an Iridium Short-Burst Data (SBD) modem in a relatively simple watertight box.

He guessed that first buoy might last a few weeks to a month, but when he finally lost contact with it after 771 days, he realized there was real potential for reducing the cost and complexity of ocean research.

Wayne recalled the origin of his project and updated the audience on where it’s gone from there during his 2024 Supercon talk, Adventures in Ocean Tech: The Maker Buoy Journey. Even if you’re not interested in charting ocean currents with homebrew hardware, his story is an inspirational reminder that sometimes a fresh approach can help solve problems that might at first glance seem insurmountable.

Continue reading “Supercon 2024: Exploring The Ocean With Open Source Hardware” →

Porting COBOL Code And The Trouble With Ditching Domain Specific Languages

April 16, 2025 by Maya Posch 80 Comments

Whenever the topic is raised in popular media about porting a codebase written in an ‘antiquated’ programming language like Fortran or COBOL, very few people tend to object to this notion. After all, what could be better than ditching decades of crusty old code in a language that only your grandparents can remember as being relevant? Surely a clean and fresh rewrite in a modern language like Java, Rust, Python, Zig, or NodeJS will fix all ailments and make future maintenance a snap?

For anyone who has ever had to actually port large codebases or dealt with ‘legacy’ systems, their reflexive response to such announcements most likely ranges from a shaking of one’s head to mad cackling as traumatic memories come flooding back. The old idiom of “if it ain’t broke, don’t fix it”, purportedly coined in 1977 by Bert Lance, is a feeling that has been shared by countless individuals over millennia. Even worse, how can you ‘fix’ something if you do not even fully understand the problem?

In the case of languages like COBOL this is doubly true, as it is a domain specific language (DSL). This is a very different category from general purpose system programming languages like the aforementioned ‘replacements’. The suggestion of porting the DSL codebase is thus to effectively reimplement all of COBOL’s functionality, which should seem like a very poorly thought out idea to any rational mind.

Continue reading “Porting COBOL Code And The Trouble With Ditching Domain Specific Languages” →