Ask Hackaday: Solutions, Or Distractions?

The “Long Dark” is upon us, at least for those who live north of the equator, and while it’s all pre-holiday bustle, pretty lights, and the magical first snow of the season now, soon the harsh reality of slushy feet, filthy cars, and not seeing the sun for weeks on end will set in. And when it does, it pays to have something to occupy idle mind and hands alike, a project that’s complicated enough to make completing even part of it feel like an accomplishment.

But this time of year, when daylight lasts barely as long as a good night’s sleep, you’ve got to pick your projects carefully, lest your winter project remain incomplete when the weather finally warms and thoughts turn to other matters. For me, at least, that means being realistic about inevitabilities such as competition from the day job, family stuff, and the dreaded “scope creep.”

It’s that last one that I’m particularly concerned with this year, because it has the greatest potential to delay this project into spring or even — forbid it! — summer. And that means I need to be on the ball about what the project actually is, and to avoid the temptation to fall into any rabbit holes that, while potentially interesting and perhaps even profitable, will only make it harder to get things done.

Continue reading “Ask Hackaday: Solutions, Or Distractions?”

PCB Design Review: TinySparrow, A Module For CAN Hacking, V2

A year ago, I’ve design reviewed an MCU module for CAN hacking, called TinySparrow. Modules are plenty cool, and even more so when they’re intended for remaking car ECUs. For a while now, every car has heavily depended on a computer to control the operation of everything inside it – the engine and its infrastructure, the lights, and  Sadly, ECUs are quite non-hackable, so building your own ECUs only makes sense – which is why it’s heartwarming to see modules intended to make this easier on the budding ECU designer!

Last time we saw this module, it was quite a bit simpler. We talked about fixing a number of things – the linear regulator, the unprotected CAN transceiver, and the pinout; we also made the board cheaper to produce by reducing the layer count and instead pushing the clearance/track width limits. This time, we’re seeing TinySparrow v2 , redesigned accounting for the feedback and upgraded with a new MCU – it’s quite a bit more powerful!

For a start, it’s got ESD diodes, a switching-linear regulator chain for clean but efficient power supply, and most importantly, an upgraded MCU, now with USB and one more CAN channel for a total of two! There’s a lot more GPIOs to go around, too, so the PCB now uses all four of its sides for breakout out power, programming, and GPIO pads. Only a tiny bit bigger than its v1, this module packs a fair bit of punch.

Let’s revisit the design, and try to find anything still left to improve – there’s a few noteworthy things I found.

Continue reading “PCB Design Review: TinySparrow, A Module For CAN Hacking, V2”

Linux Fu: The SSD Super Cache

NVMe solid state disk drives have become inexpensive unless you want the very largest sizes. But how do you get the most out of one? There are two basic strategies: you can use the drive as a fast drive for things you use a lot, or you can use it to cache a slower drive.

Each method has advantages and disadvantages. If you have an existing system, moving high-traffic directories over to SSD requires a bind mount or, at least, a symbolic link. If your main filesystem uses RAID, for example, then those files are no longer protected.

Caching sounds good, in theory, but there are at least two issues. You generally have to choose whether your cache “writes through”, which means that writes will be slow because you have to write to the cache and the underlying disk each time, or whether you will “write back”, allowing the cache to flush to disk occasionally. The problem is, if the system crashes or the cache fails between writes, you will lose data.

Compromise

For some time, I’ve adopted a hybrid approach. I have an LVM cache for most of my SSD that hides the terrible performance of my root drive’s RAID array. However, I have some selected high-traffic, low-importance files in specific SSD directories that I either bind-mount or symlink into the main directory tree. In addition, I have as much as I can in tmpfs, a RAM drive, so things like /tmp don’t hit the disks at all.

There are plenty of ways to get SSD caching on Linux, and I won’t explain any particular one. I’ve used several, but I’ve wound up on the LVM caching because it requires the least odd stuff and seems to work well enough.

