Bazzite 42 is now available!

(Oops I edited your post instead of replying, sorry for the confusion).

Lots of it is historical, you’d have to look through the github history. For android I would say that the people use need android tools asked for it so we added it. We hashed most of this out in the early days of the project and we’re long past GA now so unless something is broken we tend to not change things.

Why wouldn’t we? Everyone’s using docker, we depend on podman for all our tooling, and members of the core team use Incus every day. They’re just container runtimes.

Because they are useful tools. Devbox and virt-manager have been moved to flatpak. I don’t use toolbx but we have contributors who work at Red Hat who need it. You don’t lose anything by it sitting on disk, you can happily ignore it.

Not sure, it’s not a thing I think about often. :smiley:

Because this doesn’t matter? If you want it to be per user send a pull request with the rationale.

When possible we like to have as many things in Flatpaks where we can. We don’t solve for package number, we solve for meeting our documented use cases. If we need a tool we add it, if we don’t, we don’t.

Our target audience is cloud native developers, this is reflected in our tooling choices (we skew heavily towards CNCF tech). This is a general -dx thing though, Bazzite is free to make it’s own choices/decisions but this is the common layer that all our images derive from.

1 Like

It certainly is fixed! Thanks!

1 Like

All of the above and more. I’m a Linux engineer at Microsoft working on numerous other distros and this toolset covers everything I need to do. I was also previously a professional game developer and an e-commerce full stack engineer, all of which I’m leveraging as we build out DX and GDX.

3 Likes

Interesting. So what kinds of projects do you build on your main bazzite-dx image? C/C++? Python? JS? And why do you do so on your main image instead of doing so in a container (devcontainer, distrobox, etc)?

On my end, now that I’m retired, I tend to bounce around between projects. Use Rust for my personal project, Python for AI stuff, C/C++ for various older open source projects, Ruby and/or Node for web apps, etc. So flexibility and repeatability is key.

Oh, as an aside, the Determinate Systems nix installer does install SELinux policies for nix. Which isn’t to say it won’t have other problems on Fedora 42…

https://determinate.systems/nix-installer/

Wow that sounds familiar. I am in the same boat. I have used somewhere around 40 languages in my career. And am involved in a lot more FOSS projects now. And since I have the skills I am not afraid to bounce between languages / tool chains.

Using distroboxen and devcontainers makes that easier - in my opinion.

This is precisely my motivation for using container-based tech for enabling my workflows.

I can tear down a distrobox, reclaim the space it is taking and create a new one in minutes (with the tools I have created for myself).

I do share your thoughts about so much being on the bootable image. It was quite confusing at first because it got in the way of me making the mental transition. Until two things happened …

  • I came to the realization that much of the stuff was there to support building, operating and maintaining the image. A small percentage is historical as @j0rge mentioned or just needs to be close to the metal in order to function

I concluded that I just needed to ignore its presence.

For example, python3.13 is installed, but not all of stdlib because Fedora has broken it up into separate packages. During a conversation with one of the maintainers, it was explained that python was needed for part of their installation tooling but that they were looking for alternatives.

So if I want a python install for which I can rely upon and over which I have control I should either build it from source (and install it in my home dir) or install it in a distrobox. I use a mixture of those (currently building 3.14 while it is in alpha - it is built in a distrobox for that purpose and then the distrobox is immediately torn down).

I bet you will find that we (technical part of the community) are all thinking along those same lines. But reality is getting in the way … for now.

  • enough in the bootable container image for it to operate and be maintained
  • enough in the image to enhance adoption / reduce the on ramp length for new users
  • but as minimalistic as practical

Nonetheless, thanks for speaking up!

3 Likes

Some great points here, thank you!

Now that I have more time to post I can add more color to this. So basically we looked at, what does a cloud developer need?

Since Brian Ketelsen was one of the architects of DX we basically just literally copied his set up and decided “ok if someone were to get started in cloud native what do they need?”

