COSMIC Epoch: System76's Desktop Environment, Component by Component

What COSMIC Epoch is, and who it is built for

COSMIC Epoch is the desktop environment that System76 develops for Pop!_OS, and the repository named pop-os/cosmic-epoch is the assembly point for it rather than the code of any single program. The README lists the components it pulls together: cosmic-comp for compositing, cosmic-panel for the bar, cosmic-settings and cosmic-settings-daemon for configuration, cosmic-session for the session itself, cosmic-store, cosmic-term, cosmic-files, cosmic-edit, cosmic-player, cosmic-launcher, cosmic-notifications, cosmic-osd, cosmic-osk, cosmic-screenshot, cosmic-randr, cosmic-bg, cosmic-idle, cosmic-greeter, cosmic-initial-setup, cosmic-monitor, cosmic-applets, cosmic-applibrary, cosmic-icons, cosmic-sound-theme, cosmic-wallpapers, cosmic-workspaces-epoch, pop-launcher and xdg-desktop-portal-cosmic.

The audience is narrower than that list suggests. If you want a desktop you install and forget, COSMIC Epoch is the wrong shape of project: it is a collection of independently versioned programs, and the README points you at distribution packages rather than at a single installer. The people who get the most out of this repository are those who want to know which process draws the panel, which one handles screen capture, and which one mediates file dialogs, because every one of those is a separate entry in the tree with its own build recipe. The README also lists the shared libraries underneath the shell (cosmic-protocols, cosmic-text, cosmic-theme, cosmic-time) and libcosmic, the toolkit that applications and applets are written against. That separation is the point of the project layout, not an accident of packaging.

How the components fit together, and how the justfile builds them

The top-level tree is a set of directories, one per component, plus docs/, scripts/, a justfile and a TRADEMARK.md. There is no single Cargo workspace holding the whole desktop; each component directory carries its own build entry point, and the justfile orchestrates them.

The build recipe is explicit about that split. It creates a build directory, then calls a build-release recipe inside each component that uses Just, and falls back to make for the ones that use a Makefile:

build:
    mkdir -p build
    {{ just }} cosmic-applets/build-release
    {{ just }} cosmic-applibrary/build-release
    {{ just }} cosmic-bg/build-release
    {{ make }} -C cosmic-comp all
    {{ just }} cosmic-edit/build-release
    {{ just }} cosmic-files/build-release
    {{ just }} cosmic-greeter/build-release

That pattern repeats down the list, with cosmic-comp, cosmic-settings-daemon, cosmic-wallpapers, cosmic-workspaces-epoch and xdg-desktop-portal-cosmic going through make and the rest through Just. The install recipe mirrors it, taking rootdir and prefix arguments and forwarding them to each component's install recipe. The default prefix is /usr/local. The practical consequence is that you can build and install one component without touching the others, which is useful when you are working on the panel or the file manager and do not want to rebuild the compositor. It also means a partial build can leave you with a mismatched set of binaries, because nothing in the justfile checks that the components you installed were built from the same revision.

Installing COSMIC Epoch on Pop!_OS 24.04 and Arch Linux

On Pop!_OS 24.04 the README says the first COSMIC release, Epoch 1, is already included. You either install from the release ISO or upgrade an existing Pop!_OS 22.04 installation:

pop-upgrade release upgrade -f

The README directs upgrade problems to the pop-upgrade repository or the Pop!_OS Mattermost server rather than to this repository. On Arch, COSMIC is packaged in the extra repository, either as cosmic-session or as the cosmic group:

pacman -S cosmic-session

After installing, the README describes the same step on every distribution: log out, click your user, and use the sprocket at the bottom right of the login screen to select COSMIC before logging back in. That sprocket is the only place the session choice appears, so if COSMIC is missing from it after a successful package install, the session file was not picked up and reinstalling the package is the first thing to check.

Fedora, NixOS and openSUSE: three different levels of packaging maturity

Fedora 41 and later ship COSMIC in the built-in repositories, which the README treats as the stable path:

sudo dnf install @cosmic-desktop-environment

For newer packages with less quality control, the README points at a nightly COPR build, enabled and installed in one line:

sudo dnf copr enable ryanabx/cosmic-epoch && sudo dnf install cosmic-desktop

That distinction is worth taking literally. The COPR is a nightly, and the README says so. NixOS takes a third approach, with a module rather than a package list. The README gives the configuration to add to configuration.nix or a flake:

