You might not have noticed, but we here at Hackaday are pretty big fans of Open Source — software, hardware, you name it. We’ve also spilled our fair share of electronic ink on things people are doing with AI. So naturally when [Jeff Greerling] declares on his blog (and in a video embedded below) that AI is destroying open source, well, we had to take a look.

[Jeff]’s article highlights a problem he and many others who manage open source projects have noticed: they’re getting flooded with agenetic slop pull requests (PRs). It’s now to the point that GitHub will let you turn off PRs completely, at which point you’ve given up a key piece of the ‘hub’s functionality. That ability to share openly with everyone seemed like a big source of strength for open source projects, but [Jeff] here is joining his voice with others like [Daniel Stenberg] of curl fame, who has dropped bug bounties over a flood of spurious AI-generated PRs.

It’s a problem for maintainers, to be sure, but it’s as much a human problem as an AI one. After all, someone set up that AI agent and pointed at your PRs. While changing the incentive structure– like removing bug bounties– might discourage such actions, [Jeff] has no bounties and the same problem. Ultimately it may be necessary for open source projects to become a little less open, only allowing invited collaborators to submit PRs, which is also now an option on GitHub.

Combine invitation-only access with a strong policy against agenetic AI and LLM code, and you can still run a quality project. The cost of such actions is that the random user with no connection to the project can no longer find and squash bugs. As unlikely as that sounds, it happens! Rather, it did. If the random user is just going to throw their AI agent at the problem, it’s not doing anybody any good.

First they came for our RAM, now they’re here for our repos. If it wasn’t for getting distracted by the cute cat pictures we might just start to think vibe coding could kill open source. Extra bugs was bad enough, but now we can’t even trust the PRs to help us squash them!

youtube.com/embed/bZJ7A1QoUEI?…

hackaday.com/2026/02/22/what-a…

Mega Man is a popular video game character who is perhaps most notable for having a sort of lasery-type blaster for an arm. A real hand cannon, if you will. It’s officially called the Mega Buster, and [Arnov Sharma] recently recreated it for cosplay purposes.

Key to any good cosplay build is getting the visuals right, and [Arnov] achieved that well. The Mega Buster was first recreated in Fusion 360, scaled to an appropriate size to fit [Arnov]’s arm. It was 3D printed in several sections, with the body including a grab handle and fire button inside, and the side panel and blaster nozzle having provision for installing LEDs. The former is the blaster’s “power meter” which shows how many shots it has left until it runs out of energy, with the blaster able to fire six times before needing to cooldown. A Raspberry Pi Pico controls the LEDs and provides sound effects with the aid of a PAM8403 class D amplifier module and a small speaker.

The 3D files are available on Instructables for the curious. Perhaps by virtue of its arm-mounted nature, this build reminds us of the venerable Pip Boy from Fallout, of which we’ve seen many grand recreations before. Video after the break.

youtube.com/embed/CMXTvWcF8Cg?…

hackaday.com/2026/02/22/recrea…

Recently [ElecrArc240] got his paws on an Intel-branded 3 kW power supply that apparently had been designed as a reference PSU for servers. At 3 kW in such a compact package air cooling would be rather challenging, so it has a big water block sandwiched between the two beefy PCBs. In the full teardown and analysis video of the PSU we can see the many design decisions made to optimize efficiency and minimize losses to hit its 80 Plus Platinum rating.

For the power input you’d obviously need to provide it with 240 VAC at sufficient amps, which get converted into 12 VDC at a maximum of 250 A. This also highlights why 48 VDC is becoming more common in server applications, as the same amount of power would take only 62.5 A at that higher voltage.

The reverse-engineered schematic shows it using an interleaved totem-pole PFC design with 600 V-rated TI LMG3422 600V GaN FETs in the power stages. After the PFC section we find a phase-shifted full bridge rectifier with OnSemi’s SiC UF3C065030K4S Power N-Channel JFETs.

There were a few oddities in the design, such as the Kelvin source of the SiC JFET being tied into the source, which renders that feature useless. Sadly the performance of the PSU was not characterized before it was torn apart which might have provided some clues here.

