Bazzite 42 is now available!

Bazzite
,
1

image
image1920Ă—1050 157 KB

Bazzite 42 releases today alongside Fedora 42, bringing BETA support for the MSI Claw handhelds, improved HDR support under both GNOME and KDE, and various improvements throughout the project!

HDR Support

As of GNOME 48 HDR support is now generally available. KDE Plasma 6.3.4 has also made numerous improvements to their HDR support! If you want to try it out on the desktop you can either use a version of Wine with Wine Wayland built in, or enable the HDR support for existing releases of proton thanks to vk_hdr_layer, which we’ve preinstalled for you.

Improved HTPC support

Thanks to work by Glorious Eggroll (my hero <3), Bazzite now has a patch for Steam’s audio output resetting behavior. For people that don’t speak nerd, this means you can change your audio output options on your HTPC and expect them to stay where you set them when you enter gaming mode. Wow!

New Bazzite-DX Website

Building on our earlier announcement of developer editions of Bazzite desktop, Bazzite-DX now has a new website you can check out while we build it out. You can check it out here.

Growth

We pride ourselves on showing any numbers we have, the charts below are just a snapshot of the constantly updated one we keep on our website.

image
image1826Ă—1077 76.1 KB

image
image1697Ă—1159 124 KB

Overall it’s been a great year for Universal Blue and for the Bazzite project. We’re really looking forward to where things go from here!

Future Stuff

Our team is working with the folks at Fyra Labs (Ultramarine Linux) on a new Live ISO experience that may come to Bazzite in the future and a new Flatpak store is on the way to replace the aging Discover/Software thanks to Glorious Eggroll. Additionally, Yafti is being replaced with a modern and better first-run installer as soon as possible, and we’ll continue to work on expanding to new handhelds. As always if you want to come join us everything here is built in GitHub. We’d love the additional support!

Full release notes

The automatically generated changelog for this release can be seen here.

Update Notice

If you are having any issues updating, be sure to try the “System Update” app available in the desktop applications list:

image
image202Ă—184 11.8 KB

And if that still doesn’t work, post the full output of that application in any of our help sections. You can also try removing any applications you’ve layered with rpm-ostree reset prior to updating.

As always, if you find that you’d rather stay on Bazzite 41 for the time being you can roll back with rpm-ostree rollback.

16 Likes
3

Is there no GTS channel for Bazzite? Also, does Bazzite 42 has the same /nix issue as in Bluefin 42?

4

You will find that with the latest version of bootc that it is impossible to use Nix installer. You won’t find any support for it at Universal Blue. Prior to this state of affairs we didn’t support it due to it breaking SELinux.

GTS is specifically a Bluefin concept, being a gaming distro we really only have any interest in the latest and greatest. Bazzite 41 is abandonware and will receive no further updates of any kind.

3 Likes
5

What is not working for the Claw devices? They are relatively cheap… Was pondering about getting one.

6

I see. I guess I’ll just focus on my image builder and baking everything in there and a distrobox installer. Is there any alternatives/recommendations for config files and various files backup and management a la home-manager that works on ublue? I manage everything with Nix, including default folder links and such.

7

I’m so happy, I don’t even have to pay attention to upgrades and when and where they are happening - which is great in stressful times.

I just ran a system update this morning and then when I rebooted later, I was “magically” on Fedora 42. It’s fantastic. I’m so grateful for these images, thank you all for your great work.

6 Likes
8

No VRR in Bazzite 42

Any info if this is going to be changed?

9

Chezmoi is really great.

1 Like
10

Intel drivers are not there yet. The performance is not where it should be, and without proper compositing you don’t get night light and the steam overlay is very slow. There are also periodic audio issues in games.

There’s a reason they are cheap. But hey, great project idea in any case.

1 Like
11

though warning: this rollback has issues. Can’t rollback from F42 builds to F41 builds if you have a problem.

1 Like
12

I didn’t even manually run a system update. I just noticed yesterday that GRUB showed the OS as Bazzite 42. The update was so seamless I wouldn’t have known otherwise.

13

What’s this about replacing Discover? Is this replacement coming from upstream, or is this new software center its own thing?

14

