This week Jonathan chats with Michael Meeks about Collabora! What’s the origin story in this consulting company, why do they have an outstanding office suite, and where is the world headed to accomplish digital sovereignty? Watch to find out!
Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or have the guest contact us! Take a look at the schedule here.
In a recent post, I mentioned that I wanted to build some tools for a stripped-down Linux running on a 3D printer with a MIPS CPU. I had two options: build a toolchain to cross-compile, or use Zig, which, in theory, has built-in toolchains for MIPS. I had to jump through hoops to get Zig to work, and I did mention Crosstool-Ng, so you might wonder why I didn’t start there. Turns out, it had its own set of hoops to work through.
What is Crosstool-Ng?
Crosstool-NG is a build system for making cross-compilation toolchains: compilers, assemblers, linkers, C libraries, kernel headers, and all the other pieces needed to build software on one machine that will run on a different kind of machine. Instead of manually matching a particular GCC version with the right binutils, glibc, or musl release, Linux headers, patches, and configuration options, you select the target architecture and let Crosstool-NG download, patch, configure, and build the stack. The result is a self-contained toolchain with commands such as mipsel-linux-musl-gcc or arm-none-eabi-gcc, ready to produce binaries for the target system.
Stock? Zig? Crosstool-Ng? No way to tell from this picture.
The four-part name is in a particular format that is often used in the cross compiling world. For example, consider arm-none-eabi-gcc. The tool here is gcc and, as you might expect, there will also be arm-none-eabi-as and arm-none-eabi-ld, among other things. The first part, arm in this case, will be the target architecture.
The second part of the name can mean a few different things. In theory, it is a vendor name but it is sometimes “none” which often means “generic” or, in the case of a linux target, “linux,” which isn’t technically a vendor.
The third part is the calling convention and, often, some idea of the library. For example, arm-linux-gnueabihf-gcc would mean the GNU library using the ARM EABI and hardware floating point. These are sometimes called “target triples” because, historically, it was CPU-VENDOR-OS, but now there are usually four or even five parts if the calling convention includes the OS, like linux-musl, for example.
That sounds simple, but cross-toolchains are unusually sensitive to version combinations and ABI details. Endianness, floating-point conventions, instruction-set variants, threading support, and C library choices all have to agree. So saying “Arm” or “MIPS” doesn’t mean much. You need to account for all the possible variations in the CPU and the libraries. Crosstool-NG does not eliminate those decisions, but it turns them into a reproducible configuration rather than a long sequence of hand-built components. I had two problems that I eventually resolved.
Problem One: Versions
One nice thing about Crosstool-Ng is that it pulls the right versions of everything for you. The problem is, when you install it from your system repositories, you are probably getting a crazy old version of the tool itself. I couldn’t find the right entries in the configuration when I did that, so I eventually uninstalled and picked up the latest version right from the source.
If that was the only problem, I would have been lucky.
Problem Two: Infinite Combinations
The CPU on the printer is an odd bird. As I noted last time, the executables use the r2 instruction set but also use the nan2008 convention which is usually found in r6. While Crosstool-Ng is good at letting you specify exactly what you want, it isn’t always clear on how you specify every detail.
To be fair, just like with Zig, some of that may be on me. I don’t use Crosstool-Ng or Zig every day, so maybe I was making either or both of them too hard. The bad news: It took me three or four attempts to get the right toolchain. The good news: It was a lot easier than manually downloading a bunch of stuff, trying to fix it up, building it, and still having to do it three or four times.
Configuration
Most, but not all, of the necessary changes were here.
Sort of like buysbox or building a custom kernel, the configuration for Crosstool-Ng uses the command: ct-ng menuconfig. This gives you a menu where you can set options about what you want and where you want it stored.
The problem is that the nan2008 setting I needed isn’t part of a standard mips32r2 setup. I suspect that if I had needed mips32r6, everything would have just worked. But, of course, I’m not that lucky.
In the target settings, I needed to match all the specifications, of course, but I also needed to add -mnan=2008 to both the CFLAGS and LDFLAGS as you can see in the figure.
So what’s so hard about that? Just those changes won’t produce a working toolchain for my printer. The C compiler also needed --with-nan2008 (in the C Compiler options screen under extra target CFLAGS) and the same option needed to be placed in the C Library screen, too.
Of course, it is like a word search puzzle. Once you see the answers, they look obvious. But when you are searching through pages of options, it is easy to miss one. It isn’t like there is a checkbox for “Use nan2008” that does it all for you because using nan2008 with mips32r2 is “strange.”
The Proof is in the Build
Once everything was set correctly, I was able to produce a toolchain (ct-ng build) that could compile busybox and even a small text editor. Everything ran fine on the printer.
To build busybox, I used:
make V=1 CC="mipsel-unknown-linux-musl-gcc -march=mips32r2 -msoft-float -static -Os" STRIP='mipsel-unknown-linux-musl-strip' -j6
Unlike Zig, no patching needed. The Zig version was about 9 kB larger than this version, so not much different there. Both were just over a megabyte total. I could probably have used hardware floating point to get a smaller executable, but given that I don’t think any of this is using much floating point at all, it didn’t seem to matter very much.
I had also threatened to compile a text editor. Turns out most have dependencies on things like ncurses, which are a pain to bundle. So I grabbed a copy of the tutorial editor kilo and extended it to look a little like emacs. Works great. Great place to start if you need a static editor that doesn’t take much space.
Lesson Learned
If the CPU on the printer had been more conventional, I think either approach would have worked fine. I prefer the Crosstool solution in this case, because I’m not lying by patching the ELF header. In this case, I don’t think that lie hurts anything, but a program that did a lot of floating-point math might not work correctly, whereas I think the one produced by Crosstool would be fine even for a floating-point program.
On the other hand, like most Unix and Linux things, there are always more ways to solve any problem. If your problem is wedging executables on an alien Linux box, there are two perfectly fine ways to solve it.
My initial experience with a 3D printer came in 2020, when I got access to a buddy’s Creality LD-002R SLA printer. This was one of those awkward transition phases for SLA printers, where inefficient RGB LCDs finally got replaced by monochrome LCD panels, thus massively reducing the required exposure time and increasing the LCD panel’s lifespan.
The closely related Creality LD-002H is a monochrome SLA printer, but as this wasn’t the one that this friend opted for we had to learn the ropes on this more old-school printer. In terms of specifications this meant a build volume of 119 mm x 65 mm x 160 mm to play with and a claimed 26.1 µm resolution. Despite some struggles along the way, this machine churned out impressively high levels of detail with whatever cheap resin we threw at it, and even the post-printing processing became easy once we added a flex plate to the build plate and tweaked the cleaning and curing steps.
Despite all these positives, we both drifted away from resin printing, mostly due to the still messy and smelly printing process. FDM printers seemed like a better deal, especially after said buddy got his mittens on a used IDEX FDM printer. I would eventually go through a rather loathsome Creality Ender V2 experience before ending up with my current-day Elegoo Neptune 4, and resin printing seemed to be a thing of the past for me. Until recently, that is.
Things Have Changed
The Creality LD-002R MSLA 3D printer from 2020. (Credit: Creality)
Despite not having access to a resin printer any more, I still kept up to date on newly released hobbyist-level 3D printers of any type, as well as progress in technologies. Here I rather liked the digital light processing (DLP) types of resin printers, as they ditched the LCD and UV light source for a MEMS micro-mirror and laser setup for big power and weight savings. Unfortunately DLP resin printers appear to have fallen by the wayside again due to a variety of reasons, one of them apparently being scaling limitations with available DLP light engines and the manufacturers for the latter seemingly uninterested in this market.
Thus consumer SLA printing is still generally done with mono LCDs, which do not quite have the same efficiency and crisp edges for individual pixels as DLP, but which otherwise have come a long way, with better optics and light sources. A big push has also been towards larger build volumes, so despite new SLA printers tacking on more ‘K’s to their display resolution, the effective resolution isn’t that much better than a 2020 budget model. The real question is probably whether that’s even needed based on my own experiences printing fine details.
Perhaps the most exciting change is that with overall user-friendliness, such as easier bed levelling, the preventing of resin smells wafting out of the printer into the room, heated resin vats for reliable print results and UV-blocking lids that you can flip open instead of having to gently lift off the printer with dirty gloves while you desperately try not to drop it whilst scrambling to find a free spot to put it safely down.
Although the Creality LD-002R lists air filtration with a carbon filter, this was more filtration of the homeopathic variety. Instead of filtering anything, the tiny, noisy fan effectively blasted unfiltered, resin-rich air into the room. Thus one of the first thing we did was disabling this ‘feature’ by turning off the fan and sealing the air hole. This immensely improved the printing experience even with less optimal airflow in the room.
Picking A Resin Printer
The Anycubic Photon D2, the largest Anycubic DLP printer. (Credit: Anycubic)
The selection of resin printers to pick from these past years has been nothing short of overwhelming, even if you ignore the veritable flood of slightly different variations from certain manufacturers. Here DLP printers seemed different enough even with their small build space, to the point that I almost got one. Of course the long-awaited successor DLP printers never appeared, and the small build space was somewhat rough and put me off from an impulse buy.
Thus getting an SLA printer as a friend for my FDM printer seemed like the only option, but lacking real project motivation that idea got put on the backburner. It’s really hard to justify a purchase if you cannot justify such a financial expense, after all.
That’s when I suddenly got motivation shoved into my face, in the form of Uniformation contacting me about giving their GK3 Ultra SLA printer a shot. This would be a no-strings-attached chance to have a poke at what looked to be a rather nice and capable printer, even if its price tag of around $1,300 makes it something for people who really know that this is the resin printer they want.
I had heard of this Uniformation company before, as a smaller company that scored a pretty big hit with the somewhat-troubled-but-very-interesting GKtwo SLA printer, which had also featured on my shortlist at one point. The GK3 successor to the GKtwo had been baking in the resin printing community for more than a year by the time I got contacted, with gradual improvements over that time based on community and reviewer feedback.
This is quite different from most 3D printer companies who generally push out a new model in a take-it-or-leave-it sense, so I took them up on their offer for this printer to either play with or use as a very fancy coffee table, whatever I wanted. Based on the sheer verbal abuse I have read aimed at Uniformation during the GK3 development phase on especially sub-reddits, it makes me fairly confident that all major issues were fixed, and that at the very least it’ll be a massive upgrade over the LD-002R that’s pretty much my reference point.
Setting Up
In the world of 3D printers, it would seem that the idea of a flatpack parcel with your new 3D printer – as with my Ender 3 v2 and Neptune 4 bed slingers – has come to an end. A modern CoreXY kinematics FDM printer arrives fully assembled with only few exceptions – like Prusa 3D’s DIY kit offerings – so you’re looking at a very big box that weighs a lot. The similarly priced Prusa CORE One+ for example comes in at a cool 22.5 kg without packaging.
Super easy to move, barely an inconvenience. (Credit: Maya Posch)
The GK3 Ultra ups that to 35 kg, so I had a rather unhappy delivery bloke lug the ~40 kg box up a few steps from his van to where I could use furniture rollers to walk it over to its new home, next to the FDM printer in a sturdy rack. Lifting the printer into the rack was consequently also a bit of a chore, though less due to the weight and more due to the lack of any good places to grip it. I had to put on some good gloves for extra grip and to prevent the aluminium case from cutting into my flesh.
With that chore done, I could finally admire the fine mess that I had gotten myself into. First of all, the build volume is pretty massive, at 300 x 160 x 300 mm, almost fully beating the Neptune 4’s 225 x 225 by 265 mm. The GK3 Ultra is notably quite deep, at about 40 cm before adding space for the power and Ethernet cables, not to mention the provided Wi-Fi dongle if that’s more your thing.
Much of this extra space is taken up by the resin dispenser system, which I’ll cover more later. Within the rack you’ll need at least 85 cm between the two shelves if you want to put a resin bottle into the slot that’s conveniently placed on the top. Fortunately you can also pour resin directly into the vat and even make the flippy lid removable, but it’s a pretty hefty unit either way.
After liberating a lot of foam and goodies from the inside of the printer, I was finally able to start commissioning it. This involved removing a lot of protective film, running the exposure test to verify that the LCD and UV light source are working, and best of all a quick confirmation that the pre-levelled build plate was still level. Compared to the faffing about with four bolts on the LD-002R’s build plate assembly and sheets of A4 paper that I was used to, this was a massive improvement.
Time To Print
The resin that got sent along with the printer uses a special bottle style, which fits in the GK3’s resin feeding system. You slot the entire bottle into the hole on the top of the printer, from where it should automatically slot into all the tubing and widgets that are supposed to handle the resin flow. My only misgivings with this design is that each of these special cartridge-like bottles are only rated for ten insertion/removal cycles, after which you have to buy a new one.
Bottom of the Uniformation resin bottle, with the ports visible. (Credit: Maya Posch)
If you use non-Uniformation resin and are pouring resin into a special bottle, then this can be a bit of a pain, if only to keep track of just how many times you have inserted said bottle before you suddenly have it start draining fully into the vat, or whatever the failure mode here is. Fortunately you can also disable this feature if you’d rather pour the resin directly into the vat, which is probably what I’ll end up doing with typical resin bottles rather than use the provided empty special bottle.
Since the only bottles of non-expired resin that I have lying around use this automatic resin feeding system, I’ll be be giving it a shot. A total of two resin types are available to me, one is the water-washable type that’s supposedly not as smelly as the standard resin that I have always used, and which can be cleaned with plain water instead of IPA.
The other type of resin is ABS-like, which as the name suggests is a ‘tough’ kind of resin, targeting similar use cases as ABS, ASA and kin. For the test I’ll print everything with both WW and ABS, as well as in PLA on the FDM printer, to test both overall workflow, printing of fine detail, water-tight parts, heat-resistance and durability.
Test Setup
For a first printing round, I have so far printed a range of parts on the Neptune 4 in white PLA, and for the GK3 Ultra I will initially just use the ABS-like (AL) clear-blue resin, to not have to switch resins just yet, which is another fun topic to cover. These prints include a range of items like bottles, a miniature figurine and a bunch of LEGO Technic-compatible parts. The latter two serve to give dimensional accuracy a good workout, along with basic durability testing.
The print results and my initial findings will be in the next article, as this one is getting on in words. I’m also more than happy to consider any requests for aspects to test and questions to answer here. Although I have so far printed FDM parts in PLA, I’ll probably also be printing some parts in PETG and conceivably also TPU. Since I only have an open style FDM printer, engineering-grade materials such as ABS, ASA, etc. are naturally not available to me, for both practical and health-related reasons.
There was once a race to put out cameras with ever higher numbers of megapixels to snare customers eager to take the highest quality digital photos. These days, we know that things like optics, processing, and finer qualities of an image sensor are all very important beyond pure resolution. But, for a time, companies behaved as if megapixels mattered over all else.
But what if you could go farther—shooting not millions, but billions of pixels in a single image? That’s precisely what [Yannick Richter] came to Hackaday Europe to talk about, covering his Project Gigapixel build.
More Pixels
When it comes to building a consumer camera with higher resolution, manufacturers achieve this by creating an image sensor with a greater number of sensing elements. This, of course, can get expensive and difficult the farther you want to scale, particularly if you’re trying to fit more sensing elements into a given standard sensor size.
A scanner sensor has great linear resolution. Pan one behind a high-quality lens, and you can capture images in super high resolution… just hope that nothing moves while you’re capturing a shot!
However, there are other ways to capture images in greater resolution that don’t require a larger image sensor. Namely, you can actually use quite a simple image sensor of limited resolution, and simply move it to various positions, capturing light all the while. Then, all you need to do is stitch the output together and you have a remarkably high resolution image. It might sound complicated, but as [Yannick] explains, it’s a perfectly cromulent way to build a gigapixel image.
[Yannick’s] project began with an old Epson flatbed scanner. This made the perfect donor for such a project, as it came with a linear image sensor with quite good resolution for scanning photographs and documents. The only problem is that it needs to move in a straight path in order to capture a full image. The goal was to build it into a scanner-style camera that was truly portable, which required some reverse engineering and creative design to make it into a practical tool for real-world photography. [Yannick] didn’t want to just stuff the existing scanner in a bodged-together camera body, either. He wanted to interface the sensor directly and build a custom linear-scanning camera from the ground up, with the high-resolution linear sensor mounted behind a nice medium-format Pentax lens.
[Yannick] lashed up a Raspberry Pi to read from the sensor.The key was that the scanner in question—an Epson V370—used a Sony CCD scanning element, rather than a cheaper CIS element. A proper CCD sensor is more expensive, but produces better output, and is more suitable for the sort of imaging [Yannick] was trying to do with this build. Namely, by running the scanning element behind a medium format lens to capture incredibly high-resolution images at up to 40800 x 80000 pixels, or 3.2 gigapixels if you multiply it out.
The talk covers all the work that [Yannick] did to make this a fully functional camera. That included doing a deep dive into Epson documentation to figure out how to interface the sensor at all. Thankfully, service manuals provided enough detail on how the 12-line RGB sensor works to get the project over the line. Interfacing the sensor was achieved via reusing the ADC and timing generation hardware from the scanner itself, hooked up to a Raspberry Pi 5 and a RP2350.
Plenty of work was required to figure out how to properly offset all the R, G, and B pixels to line up properly into a coherent color image. [Yannick] also dives into the mechanical design, regarding how the sensor was assembled on a 100-millimeter linear drive to scan it behind the lens assembly to capture images. There were also issues generating a live preview that you’d get on any other digital camera, which is not exactly practical to generate from a scanning image sensor. Instead, a standard Raspberry Pi camera was included in the build for live preview to help with lining up a shot.
The camera is capable of taking incredibly high resolution images with rich detail. Of course, image sizes are hefty in turn.
Perhaps the best part of the talk is when [Yannick] shows off the final results. The simple fact is that 3.2 gigapixel images capture a ton of detail when they’re taken well and focused correctly. A simple shot of some benchtop instruments doesn’t look like anything special, until [Yannick] shows that cropping in will let you read the codes off a 0603 SMD resistor. Obviously, the camera is limited when it comes to speed and it can’t really capture moving objects well. However, when it comes to grabbing very high resolution shots of still scenes, it’s a great performer. If taking gorgeously detailed landscapes or stunning architectural shots is your thing, you might find such a build an appealing proposition for your own needs.
We’ll start this week off by giving our congratulations to Skyroot Aerospace of India for successfully launching the country’s first privately developed orbital rocket yesterday. The company’s Vikram-1 booster stands 24 m (79 ft) tall and uses a somewhat unusual four-stage arrangement, with the first three stages using solid propellant and the final liquid-fueled stage being responsible for putting the payload into a precise orbit. With this successful launch, India becomes only the third country in the world with a private company capable of performing orbital launches.
Generally, the rocket should be moving when the countdown hits zero.
On the other end of the spectrum, we have SpaceX’s prototype Starship, which elected not to leave Earth during a last-second (literally) launch termination on Thursday. Aborted launches are, of course, nothing new in the world of rocketry, especially when dealing with an in-development vehicle that has 33 engines that need to fire up at the same moment before it can leave the pad. But this dramatic abort was unique as it was the first time lift-off of the massive 124.4 meter (408 ft) rocket had been called off when the engines were already running.
Onboard systems took advantage of the very narrow window between the time the Raptor engines are switched on and the rocket actually leaves the launchpad to decide that it was not a good day to visit space after all. Word from SpaceX is that two of the Raptor engines on the first stage will be replaced and that they should be ready to make another launch attempt sometime this upcoming week.
While getting rockets off the ground is never easy, one thing that seems to have no trouble going up is the price of gasoline. Even still, Americans seem largely uninterested in electric vehicles, or at the very least, the slate of EVs that are currently available to them — especially now that the $7,500 federal tax credit has ended. Yesterday, TechCrunch ran an article about all the EVs that have exited the US market over the last year due to stagnant sales or import difficulties, and it’s quite a list.
Some of the vehicles, like the Sony-branded Afeela, aren’t exactly surprising. But major players like Honda, Volkswagen, Nissan, and Hyundai also decided not to bring the 2026 models of various EVs in their lineup to the US. Polestar has been forced out of the market entirely due to new import restrictions on Chinese tech. Even Tesla is paring down their offerings by discontinuing their Model X and S vehicles.
Speaking of struggling sales, earlier this week, Amateur Photographer detailed a fairly dire situation over at GoPro. The company, once the undisputed market leader in rugged action cameras, looks like it might fold before the end of the year if they can’t bolster their cash reserves. GoPro’s legendary status for reliability in the most extreme of conditions is still intact, with NASA trusting the company’s cameras to return external views of the Orion capsule during its historic trip around the Moon on Artemis II. But for more mundane pursuits, consumers are increasingly reaching for cheaper alternatives.
One more piece of bad news while we’re at it: OnePlus took to their community forums on Thursday to announce they’ll no longer be selling new phones in Europe and North America. Anyone who owns a OnePlus phone in these territories will still get software support and updates through the originally marketed end date, and the warranty on the hardware itself will still be honored. But after that, they’ll have to find a new company to do business with. While the company wasn’t exactly a household name, they did offer some compelling hardware, and it’s always a shame to see fewer options on the market.
We’re pretty sure Dennis Nedry would read Hackaday if he hadn’t been eaten by a dinosaur.
In hopes it will lighten the mood a bit, we’ll leave you with this exhaustive look at the computers featured in 1993’s Jurassic Park, put together by Fabien Sanglard. It covers everything from laptops, which appeared in the background of shots, to the bank of glorious Thinking Machines CM-5 with their iconic arrays of twinkling red LEDs in the park’s control room. There’s even a section that dives into the software side of things, detailing the real-world applications as well as the more fanciful creations. As Fabien notes, the original Jurassic Park novel featured some surprisingly detailed descriptions of the computer tech used at the park, as author Michael Crichton was himself an accomplished programmer.
See something interesting that you think would be a good fit for our weekly Links column? Drop us a line; we’d love to hear about it.
Modern video games are nothing short of amazing. My son and I were playing through the one of the latest Zeldas, which involve a mix of combat and puzzle-solving that’s pretty much the hallmark of the franchise. But the most recent open-world Zelda is simply massive. Made by around 1,000 people at a development expense of $150,000,000, it takes probably 60-80 hours to play through if you’re not rushing, and more if you’re taking it easy. It has layers of game mechanics, and worlds in the sky, on land, and underground. It’s big in every way.
Contrast the games of my youth, which were a lot smaller. Written by a pair of people or maybe a handful, with playtimes in the single-digit hours, and of course fitting in the limited computing resources of the time. But the low-stakes nature of the early phases of the industry meant that software developers could take risks, and many of the games were consequently kinda idiosyncratic in this more innocent time.
I think there’s something to be said for small games. They don’t require a lifestyle commitment just to get through. They can still be fun, without taking all of your time. And honestly, when you’re done with a game quickly, you have more time for other stuff. Granted, some of this spirit lives on in the small indie games of today, but even so, game developers have the big studios’ products in the backs of their minds when they are working on their smaller oeuvres.
We were talking about preserving old games for posterity around Hackaday and on the podcast, and our conversations reminded me of a couple of educational games that, despite their rudimentary graphics, are still pretty good today. Both were electronics related, and both are still playable today thanks to efforts on emulation and software preservation. To get a feel for the 1980’s, give Rocky’s Boots a try. (I like the TRS-80 Color Computer version the best, but that may just be nostalgia.) Most of you grownups out there will get through it in an hour or so.
And if you want a challenge, try Rocky’s harder sequel: Robot Odyssey. If you already have a background in digital circuits, you’ll find it doable. Younger me hit a wall about two-thirds of the way through.
Both of these games stick with me because they taught me something, but also because they were simply quirky in a way that a game can only be when it’s written by a small team of folks who are just having fun programming it. If you pitched “a puzzle game about a raccoon who builds logic circuits to activate robot boots”, the boardroom would look at you like you’re out of your mind. But it’s just exactly the quirkiness and individuality of some of these early games that I cherish the most.
If you find yourself knee-deep in an endless modern game, take a side-quest off into a more naive time, and you’ll appreciate why people are putting efforts into archiving them.
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
It’s a hot one at both microphones, as Elliot Williams and Kristina Panos wilt in the heat with ice lollies and freezer packs. But still, we persevered long enough to make a podcast.
In Hackaday news, Supercon is on! It’s going down in Pasadena, California, but the talks will be somewhere slightly larger, with a courtyard instead of an alley. Get your talk proposals in now! In other Hackaday news, we still have our Frikkin’ Lasers Contest going on until Thursday, July 23rd.
Interestingly enough, we got a comment on an older article from none other than [Michael J. Van de Graaff], whose grandfather invented the Van de Graff generator and was “quite upset” when plans for a DIY version appeared in Scientific American. And finally, Google Earth’s desktop client is being discontinued, but you can still travel the globe on your phone, or in your PC’s browser.
Not only do we have another triple mailbag this week, we have another failed attempt at guessing the Sound by Kristina. However, [Alexander] knew that it was CD-ROM drive a-spinnin’. Speaking of What’s That Sound, be sure to let us know your ideas for the new prize.
That sounds like a lot of preamble, but we quickly get to a full slate of hacks, a couple of which are pretty retro in retrospect. 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!
Two-fer! [Jonathan Comer] has many ideas for generating random numbers when it comes to rolling for the What’s That Sound winner, and [Paul Clyne] wants to know how to get a jolly wrencher sticker.
Following the reports last week using the Windows Global Device ID (GDID) in tracking a malware operators behavior, here is a comprehensive write-up about what goes into the GDID and how it is used. It’s worth noting that the GDID itself was not used to catch the malware operator, however once a suspect was identified, the GDID was used to correlate behavior across various Microsoft products on the Internet.
The GDID is generated and assigned during a Windows install, but a re-install of Windows will generate a new GDID. Developer [SmtimesIWndr] tracks the generation and tracking of the GDID through the various Windows libraries and services, identifying where it appears to be created and how it is passed to other services like Azure.
Worth noting is your GDID is a unique, personally identifiable piece of information; if you go exploring and extract it from your Windows install, be sure to keep it private!
LAME mp3 updates
Those of us who were around for the dawn of MP3 files may remember the LAME encoder and library. After almost 10 years, there is a new LAME release.
Notably, this includes two security fixes, one for a stack buffer overflow based on malicious input to the Blade encoder, and an integer underflow in the AIFF header parser. Both of the fixed bugs feel very old-school, which seems appropriate given the age of the library and most of the related code.
Buffer overflows impacting the stack are some of the simplest and most direct forms of vulnerabilities, where it is possible to write past the end of a buffer and control how the function returns and instead execute arbitrary code. Integer under-flows, similarly, impact memory management; usually caused by allowing a variable that stores the size of a buffer to go negative. Since sizes are typically unsigned positive numbers, a negative is interpreted as an enormous positive number, writing past the proper buffer length.
Despite the new findings, the LAME codebase has been extremely resilient over the years, and considering the number of programs that likely still use LAME under the covers to process audio, seeing the project wake up with security fixes is great news.
Recovering Passwords from BIOS
Researchers have found a vulnerability in Dell BIOS code that allows extraction of the administrator password from the BIOS flash chips, either with physical access via a flash programmer, or via administrator or root level access to the operating system and reading the contents of the flash chip.
Dell used a 20 byte key to encrypt a 32 byte password field: for any admin password of 12 characters or fewer, the password is stored in completely plaintext. For longer passwords, characters beyond the first 12 are encrypted – but the random bytes are computed from the first character of the password mixed with fixed device data, yielding only 256 possible encryption seeds for the remaining bytes.
Using the BIOS admin password for evil requires local access, so the attack surface is small, however as the researchers note it controls the boot order and may allow an attacker with physical access to then boot an unsigned OS or bypass full-disk encryption, so it’s serious.
Patch Tuesday Crushes Records
Last month, Microsoft broke records for the number of security fixes in the June monthly Patch Tuesday roundup. This month, Microsoft broke records for the number of security fixes in the July monthly Patch Tuesday roundup.
This month includes a record 60 plus patches for critical vulnerabilities in Windows, as well as fixes for previous Bitlocker bypasses, and an AI prompt injection which could allow web sites to trigger Copilot in Microsoft Edge on Android and execute arbitrary prompts. Another bug patched this month allowed privilege escalation and code execution over DHCP, potentially impacting all Windows installs on the same physical network or public hotspot.
Microsoft credits AI assisted tooling with the record-breaking number of bugs discovered, and indicates it’s unlikely to slow down next month.
LegacyHive Windows Vulnerability
It’s a week with a Patch Tuesday, which now seems to mean it’s a week with a new exploit from NightmadeEclipse, the researcher who previously made news for being quite upset with the responses from the Microsoft security group. After then creating a public outcry by threatening prosecution, Microsoft recently has seemed simply to be fixing bugs disclosed by NightmareEclipse in the next series of security updates.
This month, we have LegacyHive, an exploit which allows loading the “hive”, or collection of registry settings and configuration files, of another user. The Windows registry is typically used to store preferences, settings, auto-launched applications, and other important settings, so being able to access other users registry groups seems significant.
Fairlife Dairy Suspends Production
Fairlife Dairy, owned by Coca-Cola, has suspended US operations due to a ransomware attack. Filings with the SEC simply say that production facilities are impacted and will be temporarily suspended, with no estimate as to when they will be restored.
Typically when a food-processing facility goes offline, the delays for restoring service can be significant due to the sanitization requirements.
CPAN and Perl April Task Force
The April Task Force has been announced (yes, in July) with a focus on enhancing the security posture of Perl and the CPAN library.
Given the absolute havoc wreaked on the NPM and PyPi repositories in 2026, proactive measures to protect other repositories seem prudent. Funded by the Perl and Raku Foundation and the Linux Foundation, the April Task Force will be focused on supply chain security, vulnerability patching, and processing reported vulnerabilities and CVEs.
Perl may not be the juggernaut language it once was, but it’s still used widely, so any preventative measures are good news.
Secure Boot vulnerable
Researchers from ESET enumerated 11 boot loaders signed by Microsoft that can be used to bypass secure boot protections and execute arbitrary code.
Secure Boot was designed to only boot code signed by trusted organizations (in this case, Microsoft). Those of us running Linux typically know it as “the option in the BIOS to turn off to get a kernel to run properly”, but for corporate fleets, Secure Boot protections help protect disk encryption and prevent malware installs.
During boot, a Secure Boot protected system validates the code it is about to launch to ensure it is signed by a trusted organization, establishing a chain of trust where each component then validates the next before launching. Often, to enable other tools or Linux distributions to boot, a “shim” boot loader is created and signed by an organization trusted by the UEFI install, which then loads and validates the actual boot loader or kernel.
Over the years, many such shims have been signed, but updates have lagged and security vulnerabilities have been found. Even unused old boot loader code remains signed and viable, allowing attackers to replace a modern version with a vulnerable, still valid, old version.
Microsoft has removed several of the vulnerable boot loaders via recent Windows patches, however systems that are not updated and systems that do not run Windows will still likely be vulnerable.
Even for those of us that are quite technically minded, we spend precious little time thinking about the cables that carry our signals and do all the important work we need them to do on a daily basis. A great deal of theory and engineering goes into making things like telephone lines and HDMI cables work, but we mostly just plug them in and get on with whatever we’re doing.
If this is your experience, you might find the Hackaday Europe talk from [Michael Wiebusch] to be particularly interesting. He dives into transmission line theory from an accessible standpoint, explaining how two disparate signals can go in opposite directions on the very same wire. Then he demonstrates the theory by building a cable modem… well, sort of!
Signal
Michael begins his talk by discussing the Telegrapher’s Equation, but only as a fakeout. Given the limited time on offer, he decided a quicker, easier explanation of the physics involved would be more appropriate. Key to this was explaining the difference between cables and transmission lines. To create a true transmission line, by his definition, he explains that there is a necessity to have two conductors that are relatively close together. Such a transmission line is effectively a distributed network of inductances and capacitances all the way down, though often we talk about “lossless” transmission lines for modelling purposes. He also covers the point of coaxial cables, wherein one conductor is wrapped around another to shield a signal from external noise, and to prevent signal from leaking out.
Transmission lines allow signals to pass in opposing directions, much like ripples on a pond will pass through each other, retaining their form. Credit: talk slides
There are several basic facts to remember about transmission lines. They are fundamentally just channels down which EM signals can travel. It’s also good to remember that they delay signals. To a human, the signal may appear to travel instantaneously, but it does take time. This also has other impacts; for example, coax cables are filled with plastic, a material in which the speed of light is roughly 66% of the speed of light in a vacuum.
This slows the rate at which the field of an EM signal can travel to this fundamental limit. [Michael] also notes that transmission lines, as a wave medium, essentially allow waves travelling in different directions to pass each other, much like ripples spreading on the surface of a pond. This is why it’s possible to have bidirectional communication on a single transmission line. It’s also important to terminate a transmission line properly, such that the wave you’re transmitting down it ends where you want it to—at the receiver. Fail to terminate your transmission line, and you’ll have that wave bouncing back and forth which is undesirable for clear transmission.
The coupler allows sending and receiving signals via a single transmission line. Credit: talk slides
[Michael] demonstrates basic transmission line theory by building a sort of cable modem out of an Arduino and some supporting hardware. He notes it’s not really a modem—there is no modulation or demodulation going on. Instead, he’s simply squirting TTL signals into either end of a cable and receiving them on the other end. The “black box” that couples the signals into and out of the transmission line is a simple directional coupler. Built out of resistors and an op-amp, it allows sending a signal down a transmission line, as well as receiving a signal coming the other way. The design works all the way down to DC logic level signals, which let [Michael] use it to send TTL signals up and down 50-ohm and 75-ohm coaxial cables. He notes this has very obvious practical applications where it’s desirable to reduce cable counts when sending signals in multiple directions, relating this directly to his professional work on science experiments.
If you’ve ever wanted to get two devices talking over a single cable in a relatively easy fashion, then [Michael’s] talk may be valuable to you. At the very least, it’s a great way to learn some of the basics of transmission lines and better understand what’s going on when you shoot a signal down a random bit of wire. It’s all good stuff.
This week Jonathan chats with Nariman Jelveh about Puter! It’s the project that takes the idea of the Browser-as-the-OS seriously. Why did a simulated desktop on the web take off, what the story of making it Open Source, and what’s coming next? Watch to find out!
Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or have the guest contact us! Take a look at the schedule here.
We are absolutely stoked to announce that the Hackaday Superconference is taking place this year November 6th through 8th in glorious Pasadena California, and we want to see you there!
If you’ve been to any of the previous nine Supercons, you know that it’s a fantastic gathering of the most motivated and interesting hackers around — but it’s also been a relatively small gathering. And while we love the very high signal-to-noise ratio of folks who show up, we’re always a little bit sad when the tickets sell out because it represents hackers who couldn’t be there.
So this year, we’re celebrating Supercon Ten by expanding out of our traditional location at the Design Lab so that we can accommodate 20% more hackers, while still keeping the cosy nature of the event intact. So if you’ve been wanting to come to Supercon, but procrastinated the ticket sales every year, this year is looking 20% better.
Call for Proposals
If you want to give a talk to an interested audience of hackers just like you, now is your chance. Fill out the Call for Participation form before Wednesday, Aug 12th to put your hat in the ring. Presenters not only get to share their work with a like-minded audience, but they get in the door free! Presenting really is the best way to attend a conference like this – it’s the ultimate ice-breaker. (Plus, did we mention free?)
We will have two tracks of talks on two stages, and both are a mix of shorter 20-minute talks and longer 40-minute sessions, so whatever the size of your ideas, we have the slot for you. As always, we like to hear about your projects: hardware, software, creation, destruction, or anything in-between. In short, if you have a talk that would interest the readers of Hackaday, it fits. Check out last year’s slate if you’re curious, but bear in mind that we like to see new stuff, so don’t feel constrained by precedent. If you’re into it, there’s a good chance that many of us are too!
All you need is an abstract, a title, and a solid general idea of how the talk is going to go. First time speaker, or grizzled veteran: get your proposal in now.
Plus ça Change…
Supercon Ten starts out as usual with a casual badge-hacking day at Supplyframe HQ on the morning of Friday Nov 6th. We love this day because there’s “nothing” to do! It’s the perfect way to ease into the conference: the doors open, and the food and coffee starts flowing. As the solder melts, brought-along hacks get demoed, friendships form, and plans get hatched. We go on well into the night, with music and festivities to keep you motivated or distracted – the choice is yours.
Saturday and Sunday are chock-full of talks, workshops, challenges, and other events. This year, we’ll be a few blocks south at the ArtCenter South Campus, which means that we’ll be relocating our traditional back-alley ambiance to significantly fancier digs. But of course, we’ll have space for hacking, mingling, and watching the talks.
Sunday evening comes too soon, and at the end of this second day of talks, we’ll let you showcase all of the badge hacks that you’ve been working on before spilling out into the town and falling far too late into bed.
Just because enough is never enough, we’ll probably also meet up informally sometime Thursday night if you’re already in town. And if you’re able to finagle a half-day Monday into your schedule, you’ll find that a bunch of folks have off-schedule side trips that are always popular.
Get Excited!
We know that we’re announcing late this year. The new venue, combined with a late Hackaday Europe, made for a lot more planning to be done. But now that all of our ducks are in a row, we’re very much looking forward to November. And of course, we can’t wait to see what you all are going to bring with you to Supercon. After all, it’s the Hackaday community that makes it great.
Get your talk proposals in now, and in the next few weeks, we’ll open up ticket pre-sales. Tell your friends, neglect to mention it to your enemies, and start making your Supercon plans today.
Along with the many displays of outrage, gnashing of teeth and other displays of profound grief at the recent news that Sony will no longer manufacture physical game discs come 2028, we have also heard some voices pipe up with a variety of statements, such as that this decision makes game archiving basically impossible. Of course, the truth of the matter is that software archiving in general has become much harder already over the past decades, while game consoles are just late to the archiving-hostile party.
As an example, one merely has to contrast Sony’s PlayStation with e.g. the Valve Steam store and software by juggernauts like Adobe and Autodesk. Here the former moved after the Creative Suite (CS6) series of Photoshop and other tools fully over to the Creative Cloud (CC) subscription model, where DRM and constant rental software renewals are in order. Unlike that disc copy of CS6 Master Collection that will stay good practically forever, there’s nothing really to archive with Adobe’s CC software.
Similarly, with digital game downloads and their constant patches now put inside a heavily encrypted environment that relies on a special launcher, preserving video games has been turned into into a virtual nightmare for many years now.
Why Archive
Archiving is about accumulating historical records or materials. The scope and reason for a particular archive can differ, such as a company’s archive with financial records, an engineering department’s archive of technical references, or a museum’s archive of physical artefacts. Whatever the reason, the same goal applies: the maintaining or creating of a historical timeline that can be later referenced as needed.
An essential part of archives is to act as a primary reference source: where possible archives contain only the original documents and artefacts, making them as close to an objective source of history as possible. This is both extremely useful for a company when the tax office does a surprise inspection, but it is also for anyone who wishes to do any kind of historical research. This includes research into the development of a certain kind of software over the centuries and all types of related hardware.
Within the world of software archiving not much changes about this primary mission, except for the digital aspect that earns it the title of digital preservation. At least until fairly recently this meant mostly making copies of physical storage media and any associated physical media like documentation and manuals, but increasingly the subject of such preservation and archiving entails digital data that never was bound to or accompanied by any kind of physical media.
Such digital preservation is a big part of organizations like the Internet Archive, whose archives contain copies of software and games that might otherwise have been lost to the ages. The cases of retro enthusiasts coming across a floppy disk or CD containing some obscure game or set of drivers and uploading a copy to the Internet Archive are both numerous and an excellent example of digital preservation.
Other archives like the Video Game History Foundation (VGHF) have a more narrow focus, as their name implies. Their basic mission is no different, of course, with creating an archive that preserves history. Here the best part about digital preservation is that it makes it possible to create virtually infinite bit-perfect copies of the materials, making it incredibly easy to share and enjoy multimedia, gaming, and other content from these archives.
Of course, if that was all that there is to be said about digital archiving and preservation then this is basically where we could conclude merrily that all is well, and that whether software is distributed digitally or on some kind of physical storage media is of no concern. In this scenario said software can be copied around to one’s heart’s content, burned to optical media and so on without restrictions, ensuring its preservation.
With distributors of software having had fits about how easy it is to copy and distribute said software since at least the 1980s, it’s little wonder that they haven’t seen fit to rely on the fact that copyright infringement is illegal, and instead sought to make it impossible to copy the data of software. This led to a wide variety of copy restriction implementations, including on floppy disks, such as Electronic Arts’ Interlock system, while Nintendo’s game cartridges mostly relied on this more obscure format to keep people from creating their own cartridges.
In the face of these hurdles, the US Library of Congress notes that, for some software, it’s not enough to have the software on some medium, but also the console or hardware to play it on.
These copy restriction mechanisms are a form of digital restrictions management (DRM), euphemistically called ‘rights management’, since DRM only removes rights. As software became decoupled from physical media by the late 90s along with multimedia content like MP3 music, alternate DRM schemes were developed that restrict copying, generally through encryption and a convoluted decryption scheme that even includes hardware-level encryption such as High-bandwidth Digital Content Protection (HDCP).
The upshot of all these copy restriction schemes is that you have to jump through many hoops to still create a copy, whether it involves breaking a floppy copying scheme, using an HDMI splitter that accidentally forgets to re-apply HDCP before sending the content off to a capture card, catching a lucky break with a leaky DVD CSS implementation, or using the analog hole to create that ‘good enough’ copy.
Nobody buys games on DVDs anymore, however. When a digital game is provided via an online store service, how can this be preserved in a digital archive? Since all of these rely on an internet-dependent DRM scheme which fails the moment there’s an issue anywhere in the chain, or if said authentication servers are turned off in N years from now, all preservation schemes here are by definition flawed or at least legally awkward.
A Digital Void
When EA created its Interlock copy restriction scheme it was likely not concerned with whether or not copies of their games would survive into the 2020s, never mind whether anyone would still be using FDDs. It does however indicate the central problem here, one that goes far beyond a black-and-white physical media vs digital-only show-off. Especially since physical media could be argued to be flawed enough that it deserved it to die.
In today’s inevitable march towards a future in which we’re all consuming content using ‘our’ Smart Terminal Devices that rely on any number of paid subscriptions to gain access to the actual content stored on the servers of our benevolent Content Overlords, what probably rankles people the most about the PlayStation physical media announcement is less the demise of physical media and more a reminder of how much has already been taken from us.
In a statement made by VGHF director Frank Cifaldi on the end of physical PlayStation discs – and the concurrent announcement of the shutdown of the PlayStation 3 and Vita online stores – this is put in the broader context of the digital void that we’re facing, in which a large part of video game history simply cannot be legally preserved.
The Legal Conundrum
Here we have to address the rather sizeable elephant in the room, in the form of copyright infringement. Here we see large groups of very nice people in friendly online communities who carefully strip any offending DRM that may even prevent the game from working, while ensuring that the freely provided bundle is kept up to date with only the best patches and anything of relevance.
Within these communities you can find entire swathes of video game history preserved for the enjoyment of connoisseurs, including tutorials, manuals, carefully curated collections mods and extensions, plus everything else that would make a professional digital archivist salivate.
But these ‘shadow archives’ are definitely illegal according to copyright law, ergo the only option available to VGHF and other organizations that are trying to stay on the light side of the law might be to wait a few decades, see which games enter the legal grey zone of ‘abandonware‘ and see whether they’ll still get hit by DMCA takedown request in 2050 for a game that ceased being offered for sale in 2026.
Although we’d rather bring you news of clever modifications and repairs down on the farm, more often than not, the name “John Deere” has appeared on the pages of Hackaday because of their opposition to farmers actually being able to work on the machines their livelihoods depend on. But thanks to a settlement reached between the company and the Federal Trade Commission this week, farmers seem to have been handed a much-needed win in the Right to Repair battle.
When a lawsuit against a company ends in a settlement, it usually means spending money they would rather pay than go to court. Indeed, earlier cases against John Deere have resulted in plenty of checks being written. But this time around, the FTC agreement requires Deere to make its diagnostic and repair software available to owners and independent shops. It also has a clause that prevents them from retaliating against owners who want to handle their own repairs rather than going through the company’s official service channels — hard to believe that’s something that actually needs to be specified, but it does give you a hint as to just how bad the situation has been. We’ll definitely be keeping an eye on this story.
Sounds like the Feds were busy this week, as the Federal Communications Commission also gave the green light to Reflect Orbital to launch a prototype satellite for their controversial “sunlight as a service” concept. The company plans to put the spacecraft into a roughly 600 km orbit around the planet, where it will deploy its 324-square-meter reflector and angle itself to illuminate a spot on the ground. It might sound like something a Bond villain would come up with, but Reflect Orbital says the capability will be used to beam sunlight directly onto solar panels at night and to provide light for search-and-rescue operations.
As you might expect, providing such a service on a global scale would require many such reflectors, which is where the concern really comes in. Critics note that a sky full of literal mirrors can cause all sorts of issues, ranging from the scientific to the scenic. The American Astronomical Society points out that each satellite in the constellation could appear to be four times as bright as the full Moon, and that it’s possible an amateur sky watcher could get an eyeball full of redirected sunlight should one of them unexpectedly zip past the aperture of their backyard telescope.
Moving from 600 km above to 400 meters below the surface of the ocean, the Royal Canadian Geographical Society and Woods Hole Oceanographic Institution have provided our first look at the wreck of Ernest Shackleton’s final ship, Quest. The schooner-rigged steamship was launched in 1917 and had a storied career that included not only a number of scientific expeditions but service during the Second World War. The ship ultimately met its fate in 1962 when it was damaged by ice and sank off the north coast of Labrador. The exact location of the wreck was unknown until its discovery in June of 2024.
Now, before you start questioning your knowledge of history, we should probably clarify that Shackleton was not exploring the Labrador Sea in 1962. He did, however, die aboard Quest in 1922 at the age of 47 as he was preparing to depart on another expedition to the Antarctic.
This next one isn’t new, but it’s the first time we’ve come across this gallery of gorgeous Soviet-era control rooms. Hackaday isn’t the place to dive into the political and socioeconomic aspects of the USSR. All we know is that they were putting out some damn fine-looking control panels back then. Half of them look like they wouldn’t be out of place on a Moon base, and the white lab coats with the little hats really complete the retrofuturism vibe. Now we have to go watch Chernobyl again.
In software news, FreeCAD has received a new tool that we know many in the community will be excited about: Banana For Scale. Forget the confusion between Metric and Imperial measurements. Placing a 3D banana in the scene alongside your rendered part provides a globally recognized size reference. While the free and open-source CAD package has often been criticized for being behind its commercial counterparts in terms of user interface and overall feature set, we think this addition should go a long way toward evening the scales — no pun intended.
Finally, Phoronix reports that Linux 7.2-rc3 includes several vital updates to device drivers for the Sega Dreamcast. Users running Linux on the ill-fated PlayStation 2 competitor will benefit from improvements made to the keyboard, mouse, and joystick interfaces. These fixes join the improved code for the console’s GD-ROM optical drive that emerged back in April. The “Year of the Linux Desktop” continues to be elusive, but it certainly looks like 2026 may finally be the Year of Linux on the Dreamcast.
See something interesting that you think would be a good fit for our weekly Links column? Drop us a line; we’d love to hear about it.
We all know it from our own hacking. In theory, doing something ten times is ten times doing it once. But then in practice, entirely new phenomena appear as you scale up that were simply not there in the small. Maybe it happens when you repeat it one hundred times, or a thousand.
Viewed positively, this is the property of emergence: how the whole can be more than the sum of its parts, and how biology isn’t just chemistry multiplied by a few million interactions. In our blinky world, a massive wall of LEDs is a display, not just a bunch of pixels.
On the flip side, going from one microcontroller with a 10 mA current draw to 64 Ki controllers, with 655 A, is more than just a difference in scale. You need to learn a new skill set to handle the problem. Making a single prototype is a different problem from making a run of badges for a conference of 5,000 – you’ll need a team, and won’t be able to just hack it alone – not to even mention the parts sourcing woes.
So I loved watching [Bitluni] going through the upscaling. He certainly had an idea of what he was getting himself into, but as with the emerging properties of a big system, there are often emerging problems, and those you can’t always see ahead of time. Have you gotten into a project that scaled itself into something qualitatively different? Tell us about it.
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
This week’s podcast sees Elliot joined by Jenny List, as both suffer silently in the European summer heat because the sound of a desk fan would come over on the recording.
A stand-out hack of the week comes from [Bitluni], whose GPU made from thousands of cheap microcontrollers is on a scale we’ve never seen before. It’s an amazing project in itself, but the manufacturing and power consumption issues of so many processors running at the same time make for a discussion of their own.
Otherwise, we have diecasting on the bench, an impressive achievement by any measure, a Raman spectrometer, and an open source take on something like a Kei truck. In quick hacks there’s a dicussion of soldering versus crimping for high current connectors, and neon tubes used as digital logic in an organ. The recording finishes with a discussion of 7-segment display history, and whether an engineering education teaches design for manufacture.
We were contacted by long-time listener [Alex], with a question about the deadline for What’s That Sound entries. The podcast is recorded on Thursday evening European time, most of the time, but Wednesday evening when Tom is onboard. If you get your entry in by Wednesday morning, wherever you are, you’re safe. Good luck!
Then we had a couple of responses to Zoe Skyforest’s pitot tube air speed sensor piece. Reese Johnson suggested that some version of this might be found in motorcycle fuel gauges, and Jeff told us about very similar differential pressure airflow sensors being used in the climate control systems of large buildings. So we’re closer than we think to these devices.
The Januscape vulnerability allows a user in a guest VM managed by the Linux Kernel Virtual Machine (KVM) to corrupt memory in the host system and break out of isolation.
KVM virtualization is used by major hosting platforms like Amazon AWS, Google GCP, Digital Ocean, and many more. All of the shared hosting platforms count on virtualization to isolate untrusted guest systems from the physical hardware and each other; being able to corrupt memory for all guests or break isolation presents a major threat.
The bug report says the error has been present for 16 years, which is nearly the entire lifetime of the KVM subsystem in Linux. Fixes are available in mainline, and major hosting providers who count on KVM are likely already updating.
Vulnerabilities In Balcony Solar
Micro solar, or “balcony solar”, installs have been gaining traction in Europe as a way to offset rising electrical costs by connecting solar and battery systems to a house or apartment power system.
Vulnerabilities have been found in the popular Hoymiles micro-inverter, which uses a proprietary RF radio protocol to manage the devices. Unfortunately, it looks like this protocol has no encryption or authentication beyond validating the serial number, and the serial number is also available over a wireless probe command.
Armed with a Nordic nRF radio researchers were able to discover nearby inverters in the wild and collect the serial numbers, though of course they stopped short of issuing commands to random users.
The wireless management control allows controlling the device power and output levels, as well as setting a lockout PIN, which the researchers suspect could be used to disable devices and lock the legitimate owners out completely.
There are an estimated 500,000 units in use, and currently the only known mitigation is to unplug the device entirely and disconnect the solar panels, though the team suggests that setting an anti-theft PIN may also help – or at least prevent an unknown PIN being set.
Be sure to check out the link for an in-depth analysis of the protocol and the surprising lack of protection.
The most interesting security fixes appear to be to file handling in the sftp and scp file transfer tools, a malicious remote server could cause the files to be downloaded to the wrong directories. Besides those, the security fixes seem relatively calm, making behavior more consistent when forwarding and tunneling options were in conflict, mitigating a potential denial of service, and cleaning up other behavior.
OpenSSH 10.4 introduces some experimental support for additional post-quantum encryption standards, but beyond that seems to be a normal update.
Tenda Routers (may) Have Backdoor
According to CVE-2026-11405, Tenda brand routers may have a deliberate backdoor in the web interface.
The vulnerability report claims that the httpd binary contains a fallback to a plaintext, hardcoded password that allows anything on the internal network to bypass authentication and reconfigure the router. This seems entirely plausible, based on issues found in other router firmwares, however additional reports raise doubts about the pervasiveness of the backdoor, or if it exists in all firmware versions.
If you have a Tenda brand router and are so inclined, now might be a great time to investigate OpenWRT or other alternate, updated firmware, but there’s probably not a reason to panic just yet.
Tricking the GitHub Agent With Prompt Injection
Can we go a week without discussing prompt injection in AI agents? Apparently the answer is no.
Noma Labs reveals how they were able to use prompt injection against the GitHub support agent to reveal private repositories of an organization. Leveraging the GitHub Agentic Workflows that link workflows with AI agents, Noma Labs were able to file an issue in a public repository that exposed private repositories in the same organization.
The attack appears to be as simple as filing an issue in the public repo, and requesting the contents of files in both the public and private repo, which the agent happily provided. Not only did the AI agent provide the file content of private repos, but it put it in a public issue in the public repository!
Noma Labs says in the writeup that GitHub had instituted guardrails to prevent an agent from accessing private repositories, but simply including the request to “additionally” perform other tasks was sufficient to bypass. This makes GitHub the latest in a seemingly endless chain of AI agents happily helping bypass corporate security, and it doesn’t seem like a trend that will slow down for a while.
Windows Device Identifier Catches Ransomware Operator
Windows installs contain a globally unique identifier generated during the initial install, which is used to track device behavior across Microsoft platforms. Toms Hardware reports that during an investigation of the “Scattered Spider” ransomware group, Microsoft provided records tracking the GDID of one of the ransomware operators, allowing the identification and arrest of one of the groups members.
Scattered Spider has been responsible for millions of dollars in ransomware attacks globally, including high-profile ransomware attacks against major Las Vegas resorts, Qantas airlines, Visa, and hundreds of other companies.
Court documents reveal that following the arrest of one of the suspected members of the group, the Windows global ID was used to link other behavior across Azure, video games, and other telemetry.
CISA reviews lessons learned
Mentioned here in May, the US government cybersecurity agency (CISA) suffered a disclosure of authentication tokens, cloud infrastructure, and plaintext passwords via a public GitHub repository named “Private-CISA” and operated by a contractor.
CISA has published the results of their internal review. Unsurprisingly, as a large government agency, CISA essentially followed the playbook for dealing with incidents: identify the most critical issues and disable the access of the contractor who exposed credentials, determine the full scope of disclosed data, and terminate accounts, change passwords, and expire authentication tokens which were exposed.
More NPM malware packages
Opensource Malware reports on additional infostealer malware uploaded to the NPM repository. Like most NPM-based malware, these packages rely on the install script mechanism to trigger arbitrary commands, firing immediately during package install with no additional interaction.
All of the malware packages mimic existing popular packages and depend on user typos or confusion to get selected. Once triggered, the malware collects a machine fingerprint, git user information, GitHub account information, SSH account information, and corporate identifiers. The packages are largely nonfunctional – the code in the package itself is irrelevant, once a victim triggers the install the malware payload is fired.
All of the packages were uploaded by the same source, tracked to the owner of a cybersecurity company. It is unclear if this is a misguided attempt to generate leads or hype, or if this is a research project gone wrong, but the payload of the malicious packages has been developed and tuned over time. For a company trying to build a reputation or trust, this is surely the wrong way to do it.
This week Jonathan chats with Andrea Gallo about RISC-V! What does it mean for RISC-V to be an Open ISA? Where is RISC-V popping up, and what’s the new frontier? Watch to find out!
Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or have the guest contact us! Take a look at the schedule here.
I’ll admit it: I miss the simplicity of /etc/hosts. There was something elegant about it. You wanted laserprinter to mean 192.168.1.40, so you opened a text file and wrote:
192.168.1.40 laserprinter
Done. No cloud account, no discovery daemon, no dashboard with material-themed icons. Just a name and an address. The trouble, of course, is that /etc/hosts is only simple when you have one machine. The moment you have a desktop, a laptop, a Raspberry Pi, a NAS, a test box, and a phone or two, every little network change becomes a tiny distributed-database problem. Which copy of /etc/hosts is authoritative? Did you update the laptop? What about the machine you only boot once a month?
One Solution
Modern LANs solved this with mDNS, using Avahi on Linux. It resolves addresses that end in .local. Instead of asking a central DNS server “who is thing.local?”, a machine sends a multicast query on the local network: “who has thing.local?” The device that owns the name answers. This is why your Linux box named spock and usually be reached as spock.local on your LAN.
There are limits. mDNS is link-local; it is meant for the local LAN, not the whole Internet and shouldn’t route across subnets. Each device is supposed to publish its own name. That works fine when the device cooperates. But what about devices that do not publish mDNS? Or little embedded things that barely even have an IP address?
That is where I wanted the best of both worlds: keep a small authoritative /etc/hosts file on one Linux box, but publish selected entries onto the LAN using mDNS.
Publishing House
Avahi includes a handy tool for this:
avahi-publish-address widget.local 192.168.1.50
While that process is running, Avahi advertises widget.local as an mDNS address record. Kill the process, and the record goes away. So you could just write a script to publish all the addresses for things that won’t do it themselves and launch in in local.rc or a systemd unit. But that seems inelegant. I wanted to just pick things out of the /etc/hosts file. But not everything. Here is a simple publisher, installed as /usr/local/sbin/localip_pub:
#!/bin/sh
# Scan /etc/hosts for .local addressess and publish them using avahi
tmp="$(mktemp)"
pids=""
cleanup() {
rm -f "$tmp"
for p in $pids; do
kill "$p" 2>/dev/null
done
wait
}
mdns_name_exists() {
timeout 2 avahi-resolve-host-name -4 "$1" 2>/dev/null |
awk -v h="$1" '
BEGIN {
sub(/\.$/, "", h)
rc = 1
}
{
n = $1
sub(/\.$/, "", n)
}
n == h && $2 ~ /^([0-9]{1,3}\.){3}[0-9]{1,3}$/ {
rc = 0
}
END {
exit rc
}'
}
trap cleanup INT TERM EXIT
awk '
NF < 2 { next } # skip short lines
$1 ~ /^127\./ { next } # skip local address
# This assumes .local
# it will reject anything with an alias or subdomain or trailing comment
# it also rejects any full comment lines or IPv6 addresses
# although you could certainly patch it for IPv6 if you wanted to
/^[[:space:]]*[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+[[:space:]]+[^.]+\.local[[:space:]]*$/ {
ip=$1
name=$2
if (!seen[ip]++) print name, ip
}
' /etc/hosts > "$tmp"
while read name ip; do
if mdns_name_exists "$name"
then
echo found $name
continue
fi
echo avahi-publish-address "$name" "$ip"
avahi-publish-address "$name" "$ip" &
pids="$pids $!"
done < "$tmp"
wait
The script is intentionally conservative. It ignores loopback, ignores IPv6, and only publishes single names that already end in .local. So consider this hosts snippet:
The script will publish oscope.local, but leaves server.example.com alone. That avoids accidentally dumping every fully qualified name in your hosts file into mDNS.
But Wait...
The wait at the end of the script matters. Each avahi-publish-address process has to stay alive for the record to remain published. If the shell script simply started them in the background and exited, systemd would consider the service finished and might clean up the child processes. By waiting, the script remains the service’s main process.
Of course, if you want to use this, it has to be a machine that knows to query mDNS. Ironically, your workstation probably does, but if it is configured to use /etc/hosts first, that won't matter there. But it does lead to a practical annoyance: not every application on every platform uses mDNS the same way. Android itself only relatively recently grew better support for normal application-level mDNS resolution, so behavior can vary depending on Android version, app, and resolver path. Chrome on Android seems to resolve .local names correctly in my testing.
Firefox was a little more subtle. At first it looked like Firefox on Android simply did not understand mDNS, but the real culprit was Secure DNS. If Firefox is configured to use DNS-over-HTTPS, it may bypass the local resolver path that knows how to handle .local names. Turning Secure DNS off, or adding exceptions for the local names you care about, lets those names resolve normally. That is not really an Avahi problem; it is an application side effect. To be fair, even if you stood up a LAN DNS server to solve the problem, Firefox would have probably still have skipped it in favor of its "secure" DNS.
Conflicting Data
There is another gotcha: name conflicts are not the only kind of conflict. You might expect trouble if you try to publish widget.local when some other device already owns widget.local, but address conflicts can be troublesome too. If some device is already publishing mDNS information associated with a particular IP address, trying to publish a second name for that same address may fail. In my case, avahi-publish-address did not fail gracefully; it wandered into a collision path and crashed. The safe approach is to check before publishing, avoid duplicate names and duplicate addresses, and let the device itself publish its own mDNS name when possible.
Still, for a small LAN, this is a nice compromise. /etc/hosts remains the simple text file I wanted, but Avahi turns selected entries into something other machines can discover without copying that file everywhere. It is not a replacement for real DNS, and it is not quite as seamless as the old single-machine hosts file. But for those odd devices that sit quietly on the network with an IP address and no useful name, it is a handy little bridge between the old world and the new one. Were there other ways to solve this? There always are. But this works for me.
In the sweltering temperatures of an unusually hot European heatwave, I found myself having a chat with a friend of mine from my university days. After discussing the health of his cat who had solved the problem of a fur coat on a hot day by flattening himself out on the concrete floor in the coolest place in the house, we moved on to tech matters. We’ve known each other for not far short of four decades, so this is familiar territory for us. The problems that come with taking a prototype to manufacturing, a process which even the most seasoned of engineers can slip up on.
The Difference Between Making, And Making For Manufacture
If you’ve ever taken a project and replicated it, you will know the progression. If you’re making five or ten widgets, you can debug and rework as needed, tweak things, and get things going. If you’re making more then this, the process consumes a greater proportion of your time, until a point at which manufacture becomes impractical. Maybe that’s around fifty boards, sometimes more or less.
This rework on the SHA2017 badge was caused by counterfeit parts rather than bad design, but the work it created was very costly for the team.
The skill a professional engineer picks up here is designing for manufacture. It’s something I picked only progressively over the years, and learned with a bang when I became peripherally involved in the production of electronic conference badges. You learn to be much more exact in your PCB design to avoid those reworks and bodge wires, you pick your parts with much greater care, and pay far more attention to power supplies, decoupling, thermal issues, impedances, and ground isolation. Something that works has to become something that always works, first time. You go from having several spins of the prototype PCB to having maybe a couple, and you reach a point at which you can order 5000 boards and have less than 50 of them that need attention. My friend describes himself as more of a software expert than hardware, but he’s learned this process over the decades far more than I have.
One comment he made hit the mark so well that it prompted me to start writing this: that when hiring recent graduates they would design things that could not be volume manufactured, while the new hire apprentices’ designs could. This fit so well with our common experience when we came through an engineering education that it posed the question, were we failed by it? We both attended the University of Hull, on England’s north-east coast, but this isn’t specific to Hull or even our generation as the problem of inadequate preparation applies to so many other institutions. Last year I talked about a couple of young engineers wrestling with an analagous experience here in the 2020s, and they were a long way from the Humber.
Do Universities Secretly See Their Job As Training More Academics?
Hull University Electronic Engineering Department, where I learned most of what I know about electronics (except how to make things for manufacture). Hullian111, CC BY-SA 4.0.
My overwhelming memory of my degree course was shared by my friend, that about half of it was composed of useful stuff, and the other half of it was either trying to teach you to be an electronic engineering academic like the people delivering the lectures, or a course that seemed only to be there because they had someone who could teach it.
My Achilies’ heel was the mathematics, something I was later told improved in later years when the engineering department wrested its students away from the maths department. We had a very small amount of practical work, including simple transistor circuits, digital logic using real 74-series chips, laying out a PCB using crêpe paper tape on acetate film, and oddly considering it was outdated even in the early 1990s, wire-wrapping.
It’s easy to sit here and say that a university course teaches too much theory and not enough practice, but the fact is that universities aren’t there to teach you to solder. Indeed, while it’s a super-useful thing to be able to do and I’d urge every electronic engineer to learn it, soldering your own projects is not what makes you an engineer. Instead there has to be an exploration of where the boundary lies between the theoretical and the practical, and education should straddle that line rather than stay only on one side of it. It’s in deciding where that straddling point stops that the key lies.
There are university courses that manage that boundary by splitting it entirely. They combine time in industry with time studying, and a student on one of those courses would in theory learn the skills of a real-world engineer in their work placements. There are also industry sponsorship schemes placing students into industrial environments, but they are so few and the competition for them so fierce, that they might as well not exist for most students. Even the world of hackerspaces which gives the students a rare chance to mix with professional engineers in their off-time, is actively discouraged by universities. For a student in a full-time, study-based course, the challenge comes in how to bridge that gap into real-world manufacturing despite all these challenges, and learn something useful without the luxury of a real-world environment.
Torturing The Students With Diabolical Designs
The temptation for most courses is to start yet another group project. A team of six students are tasked with getting something working together, and learn stuff. The trouble with group projects though is that they either completely don’t work like our early 1990s assignment to make a telephone exchange from a Transputer link adapter chip, or a few participants end up doing all the hard work like my two young friends mentioned earlier. Group projects are inexpensive for an institution, but they look better than they really are.
Component pinouts like this one from the NXP BAV23 datasheet are a spectacularly evil trick to play on an unsuspecting student.
The hardware hacker world has been marked by a series of epochs, as new technologies bring with them a flowering of creativity. There’s one of those that I think has the potential to delover something impossible back in the 1990s when I was a student, and allow individual students to learn the art of manufacture without a group project in sight. I’m talking about inexpensive PCB manufacture, which allows multiple spins of a design to be completed with a bearable wait, and for not a lot of money.
So if I wanted to teach a bunch of students about designing for manufacture, I’d give them a ready made small project in software form, as EDA files, and as a BOM with a board assembly house. Of course, the project would be fatally flawed but fixable with probably two or maybe three spins, but I wouldn’t tell them that. Instead their first task would be to send the files off and receive a ready-made PCB, or if I was feeling charitable I could give them that first spin ready-made, and tell them to get on with it.
I would throw everything I could at this unfortunate design, a wrong-but-plausible footprint, badly thought out earthing, an accidental oscillator, and all the really annoying things which we’ve all in our time found. I am sure you could think of more diabolical but superficially plausible features. Their task would involve diagnosing the board and redesigning it before sending the files off to the assembly house. A week later they’d have that next spin, they’d have to hunt down any remaining bugs and repeat it all, and so on. I learned this process with my friends in the making of an event badge for 5,000 people, and I think it’s possible that you could learn it as a single trainee engineer with a much smaller board.
It may be unfair to throw all that is wrong with engineering education at the door of universities, even though it’s certain that there are some extremely low hanging fruit. But arriving in the workplace completely lacking an essential skill is perhaps the point at which something should be said. The question is, when it comes to designing for manufacture, is anyone listening?
Blood pressure is one of the so-called “vital signs” that medical practitioners use to determine the basic state of a patient in any given moment. It’s exactly what it sounds like—a measurement of the pressure of the blood flowing through the body, with some complications to account for the pulsatile nature of human blood flow.
You might think measuring blood pressure is a solved concern, and it mostly is. With that said, some blood pressure monitors out there aren’t quite doing their job properly, and [Milos Rasic] came to Hackaday Europe 2026 to spell out the problem.
Under Pressure
Before exploring the issue, it’s worth first understanding how blood pressure is actually measured. On a baseline level, it’s the same as pressure being measured in any other fluid. Specifically, though, when it comes to blood, it’s important to measure the pressure at two points. There is the peak, when the heart muscle is contracting, referred to as systolic pressure, and the low point, when the heart relaxes, referred to as diastolic pressure. Thus, blood pressure is referred to with two numbers, such as “140 over 90” or 140/90, referring to systolic and diastolic pressures respectively. It’s sometimes important to track the mean arterial pressure, too. Typically, nominal blood pressure would be considered around 120/80 mmHg. High blood pressure, or hypertension, starts at figures over 130/80 mmHg, while low blood pressure, or hypotension, would be considered relevant below 90/60 mmHg.
Blood pressure can be monitored in a number of ways. Most of the time, non-invasive methods are preferred, whether in the doctor’s office or at home. [Milos] notes that the classic hand-pumped blood pressure cuff device (sphygmomanometer) and a stethoscope is still a perfectly excellent way to measure blood pressure in a clinical scenario. This is referred to as the Korotkoff method, where the doctor listens for pulsations in the artery to begin as the pressure of the cuff slowly drops below the systolic pressure, and then later ease as it reduces below the diastolic pressure, monitoring pressure in the cuff on a gauge as they go. Then there are digital versions of arm cuff blood pressure monitors, which [Milos] notes can have some problems. Meanwhile, there are advanced technologies in development to do live measurement with things like mmWave radar devices or ultrasonic tricks, but they’re still emerging and less established in clinical contexts.
Many cheap electronic blood pressure monitors use the oscillometric method to measure blood pressure. Few manufacturers share the algorithms they use, but [Milos] has found many use something similar to the above, approximating systolic and diastolic pressures from measurements taken to find the mean arterial pressure. Credit: presentation slides[Milos’s] talk focuses on the digital oscillometric analysis that is behind cheap electronic blood pressure monitors that commonly retail for $30-50. These devices start by pumping up an arm cuff to well above typical systolic pressures, before slowly letting it deflate. A sensor hooked up to the cuff is used to monitor the pressure during deflation. When the cuff is below systolic pressure but above diastolic pressure, the pressure in the cuff will oscillate with the pulsing of the blood flow. When isolated from the overall pressure loss from deflation, the amplitude of this oscillatory signal is maximum at the mean arterial pressure. According to [Milos], it’s common for electronic blood pressure monitors to then take some figure like 40% and 80% of the amplitude of the oscillation envelope, and grab the systolic and diastolic pressure values at those points. As far as accuracy goes, this method isn’t exactly perfect, being more of a useful approximation rather than something that’s rooted in a true direct measurement. Furthermore, [Milos] notes that, for example, Category A blood pressure monitors are only expected to land within a +/- 15 mmHg range, for 85% of their measurements. That’s not fantastic.
[Milos] has invested a great deal of time into the Open Cardiography Digital Measuring Device, hoping to better investigate alternative methods of measuring blood pressure in a non-invasive manner.[Milos] notes that it’s important to allow the patient to sit still for five minutes before measurement if numbers are to be at all comparable between checks, as many factors can influence blood pressure in the moment.The method used by these electronic devices tends to be a little inaccurate compared to the traditional clinical methods performed by trained professionals. For that reason, [Milos] developed the Open Cardiography Signal Measuring Device. It is specifically designed to test different algorithms for blood pressure measurement. It can measure pressure in an arm cuff, and also takes signals from a photopletyzmography (PPG) clamp for measuring blood oxygen saturation. There are also inputs for ECG and digital stethoscope signals, too. [Milos] has published the device’s design on Github for anyone to explore as desired. His talk explains how the device came together, and how he has been using it to evaluate the accuracy of off-the-shelf monitors and the use of alternative algorithms to those used in such units. He also discusses the challenges of measuring blood pressure accurately in this way when dealing with, for example, patients with less stable heart rates.
It’s an interesting exploration of a very specific part of vital sign measurement that few of us ever think about in detail. Sometimes it pays to know how the machines that you’re getting measurements from actually work, and whether you can trust what they’re saying. In the world of blood pressure measurement, [Milos] has done just that.
Login