Schematic diagram of the AC-DC circuit in the 3 kW, 12VDC power supply. (Credit: ElectrArc240, YouTube)
youtube.com/embed/da9GwXX-0Zs?…

hackaday.com/2026/02/22/inside…

As far as punctuation goes, the exclamation mark is perhaps the most eye-catching of the bunch. That’s why [Conrad Farnsworth] thought this form would be perfect for his Home Assistant notifier build.

The key to this build is the large bi-color printed housing in the shape of an exclamation mark. It makes for an attractive wall-hanging, but it also perfectly serves the purpose [Conrad] had in mind. Inside the enclosure is an ESP32, hooked up to a string of 16×8 LED matrixes which are commanded over I2C. These sit behind a white panel in the enclosure to nicely diffuse the light and make their output more readable. The ESP32 displays notifications on the LEDs that are fed from Home Assistant, such as when the mailbox sensor is triggered or if a vehicle is detected in the driveway. There’s also a bell on the unit to provide audible notifications, which us dinged with a solenoid fired via a 2N2222 transistor switching a 12-volt supply from a boost converter.

It’s a neat build that fits nicely into [Conrad]’s daily life and appears to have some genuine utility. If you’re looking for other ways to neatly display notifications where you can see them, you might consider whipping yourself up a smart mirror. Video after the break.

youtube.com/embed/C5UuRmCwZ78?…

hackaday.com/2026/02/22/exclam…

Theoretically a belt drive makes for a great upgrade to a bicycle, as it replaces the heavier, noisy and relatively maintenance-heavy roller chain with a zero-maintenance, whisper-quiet and extremely reliable belt that’s rated at an amazing 20-30,000 km before needing a replacement. Of course, that’s the glossy marketing brochure version of reality, which differed significantly from what [Tristan Ridley] experienced whilst cycling around the globe.

Although initially he was rather happy with his bike, its sealed car-like Pinion gearbox and Gates carbon belt drive system, while out in the wilds of Utah he had a breakdown when the belt snapped. When the spare belt that he had carried with him for the past months also snapped minutes later after fitting it on, it made him decide to switch back to the traditional bush roller chain.

Despite this type of chain drive tracing its roots all the way back to Leonardo da Vinci, they actually offer many advantages over the fancy carbon-fiber-reinforced polyurethane belt. Although with the Pinion gearbox the inability to use a derailleur gearing system is no big deal, [Tristan] found that the ‘zero maintenance’ part of the belt was not true for less hospitable roads

Anyone up for some tasty peanut butter? (Credit: Tristan Ridley, YouTube)
A big issue was that of abrasive dust, which created a very noisy coating on the belt that’d have to be regularly cleaned off with precious water, or by having silicone lubricant sprayed on the belt. Even with all that care he found that the belt would snap after about 8,000 km, well below the rated endurance.

When it came to super-sticky mud, called peanut butter mud for good reasons, he found that chains also cope much better with this, as the mud will just squeeze out of the chain and be forced off the sprocket, whereas the belt will happily keep compacting the mud onto the contact surfaces, increasing belt tension and requiring constant cleaning to not become hopelessly stuck.

The Utah breakdown also showed why these belts are actually very fragile: the replacement belt had been packed away folded-up for a few months at that point in the luggage, and during storage the carbon fibers had become compromised to the point where the belt just snapped after a few minutes of use. A metal chain will happily be stored away for as long as you can keep it away from corrosion, and fold up very compactly.

Another awesome feature of roller chains is that they’re super-modular, allowing you to carry spare links and such with you for in-the-field repairs, while even the most remote bicycle store in any country can help you out with maintenance and repairs, unlike the special and highly custom belts that need to be shipped in by courier.

Of all the bicycle technologies that [Tristan] has used, it seems that only this drive belt has been an outright disappointment. The sealed gearbox would seem to be a massive improvement over finicky derailleurs, and hydraulic brakes are reliable and common enough that they haven’t been an issue so far.

His conclusion is that bicycle drive belts are fine if you do city driving, where they probably will last the rated kilometers, but they rapidly fall apart in even slightly adverse conditions.

youtube.com/embed/nx5nN3kyx5k?…