Ok so bottom up, container runtimes. Podman is a critical component so it has to be there. Docker has to be there, one of the primary reasons is you should be able to copy and paste install instructions from existing READMEs on GitHub without needing to do anything special. We don’t want a “And on fedora atomic/bluefin systems do this” because people hate that.

Every single time I’ve copied and pasted a docker command from all the TONs of stuff on github it has worked fine on Bluefin. That’s a huge feature for us.

It’s also part of the reason for Homebrew, which does cause gnashing of teeth. I get it, we have gcc on the image just for this. Some day an ancient UNIX god will reawaken to claim my soul. It’s also the number one feature people tell me about in the survey and in real life. The fact is, so many Linux sysadmins use Mac and they are highly skilled people, the kind of people we need around here. So I cater to them with homebrew. And it’s also good, I always have the latest version of every command line tool I care about, and it’s automatic. Just about every cool tool I see trending on hackernews is already in homebrew and at the latest upstream version. This is a solved problem for me.

For the developer warts of homebrew, I agree, that’s why we strongly invest in devcontainers and just decoupling the entire thing from the OS.

Here is the top half of the page of tags from the official docker python container.

Like, done. My python needs are done. These things have over a billion pulls and lots of people use them. At the end of the day, I wanna use the thing that most people use. I want to be on the well trodden path.

On this previous point from the earlier in the convo:

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.

I do not see the need to install multiple versions of a package on the same system because that’s an antipattern here. We use containers and tools like uv. Whatever works for you. The reality of the world is that people specialize in separate ecosystems and those ecosystems will have package managers.

And those ecosystems will have specialists, and they are the ones creating the tools I need. So when they say to use pip, I use pip. When they say use brew, I use brew. Python people are loving uv right now. And the things people use get tested the most. And on top of that these ecosystems are taking those same base images I showed above and making more specialized things on top of that.

One magical meta language to wrap that up just doesn’t line up with that world view, and it takes about 20 minutes for someone to make a bluenix with the image template so for us it’s more a matter of what we want our product to be. Also supporting nix turned our support structures into L1 nix support and we’re not willing to do that, we have our direction and mission set.

But to get back to the point (finally lol!) we provide a flexible system. I spent the first 2 years trying to get my distro packages just perfect with distrobox only to find later that I don’t ever want distro packages for my command line tools. I want the latest (like all my mac friends have) so now I roll with homebrew and I’m set. A python developer who doesn’t care about containers can also just use vscode with uv or poetry or whatever and be totally happy.

A Jetbrains user can install its toolbox and it comes with a copy of everything under the sun if you ask for it. And so on. Traditionalists can use distrobox, and the people who want to dnf install nodejs on their OS will just never be happy here, so we don’t cater to that. Traditional distros will continue to exist for those folks.

The font thing is easy. We love fonts, but we don’t love setting up all this stuff, so for a developer experience feature we spent space on curated, high quality monospace fonts that the team loves.

People are going to complain about “bloat” for what amounts to like 2% of a modern disk for an entire OS. If we’re going to stare at our screens all day we might as well be happy. That’s an easy decision, and also another one of the things people tell me they love about Bluefin.

I mostly concentrate on the happiness of our core audience because many of our decisions were already made, which is why I started interviewing and writing down all the feedback for Bluefin way before we actually started. But it also evolves. uv wasn’t around when we started, and developers move fast. So we can always adapt as needed over time.

6 Likes

Nothing, that would be missing the point.

Re: the Bazzite project preferring flatpaks, but (most?) flatpaks don’t work with SELinux:

“SEC: Flatpak Chrome, Chromium, and Firefox run without SELinux confinement?”
SEC: Flatpak Chrome, Chromium, and Firefox run without SELinux confinement? - Fedora Discussion.

  • RPM package Firefox runs firefox as an SELinux confined process; and there’s -A/--apply-live to upgrade the browser without rebooting
  • Flatpak Firefox, Chrome, and Chromium processes run as unconfined; Flatpaks bypass SELinux: ps -Z

Perhaps Flatpaks’ /app/bin directories should be conditionally blessed with SELinux extended attribute labels at install time?

