Nobara Linux: The Patched Fedora That GloriousEggroll Built

Fedora is one of the best-maintained Linux distributions available. It ships a clean, upstream-faithful system with a modern kernel, DNF package management, and a clear development philosophy. What it does not ship is NVIDIA drivers, Wine dependencies, hardware-accelerated video codecs, OBS Studio, or any of the other things that make a desktop usable for gaming and content creation. That gap is exactly what Nobara Linux exists to close -- and it does so in ways that go well beyond a simple post-install script.

Nobara is the work of Thomas Crider, a software engineer known in the Linux community as GloriousEggroll, who previously served as a Software Maintenance Engineer at Red Hat. The same person who built Proton-GE -- the widely used custom Proton fork that enables thousands of Windows games to run on Linux -- also maintains this entire distribution largely on his own. That context matters when evaluating what Nobara actually is and what it is not.

Where Nobara Came From

The story behind Nobara is unusually specific. According to Crider in a YouTube interview, the idea originated from his efforts to fix the gaming issues his father encountered on Windows. Frustrated with recurring problems and the time required to resolve them, he decided to build a Linux environment that was preconfigured for gaming with minimal setup required. Nobara Linux was first publicly released on July 10, 2022.

The name itself carries a cultural reference that the project has not officially confirmed but that has been widely noted in the Linux press: Nobara Kugisaki is a character from the manga and anime series Jujutsu Kaisen, known for fierce independence and an uncompromising approach -- qualities that loosely mirror the project's philosophy of doing things its own way without deference to the conventions that upstream distributions follow. Whether intentional or incidental, the name fits. What makes the origin story meaningful from a technical standpoint is that Nobara was never conceived as a community distro built by committee. It reflects one engineer's daily driver priorities, and that specificity shows in the choices it makes.

In the Nobara Project FAQ, Crider explained the founding rationale in straightforward terms: the goal was a system that both he and his father could use from a clean install without time-consuming troubleshooting or extra package and repository setup. He acknowledged that while some users have the technical skill to work through problems, "sometimes we just don't have the time" -- Thomas Crider (GloriousEggroll), Nobara Project FAQ.

The Fedora Relationship: Independent, Not a Spin

Understanding what Nobara is technically requires understanding what it is not. While Nobara does utilize Fedora packages, code, and repositories, it operates independently without direct involvement from Fedora developers or parties. It is not a Fedora Spin, which is a term Fedora uses for official variants produced through the Fedora Project process.

The practical consequence of this independence is significant. Nobara maintains its own COPR (Cool Other Package Repo) hosted packages -- including a heavily modified kernel -- that are outside the official Fedora signing and build infrastructure. Packages shipped from Nobara's COPR, like Mesa, kernel, or other modified ones, are updated as soon as possible and outside of Fedora's cadence.

Crider laid out the formal terms of this independence in an early Boiling Steam interview and in Nobara's EULA. The EULA specifies that Nobara is not a Fedora Spin, that no Fedora developers or parties are involved, and that the relationship is limited to Nobara's use of Fedora packages, code, and repositories -- nothing beyond that.

The same interview reveals why Fedora was chosen over Arch, Debian, or Ubuntu. Crider described the appeal in direct terms: Fedora is "a good middle buffer between bleeding edge and stability" -- Boiling Steam. That description is load-bearing for understanding Nobara. It is not an Arch derivative because Arch's rolling nature introduces breakage risk that Nobara's target audience should not have to manage. It is not Ubuntu because Ubuntu's LTS cycle is too slow for a gaming-oriented stack that needs current Mesa, current Proton components, and current kernel patches. Fedora sits at the right cadence: modern enough to carry current gaming infrastructure, stable enough not to break constantly, and the base that Crider had been running personally since joining Red Hat in 2018.

This also explains one of Nobara's most frequently cited limitations: SecureBoot must be disabled in BIOS on the target machine, as Nobara does not support it. The reason is structural. Custom COPR-hosted kernels cannot easily be signed through the standard shim process, and the project has explicitly stated it has no intention of pursuing Microsoft's shim signing requirements. This is a deliberate tradeoff -- hardware compatibility patches and low-latency performance over Secure Boot support.

Nobara also uses a snapshot-based approach to the Fedora repositories it mirrors. Rather than pulling live Fedora packages continuously, Nobara works with snapshots of the Fedora repos that are usually synced once or twice a month, depending on whether a newer dependency is needed or if a major CVE has been made public. This gives the project version control -- if a problematic upstream package lands, it can be reverted without users being exposed.

The Kernel: Where the Real Work Happens

The most technically distinctive part of Nobara is its kernel. This is not a stock Fedora kernel with one or two patches applied. It is a heavily modified build maintained outside the Fedora build system, with a patch set that has evolved significantly over the project's lifetime.

