Blue95 is an atomic Fedora Xfce desktop wrapped in a Chicago95 skin

What Blue95 is, and the base it is built on

Blue95 presents itself with one line, a desktop for your childhood home's computer room, and then explains the construction: it is a modern, lightweight desktop experience reminiscent of a bygone era, based on Fedora Atomic Xfce with the Chicago95 theme. The theme comes from the Chicago95 project by grassmunk, and the README credits that work along with Chicagofier by dominichayesferen.

The two halves of that sentence matter differently. The base is a mainstream distribution with a mainstream desktop, and the theme is a skin on top of it. The project goals section says it wants to match upstream Fedora Xfce in terms of core system components and update schedule, so the intent is to be a themed Fedora rather than a separate operating system, and to pull in adjustments from Universal Blue, with codecs and automatic updates given as examples, to produce something usable out of the box.

The repository layout matches that description. There is a recipes folder with a recipe.yml, a modules folder, a files folder, a justfile for the developer commands, and a .github folder. The topic tags list atomic, bluebuild, bluebuild-image, image-based, immutable, linux-custom-image, ublue-os, windows95 and xfce, which is an accurate summary of the design. Blue95 is an image based, immutable desktop where the operating system is assembled as a container image rather than installed piece by piece.

The build pipeline: bluebuild recipes driven by a justfile

The developer workflow is a small set of commands in the justfile, and they say more about the project than the README does. Building the image and rebasing it onto a newer base are separate targets, and the ISO is produced from the image that was built:

build:
  bluebuild build --tempdir /var/tmp recipes/recipe.yml

rebase:
  bluebuild rebase --tempdir /var/tmp recipes/recipe.yml

generate-iso:
  sudo bluebuild generate-iso --iso-name blue95-latest.iso image ghcr.io/ledif/blue95:latest

The build and rebase targets both point at recipes/recipe.yml, which is the single source of truth for what goes into the image. A rebase is the operation that takes the existing image and rebuilds it on a newer upstream base, and because Blue95 tracks upstream Fedora's update schedule, that is the command an operator runs to move forward, rather than a set of package upgrades inside a running system.

The ISO target pulls an image from a container registry and writes a bootable image, and the live ISO target does something different: it clones the titanoboa repository from Universal Blue into a scratch directory if it is not already there, pulls the latest if it is, and then runs an Anaconda web UI hook script from the repository's own files directory:

generate-live-iso:
  #!/bin/bash
  if [ ! -d scratch/titanoboa ]; then
    mkdir -p scratch
    cd scratch
    git clone https://github.com/ublue-os/titanoboa.git
    cd ..
  else
    cd scratch/titanoboa
    git pull
    cd ../../
  fi

One inconsistency in that file is worth flagging for anyone scripting it. The ISO target reads its image from ghcr.io/ledif/blue95, while the live ISO target refers to ghcr.io/winblues/blue95, so the two paths do not obviously point at the same artifact.

The live ISO is the easy path, and the installer is the rough one

Blue95 offers a live ISO that can be booted without installing anything, and the README is clear that this is new and still in testing. The image is published at a blue95-live-latest.iso file on a Cloudflare R2 bucket, and the point of it is that you can try the environment on a machine you are not willing to change.

The same section delivers the bad news about the other path. The bundled installer is described as an alpha version with many missing features, and the recommendation is to install Blue95 using the methods in the Install Guide rather than the included installer. The README's installation section does nothing more than point at that guide, at blues.win/95/docs/install, with the general documentation at blues.win/95/docs. A project can be young without this much pointing, and here the install story is genuinely unfinished, which matters because installation is the first thing an adopter has to do.

The developer commands in the justfile reflect the same state. The test-installer target copies the installer script and its interface file from the files tree into a shared folder, which reads as a way of running the installer against a running system or a virtual machine share rather than as a build step:

test-installer:
  cp files/system/usr/libexec/blue95-installer.py files/system/usr/share/winblues/installer.glade ~/Public/vm-share/

The presence of a Glade interface file means the installer is a graphical program, and the fact that the maintainers need a way to copy it into a virtual machine share for testing tells you the installation path is still being worked on.

Where the personalisation lives: a files tree and a chezmoi profile

