Upgrading PC Cooling With Software

As computing power increases with each new iteration of processors, actual power consumption tends to increase as well. All that waste heat has to go somewhere, and while plenty of us are content to add fans and heat sinks for a passable air-cooled system there are others who prefer a liquid cooling solution of some sort. [Cal] uses a liquid cooler on his system, but when he upgraded his AMD chip to one with double the number of cores he noticed the cooling fans on the radiator were ramping quickly and often. To solve this problem he turned to Python instead of building a new cooling system.

The reason for the rapid and frequent fan cycling was that the only trigger for the cooling fans available on his particular motherboard is CPU temperature. For an air cooled system this might be fine, but a water cooled system with much more thermal mass should be better able to absorb these quick changes in CPU temperature without constantly adjusting fan speed. Using a python script set up to run as a systemd service, the control loop monitors not only the CPU temperature but also the case temperature and the temperature of the coolant, and then preferentially tries to dump heat from the CPU into the thermal mass of the water cooler before much ramping of cooling fans happens.

An additional improvement here is that the fans can run at a much lower speed, reducing dust in the computer case and also reducing noise compared to before the optimizations. The computer now reportedly runs almost silently unless it has been under load for several minutes. The script is specific to this setup but easily could be modified for other computers using liquid cooling, and using Grafana to monitor the changes can easily be done as [Cal] also demonstrates when calibrating and testing the system. On the other hand, if you prefer a more flashy cooling system as a living room centerpiece, we have you covered there as well.

Raspinamp: It Really Replicates Questionable Activities Involving Llamas

In the late 90s as MP3s and various file sharing platforms became more common, most of us were looking for better players than the default media players that came with our operating systems, if they were included at all. To avoid tragedies like Windows Media Center, plenty of us switched to Winamp instead, a much more customizable piece of software that helped pave the way for the digital music revolution of that era. Although there are new, official versions of Winamp currently available, nothing really tops the nostalgia of the original few releases of the software which this project faithfully replicates in handheld form.

The handheld music player uses a standard Raspberry Pi (in this case, a 3B) and a 3.5″ TFT touchscreen display, all enclosed in a clear plastic case. With all of the Pi configuration out of the way, including getting the touchscreen working properly, the software can be set up. It uses QMMP as a media player with a Winamp skin since QMMP works well on Linux systems with limited resources. After getting it installed there’s still some configuration to do to get the Pi to start it at boot and also to fit the player perfectly into the confines of the screen without any of the desktop showing around the edges.

Although it doesn’t use the original Winamp software directly, as that would involve a number of compatibility layers and/or legacy hardware at this point, we still think it’s a faithful recreation of how the original looked and felt on our Windows 98 machines. With a battery and a sizable SD card, this could have been the portable MP3 player many of us never knew we wanted until the iPod came out in the early 00s, and would certainly still work today for those of us not chained to a streaming service. A Raspberry Pi is not the only platform that can replicate the Winamp experience, though. This player does a similar job with the PyPortal instead.

Continue reading “Raspinamp: It Really Replicates Questionable Activities Involving Llamas”

What Is X86-64-v3?

You may have heard Linux pundits discussing x86-64-v3. Can recompiling Linux code to use this bring benefits? To answer that question, you probably need to know what x86-64-v3 is, and [Gary Explains]… well… explains it in a recent video.

If you’d rather digest text, RedHat has a recent article about their experiments using the instructions set in RHEL10. From that article, you can see that most of the new instructions support some enhancements for vectors and bit manipulation. It also allows for more flexible instructions that leave their results in an explicit destination register instead of one of the operand registers.

Of course, none of this matters for high-level code unless the compiler supports it. However, gcc version 12 will automatically vectorize code when using the -O2 optimization flags.

Continue reading “What Is X86-64-v3?”

FLOSS Weekly Episode 771: Kalpa — Because Nobody Knows What Hysteresis Is

This week, Jonathan Bennett and Dan Lynch talk with Shawn W Dunn about openSUSE Kalpa, the atomic version of openSUSE Tumbleweed, with a KDE twist. What exactly do we mean by an Atomic desktop? Is ALP going to replace openSUSE Tumbleweed? Are snaps coming to Kalpa?

Shawn gives us the rundown of all the above, and what’s holding back a stable release of Kalpa, what’s up with Project Greybeard, and why Kalpa really doesn’t need a firewall.