hackaday.com/2026/02/21/why-ch…

[Hans Rosenberg] has a new video talking about a nasty side effect of using resistors: noise. If you watch the video below, you’ll learn that there are two sources of resistor noise: Johnson noise, which doesn’t depend on the construction of the resistor, and 1/f noise, which does vary depending on the material and construction of the resistor.

In simple terms, some resistors use materials that cause electron flow to take different paths through the resistor. That means that different parts of the signal experience slightly different resistance values. In simple applications, it won’t matter much, but in places where noise is an important factor, the 1/f or excess noise contributes more to errors than the Johnson noise at low frequencies.

[Hans] doesn’t just talk the math. He also built a simple test rig that lets him measure the 1/f noise with some limitations. While you might pretend that all resistors are the same, the test shows that thick film resistors produce much more noise than other types.

The video shows some rule-of-thumb lists indicating which resistors have better noise figures than others. Of course, resistors are only one source of noise in circuits. But they are so common that it is easy to forget they aren’t as perfect as we pretend in our schematics.

Want to learn more about noise? We can help. On the other hand, noise isn’t always a bad thing.

youtube.com/embed/omn_Lh0MLA4?…

hackaday.com/2026/02/21/quieti…

An interesting detail about the Intel 8087 floating point processor (FPU) is that it’s a co-processor that shares a bus with the 8086 or 8088 CPU and system memory, which means that somehow both the CPU and FPU need to know which instructions are intended for the FPU. Key to this are eight so-called ESCAPE opcodes that are assigned to the co-processor, as explained in a recent article by [Ken Shirriff].

The 8087 thus waits to see whether it sees these opcodes, but since it doesn’t have access to the CPU’s registers, sharing data has to occur via system memory. The address for this is calculated by the CPU and read from by the CPU, with this address registered by the FPU and stores for later use in its BIU register. From there the instruction can be fully decoded and executed.

This decoding is mostly done by the microcode engine, with conditional instructions like cos featuring circuitry that sprawls all over the IC. Explained in the article is how the microcode engine even knows how to begin this decoding process, considering the complexity of these instructions. The biggest limitation at the time was that even a 2 kB ROM was already quite large, which resulted in the 8087 using only 22 microcode entry points, using a combination of logic gates and PLAs to fully implement the entire ROM.

Only some instructions are directly implemented in hardware at the bus interface (BIU), which means that a lot depends on this microcode engine and the ROM for things to work half-way efficiently. This need to solve problems like e.g. fetching constants resulted in a similarly complex-but-transistor-saving approach for such cases.

Even if the 8087 architecture is convoluted and the ISA not well-regarded today, you absolutely have to respect the sheer engineering skills and out-of-the-box thinking of the 8087 project’s engineers.

hackaday.com/2026/02/21/how-th…

If you’re interested in extraterrestrial life, these past few years have given an embarrassment of places to look, even in our own solar system. Mars has been an obvious choice since before the Space Age; in the orbit of Jupiter, Europa’s oceans have been of interest since Voyager’s day; the geysers of Enceladus give Saturn two moons of interest, if you count the possibility of a methane-based chemistry on Titan. Even faraway Neptune’s giant moon Triton probably has an ocean layer deep inside. Now the planet Uranus is getting in on the act, offering its moon Miranda for consideration in a kinda-recent study in the Planetary Science Journal.

Miranda and Uranus, the new hot spot for life-hunters.
Photomontage credit NASA.
Even if you’re into astronomy, it may seem like this is coming out of left field. “Miranda, really? What new data could we possibly have on a moon of Neptune nobody’s visited since the 1980s?” Well, none, really. This study relies on reexamining the data collected during the Voyager 2 encounter and trying to make sense of the chaotic, icy world that the space probe revealed.