As of recent releases, Nobara has migrated to using the kernel from CachyOS with some additional patches and configuration tweaks. The CachyOS kernel is itself a well-regarded performance-focused build that incorporates the BORE (Burst-Oriented Response Enhancer) scheduler, which prioritizes interactive workloads over throughput, reducing latency in exactly the scenarios gaming and content creation demand.

On top of the CachyOS base, Nobara adds its own layer of patches. The current patch set includes:

• linux-surface.patch -- kernel support for Microsoft Surface laptops via the linux-surface project
• ROG-ALLY-NCT6775-PLATFORM.patch -- device quirk for the ASUS ROG Ally handheld
• ps-logitech-wheel.patch -- support for the PlayStation version of the Logitech G923 steering wheel
• amdgpu.ppfeaturemask-taint_warning.patch -- kernel taint warning when AMD GPU power controls are enabled
• valve-gamescope-framerate-control-fixups.patch -- fixes framerate control inside Gamescope
• ARM-specific patches for Ampere Altra systems

Earlier Nobara kernels also incorporated futex2, fsync, winesync, cherry-picked zen patches, OpenRGB, and AMD CPCC patches directly. Some of these have since been upstreamed into the Linux kernel or absorbed into the CachyOS base, which is partly why the migration to CachyOS's kernel made sense -- it reduced the maintenance surface while preserving the performance characteristics.

The kernel file naming convention reflects its origin. Nobara 41, for example, shipped Linux kernel 6.12.7-200.fsync.fc41.x86_64 -- the .fsync marker in the version string being a longstanding artifact of Nobara's kernel history, even as the actual patch set has evolved. For reference, at the time of Nobara 42's release in May 2025, Mesa shipped at version 25.1.0, the NVIDIA driver at 570.144, and the kernel at 6.14.6. Nobara 43 launched on the Fedora 43 base, which shipped with the Linux 6.17 kernel series.

What Gets Installed Out of the Box

Nobara fills the gap left by vanilla Fedora by offering a Fedora base with common extras included: OBS Studio with plugins, Steam, Wine dependencies, and video codecs. But listing individual packages undersells what is happening. The more precise way to describe it is that Nobara ships with a complete gaming and creator stack that would take a freshly installed Fedora system an hour and multiple reboots to replicate -- steps you can see outlined in our guide to optimizing Fedora for gaming with Steam, Lutris, and GPU drivers.

The included software stack covers:

• Steam (as a native RPM, not Flatpak) with Proton-GE accessible through the updater
• Wine dependencies -- the full set required by both Wine and Proton for compatibility with Windows applications
• OBS Studio with streaming plugins pre-configured
• GStreamer codec packages including H.264, H.265, and AV1 for hardware-accelerated video decoding and encoding
• Lutris as a native RPM, enabling GOG, Epic, and other non-Steam game libraries
• MangoHud for in-game performance overlay
• Gamescope for HDR and refresh rate management
• NVIDIA drivers (570.144 at Nobara 42 release) with a Wayland-patched build, or AMD's Mesa/ROCm stack depending on hardware

An important shift happened with Nobara 42. One notable change is the switch from using Flatpak versions of Steam and Lutris to native RPM packages. The developer says this improves performance and fixes various issues with controller input and filesystem access. This is not a minor cosmetic change. Flatpak sandboxing adds overhead and creates filesystem boundary problems -- a Steam game installed in a native RPM Steam instance has direct access to system libraries, which means better compatibility and lower latency for inputs and disk access.

falcond: Per-Game Automatic Optimization

The preinstalled software list covers the visible layer of what Nobara ships for gaming. There is a background service that does not show up in any launcher or desktop menu but that is doing meaningful work every time a game launches: falcond.

falcond is a system daemon that automatically detects when a game starts, applies a set of per-game optimizations, and reverses them when the game exits. It manages CPU scheduling policy, AMD 3D V-Cache allocation behavior, and SCX scheduler selection on a per-title basis. Rather than applying a single system-wide performance profile when gaming, falcond switches to a scheduler configuration specifically profiled for that game. The config file lives at /etc/falcond/config.conf and is generated automatically on first run. Game profiles are stored under /usr/share/falcond/profiles/ and can be overridden per-user without modifying system files.

An important precision point: falcond does not exclusively use scx_lavd. Per-game profiles specify which SCX scheduler to activate from a supported list: bpfland, lavd, rusty, and flash. Each has different characteristics. scx_lavd is the Latency-criticality Aware Virtual Deadline scheduler developed by Igalia under contract for Valve and optimized for gaming interactivity. scx_bpfland is a task-interactivity-aware scheduler that boosts interactive tasks based on sleep and wake patterns to keep desktop and game threads responsive. The profile format also accepts an scx_sched_props field that sets the scheduler's operating mode: default, gaming, power, latency, or server. A profile that selects bpfland with gaming mode is a different configuration than one that selects lavd with default mode -- falcond can target the right combination for each title. The vcache_mode field independently controls AMD 3D V-Cache thread affinity: cache pins game threads onto the CCD with the larger L3, while freq prioritizes the higher-clock CCD instead. These are separate tuning axes, each configurable per game.

