Winblues

Blue95 Dawson Now Available

Mon, 13 Jul 2026 12:00:00 +0000

We’re excited to announce that Blue95 Dawson, based on Fedora 44, is now available!

This post will go over some of the changes and improvements that Blue95 has made since the previous version Blue95 Carlton was introduced.

What’s New

Blue95 Carlton is now based on Fedora 43, which brings some minor changes to an already stable base. It includes a new kernel version 6.17 and a bunch of other important but non-user-facing changes from Fedora 43.

Special thanks to Timothée Ravier for maintaining the upstream Fedora Xfce Atomic images!

Install Now

If you are currently using Blue95 Topanga, then you should automatically be upgraded on your next reboot. If you are using another Fedora Atomic image and want to try it out, you can rebase with

sudo bootc switch ghcr.io/winblues/blue95:latest

For other installation instructions, please visit the Install Guide.

Blue95 Carlton Now Generally Available

Wed, 12 Nov 2025 12:00:00 +0000

We’re excited to announce that Blue95 Carlton, based on Fedora 43, is now generally available!

This post will go over some of the changes and improvements that Blue95 has made since the previous version Blue95 Topanga was introduced.

What’s New

Special thanks to Timothée Ravier for maintaining the upstream Fedora Xfce Atomic images and helping navigate a deprecation scare!

Clippy

Clippy returns as a local LLM agent! Included by default in Blue95 is the wonderful Clippy project from Felix Rieseberg that allows you to run models like Gemma directly on your own hardware. Privacy is baked in by default: nothing leaves your machine and everything is executed locally.

PowerPoint Templates

A new ujust recipe has been introduced to install PowerPoint templates from old products such as Office 97 that have been collected and hosted in the Internet Archive’s Microsoft Powerpoint Templates Pack.

ujust install-ppt-templates

The templates will be placed in ~/Documents/Presentations/Templates.

Install Now

If you are currently using Blue95 Topanga, then you should automatically be upgraded on your next reboot. If you are using another Fedora Atomic image and want to try it out, you can rebase with

sudo bootc switch ghcr.io/winblues/blue95:latest

For other installation instructions, please visit the Install Guide.

KDE Development on Bazzite

Fri, 19 Sep 2025 12:00:00 +0000

Bazzite, a gaming-focused Linux operating system, has garnered a reputation for being a good choice for playing video games but too restrictive for actual development work due to its read-only /usr partition and its weird package management quirks.

Often, people get tripped up by attempting to install certain toolchains for development work, realizing that installing packages on top of the bootable container image requires a reboot, and eventually conclude that this friction is an indication that the operating system is not suitable for serious software development.

Here, I will argue that the restrictions imposed by its so-called “immutable” nature are in actuality useful safeguards that help isolate your day-to-day desktop activities from your development work. By providing a strong emphasis on containerization, you are free to install, explore, develop and destroy to your heart’s content within the confines of a sandboxed environment without care. You can hack away without the sneaking worry that by somehow upgrading the system’s clang++ to a version required for your development work, you will inadvertently break the ABI of some shared-library that your web browser depended on, and now you cannot navigate to double-u double-u double-u dot reddit dot com to doomscroll for hours on end.

But aren’t containers heavily sandboxed? What if I want to develop a core component of the system, such as the desktop environment itself?

This post is written in praise of a tool that makes such an endeavor possible: Distrobox.

Setting Up KDE Builder

The magic that makes containerization a viable strategy for KDE development is Distrobox. In their own words:

Distrobox uses podman, docker or lilipod to create containers using the Linux distribution of your choice. The created container will be tightly integrated with the host, allowing sharing of the $HOME directory of the user, external storage, external USB devices and graphical apps (X11/Wayland), and audio.

Bazzite is based on Fedora, so we plan to create a Fedora distrobox. In the container, we will install all of our development tools and then build KDE from source. The resulting artifacts will be available outside of the container back on the host system.

