Should work fine, bazzite even has a premade one, try it:

distrobox create --nvidia --image ghcr.io/ublue-os/bazzite-arch --name bazzite-arch

What’s the actual difference to fedora silverblue?

Hi! Co-maintainer here, you can find the differences in the github repo: https://github.com/ublue-os/bluefin

And there's a doc page going over it here: https://universal-blue.discourse.group/docs?topic=41

If you have any other questions I'd be happy to answer them!

You can totally use one of the tiling window manager images (sericea is based around sway) -- it wouldn't be a ton of work for that to be added to bazzite, it's just another parameter in the matrix, feel free to hop into github and help out, I'm sure people will want lots of options.

Co-maintainer here, yep, you got it!

I use homebrew on linux, you're not going to get GUI apps that way though, the linux binaries are almost exclusively cli apps and libraries, etc.

Co-maintainer here. That's basically what it is. The value proposition is included hardware enablement on the image (nvidia drivers, controller support, etc). and flathub ootb.

If Red Hat engineers are your measure of success then at least three of them have contributed directly to Universal Blue. Including the Nvidia support, upstream development of ostree, and tons of great support from the CoreOS community (like @@siosm)

All this stuff is new Fedora tech that's being deployed in the cloud, they've designed it in such a way that gives the end user a clear view of exactly what's being built. You can inspect each of our changes and what is cool is when you organize a community around it. It makes it very easy for us to scale quickly to get people what they want but in a reliable image-based way.

Kyle and Co. have been working with the folks at Nobara and ChimeraOS and there's a ton of sharing going on, so either way you win. Also check out the COPRs that bazzite maintains, you can totally try them out on your system.

For the other long term concerns check out https://universal-blue.org to check out our mission statements, vision, and information. We're just about to land our open source governance which should shed some light on how we intend to be a sustainable long term project.

Yeah, look at the examples here: https://github.com/coreos/layering-examples for an ansible example.

Though some modules don't work (the flatpak one doesn't work unfortunately). This is also useful: https://github.com/j1mc/ansible-silverblue

Hope it helps!

This is usually an oversight by people who might not have deep linux technical knowledge. I left a polite reply to let them know that AMD is good to go.

Hi! I made the video and also happen to volunteer with flathub. The reason I've called it "cloud native" is because that's the common term used in the industry already and server people know what that means. "Immutable" is a terrible term that is neither technically accurate or something users need to care about.

As for the CLI thing. Shoving CLIs into flatpaks could be a thing but that wouldn't really solve a problem, it would just mean adding one more ocean to boil and someone would have to volunteer to package htop for the 30th time. There's no need to do that, distros already have htop!

It's a better time investment to fix the UX for containers on the desktop, especially since Mac and Windows are already there. :-/ There's a few options that people are exploring that are worth discussing.

• podmansh has awesome potential, you just define a system-level container that has init and all the stuff people expect, then it would behave like the distro people are coming from. I suspect this is where CoreOS/Fedora will end up.
• exo - we have a spec over at ublue to just add container support directly to the terminal, like how WSL/windows terminal does it. This is the approach Canonical is taking with workshops
• Direct package management in your home dir - also an option, you can just install homebrew, nix, or tea or whatever install packages in your home directory and then it's totally decoupled from the system.

I personally use distrobox with the assemble pattern to have what I need on all my machines, but hopefully as time progresses distros will do a better job integrating all this stuff. I hope this helps answer some of your questions!

The OCI features are pretty new (they won't hit Fedora until F40) so there's catching up to do still. They'll get there at some point, there's just a vast amount of existing work out there that they need to account for.

Nvidia is just a specific pain point, it's nice to be able to roll back to a specific version of any given deployment.

It's just more obvious for out-of-tree drivers since that's usually a worse user experience.

The real question is why do flatpaks exist at all if you can just run programs in containers

flatpaks and containers use the same kernel tech underneath, cgroups and namespaces, it's just a specific implementation designed for desktop apps, and it has things like portals and stuff that's specific for gui apps. So for example, if you use silverblue, you use htop, but it wouldn't make sense as a flatpak when there's a full fedora installation delivered via a container already on your desktop, you'd just dnf install htop and move on.

But not if it takes away my ability to make my system fit my needs.

This is the problem with the term "immutable". For some reason people seem to think that these systems take away configurability and freedom to tinker, which is wrong because the entire point of cloud native is composability. You declare what your system is supposed to look like, and then a deployable artifact comes out the other end, that's pretty much it. Hope this helps!

Someone just merged some shortcuts to let you turn them on and off easier: https://github.com/ublue-os/config/commit/0823567237f8d83a50a75e9a7cd15c7c9d758d22

Of course you can install gparted, you can run just about anything that you want, it's still Linux.

I linked to it, here it is again: https://universal-blue.discourse.group/docs?topic=41#features-9

And the previous link was directly to the source code of the image.