project / operating system
experimentalFF00 Ark
An in-development Gentoo recovery and operations system built to load itself into RAM, deploy your system, and recover your state.
- Gentoo
- Portage
- OpenRC
- Fish
- Catalyst
- QEMU
Load Thyself. Deploy Thy System. Recover Thy State.
In the works
FF00 Ark is an active product under development. This page records what has actually been proved, but there is no public source repository, ISO, or development download yet. I am keeping the implementation private until v1 is complete so publishing, packaging, and supporting unfinished checkpoints do not become a substitute for finishing the operating system.
When v1 is ready, the complete polished source will appear on Forgejo as the canonical repository and on GitHub as the public release mirror. The release will include the bootable image, checksums, licences, documentation, and the reproduction path expected of every finished FF00 open-source product.
FF00 Ark is the second generation of my Portable Bridge Workspace idea. The original Bridge made a removable drive into a portable workbench. Ark asks the next question: what if that same class of device could also boot its own known environment on an available x86-64 machine?
The intended result is a RAM-resident Gentoo recovery and operations system. It
should remain useful when the installed operating system is broken, absent, or
simply not mine. From its console I want Fish, tmux, repair tools, networking,
documentation, and guided chroot helpers. When graphics work, startx should
open my familiar Xorg and i3 workbench for a browser, VS Code, Codex, and normal
communication.
Ark is not an automated wipe-and-reinstall appliance. It is an inspectable multi-tool that gives the operator a capable environment and keeps destructive decisions explicit.
Why Gentoo
The first thought was Arch because recovery tools are readily available there. That was not a sufficient architectural reason. The wider FF00 operating-system work already converges on Portage, explicit policy, and OpenRC. Gentoo supplies the knobs needed for unusual recovery jobs while still allowing Ark releases to consume binary packages rather than compiling on somebody’s emergency machine.
Portage policy is therefore part of the product. Ark defines reviewed package
sets such as @ark-core, records USE and licence decisions, retains the exact
accepted binary closure, and refuses to treat a moving binhost as a
reproducible input.
What exists today
This is no longer only an architecture document. The private working tree has:
- authenticated, timestamped Gentoo stage and control-media inputs;
- pinned Gentoo, Catalyst, and Release Engineering source revisions;
- a clean 309-package Ark Core root reproduced with networking disabled;
- native GPKG signature checks and a demonstrated missing-key refusal path;
- a retained and hashed package pool instead of an unbounded live binhost;
- secret-key, build-cache, and lab-configuration release-root checks;
- a software-emulated QEMU and UEFI boot laboratory;
- a constrained Catalyst mount environment with no visible block device;
- architecture, decisions, status, build journal, human workflow, and LLM workflow documentation.
The clean core root currently measures 3,073,874,563 bytes before final live image compression. Its sorted installed-package inventory is recorded by hash and checked automatically.
What does not exist yet
There is no FF00 Ark ISO today. Copy-to-RAM boot, Fish console presentation,
the bridge user, recovery suites, guided chroots, Xorg/i3, the image library,
Linux-to-Ark kexec, and self-replication through Ark Media remain milestones.
That distinction matters. The work is real, but an internal build laboratory is not yet a product release.
The eventual device
The public operating system and the private Bridge profile are separate layers. The public Ark image should be safe for anyone to download, inspect, copy, and adapt. My private device may additionally carry encrypted workspace and infrastructure material, but those credentials are neither embedded in Ark nor part of its public recovery promise.
The same device should eventually provide:
- Ark itself as the primary RAM-resident workbench;
- a tested image library for selected installer and recovery media;
- a verified way to reproduce Ark onto another drive;
- a private, separately protected Bridge workspace;
- a direct
kexechandoff from a compatible running Linux system when policy and hardware allow it.
Release boundary
There is intentionally nothing to download yet. Development snapshots will not be uploaded piecemeal. The first public code is intended to be the complete v1 source beside a usable, verified release—not a repository that asks visitors to assemble the promise themselves.
Forgejo will be the canonical development and source repository at v1. GitHub will be the polished public mirror for discovery, tagged source, checksums, and release downloads. Ark remains intended for AGPL-3.0-or-later publication.
Next gate
The next task is deliberately upstream and boring: install pinned Catalyst 4.1.1 inside the constrained laboratory, validate Gentoo’s unmodified two-stage minimal-media specifications, build that control twice, and explain the output differences before adding Ark customization.
That is how this project intends to proceed throughout: show the plan, apply the decision, record the result, and keep a way back.