To reduce some friction, I’ve created a Fedora-based Docker image that contains all of the necessary KDE development packages. It is available via the GitHub Container Registry.

sudo mkdir -p /var/local/kde-dev/{home,kde}
sudo chown $(id -u):$(id -u) /var/local/kde-dev/{home,kde}

mkdir -p /var/local/kde-dev/home/.config
cp ./kde-builder.yaml /var/local/kde-dev/home/.config

distrobox create \
	--name kde-dev \
	--home /var/local/kde-dev/home \
	--volume /var/local/kde-dev/kde:/var/local/kde-dev/kde:Z \
	--init \
	--additional-packages "systemd" \
	--pull \
	--image ghcr.io/ledif/ublue-kde-dev:latest

In the above configuration, we have a directory tree in /var/local/kde-dev for the source files, the intermediate build files and the final /usr directory tree representing the entire desktop environment. We also create a separate home directory for the container, just so that our Bash history and profiles are not intermixed with those on the host.

/var/local/kde-dev
├── home
│   ├── .config
│   │   ├── kde-builder.yaml
│   ├── .local
│   │   ├── share
│   │   └── state
└── kde
    ├── build
    ├── log
    ├── src
    └── usr
        ├── bin
        ├── etc
        ├── include
        ├── lib
        ├── lib64
        ├── libexec
        ├── mkspecs
        └── share

The provided kde-builder.yml file tells the KDE build system to utilize the shared /var/local/kde-dev/kde directory.

After this is set up, you can then enter into the container and build KDE Plasma.

distrobox enter kde-dev
kde-builder workspace

It will definitely take a long time to compile, so consider taking a nice stroll around the neighborhood in the meantime.

Running Your Own Plasma

After the entire project finishes building, the build artifacts will be available on the host in /var/local/kde-dev/kde/usr. But, how can we run it?

We first need to tell SDDM about it, which means adding a session to /usr/share/wayland-sessions. But how can we add our KDE development session to /usr if it is read-only? Fortunately, there is one exception to the whole /usr being immutable thing:

❯ ls -l /usr/local
lrwxrwxrwx. 6 root root 15 Mar  5  2024 /usr/local -> ../var/usrlocal

/usr/local is actually a symbolic link to the writeable /var/usrlocal directory! Since SDDM can pick up sessions in /usr/local/share/wayland-sessions, we can actually add our session there with little fuss.

cat << EOF > /tmp/plasmawayland-dev6.desktop
[Desktop Entry]
Exec=/var/local/kde-dev/kde/usr/lib64/libexec/plasma-dbus-run-session-if-needed /var/local/kde-dev/kde/usr/lib64/libexec/startplasma-dev.sh -wayland
DesktopNames=KDE
Name=Plasma (Dev)
Comment=Plasma Development by KDE
X-KDE-PluginInfo-Version=6.4.4
EOF

sudo mkdir -p /usr/local/share/wayland-sessions
sudo mv /tmp/plasmawayland-dev6.desktop /usr/local/share/wayland-sessions

Now, you can log out of your session and pick the new “Plasma (Dev)” choice to run your fresh-from-source farm-to-table newly built KDE Plasma.

Thanks

This post was inspired by similar projects that ease KDE development on Fedora Atomic, including silverhadch/bazzite-kde-dx, whelanh/aurora-kdegit-dx and the Filotimo Project.

Everything In Its Right Place

Sun, 03 Aug 2025 00:00:00 +0000

Nostalgia often evokes melancholy for me. This video is a small capsule of yearning, like coming home to someplace that never really existed.

Is Bazzite Just A Normal Linux Distro?

Fri, 30 May 2025 12:00:00 +0000

I am fascinated by discussions around so-called immutable Linux distributions, especially how the community debates whether operating systems like Bazzite are suitable for different kinds of users. Bazzite has become the most popular member of the Fedora Atomic family, even outpacing Fedora’s own offerings of Silverblue and Kinoite (see: countme stats). As it grows in visibility, people are starting to question what exactly sets it apart.

