After nearly two(!) years of prototyping and testing, Bluefin is on its way to Beta! We're hoping to do the final release of the beta on November 1st, so we'd like to spend a some time testing the ISO.
Bluefin is an interpretation of the Ubuntu spirit built with Fedora technology. It's a familiar(ish) Ubuntu desktop for Fedora Silverblue. It strives to cover these three use cases:
For users it provides a system as reliable as a Chromebook with near-zero maintenance, with the power of Ubuntu and Fedora fused together.
For developers we endeavour to provide the best cloud-native developer experience by enabling easy consumption of the industry's leading tools. These are included in dedicated bluefin-dx and bluefin-dx-nvidia images.
For gamers we strive to deliver a world-class gaming experience via Flathub or bazzite-arch
Installation progress will appear to have stalled but is progressing in the background
Applications like Firefox and other core apps will be installed on login, this might take a while depending on your internet connection speed. The system will notify you when it is completed:
Over the past few weeks contributors have reworked parts of our build system to support more hardware. Reusing cloud patterns allows Universal Blue to offer pretty awesome Nvidia support that's baked right into the image. This has always been a special case, something we only did for Nvidia support. We've now successfully productized the pattern into something that we can repeat quickly.
Devices like certain Asus laptops sometimes need special tools, and these laptops are supported by projects like asus-linux. They not only provide tools, they also hook you up with the right kernels that you need. Similarly, the linux-surface project provides special kernels for Microsoft Surface devices. They provide the tools and repositories needed to get Fedora working great on those devices. But you have to set that up by hand. Ewww.
One of the strengths of the cloud-native pattern is our ability to use existing Fedora base images, and then automate the post-installation steps as new composable layers, and then mix and match what we need. Both Asus and Surface devices can also come with Nvidia cards, which means we can use the existing Nvidia images to help us compose Nvidia-enabled images on top of the good stuff we need from asus-linux and linux-surface! These are now ready to test!
ublue-os/nvidia are the same as the main images but include slip-streamed Nvidia drivers
ublue-os/asus - Asus images with asus-linux.org tools and kernels
The Framework 13 laptop was a unique prototype in this. It was only available as a custom spin of Bluefin to gauge interest. We've reworked that repo to line up with the rest, so instead of being Bluefin-specific you can now enjoy a wider variety of images for your Framework.
If you're wondering if we plan on supporting the Framework 16 and new AMD Framework 13 then you're in luck, it's just another set of parameters we can add. We're hoping to get feedback from folks who get this hardware so we can enable it!
Both asus-linux and linux-surface have existed for a long time, what's the benefit of doing it this way? We list these benefits in Why would I use these?, but these images are a real world example of how the pattern works.
Both of these projects have done the hard work and provided the community with the right bits. All we do is automate that and run it every night and on every merge. If it works, it ends up on your machine, if it doesn't work, your machine still works. It's broken in our GitHub repository and it doesn't get to you. Instead we use one of the strongest advantages that we get with open source: It's easier to fix things when you do it together. When the nerds figure it out, the builds pass, and THEN you get the image on your machine. GitOps for the win!
The one gotcha is that we still need to do some post-installation steps manually. You might have had to do this as part of installation, where we ask you to do a just framework-13 or just nvidia-set-kargs in order to get the right kernel parameters in place. We expect this limitation to go away someday and hope to declare kernel arguments directly in the Containerfile.