Linux Fu: Stopping A Runaway

The best kind of Hackaday posts are the ones where there was some insurmountable problem with an elegant solution devised through deep analysis of the problem and creativity. This is not one of those posts. I’m sure you are familiar with bit rot. You know, something works for a long time and then, for no apparent reason, stops working. Well, that has been biting me, and lacking the time for the creative, elegant solution, I decided to attack it with a virtual chainsaw.

It all started with a 2022 Linux Fu about using autokey.

The Problem

I use autokey to give me emacs-style keystrokes in Web browsers and certain other programs. It intercepts keystrokes and translates them into other keystrokes. The problem is, the current Linux community hates autokey. Well, that’s not strictly true. They just love Wayland more. One reason I won’t switch from X11 is that I haven’t found a way to do something like I do with autokey. But since most of the powers-that-be have decided that X11 is bad and Wayland is good, X11 development is starting to show cracks.

In particular, autokey isn’t in the normal repositories for my distro anymore (KDE Neon). Of course, I’ve installed the latest version myself. I’m perfectly capable of doing that or even building from source. But lately, I’ve noticed my computer hangs, especially after sleeping for a long time. Also, after a long time, I notice that autokey just quits working. It is running but not working and I have to restart it. The memory consumption seems high when this happens. Continue reading “Linux Fu: Stopping A Runaway”

Jenny’s (Not Quite) Daily Drivers: Raspberry Pi 1

An occasional series of mine on these pages has been Daily Drivers, in which I try out operating systems from the point of view of using them for my everyday Hackaday work. It has mostly featured esoteric or lesser-used systems, some of which have been unexpected gems and others have been not quite ready for the big time.

Today I’m testing another system, but it’s not quite the same as the previous ones. Instead I’m looking at a piece of hardware, and I’m looking at it for use in my computing projects rather than as my desktop OS. You’ll all be familiar with it: the original Raspberry Pi appeared at the end of February 2012, though it would be May of that year before all but a lucky few received one. Since then it has become a global phenomenon and spawned a host of ever-faster successors, but what of that original board from 2012 here in 2025? If you have a working piece of hardware it makes sense to use it, so how does the original stack up? I have a project that needs a Linux machine, so I’m dusting off a Model B and going down memory lane.

Continue reading “Jenny’s (Not Quite) Daily Drivers: Raspberry Pi 1”

Self-Hosting A Cluster On Old Phones

The phones most of us carry around in our pockets every day hold a surprising amount of computing power. It’s somewhat taken for granted now that we can get broadband in our hands in most places; so much so that when one of these devices has reached the end of its life it’s often just tossed in a junk drawer even though its capabilities would have been miraculous only 20 years ago. But those old phones can still be put to good use though, and [Denys] puts a few of them back to work running a computing cluster.

Perhaps the most significant flaw of smartphones, though, is that most of them are locked down so much by their manufacturers that it’s impossible to load new operating systems on them. For this project you’ll need to be lucky enough (or informed enough) to have a phone with an unlockable bootloader so that a smartphone-oriented Linux distribution called postmarketOS can be installed. With this nearly full-fledged Linux distribution to work from, the phones can be accessed by ssh and then used to run Kubernetes for the computing cluster. [Denys] has three phones in his cluster that run a few self-hosted services for him.

[Denys] also points out in his guide that having a phone that can run postmarketOS might save some money when compared to buying a Raspberry Pi to run the same service, and the phones themselves can often be more powerful as well. This is actually something that a few others have noted in the past as well. He’s gone into a considerable amount of detail on how to set this up, so if you have a few old smartphones gathering dust, or even those with broken screens or other physical problems where the underlying computing resources are still usable, it’s a great way to put these machines back to work.

Thanks to [mastro Gippo] for the tip!

8 Pins For Linux

We’ve seen a Linux-based operating system made to run on some widely varying pieces of hardware over the years, but [Dmitry Grinberg]’s latest project may be one of the most unusual. It’s a PCB with 3 integrated circuits on it which doesn’t seem too interesting at first, but what makes it special is that all three of those chips are in 8-pin SOIC packages. How on earth can Linux run on 8-pin devices? The answer lies as you might expect, in emulation.