Consider a recent post in /r/linux_gaming that asks:

Does [Bazzite] really make a difference or [is it just a] normal Linux distro?

This question captures a deeper tension I’ve seen across the Linux community: what counts as a “normal” distro in the first place? And if Bazzite isn’t normal, in what sense is it not normal? And is that a good thing or a bad thing?

After following many such discussions, I have noticed a pattern of opinions that generally emerges.

For Linux novices and people transitioning from Windows, I often hear the opinion “I like Bazzite because I can install it on my gaming PC and it just works.” From Linux enthusiasts and tinkerers, I encounter the sentiment “I do not like Bazzite because it is difficult to install my favorite tiling window manager and apply my custom kernel tweaks.” Finally, from grizzled Linux veterans and cloud-native developers, an opinion is shared not unlike that from the novice: “I like Bazzite because it just works and when I need to customize it, I can do so in a reproducible and containerized way.”

Bazzite and other bootc-based operating systems can be tweaked in the exact same ways as non-bootc systems; however, the steps required to implement the tweaks differ. Bazzite is more like a Dockerfile that happens to boot on bare metal. If you approach it like a container (i.e., immutable by default, reproducible, layered) the approach starts to make more sense.

So, is Bazzite a “normal” Linux distro? Kind of, yes. It’s just Linux. But in practice, it reshapes what we expect from a desktop system by applying ideas that originated in the container and cloud-native world.

bootc and Nix

In my mind, the goals of bootc and NixOS are not too dissimilar: declarative builds and atomic deployments of Linux systems. I run a few NixOS machines in my homelab and I love Nix for what it brings to the server world. But if I were setting up a desktop computer for a friend or my parents I certainly would not choose NixOS. I’d choose Bazzite or Fedora Silverblue or any of the many bootc images out there.

Fans of NixOS can rightly point out that Nix gives you unmatched power and control. But it also requires you to learn the intricacies of a domain-specific functional programming language. Not to say that the knowledge you gain in mastering Nix is not valuable, but much of its value is self-contained within the Nix ecosystem.

In contrast, bootc-based systems build on a different foundation: OCI containers. If you understand Dockerfiles or podman, you will kind of already get it. And what you learn by creating and maintaining a bootc image applies directly to containerized infrastructure elsewhere.

That’s the real magic of the bootc approach and the Universal Blue project more broadly. It bridges the gap between desktop Linux and modern infrastructure practices using familiar tooling around OCI containers. If you’re new to those ideas, learning them on the desktop has transferable value.

Universal Blue often gets flak for describing its projects such as Bazzite as cloud-native, a term that can sound meaningless or jargony if all you want is a Linux computer to run your games. And if you’re already deep in the Kubernetes or container world, the term cloud-native feels too vague to be helpful. But behind the buzzword is a simple truth: these tools and ideas scale. They bring consistency, composability, and reproducibility to the desktop, just as they have in server environments.

So, is Bazzite just a normal Linux distro? If normal means “has a desktop, runs Linux applications, and can be customized,” then yes; it shares those traits with many other distributions. But if normal means doing things in the same way we’ve done them for decades (e.g., running sudo apt-get install steam and accidentally removing your desktop environment) then no; Bazzite offers something different.

I will gladly choose that difference.

Chatting with AI Like It’s 1995

Tue, 06 May 2025 12:00:00 +0000

Sometimes I stumble across a project that feels right at home in Blue95. Felix Rieseberg’s Clippy is exactly that: a local LLM assistant wrapped in the aesthetic of everyone’s favorite (read: despised) paperclip. It’s charming, it’s nostalgic, and it’s surprisingly useful — three qualities I hold dear.