This arrangement worked just fine and gives you the best of both worlds. Things like /var/log and /var/spool are super fast and don’t bog down the main disk. Yet the main disk is secure and much faster thanks to the cache setup. That’s been going on for a number of years until recently.

Continue reading “Linux Fu: The SSD Super Cache”

Belting Out The Audio

Today, it is hard to imagine a world without recorded audio, and for the most part that started with Edison’s invention of the phonograph. However, for most of its history, the phonograph was a one-way medium. Although early phonographs could record with a separate needle cutting into foil or wax, most record players play only records made somewhere else. The problem is, this cuts down on what you can do with them. When offices were full of typists and secretaries, there was the constant problem of telling the typist what to type. Whole industries developed around that problem, including the Dictaphone company.

The issue is that most people can talk faster than others can write or type. As a result, taking dictation is frustrating as you have to stop, slow down, repeat yourself, or clarify dubious words. Shorthand was one way to equip a secretary to write as fast as the boss can talk. Steno machines were another way. But the dream was always a way to just speak naturally, at your convenience, and somehow have it show up on a typewritten page. That’s where the Dictaphone company started.

Continue reading “Belting Out The Audio”

Hackaday Links Column Banner

Hackaday Links: December 7, 2025

We stumbled upon a story this week that really raised our eyebrows and made us wonder if we were missing something. The gist of the story is that U.S. Secretary of Energy Chris Wright, who has degrees in both electrical and mechanical engineering, has floated the idea of using the nation’s fleet of emergency backup generators to reduce the need to build the dozens of new power plants needed to fuel the AI data center building binge. The full story looks to be a Bloomberg exclusive and thus behind a paywall — hey, you don’t get to be a centibillionaire by giving stuff away, you know — so we might be missing some vital details, but this sounds pretty stupid to us.

Continue reading “Hackaday Links: December 7, 2025”

This Week In Security: React, JSON Formatting, And The Return Of Shai Hulud

After a week away recovering from too much turkey and sweet potato casserole, we’re back for more security news! And if you need something to shake you out of that turkey-induced coma, React Server has a single request Remote Code Execution flaw in versions 19.0.1, 19.1.2, and 19.2.1.

The issue is insecure deserialization in the Flight protocol, as implemented right in React Server, and notably also used in Next.js. Those two organizations have both issued Security Advisories for CVSS 10.0 CVEs.

There are reports of a public Proof of Concept (PoC), but the repository that has been linked explicitly calls out that it is not a true PoC, but merely research into how the vulnerability might work. As far as I can tell, there is not yet a public PoC, but reputable researchers have been able to reverse engineer the problem. This implies that mass exploitation attempts are not far off, if they haven’t already started. Continue reading “This Week In Security: React, JSON Formatting, And The Return Of Shai Hulud”

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

Keebin’ With Kristina: The One With The Pretty Protoypes

Some like it flat, and there’s nothing wrong with that. What you are looking at is the first prototype of Atlas by [AsicResistor], which is still a work in progress. [AsicResistor] found the Totem to be a bit cramped, so naturally, it was time to design a keyboard from the ground up.

Image by [AsicResistor] via reddit
The case is wood, if that’s not immediately obvious. This fact is easily detectable in the lovely render, but I didn’t want to show you that here.

This travel-friendly keyboard has 34 keys and dual trackpoints, one on each half. If the nubbin isn’t your thing, there’s an optional, oversized trackball, which I would totally opt for. But I would need an 8-ball instead, simply because that’s my number.

A build video is coming at some point, so watch the GitHub, I suppose, or haunt r/ergomechkeyboards.

Flat as it may be, I would totally at least give this keyboard a fair chance. There’s just something about those keycaps, for starters. (Isn’t it always the keycaps with me?) For another, I dig the pinky stagger. I’m not sure that two on each side is nearly enough thumb keys for me, however.

Continue reading “Keebin’ With Kristina: The One With The Pretty Protoypes”