Blinded With Science

So the room-temperature superconductor was a super disappointment, but even though the claims didn’t stand up in the end, the even better news is that real science was done. A paper making extraordinary claims came out, the procedure to make LK-99 was followed in multiple labs around the world, and then it was tested. It didn’t turn out to conduct particularly well at all. After a couple weeks of global superconductor frenzy, everything is back to normal again.

What the heck happened? First of all, the paper itself made extravagant claims about a holy-grail kind of material. There was a very tantalizing image of a black pellet floating in mid air, which certainly seems like magic, even though it’s probably only run-of-the-mill ferromagnetism in the end. But it made for a great photo-op in a news-starved August, and the then-still-Twitterverse took to it by storm. And then the news outlets piled on the hype fest.

If you’re feeling duped by the whole turn of events, you’re not alone. But the warning signs were there from the beginning, if you took the time to look. For me, it was the closing line of the paper: “We believe that our new development will be a brand-new historical event that opens a new era for humankind.”

That’s not the kind of healthy skepticism and cautious conclusion that real science runs best on. Reading the paper, I had almost no understanding of the underlying materials science, but I knew enough about human nature to suspect that the authors had rushed the paper out the door without sufficient scrutiny.

How can we keep from being fooled again? Carl Sagan’s maxim that “extraordinary claims require extraordinary evidence” is a good start. To that, I would add that science moves slowly, and that extraordinary evidence can only accumulate over time. So when you see hype science, simply wait to draw any conclusions. If it is the dawn of a new era, you’ll have a lot of time to figure out what room-temperature superconductivity means to you in the rosy future. And if it’s just a flash in the pan, you won’t have gotten your hopes up.

The Right Benchmark For GPT

Dan Maloney wanted to design a part for 3D printing. OpenSCAD is a coding language for generating 3D objects. ChatGPT can write code. What could possibly go wrong? You should go read his article because it’s enlightening and hilarious, but the punchline is that it ran afoul of syntax errors, but also gave him enough of a foothold that he could teach himself enough OpenSCAD to get the project done anyway. As with many people who have asked the AI to create some code, Dan finds that it’s not as good as asking someone who knows what they’re doing, but that it’s also better than nothing.

And this is where I start grumbling. When you type your desires into the word-follower machine, your alternative isn’t nothing. Your alternative is to fire up a search engine instead and type “openscad tutorial”. That, for nearly any human endeavor, will get you a few good guides, written by humans who are probably expert in the subject in question, and which are aimed at teaching you the thing that you want to learn. It doesn’t get better than that. You’ll be up and running with your design in no time.

Indeed, if you think about the relevant source material that the LLM was trained on, it’s exactly these tutorials. It can’t possibly do better than the best of them, although the resulting average tutorial might be better than the worst you’ll find. (Some have speculated on what happens when the entire Internet is filled with these generated texts – what will future AIs learn from?)

In Dan’s case, though, he didn’t necessarily want to learn OpenSCAD – he just wanted the latch designed. But in the end, he had to learn enough OpenSCAD to get the AI code compiling without error. He spent an hour learning OpenSCAD and now he’s good to go on his next project too.

So the next time you hear someone say that they got an answer back from a large language model that wasn’t perfect, but it was “better than nothing”, think critically if “nothing” is really the right benchmark.

Do you really want to learn nothing? Do you really have no resources to get started with? I would claim that we have the most amazing set of tutorial resources the world has ever known at our fingertips. Compared to the ability to teach millions of humans to achieve their own goals, that makes the LLM party tricks look kinda weak, in my opinion.

Where Old Files Go To Die

We all lead digital lives, and we work in and on files of one sort or another. And sometimes we get attached to them. That long manifesto you poured your heart into, but nonetheless probably shouldn’t see the light of day? Love letters from former flames? Your first favorite video game that you can’t play any more, but it just sits there eating up drive space?

These are the files that are important enough that they deserve better than just a drag-and-drop into the trashcan. They deserve to be buried with dignity, and that’s just what [Ulf Schleth]’s /death/null offers us – a digital graveyard where our files no longer exist as they were, but still are allowed to linger in memory.

This is an old project, but one that tickled our funny  and poignant bones in equal parts. The pun on /dev/null probably works just a little better if you read both filepaths with a German accent in your head, but the idea translates anyway.

To use it, you simply upload your file and it gets sent to the great trashcan in the sky, but along the way a 4 x 5 matrix of colored blocks is created that represents the file, and it is registered forever in the graveyard, where you can check up on it any time you like. Of course you can’t read it – only 20 RGB triples remain – but you have the digital “gravestone” as commemoration.

Even if you don’t have any loved ones in [Ulf]’s graveyard, you can walk by and see which files others have chosen to remember. Swing on by and pay your respects to notepad.exe.

Procrastinators Rejoice! 2023 Supercon Call For Participation Extended