The faults and other features on Miranda indicated it was geologically active at some point; this study tries to recreate the moon’s history through computer modelling to find that Miranda probably had a ≥100 km thick ocean sometime in the last 100-500 million years, and that while some of it has likely frozen since, tidal heating could very well keep a layer of liquid water within the moon’s interior. Since the moon itself is only 470 km (290 mi) in diameter, a 100km deep ocean layer would actually be a huge proportion of its volume.
The model is a fairly simple one, with the ocean sandwiched between two layers of ice and a rocky core. Image from Caleb Strom et al 2024 Planet. Sci. J. 5 226
Right now, the over-optimistic thinking is that “water means life”, since that’s how it seems to work on Earth. It remains to be seen if Miranda, or indeed any of the icy moons, ever evolved so much as a microbe. Aside from the supposed presence of liquid dihydrogen monoxide, there’s nothing to suggest they have. Finding out is going to take a while: even with boots — er, robots — on the ground, Mars isn’t giving up that secret easily. Still, if we’re able to discover irrefutable evidence for such extraterrestrial life, it will provide an important constraint on one term of The Drake Equation: what fraction of worlds develop life. That by itself won’t tell us “are we alone,” but it will be interesting.

Of course, even if all these worlds are barren now, they might not be for long, once our probes start visiting.

Story via Earth.com

Header image: Miranda, imaged by Voyager 2. Credit NASA/JPL-Caltech

hackaday.com/2026/02/21/mirand…

Although digital computers are – much like their human computer counterparts – about performing calculations, another crucial element is that of memory. After all, you need to fetch values from somewhere and store them afterwards. Sometimes values need to be stored for long periods of time, making memory one of the most important elements, yet also one of the most difficult ones. Back in the 1950s the storage options were especially limited, with a 1959 Bell Labs film reel that [Connections Museum] digitized running through the bleeding edge of 1950s storage technology.

After running through the basics of binary representation and the difference between sequential and random access methods, we’re first taking a look at punch cards, which can be read at a blistering 200 cards/minute, before moving onto punched tape, which comes in a variety of shapes to fit different applications.

Electromechanical storage in the form of relays are popular in e.g. telephone exchanges, as they’re very fast. These use two-out-of-five code to represent the phone numbers and corresponding five relay packs, allowing the crossbar switch to be properly configured.

Twistor memory demonstration. (Credit: Bell Labs, 1959)
After these types of memory, we move on to magnetic memory, in the form of well-known magnetic tape that provide mass storage in relatively little space. There is also the magnetic drum, which is much like a very short and very fast tape and provides e.g. working memory. This is what e.g. the Bendix G-15 uses for its clock signal and working memory, while magnetic tape and punched tape are used for application and data storage.

Next we cover magnetic-core memory, which stores a magnetic orientation in its ferrite rings or on a ferrite plate. This is non-volatile memory, but has low bit density and performs destructive reads, preventing its use beyond the 1970s. Today’s NAND Flash memory has significant overlap with core memory in its operating principles, both in its advantages and disadvantages.

An interesting variation on core memory is Twistor memory, which saw brief use during the late 1960s and early 1970s. Invented by Bell Labs, it was supposed to make for cheaper core-like memory, but semiconductor memory wiped out its business case, along with the similar bubble memory. An interesting feature of Twistor memory was the ability to add write-inhibit cards containing permanent magnets.

Fascinatingly, a kind of crude mask ROM is also demonstrated, before we move on to the old chestnut of vacuum tubes. Demonstrated is a barrier-grid tube, which uses electrons to create an electrostatic charge on a mica surface. This electron beam is also used to read the value, which is naturally destructive, making it somewhat similar to core memory in its speed and functionality.

Finally, we get the flying-spot store system, which is a type of optical digital memory. This is reminiscent of optical disc systems like the Compact Disc, and a reminder of all the amazing breakthroughs that we’d be seeing over the next decades.

Perhaps the best part about this video is that it shows the world as it sidled still mostly unaware towards these big changes. Memory storage was still the realm of largely hand-assembled, macro-sized devices, vacuum tubes and chunky electromechanical relays. Only a few years after this video was released, we’d see semiconductor technology turn the macro into micro, by the 1970s nerds would be fighting over who had the most RAM in their home computers, and CD-ROMs would set the world of computer storage and home game consoles ablaze by the 1990s with literally hundreds of MBs of storage per very cheap disc.

youtube.com/embed/Px9ZfLyeAWU?…

hackaday.com/2026/02/21/retrot…

