Want Energy Efficiency? Dude, You’re Getting A Dell!

August 8, 2026 by Tyler August 5 Comments

With a title like “Intel Just Matched Apple Silicon. Seriously.“, the latest video from [Jeff Geerling] makes some pretty bold claims. But as we’d expect from [Jeff], he’s got the benchmarks up on GitHub for both the MacBook Neo and Dell’s latest XPS 13 to back it up.

We’ve embedded the full video below, which has [Jeff]’s comparative review of the two laptops. The Mac wins on iGPU, sound, and not shipping Windows, while the Dell gets points for being able to load Linux and having a backlit keyboard. But the figure we were hoping to see is the efficiency. After all, it’s ARM’s ability to crank out gigaflops on fewer watts that won them the mobile market and got Apple interested in that architecture in the first place. If Intel is catching up, that’s news.

On [Jeff]’s version of the Top500 benchmark — the same HPL Linpak test used for Supercomputers — the MacBook cranked out 57.012 Gflops at 10.6W, for 5.38 Gflops/W while the Dell managed 127.91 Gflops at 20.6W, for 6.21 Gflops/W. That’s just astounding, considering the historical data all goes the other way. This Dell also beats out both M4 and M3 Mac Studios, only failing to the M4 Mac Mini at 7.57 Gflops/W. Even when not crunching big numbers, say at idle or web browsing, the XPS matches the MacBook sip for sip in energy efficiency.

Some people have been saying for a few years now that ARM’s observed advantages in power consumption have more to do with the chips themselves than the instruction architecture, and it looks like the Core 5 320 chip in this Dell proves them right when it comes to x86.

While you might think you need to code in Assembly or C to maximize those efficiency gains, your choice of language may not be as important as you think.

Continue reading “Want Energy Efficiency? Dude, You’re Getting A Dell!” →

The BBC Tetris Companion

August 7, 2026 by Al Williams No comments

[Leaded Solder] took on an interesting challenge. The BBC, apparently, produced a game console known as the BBC Bridge Companion that connected to your TV and helped you learn to play Bridge back in 1985. At £200, we doubt many were sold new, but there were nine ROM cartridges available, presumably at an additional cost. [Leaded Solder] doesn’t care about playing bridge, but decided to teach the computer itself to play Tetris.

Inside is what you might expect for 1985. A Z80 and TI video chip, although naturally enough, it is the PAL variant. With 16K of VRAM the machine would have been very capable for its day. Unlike some game systems, the Bridge Companion runs its own code before launching what’s on the ROM cartridge. That required a few evenings of reverse engineering to figure out the correct header. Meanwhile, the surplus real hardware needed a quick repair on its cartridge slot before he could test it with real metal.

There were more hurdles, including adapting the PAL output for a composite monitor. Don’t miss the second part of the series for more technical details, and we’ll be interested in following the posts to their conclusion later this month.

Oddly enough, we think this is the first time the BBC Bridge Companion has made an appearance on Hackaday. However, we’ve had no shortage of card shufflers.

Block, Shmock — Just Pump Water Over The Chip

August 7, 2026 by Tyler August 7 Comments

If you’re water cooling a PC, it’s generally accepted that you need some interface between the coolant and the chips — a water block of copper or aluminum that carries the heat-removing fluid. What if you just…didn’t? That’s what [TrashBench] asked with his direct water cooling experiment. Instead of integrated pump or copper water block, he just epoxied a 3D printed pipe fitting onto his bare GPU and CPU.

The results are interesting: while the directly-cooled GPU outperforms the professional system by a decent margin, the same technique fails when applied to the CPU. It also leaks and nearly ruins his hardware, but those are the risks you take when doing mad science, and it’s nothing more epoxy can’t fix. In any case, the fact that directly exposing chips to liquid can cool them down isn’t exactly a revelation. People have been dunking computers in oil for years, but the fact that he sees such a difference between CPU and GPU is quite interesting. [TrashBench] has his own theory in the video, but what do you think is going on here?

In any case, if he continues his direct cooling experiments he’s still going to need a radiator, and if we may be so bold, we would like to recommend a giant metal snake.

Continue reading “Block, Shmock — Just Pump Water Over The Chip” →

This Filesystem Is Born To Fail

August 7, 2026 by Al Williams 12 Comments

Sandboxing a Linux process usually means spending a lot of effort deciding what it isn’t allowed to see. You might put it in a mount namespace, bind-mount a few directories into place, hide some others, add a chroot, and generally construct a carefully restricted version of the filesystem. But a new Linux kernel feature is about to change all of that. Instead of carefully hiding most of the filesystem, why not just take the filesystem away?

That’s essentially the idea behind FailFS, a tiny pseudo-filesystem expected to land in Linux 7.3. As the name suggests, it doesn’t do very much. In fact, that’s the point: every operation that reaches FailFS returns EOPNOTSUPP, meaning “operation not supported.”

The interesting bit is what happens when a process uses FailFS as its root or current working directory. At that point, normal pathname lookup essentially ceases to work. Absolute paths fail. Absolute symbolic links fail. Relative paths using the normal current-directory mechanism fail. If the application tries to open /etc/passwd, there simply isn’t a useful /etc to find.

Continue reading “This Filesystem Is Born To Fail” →

Hacking A $6000 Cotton Candy Machine To Fully Control It