However, it’s more than just a novelty. It’s a reminder of how joyful computing can be when it’s personal, local, and just a little bit odd. It feels like a glimpse into a different path we could have taken — one where the future of computing stayed weird, creative, and people-driven, instead of being handed over to platforms that measure our lives in metrics and monetize our attention.

Maybe it’s a small window into the future we lost. Or maybe it’s just a paperclip.

The Joy of Linux Theming in the Age of Bootable Containers

Sun, 20 Apr 2025 02:00:00 +0000

Having spent a couple of decades in the Linux world, I have always had an interest in Linux desktop environments and how they are themed. I would often come across a post on /r/unixporn that inspired me to try to customize the look and feel of my desktop environment. So I would install Xfce, LXQt or Sway and try to recreate components that I like from other users or create my own. I would end up installing different kinds of panels, plugins, docks and launchers as well as random themes, fonts and sounds.

A portion of this process would be documented, initially as random shell scripts in my home directory, before graduating to Ansible playbooks – with a brief detour into Nix that I will not elaborate on. Some of the customizations would live in my home directory, but there were often system-wide modifications to /usr required.

Eventually, the constant churn and randomly broken desktop components such as a panel that mysteriously vanished or a non-functional dock led me to stick with the stock configuration of whatever desktop environment I was using at the time. The major desktop environments, KDE Plasma and GNOME, are both well polished and great out of the box. The desktop experience that they have delivered over the last few years has contributed to desktop Linux being the best it has ever been, in my opinion.

But the itch to customize and tweak my desktop environment in fun and interesting ways is still there. Eventually, I was introduced to the concept of bootable containers.

Bootc As A Themer’s Playground

The bootc project, originally developed by Red Hat but now part of the Cloud Native Computing Foundation, is a core component of the Bootable Containers Initiative. Conceptually, it allows you to define your operating system as a Containerfile:

FROM quay.io/fedora/fedora-bootc:42
RUN dnf install -y my-custom-theme my-custom-fonts my-custom-panel

Once written, you can build the container locally and instruct your bootc-aware system to use the new image.

sudo podman build -f Containerfile -t my-fedora
sudo bootc switch --transport containers-storage localhost/my-fedora:latest

After a reboot, the system’s deployment is defined by the new container.

With Fedora Atomic systems, /usr is mounted read-only and because your operating system is defined by an OCI container, it is incredibly easy to revert to a previous tag of that container. I can easily create a throwaway container where I test out ideas for a theme, reboot into the new deployment and test it out on bare-metal. I can roll back to the previous container if necessary or create a new container with follow-up modifications.

One downside is that this reboot-heavy workflow can obviously cause some friction. This can be mitigated somewhat by enabling “Development Mode” with ostree admin unlock, which creates a temporary writable overlayfs on top of /usr. I often find myself using this mode to temporarily install some package, theme or configuration in /usr. After verifying that it works as expected, I can add that functionality to the Containerfile. If it doesn’t work, I can either reboot to get rid of the changes, or (more likely) just forget about the change and it will remove itself whenever I reboot normally. The lack of cruft that accumulates over time in a typical Linux installation is one of the major advantages of this approach.

Of course, there are other ways to achieve similar results without using a bootable container model:

You can write shell scripts or Ansible playbooks and hope that they accurately capture changes to the system so that they can be reliably undone. Typically, configuration drift that occurs as software gets updated is not addressed.
With systemd-sysext(8), you can create a squashfs image of a filesystem containing your theming changes for /usr and overlay it on top of the root filesystem. An ecosystem around how these images should be created, maintained, deployed and updated has yet to emerge.
You can inscribe your custom theming as runes in an arcane and inscrutable functional language known only to the elders as N̸̘̏͑̕͝į̸̈́̂x̸͙̑̅̒.

In my opinion, none of the alternatives provide the same level of flexibility and tooling support as writing a Dockerfile, nor can they achieve bootc’s level of safety and reliability by making it extremely difficult to bork your /usr directory. And if the /usr directory somehow gets borked anyway, rolling back to the previously deployed container is just a reboot away.