Your project doesn’t necessarily have to be a refined masterpiece to have an impact on the global hacker hivemind. Case in point: this great demo of using a 64-point time-of-flight ranging sensor. [Henrique] took three modules, plugged them into a breadboard, and wrote some very interactive Python code that let him put them all through their paces. The result? I now absolutely want to set up a similar rig and expand on it.

That’s the power of a strong proof of concept, and maybe a nice video presentation of it in action. What in particular makes [Henrique]’s POC work is that he’s written the software to give him a number of sliders, switches, and interaction that let him tweak things in real time and explore some of the possibilities. This exploratory software not only helped him map out what directions to go, but they also work in demo mode, when he’s showing us what he has learned.

But the other thing that [Henrique]’s video does nicely is to point out the limitations of his current POC. Instantly, the hacker mind goes “I could work that out”. Was it strategic incompleteness? Either way, I’ve been nerd-sniped.

So are those the features of a good POC? It’s the bare minimum to convey the idea, presented in a way that demonstrates a wide range of possibilities, and leaving that last little bit tantalizingly on the table?

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!

hackaday.com/2026/02/21/in-pra…

[Oliver Pett] loves creating automata; pieces of art whose physicality and motion come together to deliver something unique. [Oliver] also has a mission, and that mission is to complete the most complex automata he has ever attempted: The Archer. This automaton is a fully articulated figure designed to draw arrows from a quiver, nock them in a bow, draw back, and fire — all with recognizable technique and believable motions. Shoot for the moon, we say!

He’s documenting the process of creating The Archer in a series of videos, the latest of which dives deep into just how intricate and complex of a challenge it truly is as he designs the intricate cams required.

A digital, kinematic twin in Rhino 3D helps [Oliver] to choose key points and determine the cam profiles required to effect them smoothly.In simple automata rotational movement can be converted by linkages to create the required motions. But for more complicated automata (like the pen-wielding Maillardet Automaton), cams provide a way to turn rotational movement into something much more nuanced. While creating the automaton and designing appropriate joints and actuators is one thing, designing the cams — never mind coordinating them with one another — is quite another. It’s a task that rapidly cascades in complexity, especially in something as intricate as this.

[Oliver] turned to modern CAD software and after making a digital twin of The Archer he’s been using it to mathematically generate the cam paths required to create the desired movements and transitions, instead of relying on trial and error. This also lets him identify potential collisions or other errors before any metal is cut. The cams are aluminum, so the fewer false starts and dead ends, the better!

Not only is The Archer itself a beautiful piece of work-in-progress, seeing an automaton’s movements planned out in this way is a pretty interesting way to tackle the problem. We can’t wait to see the final result.

Thanks [Stephen] for the tip!

hackaday.com/2026/02/21/love-c…

Regardless of what you think of GPT and the associated AI hype, you have to admit that it is probably here to stay, at least in some form. But how, exactly, does it work? Well, MicroGPT will show you a very stripped-down model in your browser. But it isn’t just another chatbot, it exposes all of its internal computations as it works.

The whole thing, of course, is highly simplified since you don’t want billions of parameters in your browser’s user interface. There is a tutorial, and we’d suggest starting with that. The output resembles names by understanding things like common starting letters and consonant-vowel alternation.

At the start of the tutorial, the GPT spits out random characters. Then you click the train button. You’ll see a step counter go towards 500, and the loss drops as the model learns. After 500 or so passes, the results are somewhat less random. You can click on any block in the right pane to see an explanation of how it works and its current state. You can also adjust parameters such as the number of layers and other settings.

Of course, the more training you do, the better the results, but you might also want to adjust the parameters to see how things get better or worse. The main page also proposes questions such as “What does a cell in the weight heatmap mean?” If you open the question, you’ll see the answer.

Overall, this is a great study aid. If you want a deeper dive than the normal hand-waving about how GPTs work, we still like the paper from [Stephen Wolfram], which is detailed enough to be worth reading, but not so detailed that you have to commit a few years to studying it.

We’ve seen a fairly complex GPT in a spreadsheet, if that is better for you.

hackaday.com/2026/02/21/microg…