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

Keebin’ With Kristina: The One With The Wafer-Thin Keyboard

May 19, 2025 by Kristina Panos 8 Comments

The mikecinq, an incredibly slim keyboard. — Image by [dynam1keNL] via reddit

But sir! I can’t believe I missed [dynam1keNL]’s initial flat offering from about a year ago, the mikefive, which came about when he and some friends ordered switches directly from Kailh and Kailh were like, do you want to try these even lower-profile PG1316 laptop switches? It’s called the mikefive because it’s 5 mm thick.

That’s okay, though, because now you’re caught up and I can talk about his latest keyboard, the mikecinq. The inspiration for this one includes the aesthetics of Le Chiffre and the slimness of Le Oeuf. As you’ll see in the gallery, the top is ever-so-slightly slanted downward from the top.

You can see it really well in the second picture — the top row is flush with the case, and the keys gradually get taller toward the thumb clusters. All [dynam1keNL] really had to do was 3D model the new case and screw in the PCB from his daily driver mikefive.

[dynam1keNL] ultimately found it nice and comfy, especially for the thumbs, but decided to take it one step further and designed a new switch footprint. Why? The PG1316s are surface-mount with contacts below the switch, so you really need a hotplate or oven to mount them.

So in order to deal with this, he made a dedicated mikecinq PCB with big cutouts with castellated holes beneath each switch. Now, the switch contacts are accessible from underneath and can be soldered with an iron.

You may have noticed that the mikefive production files are not available on GitHub — that’s because it was recently licensed and will be available soon. But if you want production files for the mikecinq, let him know in the comments.

Continue reading “Keebin’ With Kristina: The One With The Wafer-Thin Keyboard” →

Hackaday Links: May 18, 2025

May 18, 2025 by Dan Maloney 8 Comments

Say what you want about the wisdom of keeping a 50-year-old space mission going, but the dozen or so people still tasked with keeping the Voyager mission running are some major studs. That’s our conclusion anyway, after reading about the latest heroics that revived a set of thrusters on Voyager 1 that had been offline for over twenty years. The engineering aspects of this feat are interesting enough, but we’re more interested in the social engineering aspects of this exploit, which The Register goes into a bit. First of all, even though both Voyagers are long past their best-by dates, they are our only interstellar assets, and likely will be for centuries to come, or perhaps forever. Sure, the rigors of space travel and the ravages of time have slowly chipped away at what these machines can so, but while they’re still operating, they’re irreplaceable assets.

Continue reading “Hackaday Links: May 18, 2025” →

Open Source Hiding In Plain Sight

May 17, 2025 by Elliot Williams 21 Comments

On the podcast, [Tom] and I were talking about the continuing saga of the libogc debacle. [Tom] has been interviewing some of the principals involved, so he’s got some first-hand perspective on it all – you should really go read his pieces. But the short version is that an old library that many Nintendo game emulators use appears to have cribbed code from both and open-source real-time operating system called RTEMS, and the Linux kernel itself.

You probably know Linux, but RTEMS is a high-reliability RTOS for aerospace. People in the field tell me that it’s well-known in those circles, but it doesn’t have a high profile in the hacker world. Still, satellites run RTEMS, so it’s probably also a good place to draw inspiration from, or simply use the library as-is. Since it’s BSD-licensed, you can also borrow entire functions wholesale if you attribute them properly.

In the end, an RTOS is an RTOS. It doesn’t matter if it’s developed for blinking LEDs or for guiding ICBMs. This thought got [Tom] and I to thinking about what other high-reliability open-source code is out there, hidden away in obscurity because of the industry that it was developed for. NASA’s core flight system came instantly to mind, but NASA makes much of its code available for you to use if you’re interested. There are surely worse places to draw inspiration!

What other off-the-beaten-path software sources do you know of that might be useful for our crowd?

ChatGPT & Me. ChatGPT Is Me!

May 16, 2025 by Jenny List 65 Comments

For a while now part of my email signature has been a quote from a Hackaday commenter insinuating that an article I wrote was created by a “Dumb AI”. You have my sincerest promise that I am a humble meatbag scribe just like the rest of you, indeed one currently nursing a sore shoulder due to a sporting injury, so I found the comment funny in a way its writer probably didn’t intend. Like many in tech, I maintain a skepticism about the future role of large-language-model generative AI, and have resisted the urge to drink the Kool-Aid you will see liberally flowing at the moment.

Hackaday Is Part Of The Machine

As you’ll no doubt be aware, these large language models work by gathering a vast corpus of text, and doing their computational tricks to generate their output by inferring from that data. They can thus create an artwork in the style of a painter who receives no reward for the image, or a book in the voice of an author who may be struggling to make ends meet. From the viewpoint of content creators and intellectual property owners, it’s theft on a grand scale, and you’ll find plenty of legal battles seeking to establish the boundaries of the field.

