Mysterious Files PH

The site of the Chornobyl Nuclear Power Plant (ChNPP) remains a unique location, as what’s left of the No. 4 reactor is the only place in the world where you can find significant amounts of what is called corium. An amalgamation of nuclear fuel, fuel rod cladding and whatever materials like concrete that the molten mass came into contact with, Soviet scientists initially struggled to make sense of this material, leading them to even have it shot at to get samples.

In this video documentary by [That Chernobyl Guy] these struggles by scientists both in and outside the USSR to comprehend this wholly new material are detailed. Much like trinitite – created by a US nuclear weapons test – these are amalgamations of material combined under extreme conditions. In the case of the ChNPP accident, the botched turbine spin-up test and disabling of all safeties by the operators allowed the bottom core chain reaction to run unconstrained, producing the massive steam explosion that flipped the biosafety lid of the RBMK reactor, while also fully melting the core material that then melted through the concrete below the reactor.

Although this Elephant’s Foot is only a tiny fraction of the total mass of corium inside the No. 4 reactor, it got rather infamous for supposedly being highly radioactive and lethal. In reality it’s one of the least dangerous parts of the exposed corium, and repeated sampling attempts along with internal degradation due to radioactive decay and weathering before the NSC shelter was installed have led to it mostly turning into slightly radioactive, rusty-looking dust at this point.

Also covered in the video is how the corium in the destroyed reactor is likely to be retrieved for final disposal, with robots cutting into the sides of the reactor building rather than trying to navigate destroyed corridors and staircases. This way it might be possible to remove most of the material without the issues that stymied Soviet engineers in the 1980s during their sampling attempts.

When we talk about programming in “bare metal,” it basically means writing software that runs right on the hardware with no operating system or abstraction layers in between. This gives the program the most direct possible access to peripherals and memory, with the tradeoff being that you don’t get the protection and ancillary features that come with an OS.

Sylvain Huet came down to Hackaday Europe 2026 to talk about making bare metal easy. Not just by ignoring operating systems and ever-bloating dependencies, but by rethinking the way we approach software development and by building a transparent platform from the ground up.

Down To Brass Tacks

Sylvain begins the talk with a look at where his own computing journey began. Back in 1982, he got his hands on a Thomson TO7, with just 8 kilobytes of user RAM and a 6809 CPU. The best way to have fun with the hardware was to work straight in assembly.  “It was easy to understand everything about your computer,” notes Sylvian of the simplicity of the platform. “There was almost no hidden side in this computer.” Of course, change was fast in that era, and a bit over a decade later, Sylvain was working on a Metaverse-like product called Second World, before moving on to work on Nabaztag in the early 2000s—a charming Wi-Fi enabled rabbit launched just as wireless networking was hitting the mainstream.

The through-line across all these projects was that much of the work was done at the bare metal level—often useful when it’s desirable to work as close as possible to the hardware peripherals or to maximise performance. Sylvain then contrasts this with how things are often done in this modern era. A poignant example was showing pictures from an airport during the CrowdStrike outage of 2024. Where once upon a time a flight schedule display might have been a purpose built device running on very simple hardware, these days it’s common to just kit out flat screen monitors with entire Windows computers behind them. It’s a convenient way to build, but as Sylvain explains, this complexity sometimes comes at a cost. He then shows that such a display can be very easily built with a Raspberry Pi running a bare-metal program with no operating system at all—with no automated security updates enforced by an outside OS provider, or any such heavy-handed management required. Since it’s coded to do one job from the ground up, it’s much less likely that the software falls apart due to some outside update or the collapse of some obscure dependency that nobody on the development team was even aware was included.

Sylvain talks about a “new minimalism”—where “all you need to understand should fit in your single brain.” It’s not just about working at the bare metal level, but about creating systems where a single developer actually understands the project from top to bottom.  Of course, there are limits to the size of a project any one person can completely understand, but for some applications, this can be a useful guiding principle. The talk also explores how we use things like outside libraries. Sylvain calls this the “low-level paradox”— wherein the more sophisticated a task is, the more we rely on black boxes to do parts of the work for us. It’s a fast way to develop, but quickly adds thousands of lines of code to a project and enables us to avoid understanding some of what’s actually going on under the hood.

To this end, Sylvain has created the Minimacy language. It’s intended to enable development with fewer dependencies, black boxes, and operating systems, while maximising the capacity for understanding. It’s concise, linear, and safe, with strong static typechecking and type inference. You can work with it using the Minimacy virtual machine, which combines an instant compiler and a virtual processor that can run the code. It’s 100% open source, and is written in less than 900 kB of C—both which support the ideal of being within the realms of a developer’s ability to understand the whole stack. Indeed, Sylvain demonstrates just how light it is by running a Minimacy game off a floppy disk on a modern UEFI laptop. The idea is that a Minimacy VM could run on a variety of different hardware, allowing near-bare-metal access for Minimacy code while still maintaining some level of portability across systems.