The files directory holds the content that makes the image Blue95 rather than plain Fedora Atomic Xfce. Paths in the justfile show the shape of it, with system files laid out under a usr tree and a winblues directory carrying the project's own material, including a chezmoi configuration directory and the installer files. The presence of chezmoi, a dotfile manager, means the desktop configuration is kept as a set of managed files in the repository, which is how the theme settings, panel layout and shortcuts are versioned and re-applied.

The panel is handled by an explicit target, and the comment in the justfile describes it as overwriting the xfce4-panel-profile in the repository based on the current profile:

refresh-panel-profile:
  #!/bin/bash
  set -exuo pipefail
  tmptar=$(mktemp -p /tmp blue95-profile.XXXXX)
  xfce4-panel-profiles save $tmptar
  cd files/system/usr/share/winblues/chezmoi/dot_local/share/xfce-panel-profile/
  tar xf $tmptar
  rm $tmptar

The script saves the panel profile from a running session into a temporary archive and unpacks it over the copy in the repository, so the workflow is: configure the desktop the way you want it, run the target, commit the result. That is a sensible pattern for an image based system where the desktop state is part of the image definition rather than a set of per user files, and it also means a change to the panel is a code review rather than a support question.

The modules folder is the other half of the build definition, and the repository carries a cosign.pub key at the root, which is the artefact used to verify image signatures.

Design goals, and the deliberate line against exact replication

The goals section is short but it is the most useful part of the README for a prospective user. Match upstream Fedora Xfce for core system components and update schedule, pull in Universal Blue adjustments such as codecs and automatic updates, and provide an aesthetic rooted in a bygone era of computing.

The non-goals section is the interesting one, because it tells you what the project will refuse to do. It states that faithful reproduction of design elements from decades old operating systems is not a goal, and that whenever usability and exact replication are at odds, usability and accessibility will generally be preferred. That is a clear statement of priorities, and it is the difference between a theme and a reimplementation. A user who wants the Chicago95 look and a working desktop gets both. A user who wants pixel accurate Windows 95 is looking at the wrong project, and the README is being honest about that rather than promising fidelity it does not intend to deliver.

It also explains why the result is described as a modern and lightweight desktop rather than a period piece. The skin is a layer over a current distribution, and the project is explicit that it wants to inherit the upstream update schedule rather than freeze a historical system.

Licence, maintenance and where Blue95 is the wrong choice

The licence is Apache-2.0, and the LICENSE file at the repository root is the document to read for the terms. Apache-2.0 covers the code in the repository, which is the practical point if you intend to publish your own variant of the desktop, since the recipe, the files tree and the modules are all part of the same work.

On maintenance, the last push to the repository was on 2026-09-02, so the work is current, and the project depends on three upstream projects that move faster than it does: Fedora Xfce for the base, Universal Blue for the adjustments and bluebuild for the build system. That dependency is a feature for anyone who wants a desktop that keeps receiving upstream fixes, and a risk for anyone who wants a fixed artefact, because a rebase can change what the image contains without any change in this repository. There are no GitHub releases, so there is no numbered version of the desktop to pin, only image tags, and the justfile uses a latest tag for the ISO build.

The wrong choice is a machine that needs a supported install path today. The installer is an alpha with many missing features, the live ISO is still in testing, and the documentation pushes you to a guide rather than walking you through the steps. If you need a desktop that behaves like a normal Linux install, with a partitioner you understand and an upgrade path you trust, then plain Fedora Xfce with the Chicago95 theme applied is the more predictable route, and the same is true for a server. Blue95 earns its place on a machine where the retro look is the point and the image based workflow is acceptable.

Editorial conclusion

Adopt Blue95 if you want a retro styled Linux desktop that still tracks upstream Fedora Xfce and that you can build or rebase yourself, and if you are comfortable with image based releases rather than a classic package install. Do not adopt it as a production workstation image, because the bundled installer is an alpha with many missing features and the live ISO is still in testing. Verify first by reading the Install Guide at blues.win/95/docs/install, then by rebuilding the recipe with the justfile so you know the image you run matches the recipe you can audit, and by checking the cosign.pub key in the repository root against the image you pull.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. winblues/blue95 on GitHub