Two of the chips are easy to spot, a USB-to-serial chip and an SPI RAM chip. The processor is an STM32G0 series device, which packs a pretty fast ARM Cortex M0+ core. This runs a MIPS emulator that we’ve seen on a previous project, which is ripe for overclocking. At a 148 MHz clock it’s equivalent to a MIPS running at about 1.4 MHz, which is just about usable. Given that the OS in question is a full-featured Debian, it’s not running some special take on Linux for speed, either.

We like some of the hardware hacks needed to get serial, memory, and SD card, onto so few pins. The SD and serial share the same pins, with a filter in place to remove the high-frequency SPI traffic from the low-frequency serial traffic. We’re not entirely sure what use this machine could be put to, but it remains an impressive piece of work.

Linux Fu: A Warp Speed Prompt

If you spend a lot of time at the command line, you probably have either a very basic prompt or a complex, information-dense prompt. If you are in the former camp, or you just want to improve your shell prompt, have a look at Starship. It works on the most common shells on most operating systems, so you can use it everywhere you go, within reason. It has the advantage of being fast and you can also customize it all that you want.

What Does It Look Like?

It is hard to explain exactly what the Starship prompt looks like. First, you can customize it almost infinitely, so there’s that. Second, it adapts depending on where you are. So, for example, in a git-controlled directory, you get info about the git status unless you’ve turned that off. If you are in an ssh session, you’ll see different info than if you are logged in locally.

However, here’s a little animation from their site that will give you an idea of what you might expect: Continue reading “Linux Fu: A Warp Speed Prompt”

Linux Fu: Use The Source (Command), Luke

You can argue if bash is a good programming language or not, but you can’t argue that it is a programming language. However, there are a few oddities about it that make it different from most other languages you probably know. For one thing, variables are dynamically scoped. Second, you can easily change variables in an upper scope. This leads to a problem when you want to do something like reset your path:

#!/bin/bash
#: This does NOT work
PATH=/usr/bin:/bin

Well, actually, it does work; it just doesn’t work the way you imagine it might. The key is to realize that when you execute our script (say, resetpath), a new copy of bash runs. It inherits all the variables from your shell. Now the script sets PATH for the new copy of bash. Anything else you run in that script will see your change. But when the script exits, the new copy of bash is gone and the old copy sees the same old PATH it always did.

Continue reading “Linux Fu: Use The Source (Command), Luke”

Bits of GRUB syntax on pink background

Wake, Boot, Repeat: Remote OS Selection With GRUB And ESP

What do you do when you need to choose an OS at boot but aren’t physically near your machine? [Dakhnod]’s inventive solution is a mix of GRUB, Wake-on-LAN (WOL), and a lightweight ESP8266 running a simple HTTP server. In the past, [dakhnod] already enlightened us with another smart ESP hack. This one’s a clever combination of network booting and remote control that opens up possibilities beyond the usual dual-boot selector.

At its core, the hack modifies GRUB to fetch its boot configuration over HTTP. The ESP8266 (or any low-power device) serves up a config file defining which OS should launch. The trick lies in adding a custom script that tells GRUB to source an external config:

#!/usr/bin/env cat 
net_dhcp 
source (http,destination_ip_or_host:destination_port)/grub/config

Since GRUB itself makes the HTTP request, the system needs a running web server. That could be a Raspberry Pi, another machine, or the ESP itself. From there, a WOL-enabled ESP button can wake the PC and set the boot parameters remotely.

Is it secure? Well, that depends on your network. An open, unauthenticated web server dishing out GRUB configs is risky, but within a controlled LAN or a VLAN-segmented environment, it’s an intriguing option. Automation possibilities are everywhere — imagine remotely booting test rigs, toggling between OS environments for debugging, or even setting up kiosk machines that reconfigure themselves based on external triggers.

For those looking to take it further, using configfile instead of source allows for more dynamic menu entries, although it won’t persist environment variables. You could even combine it with this RasPi hack to control the uptime of the HTTP server. The balance between convenience and security is yours to strike.

If you’ve got your own wild GRUB customisation, let’s hear it!