Sylvain also demonstrates the Minimacy Machine. It’s powered by a Raspberry Pi RP2350, running at 150 MHz, with lots of useful peripherals, including Ethernet connectivity, an OLED display, an SD card reader, and a real time clock. Armed with all that, it’s a platform that can run Minimacy code and allow the development of devices that run without relying on lots of outside dependencies or a heavy OS built for more general purpose tasks. It exists as a transparent software and hardware stack for developers to build upon.

Overall, though, Sylvain’s talk isn’t just about Minimacy or programming in bare metal. It’s about finding simplicity where it makes sense. Working in bare metal isn’t for everything of course, and the vast majority of us will continue to use operating systems across all sorts of applications where they’re necessary and useful. However, in the advanced age we live in, it’s sometimes good to remember that stripping away unnecessary layers of abstraction often makes a lot of sense, because they can distract us from the simple tasks we’re trying to achieve in the first place.

With the Xtensa Lx7 twin CPU cores in the ESP32-S3 running at a relatively zippy 240 MHz and accompanying PSRAM of up to 16 MB, you might find yourself wondering whether it could run Linux. As [Paulneja] demonstrates with Linux kernel 6.11, the answer is a ‘yes’, though with the usual caveats.

What complicates matters with the ESP32-S3 is that it lacks certain amenities that spoiled OSes like Linux have come to take for granted, such as a Memory Management Unit (MMU). To deal with this, the NOMMU Linux configuration was used, along with a custom fork() implementation. Although the previous 0.7 version sort-of worked, the current 0.8 release is the first that manages to actually boot reliably and has a usable amount of RAM available after boot.

You can see the comparison between the two versions in the header image, with v0.8 having a blistering 3.7 MB available after booting and with overall resource usage and performance having improved massively. Note that only one core is available to Linux, with the other used by the typical FreeRTOS ESP-IDF stack to provide WiFi and Bluetooth.

This was all run on an ESP32-S3 with the N16R8 configuration, meaning 16 MB Flash that’s also used for writable storage and 8 MB of octal PSRAM. As for practical applications, it’s noted by [Paulneja] that this is a research project, though one could imagine this being an embedded Linux project along the lines of a network router running something like BusyBox.

There are many uninterruptible power supply (UPS) solutions for the Raspberry Pi that take the form of HATs with a battery on board, but they’re not suitable for every situation. Web3-Pi are using the Pi 5 as an Ethereum node, and found the need for a UPS that didn’t sit on top of the Pi. Their solution is the Web3 Pi UPS, a device that sits in the USB power chain.

It’s a box that takes three power inputs, USB-C PD, a barrel jack, or a hot-swappable Sony camera battery, and puts out the constant 5 V at 5 A the Pi requires. The USB output isn’t just for power, it can communicate with the Pi to deliver telemetry and ask the OS to shut itself down if power reserves are failing. Inside are a CH32 RISC-V microcontroller that handles the power circuitry, and an RP2040 that handles control and an OLED screen for a UI. The project’s web site also mentions provision for an LTE add-on for remote monitoring, however this doesn’t at the time of writing appear to be fully implemented in the GitHub repository.

While it’s probable that few of you are mining Ethereum on your PI, we can see that there are plenty of other situations that this project could find a home in. It’s not the first Pi UPS we’ve seen, though some of them are considerably less complex or capable.

If you’re in motorsport, or maritime, or mining fields, you can always call on a technician to come down and fix something when it’s broken. You can lay hands on the parts, reconfigure things, make repairs, and get something working again. In space, that’s seldom possible. If you’re lucky enough to have a manned mission, you might be able to make some running repairs; if you’re working with an unmanned robot, probe, or satellite, your potions are altogether more limited. If you can’t find a fix, it’s game over—a particularly brutal result when huge budgets and years of work are on the line.

Janelle Wellons came down to Hackaday Europe to talk about space. More particularly, the engineering and debugging operations that keep all sorts of space programs alive. Her talk dives into some of the creative solutions engineers have had to come up with to save million-dollar missions from becoming unrecoverable boondoggles.

Janelle came down to Hackaday Europe to talk about space, because she lives and breathes it. An experienced aerospace engineer, she’s worked at NASA JPL and iSpace, contributing to the success of missions taking place far from our humble globe. She drew on that experience to talk through what it takes to keep a mission on the rails when things go a little sideways, which happens in space, just as it does anywhere else.

A fantastic example of that, retold in her talk, is the Galileo mission. It was built to travel far across the solar system, eventually winding up at Jupiter to study the Red Giant and its moons.  The probe was engineered with a pair of communication systems—a low-gain antenna for vital signs and management, and a high-gain antenna for sending science data and images back to Earth. The high-gain antenna was key to the mission, capable of offering 10,000 times the bandwidth of the low-gain antenna.