Continue reading “FLOSS Weekly Episode 771: Kalpa — Because Nobody Knows What Hysteresis Is”

Steampipe: All SQL All The Time

Although modern Linux has slightly shifted, the old Unix mantra was: everything’s a file. With Steampipe, a better saying might be: everything’s a SQL table. The official tagline is “select * from cloud” which also works. The open-source program relies on plugins, and there are currently 140 sources ranging from GitHub to Google Sheets and more.

There are command line interfaces for the major platforms. You can also add the system to PostgresSQL or SQLite for even more SQL goodness. Continue reading “Steampipe: All SQL All The Time”

Linux Fu: Forward To The Past!

Ok, so the title isn’t as catchy as “Back to the Future,” but my guess is a lot of people who are advanced Linux users have — at least — a slight interest in retrocomputing. You’d like an Altair, but not for $10,000. You can build replicas of varying fidelities, of course. You can also just emulate the machine or a similar CP/M machine in software. There are many 8080 or Z80 emulators out there, ranging from SIMH to MAME. Most of these will run on Linux or — at the least — WINE. However, depending on your goals, you should consider RunCPM. Why? It runs on many platforms, including, of course, Linux and other desktop systems. But it also will work with the Arduino, Teensy, ESP32, or STM32 processors. There is also experimental support for SAM4S and Cyclone II FPGAs.

It’s pretty interesting to have one system that will work across PCs and embedded hardware. What’s more is that, at least on Linux, the file system is directly translated (sort of), so you don’t have to use tricks or special software to transfer files to and from CP/M. It is almost like giving Linux the ability to run CP/M software. You still have to have virtual disks, but they are nothing more than directories with normal files in them.

Goals

Of course, if your goal is to simulate a system and you want to have 180 kB floppies or whatever, then the direct file system isn’t a benefit. But if you want to use CP/M software for education, nostalgia, or cross-development, this is the way to go, in my opinion.

It isn’t just the file system, either. If you need a quick utility inside your bogus CP/M environment, you can write it in Lua, at least on desktop systems. On the Arduino, you can access digital and analog I/O. Theoretically, you could deploy an embedded Altair for some real purpose fairly cheaply. Continue reading “Linux Fu: Forward To The Past!”

This Week In Security: Broken Shims, LassPass, And Toothbrushes?

Linux has a shim problem. Which naturally leads to a reasonable question: What’s a shim, and why do we need it? The answer: Making Linux work wit Secure Boot, and an unintended quirk of the GPLv3.

Secure Boot is the verification scheme in modern machines that guarantees that only a trusted OS can boot. When Secure Boot was first introduced, many Linux fans suggested it was little more than an attempt to keep Linux distros off of consumer’s machines. That fear seems to have been unwarranted, as Microsoft has dutifully kept the Linux Shim signed, so we can all run Linux distros on our Secure Boot machines.

So the shim. It’s essentially a first-stage bootloader, that can boot a signed GRUB2 or other target. You might ask, why can’t we just ask Microsoft to sign GRUB2 directly? And that’s where the GPLv3 comes in. That license has an “anti-tivoization” section, which specifies “Installation Information” as part of what must be provided as part of GPLv3 compliance. And Microsoft’s legal team understands that requirement to apply to even this signing process. And it would totally defeat the point of Secure Boot to release the keys, so no GPLv3 code gets signed. Instead, we get the shim.

Now that we understand the shim, let’s cover how it’s broken. The most serious vulnerability is a buffer overflow in the HTTP file transfer code. The buffer is allocated based on the size in the HTTP header, but a malicious HTTP server can set that value incorrectly, and the shim code would happily write the real HTTP contents past the end of that buffer, leading to arbitrary code execution. You might ask, why in the world does the shim have HTTP code in it at all? The simple answer is to support UEFI HTTP Boot, a replacement for PXE boot.

The good news is that this vulnerability can only be triggered when using HTTP boot, and only by connecting to a malicious server or via a man-in-the-middle attack. With this in mind, it’s odd that this vulnerability is rated a 9.8. Specifically, it seems incorrect that this bug is rated low complexity, or a general network attack vector. In Red Hat’s own write-up of the vulnerability, they argue that the exploitation is high complexity, and is only possible from an adjacent network. There were a handful of lesser vulnerabilities found, and these were all fixed with shim 15.8. Continue reading “This Week In Security: Broken Shims, LassPass, And Toothbrushes?”