When we closed the official Call for Participation for both workshops and talks last week, a good handful of folks wrote to us and asked if they could slip their presentation application in after the deadline. Who are we to say “no” to potential presenters? We want to see all the ideas!

We’re officially extending the Call for Speakers and the Call for Workshops for another week. Get your outline in before Aug. 1st at 9:00 AM PDT, and it’ll be in the selection for Supercon. (And no, we’re not going to extend it twice!)

The Hackaday Superconference is really and truly our favorite event of the year. It’s small, but not too small. The ideas everyone brings with them, however, are big. It’s like the absolute best of Hackaday live and in person. If you’re looking for a place to give a technical talk, or just to regale us all with the trials and triumphs of hacking, you won’t find a more receptive audience anywhere. Plus, presenters get in free.

Behind the scenes, we’re still working on the badge, but we’ve got many of the details fully hammered down. Expect tickets to go on sale in the second week of August – early bird tickets sell out fast. Keep your eyes on Hackaday for the announcement post when it goes live.

We know that November seems a long way out, but we’re looking forward to seeing you all already. Hooray for Supercon!

DOOM On IPhone OS, On Android

So you want to play some games from the early days of 32-bit iPhone OS that no longer run on recent OS versions? [Hikari-no-yume] wrote a sweet high-level emulator, touchHLE, to do so on modern iOS phones. But maybe you don’t have an iPhone? [Ciciplusplus] has your back. He ported the iPhone OS emulator, written in Rust, to Android, and then ported a version of DOOM that runs on iPhone OS to go with it.

[Ciciplusplus] also made a video (embedded below) where he documented the trials and tribulations of porting Rust code to the Android platform – an intensely Java environment. It doesn’t sound like it was at all trivial. Of course, this couldn’t have been accomplished without [Hikari-no-yume]’s original work on touchHLE, which was made essentially to fulfill [Hikari-no-yume]’s long-time obsession with the game Super Monkey Ball.

So for now, touchHLE can boast the ability to run a few old 32-bit games on Android and desktop operating systems. What other games from the first years of gaming on smart phones (and iPods) do you need to see ported? Get involved in the project if you’ve got an itch you need scratched.

Continue reading DOOM On IPhone OS, On Android”

2023 Hackaday Prize: A Smart Powermeter That You Actually Want

[Jon] wanted to keep track of his home power use, but didn’t want to have to push his data up to some cloud service that’s just going to leave him high and dry in the future. So he went completely DIY.

This simple and sweet build is now in its third revision, and the refinements show. A first prototype was nothing more than an ESP32 with a screen and some current transformer (CT) sensors to read the current flowing in the wires in his breaker box. The next version added a PCB and a color screen, and the most recent version swapped up to eInk and a nice local power supply, all sized to fit a nice clear power box.

What’s really cute about this design is the use of standard phono headphone jacks to plug the CT sensors into, and the overall sweet combination of a local display and interactivity with [Jon]’s ESPHome-based home automation setup. This design isn’t super complicated, but it doesn’t need to be. It has one job, and it does it nicely. What more do you want?

If you’re interested in getting into ESPHome and/or home automation, check out this great ESPHome resource. It’s probably a lot easier than you think, and you can build your system out one module at a time. If you’re like us, once you get started, you’ll find it hard to stop until everything falls under your watchful eyes, if not your control.

Who’s Afraid Of Assembly Language?

This week, [Al Williams] wrote a great thought piece about whether or not it was worth learning an assembly language at all anymore, and when. The comments overflowed, and we’re surprised that so many people basically agree with us: yes. Of course, it’s a Hackaday crowd, but I still didn’t expect the outpouring of love for the most primitive of languages.

Assembly language isn’t really one language, though. Every chip speaks its own dialect. Of course there are similarities: every CPU has an add function, right? But almost no CPU has just one add – there are variants with and without carry, storing and reading from working registers or RAM. And once you start talking about memory access, direct or indirect, the individual architectures of the chips demand different assembly languages.

But still, although the particular ways that CPUs do what they do can be incompatible from a strictly language perspective, they are a lot more similar in terms of the programming idioms that you’ll pick up along the way. Just as learning a set of solid algorithms will help you no matter which higher-level language you use, learning the concepts behind crafting loops and simple memory structures out of raw assembly language will serve you no matter which CPU you choose.

I have only written assembly language for a handful of CPUs, and not much of it at that, but I’ve found the microcontrollers to be the friendliest. So if you want to dip your toes in that water, pick up an AVR or an MSP430. Or maybe even the new hotness – a RISC-V. You’ll find the instruction sets small enough that you have to do most of the work yourself. And that is, after all, the point of learning an assembly language: learning to think like the silicon. If you treat it like a fun puzzle to solve, you’ll probably even enjoy the experience.

[Al]’s original question was when you should learn an assembly language: before or after a higher-level language. For 99% of our readers, I’d say the answer is right now.