Block Devices in User Space

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?

hackaday.com/2026/01/20/block-…

RAM Prices Got You Down? Try DDR3. Seriously!

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.

youtube.com/embed/3_BNJCUqR-o?…

hackaday.com/2026/01/20/ram-pr…

Nixie Gear Indicator Shines Bright

When you’re driving a car with a stickshift, it’s pretty easy to keep track of which gear you’re in. That can be a little bit more difficult on something like a motorcycle with a sequential shifter. [decogabry] built a neat gearshift indicator to solve this issue.

An ESP32 devboard is used as the brain of the build. It’s paired with an ELM327 dongle over Bluetooth, which is able to hook into the bike’s ODB diagnostic port to pick up data like engine RPM, wheel speed, and coolant temperature. The first two factors are combined in order to calculate the current gear, since the ratio between engine RPM and wheel speed is determined directly by the gear selection. The ESP32 then commands a Philips ZM1020 Nixie tube to display the gear, driving it via a small nest of MPSA42 transistors. A separate self-contained power supply module is used to take the bike’s 12 volt supply up to the 170 volts needed to run the tube. There is also a small four-digit display used to show status information, RPM, and engine temperature.

Notably, [decogabry] made this build rather flexible, to suit any bike it might be installed upon. The gear ratios are not hard coded in software. Instead, there is a simple learning routine that runs the first time the system is powered up, which compares RPM and wheel speed during a steady-state ride and saves the ratios to flash.

We’ve featured projects before that used different techniques to achieve similar ends. It’s also interesting to speculate as to whether there’s a motorcycle vintage enough to suit a Nixie display while still having an ODB interface on board as standard. Meanwhile, if you’re cooking up your own neat automotive builds, don’t hesitate to drop us a line.

hackaday.com/2026/01/20/nixie-…

The Windows Interface You Didn’t Like, For Linux

If you were asked to pick the most annoying of the various Microsoft Windows interfaces that have appeared over the years, there’s a reasonable chance that Windows 8’s Metro start screen and interface design language would make it your choice. In 2012 the software company abandoned their tried-and-tested desktop whose roots extended back to Windows 95 in favor of the colorful blocks it had created for its line of music players and mobile phones.

Consumers weren’t impressed and it was quickly shelved in subsequent versions, but should you wish to revisit Metro you can now get the experience on Linux. [er-bharat] has created Win8DE, a shell for Wayland window managers that brings the Metro interface — or something very like it — to the open source operating system.

We have to admire his chutzpah in bringing the most Microsoft of things to Linux, and for doing so with such a universally despised interface. But once the jibes about Windows 8 have stopped, we can oddly see a point here. The trouble with Metro was that it wasn’t a bad interface for a computer at all, in fact it was a truly great one. Unfortunately the computers it was and is great for are handheld and touchscreen devices where its large and easy to click blocks are an asset. Microsoft’s mistake was to assume that also made it great for a desktop machine, where it was anything but.

We can see that this desktop environment for Linux could really come into its own where the original did, such as for tablets or other touch interfaces. Sadly we expect the Windows 8 connection to kill it before it has a chance to catch on. Perhaps someone will install it on a machine with the Linux version of .net installed, and make a better Windows 8 than Windows 8 itself.

hackaday.com/2026/01/20/the-wi…

What Isaac Roberts Saw Without a Space Telescope

Space telescopes are all the rage, and rightfully so. The images they take are spectacular, and they’ve greatly increased what we know about the universe. Surely, any picture taken of, say, the Andromeda galaxy before space telescopes would be little more than a smudge compared to modern photos, right? Maybe not.

One of the most famous pictures of our galactic neighbor was taken in — no kidding — 1888. The astronomer/photographer was Isaac Roberts, a Welsh engineer with a keen interest in astrophotography. Around 1878, he began using a 180 mm refracting telescope for observations, and in 1883, he began taking photographs.

He was so pleased with the results that he ordered a reflecting telescope with a 510 mm first-surface mirror and built an observatory around it in 1885. Photography and optics back then weren’t what they are now, so adding more mirrors to the setup made it more challenging to take pictures. Roberts instead mounted the photographic plates directly at the prime focus of the mirror.

Andromeda

This image, captured with the NASA/ESA Hubble Space Telescope, is the largest and sharpest image ever taken of the Andromeda galaxy — otherwise known as M31. This is a cropped version of the full image and has 1.5 billion pixels. You would need more than 600 HD television screens to display the whole image. It is the biggest Hubble image ever released and shows over 100 million stars and thousands of star clusters embedded in a section of the galaxy’s pancake-shaped disc stretching across over 40 000 light-years. This image is too large to be easily displayed at full resolution.
Because it took hours to capture good images, he developed techniques to keep the camera moving in sync with the telescope to track objects in the night sky. On December 29th, 1888 he used his 510 mm scope to take a long exposure of Andromeda (or M31, if you prefer). His photos showed the galaxy had a spiral structure, which was news in 1888.

Of course, it’s not as good as the Hubble’s shots. In all fairness, though, the Hubble’s is hard to appreciate without the interactive zoom tool. And 100 years of technological progress separate the two.

Roberts also invented a machine that could engrave stellar positions on copper plates. The Science Museum in London has the telescope in its collection.

Your Turn

Roberts did a great job with very modest equipment. These days, at least half of astrophotography is in post-processing, which you can learn. Want time on a big telescope? Consider taking an online class. You might not match the James Webb or the Hubble, but neither did Roberts, yet we still look at his plates with admiration.

hackaday.com/2026/01/20/what-i…

Demonstrating The Sheer Lack Of Security In First Gen Cellular Networks

Modern cellular networks are built to serve millions upon millions of users, all while maintaining strict encryption across all communications. But earlier cellular networks were by no means so secure, as [Nostalgia for Simplicity] demonstrates in a recent video.

The video begins with an anecdote — our narrator remembers a family member who could listen in on other’s conversations on the analog AMPS phone network. This was easily achieved simply by entering a code that would put an Ericsson handset into a test mode, in which it could be switched to tune in any desired AMPS channel. Since the communications were transmitted in a purely analog manner, with no encryption of any sort, any conversation on such a network was basically entirely open for anyone to hear. The video shows a recreation of this method, using a software-defined radio to spin up a low-power, very local AMPS network. A phone call is carried out between two handsets, with a third handset able to listen in just by using the special test mode.

If you’re particularly keen to build your own first-generation AMPS phone network, just know that it’s not really allowed due to rules around spectrum allocations. Still, it’s entirely possible as we’ve covered before. It doesn’t even take much hardware in our modern SDR era.

youtube.com/embed/CaR4_l1BzVQ?…

hackaday.com/2026/01/20/demons…