For Steam games running under Proton, falcond includes a global Proton profile with broad coverage, applied automatically when no per-title profile exists. A system.conf file at /usr/share/falcond/system.conf lists Proton and Wine system processes (crash handlers, launchers) that should not trigger a game profile -- this prevents a crash handler from being misidentified as a game and receiving gaming CPU priority. The Nobara wiki maintains a profiles repository where community contributions can be submitted as pull requests, which means coverage expands over time without waiting for a distribution update.

Why scx_lavd Matters Beyond Gaming

scx_lavd was initially developed by Igalia under contract for Valve, specifically for the Steam Deck. Its design premise is that game threads are latency-critical and communication-heavy, and that conventional schedulers built for server throughput handle them poorly. The LAVD algorithm assigns each task a virtual deadline based on a measured latency-criticality score, so the most time-sensitive threads get CPU time first, consistently, without manual priority tuning.

What makes this unusual enough to be worth explaining in a Nobara article is what happened next. At the Linux Plumbers Conference in Tokyo in December 2025, Meta engineers presented findings titled "How do we make a Steam Deck scheduler work on large servers." Meta had deployed scx_lavd as a default fleet scheduler across large-scale production servers, finding that its per-LLC scheduling domains, load balancing across CCX boundaries, and core compaction behavior translated well to hyperscaler hardware. The presentation called it Meta's new default scheduler. A scheduler built for a handheld gaming console running Nobara's falcond daemon is also running Facebook's servers -- that is not a fact you find summarized anywhere, and it speaks to just how well-engineered the SCX framework underpinning Nobara's per-game optimization actually is.

On Nobara specifically, when falcond switches to scx_lavd for a game on an AMD CPU with 3D V-Cache (Ryzen 7800X3D, 9800X3D, etc.), two complementary optimizations activate simultaneously: scx_lavd's deadline-based scheduling ensures the GPU-feeding game thread gets CPU cycles immediately when it needs them, and falcond's V-Cache affinity logic pins those threads to the CCD with the larger L3 cache. The two work independently at the kernel level but are coordinated by falcond's profile, which is why per-game profiles matter -- the right combination depends on the game's thread behavior.

The Brave Browser Decision

Nobara 42 made a change that generated community discussion: it replaced Firefox with Brave as the default browser. The reason was technical, not philosophical. The Nobara project's official changelog documents the browser testing process directly: Firefox and Firefox-based browsers (including Floorp and LibreWolf) produced GPU crashes when scrolling live short-form video content -- YouTube Shorts, TikTok feeds -- with Variable Refresh Rate (VRR) enabled. The upstream Mesa bug report for this issue was filed at gitlab.freedesktop.org/mesa/mesa/-/issues/12528. Chromium and Vivaldi broke Google Meet when hardware acceleration was active. The Flatpak versions of those browsers were unaffected, but Nobara wanted a native browser. Brave was the only tested browser that held up under all scenarios and did not require external codec packages.

The Brave deployment in Nobara is not a vanilla Brave install. The Nobara team disables some of Brave's features at the administrative policy level. The official Nobara 42 changelog lists the exact policy settings shipped: BraveRewardsDisabled: true, BraveWalletDisabled: true, BraveVPNDisabled: 1, BraveAIChatEnabled: false, TorDisabled: true, and DnsOverHttpsMode: automatic. These are distributed as an administrative policy file, not user-level preferences, so they apply system-wide by default and are not silently re-enabled by a browser update.

This is a reasonable engineering response to a real bug. GPU crashes on scroll in a browser with VRR enabled is a genuine usability problem for a gaming-focused distribution. The bundled policy stripping out Brave's monetization layer addresses the obvious objection. Whether users prefer Firefox is a separate question -- the important thing is that the decision was made for documented technical reasons, not for partnership or revenue purposes.

Five Editions, One Project

Nobara ships in five distinct editions: Official (custom KDE), GNOME, KDE, Steam-HTPC, and Steam-Handheld. Each targets a different use case and form factor.

The Official edition is the reference build. It ships KDE Plasma with a custom Nobara theme -- rounded borders, a modified panel layout, and wallpapers specific to each release. This is the edition the developer uses daily and is the one with the fastest turnaround on fixes. For Nobara 43, this edition launched with KDE Plasma 6.4.5 on the Fedora 43 base; Plasma 6.6 was later pushed as an update through the Fedora 43 repos in February 2026 and flows to existing installs through the rolling update mechanism.

The GNOME edition runs a clean GNOME 49 with Nobara's underlying tweaks but without the visual customizations. It is the edition for users who prefer GNOME's workflow and do not want the KDE chrome. GNOME's Mutter compositor has received variable refresh rate patches in Nobara builds, which is a meaningful improvement for high-refresh-rate displays.