What Is A Distro?

BlueXP

Blue9

A few weeks ago, an OCI image based on Fedora Xfce Atomic that I made called Blue95 was posted to Hacker News. For the most part, the reception was warm but there were some interesting questions that were raised, such as:

Is it really necessary to spin up an entirely new distro for an XFCE+GTK theme?

The original poster made me question the nature of the project I created: is it a distro? In the age of bootc, the distinction between what is considered a Linux distribution and what is simply a Containerfile + CI/CD is, in my opinion, murky at best. Historically, the barrier to entry for creating what has traditionally been called a Linux distribution was orders of magnitude higher than creating and publishing an OCI container. My nights-and-weekends side project of building a bootable container is a far cry from what I imagine a Linux distribution to be.

Blue95 is a collection of scripts and YAML files cobbled together to produce a Containerfile, which is built via GitHub Actions and published to the GitHub Container Registry. Which part of this process elevates the project to the status of a Linux distribution? What set of RUN commands in the Containerfile take the project from being merely a Fedora-based OCI image to a full-blown Linux distribution?

Popular bootc-based projects like Project Bluefin and Bazzite are often labeled as Linux distributions, much to the consternation of their creators and maintainers. But if you’ve ever used Bazzite and booted directly into Steam’s Big Picture Mode, you might agree that it does indeed feel like its own Linux distribution; it is quite distinct from its twin bases of Fedora Silverblue and Fedora Kinoite.

Maybe the imprecision of the term “Linux distribution” is most evident when arguments arise over what is and isn’t a distro. It has always been problematic to define a distribution as simply a curated collection of software plus a Linux kernel -— but that definition is now especially lacking, as it could just as easily describe any Containerfile for a bootable container. Ultimately, “I know it when I see it” may be the best we can do when deciding whether a project deserves the label Linux distribution or not.

Finally, to address the original question about the necessity of spinning up a new distro just for a theme: creating a bootable container with a consistent visual design and curated set of applications can bring a bit of joy and levity. At this moment, my laptop is booted from a container that I have created myself. The operating system being used to draft these words is the product of my own artistic and creative expression – built on the work of countless other human beings. And that brings me joy.

Blue95 Topanga Now Generally Available

Fri, 18 Apr 2025 12:00:00 +0000

We’re excited to announce that Blue95 Topanga, based on Fedora 42 is now generally available!

This post will go over some of the changes and improvements that Blue95 has made since the previous version Blue95 Ross was introduced.

What’s New

Blue95 Topanga is now based on Fedora 42, which brings several changes along with it, including:

The latest version of Xfce 4.20. Partial Wayland support is experimental but functional. See the Xfce 4.20 Tour for more information.
Fedora Atomic bootc images now use composefs for the default / filesystem. This should not have a user-visible impact, but it makes the root filesystem more resistant to accidental modifications.
A new kernel and a bunch of other changes from Fedora 42.

Applications

Winblues Paint

Chicago 95 Plus!

Blue95 Topanga has introduced several new applications that fit the 90s aesthetic. For a full list, see Blue95 Applications:

Winblues Paint is a light GUI around jspaint.app
Chicago 95 Plus! is a GUI that lets you apply any Windows 95, 98, ME or XP theme.
Audacious is skinned with the classic Winamp skin and full support is available for any old Winamp skin.
Flatpost is now the default Flathub browser and App Store in Blue95.
LibreOffice is now provided as a Flatpak, with instructions on how to install the correct icons.

Live CD

We are now providing a Live ISO where you can boot into a Blue95 live environment. Test it out without needing to install anything. Find more information in the Documentation.

Install Now

If you are currently using Blue95 Ross, then you should automatically be upgraded on your next reboot. If you are using another Fedora Atomic image and want to try it out, you can rebase with

sudo bootc switch ghcr.io/winblues/blue95:latest

For other installation instructions, please visit the Install Guide.