In a recent post, I mentioned that I wanted to build some tools for a stripped-down Linux running on a 3D printer with a MIPS CPU. I had two options: build a toolchain to cross-compile, or use Zig, which, in theory, has built-in toolchains for MIPS. I had to jump through hoops to get Zig to work, and I did mention Crosstool-Ng, so you might wonder why I didn’t start there. Turns out, it had its own set of hoops to work through.
Continue reading “Compile Here, Run Everywhere: Crosstool-Ng”
Having Linux on so many devices is both a blessing and a curse. Sure, it is great that you can hack on things and modify them or even totally repurpose them. But it also means you have a fleet of Linux devices you have to manage and keep track of.
My current “main” 3D printer is a Flashforge AD5X: a nice, cheap machine that does four colors with the purge/exchange method. It sort of runs Klipper. I say sort of because Flashforge has Klipper running on a Linux host in the box, but it is massively crippled and modified. I’m sure it works for most folks. I’m also sure that if you know nothing about Linux, Klipper, or 3D printing, the experience is probably better thanks to all the cloud point-and-click interfaces. But, of course, I check none of those boxes.
I’ve had the printer for probably a year or more. Almost immediately, I put a “mod” on the printer to give it a more true Klipper interface and gave me things like shell access. There are several that I think will do this, but I used Zmod, which doesn’t totally replace the printer’s firmware; it just sort of patches it and extends it. You can easily bypass or even remove it and go back to the stock printer, although I would not want to.
In my case, the issue was a printer, but the same idea might apply to any embedded Linux system, from a router to a thermostat. Sure, it runs Linux, but is it Linux you can change?
The Flashforge firmware and Zmod both will run on the AD5X’s little sister, the AD5M. However, the AD5M has a significantly less capable processor board than the AD5X. That means that Linux on the boxes is very stripped down. From Flashforge’s point of view, no one should be in the Linux OS anyway, and the author of Zmod probably figures every byte used is a byte taken away from the user or other advanced Zmod features.
It may seem like a first-world problem, but there were two things that irked me about the printer’s Linux. There was no less or more command for poking around files. There was also only vi as an editor. I did a few hacks to make myself happy. I wrote a pager in shell script, for example. I would try to remember to use my desktop emacs and tramp to edit files on the box. But it was a shame that there were some very basic tools lacking. Besides that, even the tools that were there like ls lacked help commands in case you want some strange option you can’t remember.
To save space, the printer doesn’t really have programs like ls, cat, and grep. Instead, it has a single busybox executable. This is common on small systems. You get one copy of the libraries and a single executable that will do all the work you need. You can invoke, for example, grep by running “busybox grep” or, if you make a symlink to busybox named grep, the user may never realize that you don’t really have grep installed.
However, busybox has to be built. You can’t easily install packages to it. So I couldn’t just run some package manager and install less or anything else. My plan was to produce a new busybox package myself to supply at least the missing commands and maybe some of the more basic ones, too. How hard could it be?
Continue reading “Putting Some Zig In A Linux-Based 3D Printer”
I’ll admit it: I miss the simplicity of /etc/hosts. There was something elegant about it. You wanted laserprinter to mean 192.168.1.40, so you opened a text file and wrote:
192.168.1.40 laserprinter
Done. No cloud account, no discovery daemon, no dashboard with material-themed icons. Just a name and an address. The trouble, of course, is that /etc/hosts is only simple when you have one machine. The moment you have a desktop, a laptop, a Raspberry Pi, a NAS, a test box, and a phone or two, every little network change becomes a tiny distributed-database problem. Which copy of /etc/hosts is authoritative? Did you update the laptop? What about the machine you only boot once a month?
Modern LANs solved this with mDNS, using Avahi on Linux. It resolves addresses that end in .local. Instead of asking a central DNS server “who is thing.local?”, a machine sends a multicast query on the local network: “who has thing.local?” The device that owns the name answers. This is why your Linux box named spock and usually be reached as spock.local on your LAN.
There are limits. mDNS is link-local; it is meant for the local LAN, not the whole Internet and shouldn’t route across subnets. Each device is supposed to publish its own name. That works fine when the device cooperates. But what about devices that do not publish mDNS? Or little embedded things that barely even have an IP address?
That is where I wanted the best of both worlds: keep a small authoritative /etc/hosts file on one Linux box, but publish selected entries onto the LAN using mDNS.
Among the many forgotten might-have-beens of the games console world, the Atari Jaguar occupies a special place. It was the final gasp of Atari Corporation, the Jack Tramiel-era incarnation of the famous pioneering game console brand that brought us the ST line of computers, and like Marlon Brando’s Terry Malloy character from On the Waterfront, it coulda been a contender. But the early ’90s games business wasn’t kind to the console from Sunnyvale, and it was squeezed from behind by the SNES and Genesis/MegaDrive, and in front from the PlayStation. Thirty years later then, can it run Linux? [Cakehonolulu] is here to show us how.
With only 2 megabytes of RAM and space for 8 megabytes of ROM, this is hardly a powerhouse. But its 16-bit 68000 processor is a supported Linux architecture, albeit with the -nommu flag on compilation. The “Jerry” DSP chip has the required serial port and timer to boot a first Linux kernel, and after a bit of hackery to make it jump to the ROM location, something boots. There’s no init process until the flat executable file for a -nommu kernel is navigated, but with that past a BusyBox userspace and a graphics driver for the “Tom” graphics chip gives it a chunky on-screen console. The code can be found in a GitHub repository, for the curious.
It seems to be the moment for 68k consoles to receive the Linux treatment, as it’s only a few weeks since we saw it on a MegaDrive. Other ’90s consoles aren’t far behind though, with the Nintendo 64 falling to the penguin a few years ago. Meanwhile, the Dreamcast had Linux running decades ago.
Jaguar image: Evan-Amos, Public domain.
Once upon a time, there was a bit of a fad for fingerprint authentication in laptops and desktop computers. It has long since faded, but [superdog] wanted just such a device for Linux and Mac machines. Thus, it was time to build one.
[superdog] designed the device, nicknamed immurok, as a tool for people who use external keyboards, and do lots of terminal work on Mac and Linux machines. Repeat password requests can interrupt one’s flow when hustling at the keys, so immurok was designed to ease this pain.
The device is based on a WCH CH592F microcontroller, which comes with Bluetooth connectivity out of the box. This allows immurok to connect wirelessly to the machine of your choice, advertising itself as a standard Bluetooth HID keyboard device. Fingerprint-wise, scanning is done with an R559S capacitive sensor, which verifies the match locally so there’s no transmitting biometric data anywhere. On the computer side, Linux is setup to use a CLI/TUI app plus PAM integration to handle authorization for system logins and sudo in the terminal. On the Mac platform, it’s used with a menu bar app, with PAM integration for admin prompts. There’s also a separate helper path for using it with the lock screen.
If you’re sick of entering your password all the time and wish unlocking your PC was more like unlocking your phone, this might be the project for you. We’ve seen similar projects before, too. If you’re whipping up fun gear for biometric auth, don’t hesitate to let us know on the tipsline.
If you were in the market for a games console in 1990, the chances are that the object of your desire was either a Super Nintendo with its 16-bit 6502 derivative, or the Sega Megadrive, sold as the Genesis in North America, with its Motorola 68000. Both machines featured impressive graphics and sound for their time, but they remain firmly in the 16-bit era. Which makes it a surprise to see LinuxMD. It’s Linux, for the Sega Megadrive, with the latest mainline kernel.
The Motorola 68000 series of chips was the first porting target for Linux, and is still maintained in 2026. This build runs from an SD card in a modern Megadrive storage peripheral, and is reported to run on the original hardware. The lowly 68000 in the Sega doesn’t have a memory management unit required for the full Linux experience, so what’s really running here is a kernel compiled with the -nommu option. That in itself is a feat, on this architecture. On it you get smolutils, a cut down coreutils, and that seems to be it.
We like this project, for pushing both console and kernel to the limit, even though we see that maybe it’s not the most practical Linux machine. Meanwhile though, this isn’t the only UNIX-like OS for this console.
Image: Evan-Amos, Public domain.
The smart TV is a fixture in most houses, variously an entertainment portal, corporate data gathering tool, or sometimes an outright spy. It’s a nice monitor with a computer built in, so can that computer be released to do something else? It’s a question [Xen’on] is answering, on an Android-based TV.
The guide is not too different from many others relating to Android phones, with a few quirks. An Android Debug Bridge (ADB) connection is established, root access is gained using Shizuku, and then it’s a case of installing a more conventional Linux front end with the Openbox window manager through Termux. There are some TV-specific things to do with handling power cycles, but the TV is now a usable Linux box.
It’s always good to see someone retrieve the Linux underneath a locked-down device, but the system spec tells the real story. By the looks of things this TV is a few years old as it had an Android version that’s a bit long in the tooth, and thus it also packs an aged version 4.x kernel. Couple that with a more seat-of-your-pants experience compared to a regular distro where many of the annoyances are taken care of, this isn’t an easy route to a trouble free desktop. Instead it has a lot of potential for making the TV what it was intend to be, an entertainment device. Merely one that gives much more software freedom.
Meanwhile, this isn’t the first Termux guide we’ve seen.