The KDE edition (distinct from Official) ships a closer-to-stock KDE Plasma experience without the Nobara-specific visual theming. This edition targets users who want KDE's flexibility without the opinionated defaults that the Official edition imposes.

The Steam-HTPC edition is one of the more interesting offerings in the gaming Linux space. It boots directly into a console-like interface tuned for TV navigation with a gamepad. It is positioned as an alternative to SteamOS for living room setups on arbitrary x86 hardware -- not just Valve-certified devices.

The Steam-Handheld edition targets the growing market of Windows-based handheld PCs: the ASUS ROG Ally, Lenovo Legion Go, and similar devices. It includes the ROG Ally platform patches in the kernel, the xpadneo Xbox Elite controller patch, and a compact desktop layout scaled for smaller screens. The Nobara Tweak Tool introduced in Nobara 41 can be used to manage auto-updates for HTPC/handheld systems and auto-updates for Decky Loader, a plugin framework for handheld gaming interfaces.

The Rolling Release Model

One of the significant architectural changes Nobara made in 2025 was the formal adoption of a rolling release model. Nobara 41 was the first release to receive rolling updates -- users on 41 began receiving Nobara 42 package updates via the system updater before the 42 ISO was officially published. Nobara 42, released May 13, 2025, was the first release developed entirely under the rolling model from the start. In the official changelog, GloriousEggroll confirmed it simply: "Nobara is officially rolling release now." The changelog is accessible from the Nobara Project site.

What rolling release means in Nobara's specific context is worth clarifying, because it is not the same as Arch Linux rolling release. Nobara is rolling within a major Fedora release cycle, but it does not automatically bump to new Fedora base releases without a user-initiated upgrade. The rolling behavior applies to the packages that Nobara maintains: the kernel, Mesa, NVIDIA drivers, Wine components, OBS, and other gaming and creator tools. These can receive updates outside of the monthly snapshot cadence when critical fixes or new capabilities warrant it.

The practical effect is that a Nobara user on version 42 will receive kernel updates, Mesa updates, and gaming stack updates continuously without waiting for a point release, but they will not automatically be migrated to Fedora 43's base packages. That migration happens through a separate upgrade process.

One thing worth understanding about how Nobara's update system works: running dnf update alone is not sufficient and is not recommended. The Nobara Updater application -- launchable as nobara-sync from a terminal, or via CLI with nobara-sync cli -- does more than install packages. It checks installed package versions against the upstream repository versions, syncs them to the correct state, and carries an auto-rollback mechanism that can revert packages that were pushed upstream and then removed or downgraded. This sync behavior matters because Nobara's custom package layer can conflict with packages a user has manually installed or overridden. The graphical updater handles that reconciliation; plain DNF does not.

# Always use nobara-sync, not plain dnf update
$ nobara-sync              # Opens the graphical updater
$ nobara-sync cli          # Runs the same update logic from the terminal

# nobara-sync handles: kernel, Mesa, NVIDIA drivers, gaming stack, and rollbacks
# plain dnf update misses Nobara-specific sync logic -- do not use it as the primary updater

# Ensure the updater itself is current before running (the underlying package is nobara-updater)
$ sudo dnf update nobara-updater --refresh --nogpgcheck --best -y

Driver Management Without the Terminal

One of Nobara's most practically useful features for its target audience is the Nobara Driver Manager. This graphical tool handles the detection and installation of GPU drivers without requiring any command-line interaction. For NVIDIA users, Nobara now defaults to using the open source driver, with a cuda-devel option being made available via the driver manager for those who need additional CUDA package support.

There is a hardware floor to be aware of. Nobara requires NVIDIA open driver support, which means the GPU must be Turing architecture or newer. That includes the GTX 16xx series (GTX 1630, 1650, 1660 and variants) and the entire RTX line from the RTX 20-series forward. Pascal (GTX 10-series, GTX 1080 Ti and older) and anything before it lacks the GSP firmware that the open driver requires and is not supported. If you are running older NVIDIA hardware, Nobara is not the right choice. The Nobara wiki maintains a full list of supported NVIDIA GPUs at wiki.nobaraproject.org.

On the display server side, Nobara made a complete break with X11 starting with version 41. X11 packages are not shipped, and X11 is not supported going forward. The entire desktop experience runs on Wayland. This aligns with the direction of the broader Linux ecosystem -- GNOME removed its X11 backend entirely in late 2025 -- and it is what allows Nobara to support VRR, Gamescope HDR, and the NVIDIA Wayland improvements that the patched driver provides. Users who depend on X11-only workflows or legacy applications without XWayland compatibility should account for this before installing.

The Driver Manager also extends beyond GPUs. It provides:

• asusctl for ASUS laptop power and fan profiles
• xpadneo as a kernel-level patch for Xbox Elite and Xbox Elite v2 controllers over Bluetooth
• Broadcom wireless drivers for hardware that requires proprietary firmware
• AMD ROCm packages from upstream Fedora for GPU compute workloads