It’s by GloriousEggroll, so nothing to do with KDE Plasma or GNOME.

Here is the repo:

15

So the bottom line here is that nix and the tools that depend on it (e.g. devenv.sh, devbox, flox, etc) won’t work on bazzite-dx or any other -dx variant of ublue, going forward? That sucks, I gotta say. Linux homebrew often falls flat on its face for me, especially compared to nix:

  • Only 7600 packages vs nixpkg’s 120K packages, homebrew is often faster at integrating updated packages, though.
  • No plugin/extensions community to speak of
  • No container integration, especially container image building
  • Can’t install multiple versions of a package easily which forces separate environment managers like uv, rvm, etc, - You can skip all that stuff with nix.
  • No ability to create customized shells, etc).
  • Weak support for CI systems (hard to get high levels of build reproducibility), and weaker support for github actions.

I guess the recommended path is to run a distrobox to do day to day development if we need something which isn’t in homebrew like nix? Which I guess begs the question of why even have -dx variants of bazzite/bluefin if the base version tooling is so constrained that you can’t make it usable for modern dev workflows people need to actually use? Just make everything be in separate containers and save all the disk space in the main image…

(As an aside, it was this precise issue that made me question the usefulness of bazzite-gdx version - what are the odds that the bundled tools will actually match any non-hobbyist’s gamedev workflow, and what do they do about it when they can’t make the base image work for them? Guess they have to run a distrobox and reinstall all those tools again and maintain some of them in both places)

16

The -dx pattern is documented here but not yet included in the bazzite docs. It does not include nix because the rest of us don’t have the problems that you are describing.

This is exactly what you should be doing, putting your stuff in containers.

1 Like
17

Which I guess begs the question of why even have -dx variants of bazzite/bluefin if the base version tooling is so constrained that you can’t make it usable for modern dev workflows people need to actually use?

I had the same concern about using distroboxen at first too. I guess we all do.

But in practice, it just isn’t that hard. It is a mental shift though.

I had to accept that with a container first development environment that I really do want the host OS to be as light as is practical and use the features of containers where I need to install multiple versions of complex tool chains, etc. And that forces my dev environment to look and behave more like production. If I am developing in a container, and testing in a container then deploying to a prod container is more straight-forward; meaning less variables introduced during deployment because dev and prod are deployed the same way.

And to be honest, if I were using nix I would use it in a carefully designed distrobox. Because I do not want to be doing all that compiling and installing on my purposely light host OS. When I move to another project that is using go instead of zig, web assembly, react, etc. - I would just blow the distrobox away and create a new one to reclaim the disk space. It is so much easier to work that way compared to keeping all the cruft around forever.

Personally I absolutely love the -dx variant I use. After making the mental leap I find that this is what I have been wanting since I deployed my first app using docker compose ~2005-06.

Be a little patient with yourself (and us please). I empathize with what you are going through. I have made that same journey myself.

3 Likes
18

VRR should be fixed as of last nights build.

1 Like
19

Can’t say I like having another GTK program on my Plasma install, but it says it doesn’t require GNOME dependencies. So I guess I can’t complain.

20

Thanks, Jorge, I get the containers-first model of dx, and I support it. I’ve been using containers for development since well before I started using bluefin-dx. But I just don’t understand the purpose of all the dx stuff installed in the base image. For bluefin-dx, this includes an additional 60+ packages, some of which seem a bit niche to me. How many developers actually need/use the android dev tools, and why can’t they live in a container if they do need them? Why do we preinstall docker, podman, AND incus? Why do we have devbox, distrobox, toolbox and virt-manager all available by default? Why isn’t cockpit running in their flatpak or container image? Why do things like nerd fonts not get installed per user, given that multi-user machines are not at all the common use case for bluefin/bazzite? etc etc etc.. Is the intent to remove as many packages from the base image as technically possible, or are the rules more complicated than that?

I’d also like to understand who are the “rest of us” developers you are targeting with the base -dx tools? People who work at small startups with a single product? Hobbyists? Open source developers on small projects? I’m not really getting which developers it is supposed to be optimized for, and right now I have a hard time seeing the base environment handling anyone’s needs well on its own.

2 Likes