TechyMagThings

The topic of downstream and upstream is an important one in the Linux ecosystem, where from one base distribution you can go many layers of distros deep before even looking at all the other base distributions. Within that veritable jungle you get questions about who is responsible for packaging software, where to report bugs found with a specific application, as well as what ‘LTS’ truly means in a consumer context. These and other points are raised in a recent video by [Brodie Robertson], with many examples of things going tragically wrong.

There’s a good argument to be made that ultimately it is the distro that is responsible for the software that they provide via their repositories. As [Brodie] shows in the video, there are a few cases where an ‘LTS’ distro uses an old version of some software that contains a bug that has been fixed a while ago, so reporting it to the developer is rather pointless, while the distro maintainers should fix it with backporting of patches or updating the version.

From an end user experience this also makes the most sense, as in the end they just want to have the Windows experience of downloading a proverbial installer, clicking through whatever dialogs pop and have working software. If the software is provided via the distro, it is their responsibility, the same way that you contact the developer if you get a DEB or RPM from a GitHub project page and it doesn’t work.

This current Linux Chaos Vortex can be called a major issue when e.g. FreeBSD has no such upstream/downstream issues, with cross-platform installers being basically impossible on Linux ever since the Linux Standard Base effort died.

Perhaps Linux will get a distroless future, however, which may finally herald that Year of the Linux Desktop.

Although resistors are hardly among the most exciting components, they are arguably one of the most important ones, as anyone who has done any amount of circuit design and debugging can attest to. So too with a single carbon resistor in a vintage Metrix oscilloscope that [CuriousMarc] recently repaired. After recapping the board there was still a major issue that got traced down to said resistor. After replacing it with a fresh resistor obviously this meant doing an autopsy to see why the old resistor had failed.

The 20 kOhm-rated resistor looked fine on the outside, with no obvious damage or discoloration, but it measured around 0.843 MOhm. To get to the insides [CuriousMarc] asked his friend [TubeTime] on how to proceed. The answer here was sandpaper and a lot of patience, and thus the experiment to see how much sanding it takes to get to the core of a fairly big resistor commenced.

Ultimately the insides were revealed, and they turned out to be rather interesting, with what looked like a glass tube filled with what would be the carbon-laden material between the two lead terminals. From poking around a bit at these insides it would appear that the failure mode was a degraded contact between these terminals and the carbon material. Considering that this resistor is many decades old and has gone through many thermal cycles and potentially various kinetic events some fractures are probably to be expected.

Perhaps most fascinating is the construction of this carbon resistor that looks to be a step above that of the average carbon resistor that [TubeTime] has taken apart over the years.

One simple screening tool for cognitive impairment is the clock-drawing test (CDT): the patient is provided with a printed circle and asked to draw a clock face with the hands pointing to a certain time. Depending on how the clock is drawn, this could indicate a variety of different disorders, particularly dementia, with a particular deformity in the drawing sometimes pointing to a specific issue. These failed tests inspired [John Silvia] to create a clock with a unique, disordered face.

The numerals in this clock face are placed exclusively along the right half of the clock (in the test, this can be a sign of damage to the right parietal lobe, or of executive dysfunction caused by dementia), and out of order. The hour hand is controlled by a servo motor, and the minute hand is mounted on a separate, commercially-purchased clock mechanism on the left-hand side of the face.

The frame for the clock and the face are 3D-printed, and the servo motor is controlled by an ESP32-C3 with an RTC module. To minimize power draw, a MOSFET disconnects the servo motor from power except for the once-per-hour position update. Once per month, the ESP32 connects to Wi-Fi to synchronize to NTP time, otherwise remaining in a low-power state – even its indicator LEDs are disconnected to save power. These efforts paid off: when the servo isn’t active, it draws only about 160 µA, and a set of three AA NiMH cells lasts about a year.

Since the servo motor draws most of the power budget, it wouldn’t make much difference, but the ESP32’s co-processor can also be used for ultra-low-power projects. For a happier take on a drawing-related clock, check out one of these projects.

It seems fair to say that Dyson sits at the intersection of impressive engineering and borderline ridiculous products. The Dyson Airblade 9KJ hand dryer that [ElectrArc240] recently took to bits would definitely seem to fall under the latter, combining an incredible amount of engineering all for the simple task of drying wet hands.

These hand dryers are rated for a cool 900 Watts, with an 0.5 W standby power consumption, though you can also switch it to a 650 W ‘eco mode’ when installing it. The air that gets sucked into the dryer first passes through a HEPA filter before it hits the heating element and then gets blown out of the handles onto one’s hands.