The Nobara Updater -- the graphical package manager -- has also gained the ability to install RPM files by double-clicking them, which eliminates a common friction point for users coming from Windows who expect GUI-driven software installation. It also detects whether HTPC packages are installed and automatically disables the GRUB boot timeout for a cleaner, console-like boot experience.

Security Posture: What Nobara Does and Does Not Do

Nobara makes a deliberate departure from Fedora's security defaults at the mandatory access control layer. Rather than keeping Fedora's SELinux in Enforcing mode, Nobara has swapped SELinux out entirely in favor of AppArmor -- the same MAC system used by Ubuntu and openSUSE. The Nobara project documents this decision directly, describing AppArmor as more user-friendly, less intrusive, and easier to manage and write policies for. Some SELinux packages remain installed to preserve Fedora package compatibility and avoid broken dependencies, but SELinux itself is disabled. Firewalld is installed and active. PipeWire handles audio, which among other benefits reduces the attack surface compared to the older PulseAudio/JACK split.

Where Nobara diverges from Fedora's security stance extends beyond the MAC layer. On Secure Boot and kernel signing: because the custom kernel is built and hosted on COPR rather than through Red Hat's build infrastructure, it cannot carry the signed shim required for UEFI Secure Boot. The project's FAQ is direct: they have no plans to pursue the shim signing requirements. This is not a decision that affects day-to-day security for desktop users on private hardware, but it is worth understanding for users in environments where Secure Boot enforcement matters.

The NVIDIA driver situation is also relevant from a security standpoint. Nobara ships a patched NVIDIA build that includes Wayland support and latency improvements not yet in the official release. Patched proprietary drivers are harder to audit than upstream releases. The tradeoff is better Wayland compatibility versus a non-standard binary running in kernel space.

Nobara vs. the Alternatives

The gaming-focused Linux distribution space has grown significantly. Bazzite, CachyOS, and the Steam Deck's SteamOS are all relevant alternatives. Each makes different tradeoffs.

Bazzite is image-based, using OSTree to deliver atomic, immutable system updates. This makes it extremely resilient to breakage -- a bad update can be rolled back by booting the previous image. The cost is a more constrained package management model. Nobara, by contrast, is a traditional mutable system that behaves like Fedora: packages install directly to the running filesystem, which gives more flexibility but also more opportunity for users to break things.

CachyOS is Arch-based and uses the same BORE-scheduled kernel that Nobara has migrated to. CachyOS targets users comfortable with Arch's rolling nature and pacman. Nobara targets Fedora's ecosystem and DNF, which means a different package availability profile and different system management conventions.

SteamOS is Valve's own Arch-based gaming OS, primarily designed for the Steam Deck. On third-party handheld hardware, Nobara's Steam-Handheld edition is often a better fit because it carries device-specific kernel patches (ROG Ally, Legion Go) that SteamOS does not include in its mainline builds.

Nobara aims to work well right away, without the user needing to troubleshoot hardware or hunt down packages. It's not the only distro that takes this approach -- Linux Mint or Pop!_OS offer similar plug-and-play experiences -- but Nobara focuses more on gaming and multimedia out of the box. The key differentiator is the patched kernel. Bazzite, Mint, and Pop!_OS do not ship a kernel with BORE scheduling, fsync, and device-specific handheld patches by default.

What About Windows?

The distro comparisons above matter for Linux users who are already decided on switching. But for someone evaluating whether to switch at all, the relevant question is how Nobara compares to Windows, not how it compares to Bazzite.

The honest answer in 2026 is that the gap is much smaller than it used to be and runs in both directions depending on the title. Independent testing has found games and hardware combinations where Nobara delivers single-digit to low-double-digit percentage gains in average frame rates and 1% lows compared to Windows 11. The BORE scheduler's preference for interactive workloads, the lower system overhead of a lean Fedora-based desktop versus Windows' background service stack, and the fsync patches in the kernel all contribute to a latency profile that in many games translates to perceptibly smoother frame pacing -- even when the average frame rate is similar.

Windows retains real advantages in specific areas. Titles that use vendor-specific DirectX optimizations, games that ship with Windows-exclusive features not yet replicated in DXVK or VKD3D-Proton, and applications that depend on Windows system APIs without Wine equivalents all run better or exclusively on Windows. Frame generation via DLSS 4 and FSR 4, for example, has had uneven Proton support depending on the title and implementation. The gap is narrowing, but it is not gone.

The practical framing for someone on the fence: if 90 percent or more of your Steam library shows Platinum or Gold ratings on ProtonDB, and none of your regular titles use kernel-level anti-cheat, the performance tradeoff of switching to Nobara is minimal and potentially favorable. If your regular rotation includes Valorant, Call of Duty, or any title with a Vanguard-equivalent anti-cheat, Windows remains the only option for those specific games.