Tragically, though, the high-gain antenna never got to play its starring role. It didn’t deploy properly after launch, and that left NASA with a probe capable of capturing all this fantastic science data, but no way to send it home at a reasonable data rate. Janelle steps through the multiple hacks that make the most of the communication link with the low-gain antenna. NASA engineers whipped up compression algorithms for images and science data, and figured out how to array several Deep Space Network antennas for better signal. This netted an effective data transfer rate of 1,000 bits/second with the low gain antenna. It was still a far cry from the 134 kilobits per second that should have been possible with the high-gain antenna, but a huge leap forward from the 8-16 bits originally possible with the low-gain rig. Ultimately, it saved the mission, allowing the capture of mountains of scientific data on the largest planet in the solar system.

“NASA Astronaut Christina Cook is also working through troubleshooting steps of the waste management system that’s aboard the Integrity spacecraft.” – Ground control, Artemis II mission, 2026

Another great story told by Janelle concerned the Artemis II mission. The lunar flyby was part of NASA’s efforts to eventually return to the Moon itself, and was notable for debuting some special new hardware—the toilet. Unlike previous visits to the moon as part of the Apollo program, Artemis astronauts travel in luxury, with a proper commode built to handle the specific requirements of the zero-gravity space environment. Unfortunately, though, this new hardware had plenty of teething problems.

Early attempts to repair the system involved attempting to reprime the toilet’s pump by adding water to the system. It wasn’t long before the toilet threw another error, though. On the short-duration Artemis II mission, the toilet was set up to vent urine to space. Only, venting wasn’t working—with the suspicion being that the vent pipes had frozen over. The trick to solve this was simple—turning the spacecraft to face the vents towards the sun, so as to heat them enough to melt the blockage. Janelle also notes that during the multiple periods the toilet was down, the astronauts had to rely on alternative means of passing waste—showing a slide of the “collapsible contingency urinals” that did the job.

There’s also a great look at Perseverance’s twin, which lives here on Earth. Janelle has been down to the Mars yard at NASA’s Jet Propulsion Laboratory, where engineers, in her words—”test before you do.” The problem is, when you’re driving a robot on a foreign planet, you can’t just send someone over to repair a broken wheel or flip it back up if it tips over. Thus, many maneuvers and operations are rehearsed in the Mars yard with the twin of Perseverance, running it over recreated obstacles to determine a safe plan of attack.

Recently researchers finished mapping the central nervous system (CNS) connectome of not just the female Drosophila melanogaster (i.e. fruit fly) brain, but also that of the male D. melanogaster for a comparative analysis. Here the sexually dimorphic changes turned out to induce specific mating behavior that ensures that there will only be smooching between genetically fit D. melanogaster males and females, while the rest of the connectome remained effectively the same.

Of course, with this connectome in hand it led some people to ask themselves what else one can do with this connectome graph of about 160,000 neurons other than make a fruit fly into a fruit fly. So far we have seen [Nftechie] turn this connectome into a crypto stock trader with the Stonkfly project that uses the connectome’s reward circuits to potentially make profitable trades, though [Nftechie] says that they haven’t verified yet how good a fruit fly is at trading stocks, only that it does said stonks.

Over at [PC Gamer] they summarized a number of things that people have also done, including trying to make the connectome control a game of DOOM and Beat Saber. Each game frame stimulates sensory neurons, with the generated outputs then mapped to game controls, with dopamine-producing reward circuits wired in for reinforcement learning.

Although the D. melanogaster brain is only the merest fraction of the size of the human brain, it does provide us with a glimpse of what actual artificial intelligence research may lead to, as we unravel how even a 160,000 neuron connectome is enough to make these terrors of rotting plant matter do their wonderful things.

After the Orion capsule of the Artemis I lunar mission returned to Earth, it was found that massive chunks of its heatshield had been ripped off, posing a serious risk to any future missions. In a recent video in which [polymatt] takes a break from repairing old laptop shells and the like, he tries to recreate the Orion’s heatshield using a variety of methods and materials.

For this test a number of samples were created, each using the same kind of segmented structure as the larger Orion heatshield. The filler was created from the published materials for the heat shield by NASA, requiring just serious mixing.

The resulting samples were then cured with thermocouples inserted, before they got blasted with the heat from a propane torch, trying to simulate the various re-entry patterns.

Perhaps unsurprisingly, the results matched the findings by NASA for why the Orion’s heat shield had failed, being the build-up of gases due to the sustained pyrolysis processes that eventually fractured the material. Despite some experimental flaws that injected residual heat from the copper structure, this still seems to be a pretty good setup to test ablative heat shields in DIY lab conditions.