Blueberry Linux is a source-built rolling x86-64 server distro I’ve been working on since May. It isn’t a respin of anything. It has its own package manager (bpm, written in Rust with streaming installs and SHA-256 verification), its own package format, and its own signed repository using an Ed25519 signature over the index.
There are 225 package recipes so far, from glibc and binutils upward.
It’s also self-hosted in the real sense. The base system is built from Blueberry packages using the Blueberry toolchain, and if a build falls back to a foreign bootstrap, that’s considered a build failure rather than a successful build.
I came back to the project after about a month away and spent some time auditing the live infrastructure before getting back to development. I fixed the repository issues I found, published nine package updates, and built something new: you can now try Blueberry directly in your browser at https://try.blueberrylinux.org.
The hardest part of this round was actually a near miss.
There’s an old copy of bpmrepo.sh sitting on the repository host that predates serial support. It doesn’t emit the |serial| line. It was sitting there looking perfectly usable, and it would have worked.
The problem is that using it would have silently removed rollback protection from the signed repository index. Nothing would have obviously failed. The index would still have been signed and the repository would still have worked.
I only caught it because I went back and checked what my own client actually expects instead of assuming the existing tool was the right one.
The browser shell also had two bugs that took a bit of debugging.
First, pty.fork() already calls setsid(), so I was calling it a second time. That resulted in EPERM and killed every session immediately after launch.
Then the xterm CDN URLs started returning 404s. The frontend failed before it could even display the actual error, so from the user’s perspective it just sat there saying “connecting…”.
I vendored the assets locally and changed the frontend to report asset loading failures properly.
The part I’m happiest with is how the browser environment is built.
The thing you’re running in the browser is actually assembled from the same packages the distro itself uses.
The isolation is also verified rather than assumed. From inside a live session, the router, the hypervisor, and 1.1.1.1 are all unreachable, and only three PIDs are visible.
If you want to try it, open https://try.blueberrylinux.org.
It’s a real shell on a real Blueberry rootfs.
There’s no network access, nothing persists between sessions, and each session is limited to ten minutes.
The source is available here: https://github.com/zsigisti/blueberry
- 1 devlog
- 45h