“SELinux on NixOS” SELinux on NixOS | Hacker News.

Hello I’ve been wondering, if you guys have an image of bazzite like barebones without the much added flatpaks and stuff. I’ve been having a hard time to recreate stuff that bazzite did like the custom kernel and many other optimization using the image template, and i was looking for better approach maybe you guys could provide an image that has the custom kernel and optimization (without the customization?) and other flatpak aside from the default that comes with the base image. Thank you

Sorry for my bad english

This thread is full of falsehoods proven incorrect by actual Firefox developers. The flatpak sandbox and firefox’s own process isolation are sufficient. Claiming Firefox not using zypak is an issue is like claiming my electric toothbrush not being able to use the turbocharger from my Audi is an issue.

Any changes to SELinux are firmly in Fedora’s court and not something Universal Blue would tackle.

Flatpaks are installed by the ISO and not part of the image, you can remove any RPMs you want in your custom image and generate an ISO with any Flatpaks you want.

1 Like

Thank you for the clarification

hi there, I’ve been using a bazzite derivative for both dev and gaming for a while and I really appreciate all the work you’ve been doing. Thank you for creating a rock-solid Linux experience!

I wanted to mention a couple of things about Nix and homebrew.

Homebrew isn’t great

To be honest, Homebrew sucks for one big reason: if you ask for a package, it puts all of the package’s dependencies on your path. For example, you might install something unrelated and suddenly find out that you have Homebrew’s copy of pkg-config/libxml2/LLVM in your PATH. This has caused no end of issues for me while working on larger projects with complex build systems.

Moving Homebrew to the end of the PATH isn’t really a consideration here, because part of the point of using Homebrew is to get packages newer than what the system has.

Nix doesn’t have this issue – the set of things publicly exposed is what you ask for. This is much more reasonable than what Homebrew does. The issues I had with Homebrew have completely disappeared with Nix.

Distrobox isn’t suitable for everything

Even with distrobox’s export feature, some things have to run on bare metal. For example, I use htop and step-cli from Nix – those packages have to run on bare metal to be effective.

This isn’t a huge issue for me

Since I build my own images, I added an instruction to install Nix myself. I agree that suitably technical users can do this themselves, but it is a bit of a barrier to entry for them.

I completely understand your frustration

Nix is genuinely quite annoying to use and its users get quite loud, so I completely understand the concerns around support burden. Personally I would never file an issue against y’all unless there’s a clearly identified bug, but I’m also lucky to be in private channels where I can ask Nix devs questions directly.

I also agree for what it’s worth that any decision here has to be made by Fedora, not by Universal Blue or Bazzite.

Anyway, just wanted to share my perspective as someone who switched from Homebrew to Nix and was impacted in a minor way by this change.

5 Likes

You have to understand that nix is a non-starter for many of us. It simply is not an option. I do not want code built where integrated binaries are available.

This is because that nix is a distro - a deployment decision. I never used gentoo for a reason. I stopped compiling my source back in the 1990s when Softlanding Software produced the first Linux distro.

And I do not want to have to trust yet another ‘Arch AUR’ for binaries.

I really wish people would embrace brew and where it does not work do something else that does not involve changes to the OS on which they live.

I build Python 3.14 from source regularly because it is not released yet. I would never expect (or trust) any distro to get that right.

I get it that nix has a niche following. I just cannot fathom why.

But expecting opinionated products like bluefin or bazzite to adopt it is just not going to happen in my opinion.

For me, the reason is simple: I just use the same tool, and it works on every distro. If I, say, decided to move my ROG Ally to SteamOS? Run detsys nix installer, fetch my home-manager repo, run it, and I have the same CLI, config, and even GUI tools. If I decided to move my server from Ubuntu LTS to Debian? Same thing - same repo, same ‘defaults’, just different configs based on my needs, automatically selected based on my hostname.

For me, this is the reason why I stopped distrohopping in the first place. Distro doesn’t matter to me - I just use Flatpak and Nix.