August 7, 2026 by Maya Posch 6 Comments

Some of the cotton candy options by the machine. The Chinese text reads 'flower type'. — Some of the cotton candy options by the machine. The Chinese text reads ‘flower type’.

Having a fully automated cotton candy vending machine in your possession is a great thing, but not if you do not have full access to its software. With [Block’s Retro Repairs] getting ghosted by the manufacturer on regaining account access to the machine he bought used for $300, there was little left but to try and break into the system.

We previously covered the journey in getting the vending machine back into a state where it’d actually reliably produce cotton candy again, a process which is quite tedious and temperamental. After a lot of fiddling with sensors and temperature settings this was fixed, but still left the issue that as a vending machine it should allow the owner to set prices and such. Sadly this could only be done remotely via a special account, which access to had been left with the previous owner.

Despite the very custom exterior, the vending machine runs what is effectively an Android system, consisting of an industrial computer board wired into a lot of stepper drivers and other control boards. To the extreme delight of everyone involved, it was possible to access the Ct Terminal application with adb and its product database on the device’s storage. Unfortunately writing back a changed database file didn’t change anything in the UI, so for a few months the project languished.

After nearly bricking the system and ending up factory resetting the control software including temperatures, it actually improved the performance of the machine and produced cotton candy, so that was one win. Ultimately the solution was to modify the original app, but a combination of weak coding skills and the app being in Chinese led him to use free LLM coding chatbots to assist here.

This resulted in a custom settings menu being added with the ability to modify pricing, no need for online access any more and a very nice cotton candy vending machine for the private arcade where presumably friends and family can enjoy cheap or even free cotton candy. Finally having the machine sealed against ant intrusion was also a major improvement.

Continue reading “Hacking A $6000 Cotton Candy Machine To Fully Control It” →

Chernobyl’s Robots, Or The Hackathon From Hell

August 7, 2026 by Maya Posch 10 Comments

When the Chernobyl Nuclear Power Plant’s #4 reactor experienced an extreme criticality event on that infamous day in 1986, the resulting steam explosion and lack of any kind of containment building meant that parts of the core were scattered throughout the site. In an extensive update to the original 2023 video, the [Chornobyl Family] covers the mad scramble to design robots to perform on-the-ground measurements, and ultimately remove all this debris for safe disposal.

The TR-1A, an early debris removal robot. (Source: Chornobyl Family, YouTube)

This essentially took the form of a hackathon, involving teams from all over the USSR and allied nations, creating the most diverse range of robots that 1980s Soviet technology and later Western technology could muster.

Many of these robots didn’t perform very well, or at all, mostly due to the bypassing of any kind of testing before deployment. Especially at the beginning of the clean-up the robots were being pushed into the high-radiation zones as soon as they were finished, with not only mechanical issues being a problem, but also with e.g. inaccurate radiation measurements by the RR-1 robot, that overstated measurements by more than a factor of ten. Meanwhile the RR-2 and RR-3 were too top-heavy and after deployment by helicopter simply tipped over. Eventually manual measurements proved to be faster and safer.

Early debris removal robots like the TR-1A were rather simplistic, with successive generations of robots over the next weeks and months improving on it. The use of a combustion engine instead of batteries provided to be a boon, as combustion engines are far less affected by radiation.

The BAER Beloyarets used an airport cart as the basis, with its electronics relying on vacuum tube technology and relays, with an internal combustion engine. This proved to be one of the most reliable designs and it’s been largely preserved on display in the Chornobyl Exclusion Zone, with many others of these robots also being on display around the nuclear plant or in the city of Chornobyl.

Overall an absolutely dizzying number of robotic designs were invented on the spot, adapted from existing designs or repurposed for operation in a high-radiation zone. Eventually bulldozer designs like the STR-1 helped to push radioactive debris off the roofs into containers, massively reducing the radioactive contamination of the area.

The fact that following #4’s RUD the other three RBMK units were able to keep operating safely without risks to its operators, and with the zone now safe for tourists, is a real testament to the success of the worst hackathon imaginable. Many of the lessons learned are relevant today, including during the decommissioning of Fukushima Daiichi’s melted-down cores.

Continue reading “Chernobyl’s Robots, Or The Hackathon From Hell” →

Hackaday Podcast Episode 381: Airless Tires, Full-color Prints, And 28 MW Of LEDs

August 7, 2026 by Jenny List 5 Comments

This week’s Hackaday podcast is a European affair again, as Elliot Williams is joined by Jenny List on a summer evening to review the week. And we have a feast of hacks for your delectation.

As the title above says, one of the stand-out hacks this week was a set of airless mountain bike tyres 3D printed in glorious fluorescent TPU. They look as though they shouldn’t work but in fact they showed real promise, and we discuss the process behind their design. Then we take a look at a hybrid of a UV printer and an SLA 3D printer, capable of making high-resolution and robust 3D prints. The prospect of new Amigas intrigues us for a while, then carbon-fibre fabric in 3D prints.

Finally we’re in awe of the tech behind the Las Vegas Sphere, and we’re there for some radio at the Danish BornHack hacker camp. Follow that one up and you’ll find a bonus, an unofficial extra Hackaday podcast.

All the usual links are below, but before you head on down to have a listen, don’t forget we’ve got a mailbag for the podcast and we’d love to hear from you!

Download your own non-volatile MP3 here.