The Installer and First Boot

Nobara uses Calamares as its installer, but not the default upstream Calamares build. Nobara's Calamares implementation has been rebased on KaOS's fork to take advantage of on-screen keyboard functionality and other features. The KaOS fork adds improved touch support and a more polished hardware detection flow, which matters for handheld installations where keyboard input may be limited.

A notable installation quirk: the network check has been eliminated, enabling the installation of Nobara offline from any downloaded ISO. Standard Fedora's Anaconda installer requires internet connectivity during installation for certain package resolution steps. Nobara's Calamares-based installer bundles everything needed for a complete installation in the ISO itself, which is more reliable for users on slow or metered connections.

On first boot, the Nobara Welcome application runs automatically. This is where users select codec installation, configure GPU drivers, choose a desktop layout preset (several mimic Windows 10/11 or macOS panel arrangements), and run initial system updates. Crucially, the Welcome app handles NVIDIA driver installation through a graphical flow rather than requiring terminal commands -- the most common post-install task for new Linux gaming users.

The Maintenance Reality

Nobara is, at its core, a single-maintainer project. Thomas Crider does most of the substantive work: kernel patching, package maintenance, driver testing, and release management. Community members contribute testing, bug reports, and occasional patches, but the bus factor is real. In a 2022 Boiling Steam interview Crider noted that a contributor known as Jan (sentry) handled regular kernel maintenance during the early phase while Crider managed everything else -- a division of labor that reflects how the project operated before it grew to its current scope. Nobara's January 2026 participation in the Open Gaming Collective has since provided a collaborative review path for kernel patches and input tooling -- covered in its own section below.

Crider has addressed the project's long-term continuity directly in the FAQ, stating that the project will continue for as long as he is alive and using Linux. The intent is clear, even if the guarantee is informal.

This is both reassuring and clarifying. The project will continue as long as Crider has interest and capacity. There is no foundation, no governance board, no organizational continuity independent of the developer. For a personal desktop OS, that is a perfectly acceptable arrangement. For anything that needs guaranteed long-term support, it is a reason to look elsewhere.

The snapshot-based repo model also has implications for update timing. New Fedora packages reach Nobara users on a monthly cycle by default, except for Nobara's own maintained packages (kernel, Mesa, driver components), which are updated more frequently. In general, Crider waits about two weeks after a major Fedora release for any release bugs to be ironed out, then adds the time required to convert Nobara packages to the new version, meaning users can expect about a month delay relative to upstream Fedora on major version bumps.

The Open Gaming Collective

On January 29, 2026, Universal Blue -- the team behind Bazzite -- announced the formation of the Open Gaming Collective (OGC), a collaborative initiative aimed at reducing fragmented development across the Linux gaming ecosystem. Nobara joined the collective as a strategic partner alongside founding members Bazzite, PikaOS, ASUS Linux, ShadowBlip, and Fyra Labs, with ChimeraOS and Playtron also participating as strategic partners.

The OGC's stated technical focus is on the foundational layers of the Linux gaming stack: shared kernel patches, the InputPlumber input remapper daemon (already in use across SteamOS, ChimeraOS, Nobara, Playtron, and others), Gamescope, hardware drivers, and display tooling including Mesa, Vulkan, and Wayland components. The collective operates under a "Lazy Consensus" governance model -- proposals are published publicly and given 72 hours for community objections before moving forward -- and an "Upstream First" policy requiring that any code produced or improved by OGC be submitted to the original upstream project rather than living indefinitely as a downstream patch.

For Nobara specifically, the OGC membership means that kernel patches Crider has historically maintained solo now have a collaborative review path. The plan outlined at launch calls for Nobara to adopt the OGC shared kernel and contribute its patches to the collective for upstream review. This addresses one of the long-standing legitimate criticisms of the project -- that a single-maintainer custom kernel is a structural fragility -- by situating Nobara's kernel work within a broader, multi-project process. The "Upstream First" commitment also means that hardware enablement work (device quirks for the ROG Ally, Surface, and similar hardware) has a clearer path to eventual mainline inclusion rather than remaining permanently in Nobara's private COPR patch set.

Nobara 43: The Current Release

Nobara 43 was initially released on December 27, 2025, with ISO respins continuing through early 2026. The project's active respin cadence means updated images are published frequently -- in the case of Nobara 43, fresh ISOs dated 2026-03-28 are the current download across all editions: Official, GNOME, KDE, Steam-HTPC, and Steam-Handheld, with corresponding NVIDIA pre-installed variants for the first four. The Fedora 43 foundation under these images shipped with the Linux 6.17 kernel series, GCC 15.2, glibc 2.42, and GNOME 49 for the GNOME edition. For the KDE and Official editions, Fedora 43 shipped with KDE Plasma 6.4.5 at release; Plasma 6.6.0 was pushed to Fedora 43 as an update in February 2026 and is present in current Nobara 43 installs. Python 3.14 and LLVM 21 are part of the Fedora 43 toolchain base. Because Nobara is rolling within the Fedora 43 cycle, the kernel version on a running install will be newer than the ISO's initial kernel as rolling updates are applied via nobara-sync.