And no, I don’t compile from source – why would I do that? I just state what packages I want to install from Nix. For some, there is a module to define the configs as well, but if I don’t feel like using it, I just have home-manager either create a static file where I can arbitrarily set the exact text file content, or I just have home-manager link to a file on the repo so it can be updated and synced. But I don’t build things - it just pulls the binary from the nix server and then ‘builds’ the environment based on the recipe.

Essentially, what I am doing is like using a container as my user space. I just have the core distro be up-to-date enough and I never really touch it, everything is done in the Nix layer, thanks to home-manager. And I know exactly what is going on, because I wrote the recipe myself, and when I get an error message, I know what and why they want me to fix something.

I know there are other solutions, but I like how home-manager works, and it works for me. Now, I’m not saying the Universal Blue devs must support that, but just like when Wayland was initially pushed, I am going to grumble about it until things get better, like Wayland.

Also, for one last reason: because it’s fun. It’s fun to talk with fellow Nix users and learn more about it. I build my own image because it’s fun and there’s a practical reason for it. The same is true with Nix.

But you implicitly trust the nixpkgs repo. I do not.

Essentially, what I am doing is like using a container as my user space.

How?

Nothing about nix is isolated like container isolation. Not sure I get that point.

I too am here for the community. I get that. I just don’t get nix.

With bluefin / bazzite there is no need for nix. It is a solution looking for a problem IMHO.

Wayland, systemd, yeah people just need to understand the history and get over their-selves.

Nonetheless, I am glad that differing opinions exist.

It means that I am still alive and am still on planet Earth. :wink:

The way it works with Nix is that all ‘binaries’ are really just wrappers on top of wrappers on top of wrappers – text files on top of text files on top of other text files until it finally calls the actual binary once the environment is properly defined. This allows you to specify which version of a package to install, and it’ll just take care of the dependencies correctly, even when different packages want different versions of the same packages.

Is this foolproof? Absolutely not, at least not with home-manager well the final symlinked wrappers are added to PATH. This was a problem during the KDE 6 transition, until I realize what was happening and change the channel I use to be the one with KDE 5 in it. Because it does offer a level of control that I like, where I can decide which versions I use, and when I upgrade – just like with me building my own image, but more granular.

More than that, the point for me is to integrate with the system. It’s just a decent middle ground between Flatpak, Distrobox, layering, and building on my own image. I like to choose where and what level a package is integrated. For all the issue that the KDE 6 transition was, it does allow me to identify some things that could be an issue – like how psifidotos Window Buttons applet was still broken, so I waited until that’s fixed before I upgrade.

Edit:

Sorry, I missed this. I’m kinda confused, because you did say you don’t want to build from source? You kinda have to trust someone at some point if you’re not auditing everything yourself.

I trust Fedora, hence why I use Universal Blue that uses almost everything from them. I don’t trust Manjaro, which is why I don’t use them despite me preferring the way they ship updates.

I trust nixpkgs because I’ve seen how the packages are build. There is so many checks, that it reminds me of Rust with how strict it can be. If you don’t trust it, instead of referencing the nixpkgs directly, you can just pull the nix configs and make your own derivation that doesn’t rely on nix’s built binaries.

Speaking of, that reminds me of something I like about Nix: the declarative config. I often lose track of what I’ve added and changed, especially when I saw a new app I want to try. The declarative way of doing things makes it easier to keep track of everything and evaluate if I still need it. I build my own image and use decorative-flatpak because of that, actually - the declarative way of doing things just really appeals to me.

1 Like

And further to your point - brew is another such distro. I just do not trust nix. (personal preference)

I dislike the language they have developed as well. But the flakes concept shows real promise.

I have spent all of the time I am going to on nix and nixos. It is a pass for me.

But if I would be looking to use nix on bluefin I would work on the following:

  • configure it so that it is usable without /nix - preferable would be ~/.local/share/nix or /usr/local/share/nix
  • configure it so it only uses / installs into ~ or /usr/local
  • if those features are missing - look to submit PRs to add them

Good luck.