Agreed (and also with jjaksic above). Especially if you’re extending the engine with plugins and/or modifications which require you to rebuild the engine.
virtmanager and the tooling that goes with it would help quite a bit, but I’m guessing that’s part of all the -dx images.
I love the idea and I will definitely keep my eye on Bazzite DX!
Honestly, I use Bazzite like this from the beginning, ie. it’s on my main workstation PC - in the end, it’s always a Fedora with bunch of great tools on the top to help run Steam smoothly (apologies for simplifying it like that, but you know what I mean) and I always needed to take care of that separately (not anymore, and I salute to the entire Universal Blue team for that, thanks!)
Flatpaks/Homebrew/Toolbox is already a great combo to get everything what’s needed, but indeed it will be even better to have some of the tools included in the default image. Can’t wait!
Great idea! I have some experience with setting up Unity on Bazzite. Here I wrote about the problems and solutions: Setting up older Unity version under Bazzite (Fedora Atomic desktop) | by Laszlo Molnar | Medium
Basically, the main pain point was at start, that the older Unity versions are not running on new Fedora. I had to set up a distrobox with an older Fedora, and install everything there to make it work. From Distrobox, it works well, but I felt like it’s a bit slower than running it natively.
If you are using the flatpak, another problem is that it is not easy to make the flatpak and VSCode (also flatpak) to see the .NET packages. I’m not a linux pro, so there may be an easier way, but my final solution was to just copy the .net files to a directory and make the flatpaks see it. I’m able to debug from VSCode now but still having the annoying error popups from Unity that .net is not found. I saw the freedesktop mono6 and .net packages installed in the system but wasn’t able to make it work with them. Any tutorial I found was not working in my case.
I would be happy if setting up Unity would be easier, so I’m hoping for these new images!
Is the only way to test the Bazzite-GDX image is to rebase, correct? Is there an ISO installer yet?
Also, just to confirm, since they are currently built from bazzite:41, it means that it is KDE Plamsa for the desktop, right?
I am very excited to see the switch from RPM-OStree to Bootc for these OSes.
No there’s nothing in there at all it’s just a blank repo right now, we’re working on bazzite-dx first.
Ah, thanks for clearifying. I will patiently wait until it is built then.
Alright here’s nvidia, gnome, and friends!
Hello,
I just rebased from Bluefin DX to Bazzite DX, I love how I can change distros with only a command and a reboot!
My only issues are with the installation of oversteer, CoolerControl and openRGB using ujust and the First Boot Setup utility. Should I post my logs here or create an issue over at GitHub · Where software is built ?
Not sure on this one, did you have the same problems in Bazzite (non-dx version?)
I rebased directly to Bazzite DX from Bluefin DX, should I have rebased to non-DX Bazzite first?
The ujust commands for those are missing entirely in Bluefin so assuming everything went fine you should be able to run those after you’ve booted into bazzite.
In the case of CoolerControl and OpenRGB, I get the following errors using ujust:
axel-Desktop in ~
❯ ujust install-openrgb
error: Justfile does not contain recipe `install-openrgb`
Did you mean `_install-openrgb`?
axel-Desktop in ~
❌1 ❯ ujust install-coolercontrol
error: Justfile does not contain recipe `install-coolercontrol`
Did you mean `_install-coolercontrol`?
Prefixing the commands with an underscore does work.
For oversteer though, DNF complains that Python 3.12 is not installed
axel-Desktop in ~
❯ ujust install-oversteer
distrobox enter -n fedora -- bash -c 'sudo dnf copr enable -y bazzite-org/oversteer && sudo dnf install -y oversteer && distrobox-export --app oversteer'
https://copr.fedorainfracloud.org/api_ 100% | 1.4 KiB/s | 437.0 B | 00m00s
Enabling a Copr repository. Please note that this repository is not part
of the main distribution, and quality may vary.
The Fedora Project does not exercise any power over the contents of
this repository beyond the rules outlined in the Copr FAQ at
<https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-in-copr>,
and packages are not held to any quality or security level.
Please do not file bug reports about these packages in Fedora
Bugzilla. In case of problems, contact the owner of this repository.
Updating and loading repositories:
Copr repo for oversteer owned by bazzite-org 100% | 19.0 KiB/s | 2.1 KiB | 00m00s
Repositories loaded.
Failed to resolve the transaction:
Problem: conflicting requests
- nothing provides python(abi) = 3.12 needed by oversteer-0.0.git.362.0561f316-1.fc41.noarch from copr:copr.fedorainfracloud.org:bazzite-org:oversteer
You can try to add to command line:
--skip-broken to skip uninstallable packages
error: Recipe `install-oversteer` failed on line 130 with exit code 1
OK, someone from the Bazzite team will need to answer this, outside my skill set!
I’m a game developer with over 10 years of experience and have been using Bazzite as my daily workstation for over a year now, so the idea of Bazzite GDX is really interesting to me and I know people who would be easy converts with this available!
Bazzite is great as an out-of-the-box gaming setup from a user-focused perspective, and with a few tweaks, it would be great as an out-of-the-box developer-focused workstation.
So far, I’ve been using Blue Build to tailor my image to add more content creation tools and development packages. But for a more generalized approach, I think a customized Bazzite Portal would be the best approach. On first boot, you’d be given categories of software you can acquire based on discipline:
It would also include some packages that most developers would need:
And certain things in default Bazzite made optional that don’t pertain to development, like Waydroid and Lutris.
If this sounds like an appealing approach, I could start tinkering!
Looks great imo! I’d also add Furnace next to Renoise, though it is much more specialized on chiptune, and maybe Pixelorama for 2D Art too?
I got excited about Nvidia, but as of right now there’s only “nvidia-open”. My Nvidia is too old for open drivers. Is “nvidia-closed” coming too? 
Also, what happens if I rebase to bazzite-dx when I already have some “dx” packages layered on top of a regular bazzite? Will the layers get automatically removed, or should I remove them manually, before or after rebasing?
IIRC In general you should remove layers before rebasing. It shouldn’t be too hard to re-layer everything later since you can just copy paste the package names rpm-ostree status puts out
First of all, let me just say i’ve been watching the issue for quite some time and im glad you pushed it forward. But Is it just me or do i get the feeling we are slowly moving torwards the option to choose what we want? For example, if we just had ublue-desktop / ublue-desktop-nvidia / ublue-deck and we chose gaming tools and dev tools in startup. But i guess that’s system extensions that are coming down the road, isn’t it?
I just switched from Bluefin DX 41 to Bazzite 41. My main applications are embedded development and computer music, and I switched to Bazzite mostly because of the kernel optimizations Bazzite has for gaming. I don’t do much gaming, but I am likely to use some Windows audio tools.
I do most of my development in Distrobox containers, and Bazzite already supports them. So what would Bazzite DX or GDX give me that Bazzite doesn’t already have?
I think that‘s the long-term plan, yeah.
the final one should be called GlorpOS