Less popular Linux distributions can still be surprisingly practical.

Getting started

Last month, I tried using piCore on a Raspberry Pi. At first, the goal was to deal with a printer-related problem, but since there was no printer driver available, that idea ended up going nowhere. In the end, using a regular computer was simply easier for that task.

What made piCore interesting to me was a different situation. There was also a Raspberry Pi at school, but it didn’t have an SD card. That turned out to be exactly the kind of case where piCore shines. I inserted one of my own SD cards, booted the machine with piCore, and then removed the card after startup. Because the system runs in RAM, the Pi could keep working normally even after the SD card was gone.

After that, I set up a tunneling service on it, which meant I could access and play around with the school’s Raspberry Pi from home.

What it was like to use

Installing software after removing the SD card

piCore runs from memory, but by default its installed software still lives on the SD card. So the first problem appeared as soon as I pulled the card out: the software stopped being usable. Programs that had already been installed would not start, and installing anything new also failed.

That quickly becomes annoying. Even the tools for connecting to Wi-Fi were stored on the SD card. Some daemons continue working because they are already loaded into memory once started, so they don’t immediately break when the card is removed. But if I wanted to connect to a different Wi-Fi network, I no longer had the tools to do it. That obviously wasn’t workable.

So I looked into how piCore handles software installation. The package management tools are written in Shell, and since I’ve been using Shell since I was young, reading through them wasn’t especially difficult. Eventually I found the important detail: installed software is not actually read from the SD card’s mounted directory directly. Instead, it uses /etc/sysconfig/tcedir, and that path is just a symbolic link pointing to the SD card mount.

That made the workaround fairly straightforward. I deleted the original symlink and created a real tcedir directory in its place. That alone was not enough, though. Inside it, I also had to create an optional directory so that downloaded packages would go to the correct location.

At that point, installing brand-new software worked, but there was still another issue: reinstalling software that had been installed before would fail. In piCore, once a package has been installed, a file is created under /usr/local/tce.installed. The package manager checks that directory to decide whether a program is already installed. Removing the SD card does not make those files disappear, so I had to manually delete the relevant files there as well. After doing that, reinstalling previously installed software stopped causing problems.

There was also a permissions-related detail worth noting. For whatever reason, the package manager expects software installation not to be done under root privileges. That means when creating the /etc/sysconfig/tcedir/optional path, you need to be careful not to create it as root, otherwise package installation may fail.

piCore—or TinyCore more broadly—isn’t a mainstream distribution, but the available software is still decent. It’s obviously not like Ubuntu with apt and a huge package ecosystem, yet for ordinary use there is still enough to get by. A graphical desktop can also be installed, but I was using a Raspberry Pi 3B with only 1 GB of RAM, so I didn’t really want to push it. Besides, I already had Windows Remote Desktop available, so there was no strong reason to force a GUI onto the Pi.

Running software outside the package repository

For a Linux distribution, software availability and ecosystem matter a lot, but package installation is not the only way to use software. In the end, software is still just binaries. That means if something is missing from the piCore repository, there are cases where you can simply run a compiled binary directly.

A good example is Cloudreve, a cloud storage system written in Go. It runs on piCore very easily. You just find the arm64 build from the releases page, download it to the Raspberry Pi, extract it, and run it directly. For precompiled software like that, the process is extremely simple.

I did the same kind of thing for tunneling. I used SakuraFrp, which is also distributed as a standalone compiled program. Again, I only needed to download the arm64 version and run it.

Another example would be software used for bandwidth-sharing or CDN-style earning programs, like 甜糖. As long as there is a matching compiled build, the same idea applies: just download and run it. That said, even if the program itself runs, that particular service requires more than 32 GiB of storage, so in practice you would still need to attach something like a USB drive.

Why I ended up liking it

Because piCore can run entirely in memory and still comes with a fairly capable software manager, I think it is genuinely a very good system for Raspberry Pi use. It also feels relatively simple. Maybe something similar could be built with buildroot, but piCore is much more convenient: no compiling, package installation is easy, and updates are easy too. You can update with tce-update, and I later found that uninstalling uses tce-audit remove.

So overall, I came away with a very positive impression of the system itself. The design is solid. The weak point is the documentation, which is honestly pretty bad. A lot of things are explained unclearly, and for many features I had to dig through them myself. There also isn’t much useful reference material online. Other than that, though, the system is genuinely well designed.