← Journal

BifrOSt starts with the unsafe parts

Why BifrOSt keeps Arch Linux intact, makes Icelandic defaults explicit, and treats the installer as the work that needs the most scrutiny.

  • linux
  • arch-linux
  • bifrost

BifrOSt is my Icelandic-first workstation distribution built on Arch Linux. It keeps Arch's kernel, pacman, repositories, and rolling updates. The changes are deliberately narrower: COSMIC, Icelandic locale and keyboard defaults, optional development profiles, and a separate visual identity.

The current core source is version 0.2.2. It is a patch release, so it ships as the bifrost-system package through the signed [bifrost] repository rather than as another ISO. The latest core build, AkurAI Build run 853, succeeded on main. A package update should still be a complete sudo pacman -Syu transaction; BifrOSt does not try to replace the package manager or freeze Arch packages.

The installation boundary

The installer is where a distribution can do permanent damage, so that is where I have put most of the defensive work. BifrOSt 0.2 only installs to a whole disk. There is no dual-boot or manual-partitioning route. The installer shows the target path, model, capacity, serial number, and WWN when available; the final confirmation asks for the path again. Its privileged backend checks the target again immediately before the wipe and refuses a changed identity or topology.

That is not a claim that software can identify a disk better than its owner. Device paths and capacity are weak evidence. The installation guide tells the user to compare a model plus serial number or WWN with the physical drive or firmware inventory, and to stop if they differ. The guardrails reduce a class of mistakes; they do not make destructive work safe by default.

Online installation is the normal 0.2 path. Before wiping, the backend refreshes signed Arch package databases, resolves the requested packages, and checks the actual source URL. Offline installation is only available when the medium contains a signed manifest, trusted keyring and local repository, plus every required package; each archive is verified before the wipe. A bootable USB is not, by itself, evidence of a complete offline installation.

Three repos, separate responsibilities

The operating-system repository owns the ISO profile, installer, first-party system package, and the Update Assistant. It also keeps the signing and admission boundary for first-party Flatpak releases.

BifrOSt-Apps is kept separate so application source and templates do not also carry the authority to publish into that catalog. The core source currently reports an empty production catalog. It names the RÚV player org.bifrost.Ruv 0.1.1 as an unsigned, unpublished review candidate; that is useful progress, not a released application. The Apps project remains in progress.

BifrOSt-Web is likewise separate from the installer and package source. Its role is the public home, release material, installation guidance, screenshots, and eventual catalog. Its latest recorded AkurAI Build run, 747, succeeded on main; the Web project is still marked in progress.

That split is intentional. An application candidate, a website update, and a system release do not deserve the same trust boundary. Keeping them apart lets me make the package and installer path conservative without blocking work on the rest of the project.

For current limits and install instructions, read the BifrOSt source documentation. Secure Boot is not supported in 0.2, and hardware support is only claimed for explicitly qualified machines. Those limits belong next to the release, not in small print.