2025-07-03 07:00:21
How many times do you have to forget your keys before you start hacking on the problem? For [Binh], the answer was 5 in the last month, and his hack was to make a gesture-based door unlocker. Which leads to the amusing image of [Binh] in a hallway throwing gang signs until he is let in.
The system itself is fairly simple in its execution: the existing deadbolt is actuated by a NEMA 17 stepper turning a 3D printed bevel gear. It runs 50 steps to lock or unlock, apparently, then the motor turns off, so it’s power-efficient and won’t burn down [Binh]’s room.
The software is equally simple; mediapipe is an ML library that can already do finger detection and be accessed via Python. Apparently gesture recognition is fairly unreliable, so [Binh] just has it counting the number of fingers flashed right now. In this case, it’s running on a Rasberry Pi 5 with a webcam for image input. The Pi connects via USB serial to an ESP32 that is connected to the stepper driver. [Binh] had another project ready to be taken apart that had the ESP32/stepper combo ready to go so this was the quickest option. As was mounting everything with double-sided tape, but that also plays into a design constraint: it’s not [Binh]’s door.
[Binh] is staying in a Hacker Hotel, and as you might imagine, there’s been more penetration testing on this than you might get elsewhere. It turns out it’s relatively straightforward to brute force (as you might expect, given it is only counting fingers), so [Binh] is planning on implementing some kind of 2FA. Perhaps a secret knock? Of course he could use his phone, but what’s the fun in that?
Whatever the second factor is, hopefully it’s something that cannot be forgotten in the room. If this project tickles your fancy, it’s open source on GitHub, and you can check it out in action and the build process in the video embedded below.
After offering thanks to [Binh] for the tip, the remaining words of this article will be spent requesting that you, the brilliant and learned hackaday audience, provide us with additional tips.
2025-07-03 04:00:00
When it comes to text, how small is too small? The experts say a six point font is the minimum for readability, but as [James Bowman] shows us, you can get away with half of that.
The goal is to produce a 40-character display on a 24 mm x 24 mm LCD that has a resolution of 240 x 240 to show a serial terminal (or other data) on the “TermDriver2” USB-to-Serial adapter. With 24 lines, that’s a line per millimeter: very small text. Three points, to be precise, half what the experts say you need. Diving this up into 40 columns gives a character cell of six by nine pixels. Is it enough?
Not by itself, no. That’s where the hack comes in: sub-pixel rendering. After all, a “white” pixel on an LCD is actually three elements: a red, a green, and a blue subpixel, stacked side-by-each. Drive each of those subpixels independently and 240 pixels now becomes 720. That’s plenty for a 40 column terminal.
The article discusses how, in general terms, they pulled off the subpixel rendering and kept the font as legible as possible. We think it’s a good try, though the colored fringe around the characters can be uncomfortable to look at for some people — and then we can’t forget the physical size of the characters being 1 mm tall.
If this trick were being used on a larger display with a 240-wide resolution, we’d say “yes, very legible, good job!”– but at this size? We hope we can find our reading glasses. Still, it’s a neat trick to have in your back pocket for driving low-resolution LCDs.
It may not surprise you that aside from improving legibility, subpixel rendering is also used for pixel (er, sub-pixel) art.
2025-07-03 02:30:47
This week Jonathan chats with benny Vasquez about AlmaLinux! Why is AlmaLinux the choice for slightly older hardware? What is the deal with RISC-V? And how does EPEL fit in? Tune in to find out!
Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or contact the guest and have them contact us! Take a look at the schedule here.
Direct Download in DRM-free MP3.
If you’d rather read along, here’s the transcript for this week’s episode.
Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 4.0 License
2025-07-03 01:00:46
When a fire breaks out in a high-rise building, conventional wisdom is that stairwells are the only way out. Lifts are verboten in such scenarios, while sheer height typically prevents any other viable route of egress from tall modern buildings. If the stairs are impassable, or you can’t reach them, you’re in dire peril.
In South Korea, though, there’s another option for escape. The answer involves strapping on a harness and descending down ropes hanging off the side of the building, just like in an action movie. It might sound terrifying, but these descending lifeline devices have become a common part of fire safety infrastructure across the country.
The concept is elegantly simple—tall buildings like apartments and hotels feature compact rope escape devices that can be quickly deployed from windows or balconies. These allow people to control their descent down the exterior of a building in the event that there is no other route of escape. While fleeing a building down a rope is typically the preserve of fictional spies or trained climbers, these carefully engineered systems are designed for use by ordinary people in emergency situations.
The typical Korean descending lifeline comes as a kit with some simple components. It consists of a rope or cable, a friction-based descent control mechanism, and a harness system that can be donned quickly by sliding under the arms and tightening a strap. Deploying the device is relatively simple. The rope reel is attached to a large deployable hook that is firmly mounted to the building’s wall, using a screw-threaded coupling. The rope is then thrown out the window. At this point, the user merely needs to attach the harness and tighten it prior to leaving the building.
When exiting the window, the user is instructed to face the wall on the way down, using their hands and/or feet to control the descent. Ultimately, though, the mechanical speed regulator ensures a safe pace of descent. The devices only allow the descent of one person at at time. However, each end of the rope has a harness. Thus, when one user has descended to ground level, the next person can grab the harness at the other end which has ascended to the window, and begin their descent. This can continue for as many people as needed.
Key to these devices is their focus on simplicity. The descent control mechanism uses a geared braking system that automatically limit the speed of descent to 1.5 meters/sec or less, preventing the user from descending too quickly even if they panic and release their grip. The lifelines are also sold in a range of different lengths to suit the heights of individual floors in a building. This is important to ensure that as the user hits the ground, the other end of the rope has carried the other harness back up to the floor for the next user. The longest variants typically sold are 45 meters in length, intended for buildings up to 15 stories tall. Limits of practicality mean that while these lifelines are useful for many buildings, they’re perhaps not applicable to taller skyscrapers where such escape would be more difficult.
The engineering challenge here isn’t just mechanical. Automatic rope descent systems are a well understood technology, as are hooks and brackets rated to carry human weight for climbing or otherwise. The real challenge comes down to human factors—in that these systems need to be something people can figure out how to use under conditions of extreme stress. The devices need to be intuitive enough that someone who has never used one before can figure it out while a fire rages behind them. It’s one thing to learn how to use a rope descent system by watching a video and trying the equipment at a calm training session. It’s another thing entirely to do so while a fire rages in the hotel hallway behind you.
While these lifeline systems are relatively simple, they’re still a lot more complicated to use than something like an airliner life jacket. Requiring an inexperienced end user to thread a fitting on a rope coupler without dropping it out the window in a panic situation is a tall ask. Still, the lifelines provide a useful additional escape option. It may not be the easiest way out of the building, or anybody’s first choice, but when there’s no other option, it’s good to have.
South Korea’s adoption of these systems reflects both the country’s high-rise-heavy urban landscape and a pragmatic approach to disaster preparedness. Many apartment buildings and hotels are now required to have these devices installed. The devices are typically mounted in weatherproof boxes near windows or on balconies, ready for deployment when traditional escape routes are compromised. In some cases, the rugged boxes the lifelines come in can even be used as a step-up to ease egress out of higher windows.
Perhaps most importantly, these systems represent a shift in traditional thinking about fire safety. In most jurisdictions, the idea of asking average people to belay down a building is considered untenable—too dangerous and too complicated. In South Korea, the lifelines are on hand, and put control back in the hands of building occupants. When every second counts and traditional escape routes have failed, having a lifeline system could mean the difference between life and death. It’s a sobering reminder that sometimes the best high-tech solution is one that lets people save themselves.
2025-07-02 23:30:54
[Bogdan Micea] uses a laptop cooler, but was a bit annoyed that his cooler would run at the same power no matter how hard the laptop was working. Rather than keep adjusting the cooler’s power manually, he automated it by installing an Arduino Pro Micro as a controller in the cooler and writing a Rust controller application for his computer.
[Bogdan]’s cooler is controlled by four buttons, which can have different functions depending on how long they’re pressed. After mapping out their functionality and minor quirks, [Bogdan] soldered four transistors in parallel with the buttons to let the Arduino simulate button presses; another four Arduino pins accept input from the buttons to monitor their state. The Arduino USB port connects to the cooler’s original USB power input, so the cooler looks superficially unchanged. When the cooler starts up, the Arduino sets it to a known state, then monitors the buttons. Since it can both monitor and control the buttons, it can notify the computer when the cooler’s state changes, or change the state when the computer sends a command.
On the computer’s part, the control software creates a system tray that displays and allows the user to change the cooler’s current activity. The control program can detect the CPU’s temperature and adjust the cooler’s power automatically, and the Arduino can detect the laptop’s suspend state and control power accordingly.
Somewhat surprisingly, this seems to be the first laptop cooler we’ve seen modified. We have seen a laptop cooler used to overclock a Teensy, though, and a laptop’s stock fans modified.
2025-07-02 22:00:50
Some time ago, Linus Torvalds made a throwaway comment that sent ripples through the Linux world. Was it perhaps time to abandon support for the now-ancient Intel 486? Developers had already abandoned the 386 in 2012, and Torvalds openly mused if the time was right to make further cuts for the benefit of modernity.
It would take three long years, but that eventuality finally came to pass. As of version 6.15, the Linux kernel will no longer support chips running the 80486 architecture, along with a gaggle of early “586” chips as well. It’s all down to some housekeeping and precise technical changes that will make the new code inoperable with the machines of the past.
The big change is coming about thanks to a patch submitted by Ingo Molnar, a long time developer on the Linux kernel. The patch slashes support for older pre-Pentium CPUs, including the Intel 486 and a wide swathe of third-party chips that fell in between the 486 and Pentium generations when it came to low-level feature support.
Going forward, Molnar’s patch reconfigures the kernel to require CPUs have hardware support for the Time Stamp Counter (RDTSC) and CMPXCHG8B instructions. These became part of x86 when Intel introduced the very first Pentium processors to the market in the early 1990s. The Time Stamp Counter is relatively easy to understand—a simple 64-bit register that stores the number of cycles executed by the CPU since last reset. As for CMPXCHG8B, it’s used for comparing and exchanging eight bytes of data at a time. Earlier Intel CPUs got by with only the single-byte CMPXCHG instruction. The Linux kernel used to feature a piece of code to emulate CMPXCHG8B in order to ease interoperability with older chips that lacked the feature in hardware.
The changes remove around 15,000 lines of code. Deletions include code to emulate the CMPXCHG8B instruction for older processors that lacked the instruction, various emulated math routines, along with configuration code that configured the kernel properly for older lower-feature CPUs.
Basically, if you try to run Linux kernel 6.15 on a 486 going forward, it’s just not going to work. The kernel will make calls to instructions that the chip has never heard of, and everything will fall over. The same will be true for machines running various non-Pentium “586” chips, like the AMD 5×86 and Cyrix 5×86, as well as the AMD Elan. It’s likely even some later chips, like the Cyrix 6×86, might not work, given their questionable or non-existent support of the CMPXCHG8B instruction.
Molnar’s reasoning for the move was straightforward, as explained in the patch notes:
In the x86 architecture we have various complicated hardware emulation facilities on x86-32 to support ancient 32-bit CPUs that very very few people are using with modern kernels. This compatibility glue is sometimes even causing problems that people spend time to resolve, which time could be spent on other things.
Indeed, it follows on from earlier comments by Torvalds, who had noted how development was being held back by support for the ancient members of Intel’s x86 architecture. In particular, the Linux creator questioned whether modern kernels were even widely compatible with older 486 CPUs, given that various low-level features of the kernel had already begun to implement the use of instructions like RDTSC that weren’t present on pre-Pentium processors. “Our non-Pentium support is ACTIVELY BUGGY AND BROKEN right now,” Torvalds exclaimed in 2022. “This is not some theoretical issue, but very much a ‘look, ma, this has never been tested, and cannot actually work’ issue, that nobody has ever noticed because nobody really cares.”
Basically, the user base for modern kernels on old 486 and early “586” hardware was so small that Torvalds no longer believed anyone was even checking whether up-to-date Linux even worked on those platforms anymore. Thus, any further development effort to quash bugs and keep these platforms supported was unjustified.
It’s worth acknowledging that Intel made its last shipments of i486 chips on September 28, 2007. That’s perhaps more recent than you might think for a chip that was launched in 1989. However, these chips weren’t for mainstream use. Beyond the early 1990s, the 486 was dead for desktop users, with an IBM spokesperson calling the 486 an “ancient chip” and a “dinosaur” in 1996. Intel’s production continued on beyond that point almost solely for the benefit of military, medical, industrial and other embedded users.
If there was a large and vocal community calling for ongoing support for these older processors, the kernel development team might have seen things differently. However, in the month or so that the kernel patch has been public, no such furore has erupted. Indeed, there’s nothing stopping these older machines still running Linux—they just won’t be able to run the most up-to-date kernels. That’s not such a big deal.
While there are usually security implications around running outdated operating systems, the simple fact is that few to no important 486 systems should really be connected to the Internet anyway. They lack the performance to even load things like modern websites, and have little spare overhead to run antiviral software or firewalls on top of whatever software is required for their main duties. Operators of such machines won’t be missing much by being stuck on earlier revisions of the kernel.
Ultimately, it’s good to see Linux developers continuing to prune the chaff and improve the kernel for the future. It’s perhaps sad to say goodbye to the 486 and the gaggle of weird almost-Pentiums from other manufacturers, but if we’re honest, few to none were running the most recent Linux kernel anyway. Onwards and upwards!