Both of these handles come with a presence sensor in the form of an ST VL53L3CX time-of-flight sensor, along with a path for the heated air towards the thin slits. Returning to the section just past the HEPA filter is the compressor, with a rather fancy airflow path that involves various stacked meshes. As can be seen in the video, where you’d expect basically a simple blower motor or so, there is a truly astounding amount of parts as the teardown progresses.

The motor disassembly is the first part where some desoldering and breaking of glue bonds is really necessary, but it gives full access to the driver board. The circuit used here is your typical IGBT-based gate driver, though with a mystery PIC MCU to do things. Following this the tear-down turns fully destructive, giving access to the motor internals.

Following an analysis of these internals we marvel at the carbon-fiber rotor that keeps the single magnet in one piece. This is another engineering choice that serves to justify the 1,000 quid price tag. All so that rest room visitors do not have to suffer the humility of using paper towels.

In some parts of the world it’s common for cell service providers to sell new phones at a price significantly below market value, with the caveat that these phones are locked to that service provider alone. It’s questionable whether this practice is good for consumers, but as [Gabriel Broussard Korr] notes, it’s an opportunity for hackers: since it’s possible to run a Linux environment on these phones, they make an inexpensive source of quite powerful computing hardware.

In this case, [Gabriel] was using the Moto G Power 2024, which has 128 GB of storage, 12 GB of RAM, and costs less than $50 when carrier-locked. Rather than trying to install a mobile-oriented Linux distribution (such as postmarketOS), [Gabriel] installed Termux, a terminal emulator which provides a Linux environment within Android. Before doing this, he set up the phone and configured a number of settings for a better Linux experience. Since automatic updates can interfere with these settings, and since none of the provided settings effectively disable these, he used NetGuard to block Internet access from the updater app and from Google Play services.

The next step was to actually install Termux, as well as an X11 extension and an app which exposes an API for Termux. The desktop environment (XFCE in this case) was installed through Termux, and [Gabriel] wrote a shell script to go through the steps of starting it. XFCE worked well on mobile devices because of its full-desktop zoom capability. Even running Linux indirectly, the experience was smooth; [Gabriel] found that GIMP, Shotcut, and VS Code all performed well.

It’s not quite the same set of software, but we’ve previously featured a guide to setting up a similar Linux environment using Termux and AnLinux. Lindroid provides a similar containerized Linux environment; on the other hand, you can also use postmarketOS to make a server from an old phone.

We’ve covered etch-a-sketch robots before, but usually they’re not quite as fast as [Every Flavor of Robot]’s “video” etch-a-sketch, capable of drawing a full portrait in as little as a minute.

The idea comes from the motivation to make something cool for Open Sauce. Of course, most projects with a deadline come very close to missing it, and–like many an Open Sauce project–this one is no exception. Arriving in California, they realize they couldn’t access their code! Fortunately, they get a demo working where your portrait is drawn just in time.

After the event, [EFoR] sought to improve their robot. In doing so, they developer their own motor driver platform, complete with a custom PCB that can double as a Raspberry Pi hat. The software, being control theory, also needed some tweaking. Because the real world isn’t perfect, just a PID controller isn’t always enough and, in this case, they also needed to add code to account for backlash. Finally, as a finishing touch, they added a time-lapse camera so the “etchbot” could play videos by taking a picture after every frame.

The Honeywell X2S Smart Thermostat is a Wi-Fi-enabled thermostat that is meant to integrate with your typical ‘smart home’ setup, with mobile app control available as well. Of course, just using it as-is would be extremely boring, so fortunately we have [author0] to take it apart and reverse-engineer its encrypted firmware.

Of the two brains in this thermostat the first is a succinctly named Renesas R7FA6M4AF3CFP MCU containing a 200 MHz Cortex-M33 core with TrustZone features to theoretically keep out any firmware hackers. Handling the wireless side is a Realtek RTL8721DM Wi-Fi/BLE 5.0 SoC. There are also two Winbond Flash chips connected to these two main chips, with their contents of course encrypted.

Fortunately there are plenty of test points to connect to, for which a custom pogo-pin equipped breakout board was created. Cracking the encryption for the Realtek turned out to be as simple as using its RSIP decrypt-on-the-fly feature. From there exploring the firmware was the next step, with a TLS issue pertaining to certificates found to make man-in-the-middle attacks easy, along with a seeding bug that makes recovering session keys possible.

Although the Renesas MCU firmware still has to be decrypted and the full wireless handshake reverse-engineered, these do seem to be solid steps towards fully reverse-engineering this thermostat. It also makes it very clear once again that the ‘S’ in IoT absolutely stands for ‘security’. Maybe that’s why the smart home bubble popped.