Nobara 43 continues shipping with the CachyOS-based kernel with Nobara-specific device patches layered on top. The five-edition model is maintained, and the rolling release infrastructure introduced with Nobara 42 means that post-release updates to the kernel and graphics stack flow to existing Nobara 43 installs without a full reinstallation.

Dual-Booting Nobara Alongside Windows

A significant portion of Nobara's target audience is not replacing Windows outright but running both systems side by side. Gaming on Linux has come far, but some users still need Windows for specific titles, productivity software, or hardware that has no Linux driver. Dual-booting Nobara with Windows 10 or 11 works, but there are concrete steps and hazards worth knowing before touching a partition table.

The order of installation matters. Windows should already be installed before Nobara is added. Installing Nobara first and then Windows afterward will cause the Windows installer to overwrite the bootloader, leaving Nobara inaccessible until GRUB is manually restored. The correct path is: install Windows, shrink the Windows partition using Windows Disk Management to free space, then install Nobara into that unallocated space. Nobara's Calamares installer will install GRUB and, in most cases, automatically detect the Windows boot entry and add it to the boot menu.

There is one pre-flight requirement that catches people coming from systems that shipped with Windows pre-installed: BitLocker. If Windows is encrypted with BitLocker -- which is enabled by default on many OEM machines running Windows 11 -- disabling Secure Boot (required for Nobara) will trigger a BitLocker recovery key prompt on the next Windows boot. Users who do not have that recovery key stored somewhere will be locked out of their Windows installation. The procedure is: save the BitLocker recovery key first, then disable Secure Boot, then install Nobara. Alternatively, decrypting the Windows drive entirely before starting removes this risk.

After installation, GRUB serves as the bootloader for both systems. One practical issue: Windows Update can occasionally reset the UEFI boot order so that Windows boots directly, bypassing GRUB. If the Nobara boot entry disappears after a Windows update, the fix is entering BIOS/UEFI firmware settings and manually setting the GRUB entry back as the first boot device. This is a known behavior with dual-boot on UEFI systems and is not specific to Nobara.

For users who want to share files between Windows and Nobara, creating a shared NTFS or exFAT partition works well. Both formats are fully supported in Linux. NTFS in particular reads and writes reliably under the modern kernel's ntfs3 driver, making it a practical shared data partition for game saves, documents, or media that both systems need to access.

Upgrading Between Major Nobara Versions

The rolling release model introduced with Nobara 42 handles kernel, Mesa, driver, and gaming stack updates automatically through nobara-sync. What it does not handle automatically is upgrading from one major Fedora base to the next -- for example, moving from a Nobara 42 (Fedora 42 base) installation to Nobara 43 (Fedora 43 base). That is a separate process, and one the article so far has not addressed directly.

Major version upgrades in Nobara do not follow the standard Fedora dnf system-upgrade path. The Nobara wiki explicitly warns against using dnf system-upgrade download and dnf system-upgrade reboot, noting that this method has been found to fail on non-standard hardware such as Surface devices and MacBooks because it relies on a transient install environment that may not boot correctly. The correct procedure works through the Nobara updater itself after manually syncing the repository files to the new release.

The high-level sequence for a major version upgrade is:

# Step 1: Update repo and GPG key packages against the new release repos
$ sudo dnf update -y nobara-repos nobara-gpg-keys fedora-repos fedora-gpg-keys \
    rpmfusion-free-release rpmfusion-nonfree-release nobara-updater --nogpgcheck

# Step 2: Remove packages that are incompatible with the new release
# (X11 packages, legacy ROCm, and deprecated OBS/kernel packages)
$ sudo dnf remove plasma-workspace-x11 kwin-x11 rocm* obs-cef \
    obs-studio-plugin-webkitgtk kernel-uki-virt

# Step 3: Update the kernel package first
$ sudo dnf update kernel -y --refresh

# Step 4: Run the Nobara System Updater to apply quirks and complete the upgrade
$ nobara-sync cli

# Step 5: After reboot, run the updater once more to clean up deprecated packages
$ nobara-sync cli

There are important caveats. Repository files for the new release version must be in place before the package update step -- these are normally distributed as part of the nobara-repos package update, but the official wiki also documents the exact repo file contents for manual editing if needed. Nobara's own modified packages must be ready for the target release before the upgrade path works reliably. The project's general guidance is to wait until Nobara officially announces that the new version is available -- typically about a month after the corresponding Fedora release -- before attempting an in-place upgrade. The project's Discord is the fastest way to know when the upgrade path is ready.

