The Frikkin Lasers Contest Starts Now

May 28, 2026 by Elliot Williams 7 Comments

We don’t need to tell you: lasers are awesome. Those tiny red beams aren’t just for frustrating cats, but can do real work, be a source of infinite beauty, or constitute a science project in its own right — and you can win a $150 DigiKey gift certificate simply by writing your project up on Hackaday.io. The contest runs until July 23rd.

Of course, red lasers are only the beginning. If you have enough energy to move electrons into higher orbitals, you can make nearly anything lase. RGB setups can be breathtaking. Powerful IR and UV lasers are real tools. And the DIY side of lasering combines physics and electronics, with a spicy side of danger that needs to be contained.

We love laser builds of all sorts, and we’d like to see yours! Create a new Hackaday.io project that features what you’re working on, and we’ll pick our three favorites for a $150 gift certificate courtesy of this contest’s sponsor, DigiKey.

Continue reading “The Frikkin Lasers Contest Starts Now” →

Linux Fu: Fake Webcams Have Many Uses

May 28, 2026 by Al Williams 14 Comments

Dealing with text streams is a fundamental skill for the Linux power user. You can sort, merge, and search text files easily from the command line. What if you could do the same thing with video? Well, you can. Maybe you want to add a logo to a webcam feed before sending it to a conference app. Maybe you want to blur, color-correct, or annotate video in real time. Or perhaps you want to inject prerecorded video into Zoom while pretending it is a live camera. Linux can do all of this, and the key ingredient is usually the same: a loopback video device.

The basic idea is simple. Instead of an application reading directly from /dev/video0, you create a fake camera device using the v4l2loopback kernel module. Your software pipeline writes processed video into the fake camera, and applications read from it as if it were a normal webcam. The result is surprisingly powerful.

Continue reading “Linux Fu: Fake Webcams Have Many Uses” →

Virtual Museum Hosts Every OS You Haven’t Heard Of

May 28, 2026 by Tyler August 11 Comments

OK, every operating system is a bit of a stretch — Windows Vista notably didn’t make the cut — but [Andrew]’s Virtual OS museum has a good claim to being the most comprehensive archive of operating systems yet assembled.

[Andrew] has a blog post describing the project, as well as a YouTube video that we’ve embedded below. But the real fun is in the downloading and spinning up one of 570+ operating systems for more than 250 platforms on pre-configured virtual machines that have been packaged up for us.

This isn’t just the usual retrocomputer nostalgia-fest of Macintosh System and DOSBox. There’s everything from IBM Big Iron and VAXen to Texas Instrument graphing calculators emulated in the museum, with software to run on them, too. If you’ve ever wondered what you could do with the Manchester Baby, well, all known software for that machine is included with its ‘operating system’.

Admission is free, but like any good museum you’ll be waiting in line a while to get in, so expect the full 128 GB download to take some time. If you’re into computer history, though, it’s going to very much be worth the wait. If you try it and like it, you could help others by seeding the torrent.

The actual museum launches in a VM as a modern Linux system — perhaps that can be considered an exhibit itself — with a launcher to select any of the other system/OS combos, including various other, older Linuxes hosted on their own VMs. There are more to come, too, as [Andrew] continues the long debugging process of making sure everything works as expected.

Purists may decry this virtual emulation as not being quite the real thing, which is true. But while MiSTer supports a lot of cores via FPGA, you probably won’t find everything here on that platform. We have, however, seen an FPGA recreation of the Manchester Baby. More than once, even.

Continue reading “Virtual Museum Hosts Every OS You Haven’t Heard Of” →

Testing LFP Battery Failure Modes With Overcharging

May 28, 2026 by Maya Posch 33 Comments

As great as batteries are, it’s essential to understand their risks and how to keep them from going spicy. Recently there has been a bit of a fuss about the dangers of LiFePO₄ (LFP) batteries after someone’s dedicated LFP battery shed got shredded into matchsticks by a hydrogen explosion, following said LFP batteries having a thermal event. The thing about the LFP chemistry is that if it suffers such a thermal event, it generates hydrogen gas, which is one of the most explosion-happy gases known to man. This is demonstrated in a recent video by [Will Prowse].