Anyway, once an LLM has enough text from a particular source, it can do a pretty good job of writing in that style. ChatGPT for example has doubtless crawled the whole of Hackaday, and since I’ve written thousands of articles in my nearly a decade here, it’s got a significant corpus of my work. Could it write in my style? As it turns out, yes it can, but not exactly. I set out to test its forging skill. Continue reading “ChatGPT & Me. ChatGPT Is Me!” →

Hackaday Podcast Episode 321: Learn You Some 3DP, Let The Wookie Win, Or Design A Thinkpad Motherboard Anew

May 16, 2025 by Tom Nardi 3 Comments

Join Hackaday Editors Elliot Williams and Tom Nardi as they take a whirlwind tour of the best and brightest hacks of the last week. This episode starts off with an update about that Soviet Venus lander that’s been buzzing the planet, then moves on to best practices for designing 3D printed parts, giving Chrome OS devices a new lease on life, and a unique display technology that brings a Star Wars prop to life.

You’ll also hear about designing new motherboards for beloved old computers, why you might want to put your calipers on a flatbed scanner, and a NASA science satellite that’s putting in double duty as a wartime reporter. Finally, they’ll cover the interesting physics of meteor burst communications, and the latest developments in the ongoing libogc license kerfuffle.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Download in DRM-free MP3.

Continue reading “Hackaday Podcast Episode 321: Learn You Some 3DP, Let The Wookie Win, Or Design A Thinkpad Motherboard Anew” →

This Week In Security: Lingering Spectre, Deep Fakes, And CoreAudio

May 16, 2025 by Jonathan Bennett 5 Comments

Spectre lives. We’ve got two separate pieces of research, each finding new processor primitives that allow Spectre-style memory leaks. Before we dive into the details of the new techniques, let’s quickly remind ourselves what Spectre is. Modern CPUs use a variety of clever tricks to execute code faster, and one of the stumbling blocks is memory latency. When a program reaches a branch in execution, the program will proceed in one of two possible directions, and it’s often a value from memory that determines which branch is taken. Rather than wait for the memory to be fetched, modern CPUs will predict which branch execution will take, and speculatively execute the code down that branch. Once the memory is fetched and the branch is properly evaluated, the speculatively executed code is rewound if the guess was wrong, or made authoritative if the guess was correct. Spectre is the realization that incorrect branch prediction can change the contents of the CPU cache, and those changes can be detected through cache timing measurements. The end result is that arbitrary system memory can be leaked from a low privileged or even sandboxed user process.

In response to Spectre, OS developers and CPU designers have added domain isolation protections, that prevent branch prediction poisoning in an attack process from affecting the branch prediction in the kernel or another process. Training Solo is the clever idea from VUSec that branch prediction poisoning could just be done from within the kernel space, and avoid any domain switching at all. That can be done through cBPF, the classic Berkeley Packet Filter (BPF) kernel VM. By default, all users on a Linux system can run cBPF code, throwing the doors back open for Spectre shenanigans. There’s also an address collision attack where an unrelated branch can be used to train a target branch. Researchers also discovered a pair of CVEs in Intel’s CPUs, where prediction training was broken in specific cases, allowing for a wild 17 kB/sec memory leak.

Continue reading “This Week In Security: Lingering Spectre, Deep Fakes, And CoreAudio” →

Remembering More Memory: XMS And A Real Hack

May 15, 2025 by Al Williams 28 Comments

Last time we talked about how the original PC has a limit of 640 kB for your programs and 1 MB in total. But of course those restrictions chafed. People demanded more memory, and there were workarounds to provide it.

However, the workarounds were made to primarily work with the old 8088 CPU. Expanded memory (EMS) swapped pages of memory into page frames that lived above the 640 kB line (but below 1 MB). The system would work with newer CPUs, but those newer CPUs could already address more memory. That led to new standards, workarounds, and even a classic hack.

XMS

If you had an 80286 or above, you might be better off using extended memory (XMS). This took advantage of the fact that the CPU could address more memory. You didn’t need a special board to load 4MB of RAM into an 80286-based PC. You just couldn’t get to with MSDOS. In particular, the memory above 1 MB was — in theory — inaccessible to real-mode programs like MSDOS.

Well, that’s not strictly true in two cases. One, you’ll see in a minute. The other case is because of the overlapping memory segments on an 8088, or in real mode on later processors. Address FFFF:000F was the top of the 1 MB range.

PCs with more than 20 bits of address space ran into problems since some programs “knew” that memory access above that would wrap around. That is FFFF:0010, on an 8088, is the same as 0000:0000. They would block A20, the 21st address bit, by default. However, you could turn that block off in software, although exactly how that worked varied by the type of motherboard — yet another complication.

XMS allowed MSDOS programs to allocate and free blocks of memory that were above the 1 MB line and map them into that special area above FFFF:0010, the so-called high memory area (HMA). Continue reading “Remembering More Memory: XMS And A Real Hack” →