DDR3 seemed plenty fast when it first showed up 19 years ago. Who could say no to 6400 Mb/s transfer speeds? Of course compared to the modern DDR5 that’s glacially slow, but given that RAM is worth its weight in gold these days– with even DDR4 spiking in price– some people, like [Gheeotine], are asking “can you game on DDR3“? The answer is a shocking yes.

[Gheeotine] builds two budget-friendly PCs for this video, using some of the newest DD3-supporting motherboards available. That’s not exactly new: we’re talking 12 to 15 years old, but hey, not old enough to drive. We certainly didn’t expect to hear about an x79 motherboard hosting an Ivy Bridge processor in 2026, but needs must when the devil dances. The only concession to modernity is the graphics cards: the x79 mobo got an RX6600XT 8GB, and the other build, using a z97 motherboard got an NVIDIA RTX 4060. The z97 motherboard allowed a slightly newer processor, as well, an i7 4790, with the new and exciting Haswell architecture you may have heard of. Both boards are maxed out on RAM, because at less than one USD/GB, why not?

[Gheeotine] puts a few new titles through their paces on these boxen, and while the results aren’t amazing, everything he tries comes out playable, which is amazing in and of itself. Well, playable unless you’re one of those people who can’t stand playing at resolutions under 4K or FPS under 100. Those of who spent their formative years with 29.7 FPS or 25 FPS in NTSC or PAL regions aren’t going to complain too loudly if frame rates dip down into the 30s playing at 1080p for some of the more demanding titles. Ironically, one of those was the five-year-old Crysis Remastered. Given the age of some of this hardware “Can it Run Crysis” is a perfectly reasonable question, and the answer is still yes.

If you want modern games, you’re much better off with a z97 chipset motherboard if you chose to go the DDR3 route, since you won’t run into issues related to the AVX2 instruction, which first appeared with the Haswell microarchitecture. Here at Hackaday our preferred solution to the rampocalypse is software optimization, Since holding your breath for that would probably be fatal, cost-optimizing PC builds is probably a good plan, even if some might balk at going all the way back to DDR3.

Of course if you’re going to use nearly-retro hardware like DDR3, you might as well go all-out on retro vibes with a nostalgic 80s-style, or even 50s-style case. 

Your new project really could use a block device for Linux. File systems are easy to do with FUSE, but that’s sometimes too high-level. But a block driver can be tough to write and debug, especially since bugs in the kernel’s space can be catastrophic. [Jiri Pospisil] suggests Ublk, a framework for writing block devices in user space. This works using the io_uring facility in recent kernels.

This opens the block device field up. You can use any language you want (we’ve seen FUSE used with some very strange languages). You can use libraries that would not work in the kernel. Debugging is simple, and crashing is a minor inconvenience.

Another advantage? Your driver won’t depend on the kernel code. There is a kernel driver, of course, named ublk_drv, but that’s not your code. That’s what your code talks to.

The driver maintains the block devices and relays I/O and ioctl requests to your code for servicing. There are several possible use cases for this. For example, you could dream up some exotic RAID scheme and expose it as a block device that multiplexes many devices. The example in the post, for example, exposes a block device that is made up of many discrete files on a different file system.

Do you need this? Probably not. But if you do, it is a great way to push out a block driver in a hurry. Is it high-performance? Probably not, just like FUSE isn’t as performant as a “real” file system. But for many cases, that’s not a problem.

If you want to try FUSE, why not make your favorite website part of your file system?

The meaning of Inception’s ending famously revolves around a top which spins forever in dreams, but in real life comes to a stop like any other top. Any other top, that is, except for [Aaed Musa]’s self-spinning top, which can continuously spin for about two hours before coming to a stop.

The one constraint was that every functional component had to be contained within the top’s shell, and [Aaed]’s first approach was to build a reaction wheel into the top. When a motor accelerates a weighted wheel, conservation of angular momentum applies an equal and opposite torque to the motor. The problem is that motors eventually reach a top speed and stop accelerating, which puts an end to the torque. This is known as saturation, and the only way to desaturate a reaction wheel is to slow it down, which counteracts the originally generated torque. [Aaed] originally planned to mount the motor in a one-way bearing, which would let it bleed off speed without producing torque against the rest of the top, but it was rather choppy in practice.

The solution occurred to [Aaed] while watching the aforementioned final scene, when it occurred to him that the wobbling of a top could actually generate rotation. A prototype proved that an off-center weight rotating at a constant speed did successfully spin the top by rotating the center of mass, and after that, it was a matter of incremental testing and improvement. A higher moment of inertia worked better, as did a lower center of gravity and a tip made from a hard, low-friction silicon nitride ball bearing. He made housings out of both 3D-printed plastic and CNC-milled aluminium, which each contained a tiny brushless motor, an electric speed controller, a microcontroller, and a small rechargeable lithium battery.

If you allow for external power, you can make the top itself the rotor of a motor, and drive it from a base. Alternatively, if you levitate your top in a vacuum, it could spin for longer than recorded history.