Users who prefer a clean slate over an in-place upgrade can always reinstall from the latest ISO. Because Nobara's rolling release model keeps the gaming stack current within a major version, there is rarely a compelling reason to reinstall mid-cycle. The main reason to reinstall would be moving to a new Fedora base before Nobara officially supports the in-place upgrade path, or recovering from a system in an inconsistent state.

Anti-Cheat: The Honest State of Play

The question that matters most to a large portion of Nobara's potential user base is not which kernel scheduler it uses -- it is whether the games they actually play will work. For competitive multiplayer titles, that comes down to anti-cheat software. Easy Anti-Cheat (EAC) and BattlEye are the two dominant systems, and their Linux compatibility status is the deciding factor for many users.

The current situation is meaningfully better than it was a few years ago, but it is not a blanket yes. Valve worked directly with both EAC and BattlEye to enable their runtimes to run under Proton. Games that use EAC or BattlEye and have opted into the Linux/Proton runtime through their respective developer portals work on Nobara. Games that use EAC or BattlEye but have not opted in do not -- the anti-cheat will block launch or kick the player from servers. Whether a specific game is supported is a per-title decision by the game's developer, not a Nobara or Proton limitation.

The practical tools for checking compatibility before committing are:

• ProtonDB (protondb.com) -- community-reported compatibility ratings, sortable by game title. Reports note whether anti-cheat blocks the title on Linux.
• Are We Anti-Cheat Yet? (areweanticheatyet.com) -- a community-maintained database specifically tracking anti-cheat status for individual games. It categorizes each title as Supported, Running, Planned, Broken, or Denied.

Nobara's kernel patches are relevant here. The fsync and futex2 patches that ship in Nobara's kernel reduce CPU overhead for the NT synchronization primitives that Windows games use, which helps with performance in titles that do run. They do not bypass or circumvent anti-cheat systems -- that framing is both technically inaccurate and a good way to get a ban. What the patches do is make the compatibility layer more efficient, so games that are permitted to run under Proton run better.

Community, Support, and Staying Current

Nobara is a hobby project maintained primarily by one developer, but it has a sizable and active community that fills in the support gap that no formal SLA can provide. Knowing where to go when something breaks -- or before committing to an install -- is worth documenting.

The Nobara Discord is the primary community hub and the fastest channel for support. It is where Crider posts update announcements, where release windows for new major versions get communicated, and where the community troubleshoots hardware-specific issues. The link is available from the official project site at nobaraproject.org.

The Nobara Project Wiki at wiki.nobaraproject.org carries the authoritative FAQ, the new user guide, the supported NVIDIA GPU list, and first-steps documentation. It is the first place to check before posting a support question.

The GitHub repository at github.com/Nobara-Project is where bugs should be filed and where patch contributions can be submitted. Kernel patch requests -- for device quirks that are not yet in Nobara's patch set -- are fielded here.

For users who want to support the project financially, Nobara accepts contributions through Patreon and Ko-fi, both linked from the official site. The project also runs a merchandise store. These are not trivial considerations: maintaining a custom kernel, multiple editions, and a responsive update cadence as a solo developer is a significant time commitment, and the community's financial support directly affects the project's sustainability.

For context on Nobara's January 2026 Open Gaming Collective membership and what it means for the long-term sustainability of the project's kernel work, see the Open Gaming Collective section above.

Who Should Run Nobara

Nobara occupies a specific and well-defined position in the Linux ecosystem. It is the right choice if you want a Fedora-based system that is configured for gaming and content creation with minimal setup, on hardware that benefits from device-specific kernel patches, and you are comfortable with the tradeoffs of a hobby-maintained single-developer distribution.

It is not the right choice if you need Secure Boot, require long-term support guarantees, run the system on production infrastructure, or are new enough to Linux that you cannot recover from an update that temporarily breaks something. The project documents this clearly and consistently -- the honest scope management is one of Nobara's genuine strengths as a project.

The technical substance is real. A patched kernel with BORE scheduling, device quirks for the ROG Ally and Surface hardware, Gamescope HDR fixes, and a complete gaming stack on a solid Fedora base is genuinely useful. The former Red Hat engineer who built Proton-GE built this distribution, and that provenance shows in the specific choices that have been made. The January 2026 Open Gaming Collective membership adds a collaborative dimension to the kernel work that addresses the project's long-standing single-maintainer fragility at the most critical layer.

Crider has been direct about why Fedora ended up as Nobara's base. In an early Boiling Steam interview he described the founding frustration: he grew tired of reinstalling Fedora and repeating the same growing list of fixes, configuration changes, and repository additions every time. He had been on Fedora since joining Red Hat in 2018 and came to rely on it as a daily driver -- a fact he confirmed in a Linux Gaming Central interview:

That daily driver mentality is what makes Nobara coherent. It is not a distro designed to win benchmarks or attract enterprise contracts. It is a system one engineer uses every day, refined over three years to eliminate the friction that Fedora's upstream purity intentionally preserves. For the audience it targets, that is exactly what is needed.