{
  # Enable the COSMIC login manager
  services.displayManager.cosmic-greeter.enable = true;

  # Enable the COSMIC desktop environment
  services.desktopManager.cosmic.enable = true;
}

The README states that while packages like cosmic-session may exist in earlier releases, the modules that add full support were added in NixOS 25.05, so enabling this on an older release will not give you the same result. The section on openSUSE Tumbleweed is cut off in the README text, so there is no installation command to quote for it here.

Pop!_OS 22.04 is the case where COSMIC Epoch is the wrong tool

The README is blunt about this one. Because of dependency requirements, COSMIC Epoch is no longer receiving updates on Pop!_OS 22.04 LTS, and the README says it is no longer recommended to test COSMIC Epoch there because the latest fixes and features are only available on newer distributions such as Pop!_OS 24.04. An older alpha release remains installable on 22.04, but the instructions for it are a sequence of manual system changes rather than a package install: editing /etc/gdm3/custom.conf to set WaylandEnable=true, commenting out two RUN statements in /usr/lib/udev/rules.d/61-gdm.rules for NVIDIA users, restarting gdm, and then installing cosmic-session.

If you are on 22.04 and want the COSMIC applications rather than the desktop, the README offers a middle path:

sudo apt install cosmic-edit cosmic-files cosmic-player cosmic-store cosmic-term

Those run inside the default GNOME session. That is the honest recommendation for anyone unwilling to move to 24.04: take the individual applications, leave the session alone, and do not report bugs against a build the project has stopped updating. The second limitation is structural rather than version-specific. This repository is an assembly point, so a bug you hit in the panel belongs to cosmic-panel, and one in file dialogs belongs to xdg-desktop-portal-cosmic. Filing it against cosmic-epoch is unlikely to route it to the right maintainer.

How COSMIC Epoch compares with GNOME as a packaging model

The obvious alternative for a Pop!_OS or Fedora user is GNOME, which is distributed as a coordinated release: the shell, the settings daemon, the file manager and the terminal move together, and a distribution packages one version of the set. COSMIC Epoch inverts that. The README's component list is a list of separate GitHub repositories, each with its own release cadence, and the top-level repository is what ties a particular combination together. That is why the epoch releases exist at all: epoch-1.8.0, epoch-1.7.0 and epoch-1.6.0 are tags on this tree, published within weeks of each other in August and September 2026, and they name a snapshot rather than a version of one program.

The trade-off is real in both directions. GNOME gives you a single version number and a single bug tracker entry point, at the cost of having to take the whole stack at once. COSMIC Epoch lets a distribution ship a newer file manager than compositor, and lets you build the panel alone from this tree, at the cost of having to know which component you are actually running. If your reason for looking at COSMIC is a specific application, such as cosmic-term or cosmic-files, installing that application on its own is closer to what you want than adopting the whole desktop.

Maintenance, licensing and what to verify before adopting

The repository is not archived, and the last push was on 2026-09-17, with epoch-1.8.0 released on 2026-09-10. Upgrade cost depends on how you install it. Through a distribution package on Pop!_OS 24.04, Fedora 41+, NixOS 25.05, Arch or openSUSE Tumbleweed, upgrades arrive with the rest of your system. Through the Fedora COPR you are tracking a nightly, and the README warns that quality control is lower there, so pinning to the built-in repository is the lower-risk choice if you care about stability. Building from this tree yourself is the highest-cost path: the justfile drives roughly two dozen component builds, and you own the job of keeping them consistent.

On licensing, the repository metadata gives no licence identifier, and the tree contains a TRADEMARK.md alongside the component directories. That combination means two separate questions need answering before you redistribute anything: the licence terms of each component, which are not stated here, and the trademark terms, which TRADEMARK.md covers. This is not legal advice, and the file to read is TRADEMARK.md in the repository root.

Editorial conclusion

Adopt COSMIC Epoch if you already run Pop!_OS 24.04, Fedora 41+, NixOS 25.05, Arch or openSUSE Tumbleweed and you want a Wayland desktop whose parts you can inspect and build one at a time. Do not adopt it on Pop!_OS 22.04, where the README states COSMIC Epoch no longer receives updates, and do not treat the top-level repository as a supported source-build path until you have checked the docs directory and the per-component build files yourself. Verify first that your distribution ships a cosmic-session package, and check TRADEMARK.md before you ship anything built from this tree under the COSMIC name.

Frequently asked questions

Official sources

1. Issues
2. pop-os/cosmic-epoch on GitHub
3. Project website
4. README
5. Releases