To kick things off, a single prismatic LFP cell is overcharged for half an hour after it was already at 100% state of charge. This ultimately pops the vent as the cell begins to release hydrogen gas into the aquarium that the cell was placed in. Using a spark generator it’s then attempted to ignite the gas, which initially takes a bit as enough hydrogen has to collect first.

Once there’s ignition, however, it happily keeps burning as more and more hydrogen pours out of the by now bulging cell’s vent. If any other LFP cells had been nearby these too would be at risk of suffering thermal runaway, showing how just one bad LFP cell is enough to potentially set an LFP battery bank ablaze.

In a commercial setting you will have precautions such as hydrogen sensors, ventilation and spark generators to deal with any generated hydrogen gas, as well as blow-out panels in case things end up going squirrely in a hurry.

While a benefit of LFP chemistry is that it does not generate its own oxygen as with other lithium-ion chemistries, hydrogen gas is a major problem due to how incredibly volatile it is. It’s not just a headache with battery storage, but also in the nuclear power sector, where zirconium fuel rod cladding can very efficiently turn steam into hydrogen and oxygen. This was the reason why some of Fukushima Daiichi’s buildings suffered detonations, with the nuclear plant operator opting to not install recommended hydrogen gas mitigation systems.

Continue reading “Testing LFP Battery Failure Modes With Overcharging” →

Decoding The Tianwen-2 Sample Return Mission’s Telemetry Signal

May 27, 2026 by Maya Posch No comments

China’s Tianwen-2 asteroid sample return mission launched on 28 May of 2025 and is scheduled to arrive at its target – near-Earth asteroid 469219 Kamo’oalewa – in June 2026. This gives folk back on Earth plenty of time to listen in on the probe’s communication with its home base, such as [Daniel Estévez] who recently had a poke at this telemetry as captured by the Dwingeloo radio telescope in the Netherlands.

With not a lot of public information on its trajectory it’s a hard probe to track, but now that it’s nearing its destination there’s an obvious part of the sky to aim for. This is X-band telemetry, broadcast at 8428.19 MHz, with the same basic modulation as its predecessor Tianwen-1.

Where it differs is in the coding, with Tianwen-2 also using concatenated coding, but having a frame length that’s better suited to submitting full Reed-Solomon codewords and does not require omitting bytes to make things awkwardly fit.

After analyzing the telemetry data itself, there doesn’t seem to be anything exciting contained within this capture. This does seem to be as expected considering that the probe is still in its coast phase where it doesn’t have to do much and likely is in a low-power state most of the time. Once its orbital insertion burn begins is when this knowledge can likely be used to track the mission in fine-grained detail, which is an event that we’re definitely looking forward to.

Linux Distributions And Who Is Responsible For The Software

May 27, 2026 by Maya Posch 57 Comments

The topic of downstream and upstream is an important one in the Linux ecosystem, where from one base distribution you can go many layers of distros deep before even looking at all the other base distributions. Within that veritable jungle you get questions about who is responsible for packaging software, where to report bugs found with a specific application, as well as what ‘LTS’ truly means in a consumer context. These and other points are raised in a recent video by [Brodie Robertson], with many examples of things going tragically wrong.

There’s a good argument to be made that ultimately it is the distro that is responsible for the software that they provide via their repositories. As [Brodie] shows in the video, there are a few cases where an ‘LTS’ distro uses an old version of some software that contains a bug that has been fixed a while ago, so reporting it to the developer is rather pointless, while the distro maintainers should fix it with backporting of patches or updating the version.

From an end user experience this also makes the most sense, as in the end they just want to have the Windows experience of downloading a proverbial installer, clicking through whatever dialogs pop and have working software. If the software is provided via the distro, it is their responsibility, the same way that you contact the developer if you get a DEB or RPM from a GitHub project page and it doesn’t work.

This current Linux Chaos Vortex can be called a major issue when e.g. FreeBSD has no such upstream/downstream issues, with cross-platform installers being basically impossible on Linux ever since the Linux Standard Base effort died.

Perhaps Linux will get a distroless future, however, which may finally herald that Year of the Linux Desktop.

Continue reading “Linux Distributions And Who Is Responsible For The Software” →