I absolutely love what the universalblue team has been doing. They are one of the few organizations that are truly dedicated to providing a first-class, enjoyable, batteries included linux experience on the desktop.
I truly believe that updates are seamless not just because of all the buzzwords about the underlying technology but because its made for people who actually use the system daily. They gate the fedora kernel and track breaking changes so you don't get them, and generally care about the user experience. If you want sensible gnome defaults and extensions they are there (or there to be disabled at the click of a button). If you want remote desktop streaming (sunshine/moonlight) its there.
On the flip side, their distribution model also means no more need to keep track of out of tree kernel modules on upgrades (zfs, nvidia, waydroid even on Bazzite).
Now onto the post specifically: LTS from a CentOS Stream base seems interesting. Fedora is nice, and the universalblue team tames it 99%, but its edge can be a bit too bleeding sometimes. My only reticence with CentOS Stream though is that it is veering dangerously close to Red Hat proper which I am unsure how to feel about. I am eagerly awaiting when non-rpms distros will be able to use the same underlying technology Bluefin uses, and see how the space evolves. A debian base especially seems interesting in theory. There has recently been some progress on that front:
https://github.com/bootc-dev/bootc/issues/865https://github.com/bootcrew/debian-bootc
I think they have some improvement to do on supply-chain though. A lot of random COPRs and kernel patches pulled in from various random third- and first party repos that I think should get consolidated before I can consider it mature and really ready for prime time.
Similarly it would also be nice to see end-to-end builds being reproducible locally. (Things are currently hardcoded to github.com or tied to GitHub Actions in a few places. The patching required for that is nothing crazy - Good First Issue material :))
For Bluefin LTS we're in control of all the 3rd party repositories we use. We depend on EPEL but so does everybody else. I am unaware of any kernel patches that we are shipping since we ship the default CentOS Stream kernel and the optional hwe kernel ships CentOSs' kmod kernel.
Hi I'm jreilly1821, I made those COPRs for Bluefin LTS. I guess I could put something malicious but you can see that they are all just packages from Fedora DistGit. I'm not sure what your preference would be? I think distros have mystique given to them that is misappropriated. At the end of the day they are mostly middlemen packaging someone else's code.
Bootc is and will change things, images will be tested as an integrated experience and we'll continue to strive to pull from as far upstream as we can.
Negativo17 is Simone, an NVIDIA employee who has been instrumental in packaging nvidia drivers for linux for years. I don't know for certain, but I wouldn't be suprised if they are also doing the official packaging for nvidia drivers as well. Needless to say they are very trusted and a known entity in the Linux community
Perhaps if a supply chain attack is your largest concern then using some well vetted system like wolfi is more up your alley. (See some of their related repos on GitHub https://github.com/projectbluefin - I've been following the development of it and currently it still under development.)
Again "vetting" is a source of contention here as I'm not sure how the quality of official rpm sources compare to those outlined in an sbom
After about 5 years away from desktop Linux, I have now been using Bluefin/Bazzite for the past few months as a Windows/MacOS replacement on my personal desktop and laptop.
I knew that Bazzite was supposedly good for gaming but never looked into it any more than that. When I eventually learned about Bluefin, I was surprised to find that it, Bazzite, and all the other Universal Blue “distros” are built with the same container-native tech that I use every day at work. Needless to say I was immediately sold.
I have been very impressed so far. I don’t find the immutable OS limiting in my day-to-day work at all. I guess I’m all about that “defaults lifestyle” now.
> I have been very impressed so far. I don’t find the immutable OS limiting in my day-to-day work at all. I guess I’m all about that “defaults lifestyle” now.
Distrobox and custom podman containers get you a long way on an immutable system. It's actually a huge deal that podman supports rootless containers as a first-class feature.
Same here! Been developing embedded, server and frontend stuff all fron Bluefin/Bazzite for 2 years now. Having Homebrew and Tailscale all set up for me is super clean, and the system is just set-and-forget. Gaming works great too.
I was confused by my first several readings of the projectbluefin.io site, due in part to not having prior experience with some of the techs (e.g. their 2023 announcement said "Bluefin is a custom image of Fedora Silverblue by a bunch of cloud-native nerds. ... Originally Bluefin was "Fedora Silverblue for Ubuntu Expatriates". I ... wanted Silverblue but with a more Ubuntu-like desktop." I've never used Silverblue so that told me very little.
But I think I'm beginning to understand. Please correct me if I'm getting any of this wrong:
- Bluefin is, fundamentally, a container image that you run with your preferred container runtime (Docker, Podman, whatever).
- But where most containers are slimmed-down to run just one app, Bluefin is a Linux desktop in a container.
- Bluefin includes Podman in its image, so you can run other containers inside your container. (Yo dude, I hear you like containers...)
- Because Bluefin is a container image, updates are all-or-nothing, i.e. atomic. You download the updated image, then reboot into it next time you're ready to reboot.
- Installing other apps once you're running Bluefin is done via flatpak, rather than snap or apt or dnf or pacman. And there's a graphical app store that connects to Flathub. (I don't yet know what the offically-recommended way is to install software that isn't yet on Flathub).
Anything incorrect in that list? Anything major that I left out?
(Edited only to add a newline between bullet points, because I didn't realize that Hacker News doesn't implement that part of Markdown. The fact that asterisks around words gives you italics fooled me into thinking that more of Markdown than italics was implemented.)
>Bluefin is, fundamentally, a container image that you run with your preferred container runtime (Docker, Podman, whatever).
Nope, you don't execute it like a container. Although it is an OCI-compatible container image and can be built using Docker/buildah/etc, it's "executed" (well, deployed) using bootc (boot container). This is a technology that basically blasts the container out to a filesystem tree using a technology called OSTree. OSTree is the same technology behind Flatpaks.
The older, pre OCI-based version of this tech is called rpm-ostree.
>Because Bluefin is a container image, updates are all-or-nothing, i.e. atomic. You download the updated image, then reboot into it next time you're ready to reboot.
Key word being atomic, you can layer packages onto the container image. This gives you some flexibility without needing to rebuild the entire container. For example, I use Kinoite and I depend on zsh which isn't shipped in the image. If I `rpm-ostree install zsh` and reboot, I now have zsh layered and it'll be automatically re-layered after every upgrade.
It's very much having your cake and eating it too. You get all the benefits of an atomic system's stability and ease of upgrades but you don't trade much flexibility for it.
One foundational misunderstanding in your very first bullet - Universal Blue distros are installable operating systems that happen to use container image formats as a file representation for network distribution and update mechanisms, but you're expected to be running it on actual hardware or as a traditional VM. The outermost "container" part is largely an incidental implementation detail. You don't run these as a workload on like, a Kube cluster, or anything like that.
The underlying project in question for the next conceptual layer down is rpm-ostree:
As someone quite happy with a vanilla Fedora Silverblue install on both my desktop and laptop, can anyone explain why I would rebase to Bluefin instead? It seems like there must be technical merit to the Universal Blue spins beyond adding preinstalled software/configs, but I can't find it, despite looking.
Haven't used Silverblue or Bluefin but the way I've seen it explained is that Bluefin, Aurora, etc include a number of QoL and practicality adjustments that make them nicer/easier to live with as a desktop OS than baseline Silverblue is.
Yes! I used to use Silverblue too. Things like Tailscale, Docker, Davinci Resolve, nvidia drivers, and all codecs are a button-click away or already properly set up for you out of the box on the universal blue projects.
Co-maintainer here. I dogfooded Silverblue for about 2 years before deciding to do this. Initially Bluefin was just a "fix me script" that did the usual bits. When bootc came around this let me put that script in GitHub CI and then just consume the fixes I want. A few of us started to do this and then since a bunch of us were kubernetes nerds we defaulted into "let's make this together."
Here are some of the changes:
- We add all the codecs, and drivers in the build step so the user never has to care.
- We turn on automatic updates by default, these are silent
- We remove Fedora's broken flatpak remote and go full Flathub out of the box
- We handle major version updates for you in CI, there's no "distro release day" update that's just a normal update that day
- Since we use bootc it's easy for people to FROM any of our images and make a custom build, and we ship a template for anyone to do so: https://github.com/ublue-os/image-template
- You can turn on "developer mode" which gives you vscode with devcontainers, docker, incus, etc in addition to podman.
- We integrate homebrew out of the box for package management for the CLI, flathub handles the GUI packages - we don't want to be a distro, in this world the base image is a base image and my relationship is with brew and flathub. I don't need or want to have a relationship with my OS.
- We gate kernel versions to avoid regressions, so we can avoid certain releases or "ride it out" until fixes are published.
- We ship [Bazaar](https://github.com/kolunmi/bazaar) - which is a flatpak only store designed for performance. Since the OS is a different layer we can throw away all those packagekit jankfests and start from scratch.
As for the desktop, I worked on Ubuntu for about a decade and wasn't happy with the direction Ubuntu was going at the time. Fedora had rpm-ostree/bootc but didn't know what to do with it so they were just sitting on the tech. So I just combined them, the desktop has an Ubuntu-like layout and vibe.
The clear benefit is that you have one image for everything, whereas local layering in Silverblue doesn't really make sense to me anymore, if you want to handle a bunch of local packages just use a traditional distro. Because doing that in Silverblue breaks just as often as it does in package distros. Pure image mode is the strongest benefit. It's 2025 I refuse to do "post installation crap" that should be automated, bootc lets me do that!
Hmm so you don't use rpm-ostree? Or ostree at all? Sorry I'm just having trouble finding some of the technical implementation details, seeing a lot of details on the UX though.
Boots currently relies on OSTree, you use OSTree enable base images. But the work is well on its way to transition to composefs which uses kernel native tech to replicate the features need from OSTree, so any systemd enabled distro can become bootc-able, for a bunch of example see: https://github.com/bootcrew
ostree is the library that rpm-ostree and bootc share. However bootc is moving over to composefs as a backend. This effectively makes it distro agnostic and there are communities forming: https://github.com/bootcrew
Fedora still uses rpm-ostree, when you do an update it's pulling from an ostree remote served from a server. bootc replaces that with just an OCI registry. We ship the `rpm-ostree` binary on the systems still. It's still used for things like adding kernel boot arguments.
Generally speaking new users can skip the rpm-ostree parts and just start with bootc. I am not an expert in this, there's a rust library in there somewhere. Hopefully someone can help fill in the blanks.
I can answer for me coming from the same boat... exactly zero risk to try, given how easy it would be to rebase back onto silverblue. I didn't have to worry about the codecs Fedora couldn't legally ship so I could remove an overlay, plus I figured bootc was the future and I wanted to see it working.
Sure there is zero immediate risk, I just genuinely don’t know what I would get out of taking on the risk of adding a community maintained middleman into the supply chain. I know, because rpm-ostree, it’s not the same as some random distribution. If there’s nothing to get out of it personally that layering a package or two can’t give me (or better, writing my own simple image).. why?
I’m not saying there isn’t a reason; I’m genuinely looking for it
It looks like Debian equivalents might be VanillaOS, EndlessOS, and (though not as similar) StarlingX, since all are OSTree-based for atomic updates.
I’m curious what others’ experience is with developing on these- do drivers work out-of-the-box and is it easy to configure, similar to macOS stability with something like brew to get latest packages and apps?
Eventually I’ll probably have to go back to free OSes because things don’t seem to be getting better.
As soon as Fedora/Centos updates their images (pretty much immediately usually as it's upstream of EL), and the CI runs to re-layer the Bluefin changes. They also have Dependabot set up. https://github.com/ublue-os/bluefin/actions
Same but for Kinoite and Aurora. I recently rolled my own image off Kinoite using the template you linked. I highly recommend it! It’s fun, pretty straightforward, and it feels good to have a custom base for your exact needs.
Co-maintainer here. When I saw one of these I immediately want to run Bluefin on it.
In spirit I would love to support this, someone with one of these would need to PR in support, but it's usually taking the enablement instructions from NVidia and putting it in a dockerfile. Bluefin is already working well on on the Ampere ARM workstations that System76 sells. Getting it on one of these would be awesome.
Meh. I haven't seriously considered GTK ecosystems since 3 got released. Between the increased usage of screen real estate, feature minimalism as a philosophy, becoming infested with ever more JavaScript that hampers performance, the continuous API instability that strangles extension development, and "my way or the highway" approach to workflows... I just don't get why people like it.
While not mentioned in the post, there is a KDE flavor of the same project called Aurora/kinoite. While it doesn't get the LTS treatment (IMO it would have been the better pick over Bluefin), it's still viable.
I love the u-blue stuff I've used so far (Bazzite and uCore) but god do I wish they had one with cosmic desktop. Fedora atomic does, and it looks like u-blue used to (there's an archived repo), but until then I'm sticking with pop-os
Each version of CentOS Stream is maintained for about 5.5 years, plenty to qualify as an LTS and significantly longer than Fedora (the base for non-LTS Bluefin).
I absolutely love what the universalblue team has been doing. They are one of the few organizations that are truly dedicated to providing a first-class, enjoyable, batteries included linux experience on the desktop.
I truly believe that updates are seamless not just because of all the buzzwords about the underlying technology but because its made for people who actually use the system daily. They gate the fedora kernel and track breaking changes so you don't get them, and generally care about the user experience. If you want sensible gnome defaults and extensions they are there (or there to be disabled at the click of a button). If you want remote desktop streaming (sunshine/moonlight) its there. On the flip side, their distribution model also means no more need to keep track of out of tree kernel modules on upgrades (zfs, nvidia, waydroid even on Bazzite).
Now onto the post specifically: LTS from a CentOS Stream base seems interesting. Fedora is nice, and the universalblue team tames it 99%, but its edge can be a bit too bleeding sometimes. My only reticence with CentOS Stream though is that it is veering dangerously close to Red Hat proper which I am unsure how to feel about. I am eagerly awaiting when non-rpms distros will be able to use the same underlying technology Bluefin uses, and see how the space evolves. A debian base especially seems interesting in theory. There has recently been some progress on that front: https://github.com/bootc-dev/bootc/issues/865 https://github.com/bootcrew/debian-bootc
Mostly agree.
I think they have some improvement to do on supply-chain though. A lot of random COPRs and kernel patches pulled in from various random third- and first party repos that I think should get consolidated before I can consider it mature and really ready for prime time.
Similarly it would also be nice to see end-to-end builds being reproducible locally. (Things are currently hardcoded to github.com or tied to GitHub Actions in a few places. The patching required for that is nothing crazy - Good First Issue material :))
For Bluefin LTS we're in control of all the 3rd party repositories we use. We depend on EPEL but so does everybody else. I am unaware of any kernel patches that we are shipping since we ship the default CentOS Stream kernel and the optional hwe kernel ships CentOSs' kmod kernel.
Really? Do you control the negativo17.org repo (just one example from akmods)?
https://github.com/ublue-os/akmods/blob/9946c17373b1a49e60a0...
https://github.com/ublue-os/bluefin-lts/blob/84cac6e9a063ec5...
How about jreilly1821? Looks like nothing's really preventing them from sneaking in a malicious version of glib2..
https://github.com/ublue-os/bluefin-lts/blob/84cac6e9a063ec5...
I would be in trouble if I didn't trust jreilly1821 since he's one of the Bluefin maintainers. And the nvidia binaries come from an nvidia employee.
Hi I'm jreilly1821, I made those COPRs for Bluefin LTS. I guess I could put something malicious but you can see that they are all just packages from Fedora DistGit. I'm not sure what your preference would be? I think distros have mystique given to them that is misappropriated. At the end of the day they are mostly middlemen packaging someone else's code.
Bootc is and will change things, images will be tested as an integrated experience and we'll continue to strive to pull from as far upstream as we can.
Negativo17 is Simone, an NVIDIA employee who has been instrumental in packaging nvidia drivers for linux for years. I don't know for certain, but I wouldn't be suprised if they are also doing the official packaging for nvidia drivers as well. Needless to say they are very trusted and a known entity in the Linux community
You control github?
Perhaps if a supply chain attack is your largest concern then using some well vetted system like wolfi is more up your alley. (See some of their related repos on GitHub https://github.com/projectbluefin - I've been following the development of it and currently it still under development.)
Again "vetting" is a source of contention here as I'm not sure how the quality of official rpm sources compare to those outlined in an sbom
After about 5 years away from desktop Linux, I have now been using Bluefin/Bazzite for the past few months as a Windows/MacOS replacement on my personal desktop and laptop.
I knew that Bazzite was supposedly good for gaming but never looked into it any more than that. When I eventually learned about Bluefin, I was surprised to find that it, Bazzite, and all the other Universal Blue “distros” are built with the same container-native tech that I use every day at work. Needless to say I was immediately sold.
I have been very impressed so far. I don’t find the immutable OS limiting in my day-to-day work at all. I guess I’m all about that “defaults lifestyle” now.
> I have been very impressed so far. I don’t find the immutable OS limiting in my day-to-day work at all. I guess I’m all about that “defaults lifestyle” now.
Distrobox and custom podman containers get you a long way on an immutable system. It's actually a huge deal that podman supports rootless containers as a first-class feature.
How do you choose between Bluefin and Bazzite? Can you do any gaming from Bluefin, or is Bazzite a requisite for an easy functional setup for this?
The difference is mostly about default settings
Bluefin even includes stuff like built in propietary controller support and such
If on desktop I'd probably keep to Bluefin (Gnome) or Aurora (KDE) mostly because those have better defaults for it
Same here! Been developing embedded, server and frontend stuff all fron Bluefin/Bazzite for 2 years now. Having Homebrew and Tailscale all set up for me is super clean, and the system is just set-and-forget. Gaming works great too.
Hi everyone! I built this 4 years ago as a passion project and now it's led to a culmination of things that led to release. Happy to answer questions!
Bluefin rocks. Thanks for your work!
I was confused by my first several readings of the projectbluefin.io site, due in part to not having prior experience with some of the techs (e.g. their 2023 announcement said "Bluefin is a custom image of Fedora Silverblue by a bunch of cloud-native nerds. ... Originally Bluefin was "Fedora Silverblue for Ubuntu Expatriates". I ... wanted Silverblue but with a more Ubuntu-like desktop." I've never used Silverblue so that told me very little.
But I think I'm beginning to understand. Please correct me if I'm getting any of this wrong:
- Bluefin is, fundamentally, a container image that you run with your preferred container runtime (Docker, Podman, whatever).
- But where most containers are slimmed-down to run just one app, Bluefin is a Linux desktop in a container.
- Bluefin includes Podman in its image, so you can run other containers inside your container. (Yo dude, I hear you like containers...)
- Because Bluefin is a container image, updates are all-or-nothing, i.e. atomic. You download the updated image, then reboot into it next time you're ready to reboot.
- Installing other apps once you're running Bluefin is done via flatpak, rather than snap or apt or dnf or pacman. And there's a graphical app store that connects to Flathub. (I don't yet know what the offically-recommended way is to install software that isn't yet on Flathub).
Anything incorrect in that list? Anything major that I left out?
(Edited only to add a newline between bullet points, because I didn't realize that Hacker News doesn't implement that part of Markdown. The fact that asterisks around words gives you italics fooled me into thinking that more of Markdown than italics was implemented.)
>Bluefin is, fundamentally, a container image that you run with your preferred container runtime (Docker, Podman, whatever).
Nope, you don't execute it like a container. Although it is an OCI-compatible container image and can be built using Docker/buildah/etc, it's "executed" (well, deployed) using bootc (boot container). This is a technology that basically blasts the container out to a filesystem tree using a technology called OSTree. OSTree is the same technology behind Flatpaks.
The older, pre OCI-based version of this tech is called rpm-ostree.
>Because Bluefin is a container image, updates are all-or-nothing, i.e. atomic. You download the updated image, then reboot into it next time you're ready to reboot.
Key word being atomic, you can layer packages onto the container image. This gives you some flexibility without needing to rebuild the entire container. For example, I use Kinoite and I depend on zsh which isn't shipped in the image. If I `rpm-ostree install zsh` and reboot, I now have zsh layered and it'll be automatically re-layered after every upgrade.
It's very much having your cake and eating it too. You get all the benefits of an atomic system's stability and ease of upgrades but you don't trade much flexibility for it.
Thank you for correcting my mistakes; I appreciate it.
One foundational misunderstanding in your very first bullet - Universal Blue distros are installable operating systems that happen to use container image formats as a file representation for network distribution and update mechanisms, but you're expected to be running it on actual hardware or as a traditional VM. The outermost "container" part is largely an incidental implementation detail. You don't run these as a workload on like, a Kube cluster, or anything like that.
The underlying project in question for the next conceptual layer down is rpm-ostree:
https://coreos.github.io/rpm-ostree/
Thank you for correcting my mistake; that helps.
As someone quite happy with a vanilla Fedora Silverblue install on both my desktop and laptop, can anyone explain why I would rebase to Bluefin instead? It seems like there must be technical merit to the Universal Blue spins beyond adding preinstalled software/configs, but I can't find it, despite looking.
Haven't used Silverblue or Bluefin but the way I've seen it explained is that Bluefin, Aurora, etc include a number of QoL and practicality adjustments that make them nicer/easier to live with as a desktop OS than baseline Silverblue is.
Yes! I used to use Silverblue too. Things like Tailscale, Docker, Davinci Resolve, nvidia drivers, and all codecs are a button-click away or already properly set up for you out of the box on the universal blue projects.
Co-maintainer here. I dogfooded Silverblue for about 2 years before deciding to do this. Initially Bluefin was just a "fix me script" that did the usual bits. When bootc came around this let me put that script in GitHub CI and then just consume the fixes I want. A few of us started to do this and then since a bunch of us were kubernetes nerds we defaulted into "let's make this together."
Here are some of the changes:
- We add all the codecs, and drivers in the build step so the user never has to care.
- We turn on automatic updates by default, these are silent
- We remove Fedora's broken flatpak remote and go full Flathub out of the box
- We handle major version updates for you in CI, there's no "distro release day" update that's just a normal update that day
- Since we use bootc it's easy for people to FROM any of our images and make a custom build, and we ship a template for anyone to do so: https://github.com/ublue-os/image-template
- You can turn on "developer mode" which gives you vscode with devcontainers, docker, incus, etc in addition to podman.
- We integrate homebrew out of the box for package management for the CLI, flathub handles the GUI packages - we don't want to be a distro, in this world the base image is a base image and my relationship is with brew and flathub. I don't need or want to have a relationship with my OS.
- We gate kernel versions to avoid regressions, so we can avoid certain releases or "ride it out" until fixes are published.
- We ship [Bazaar](https://github.com/kolunmi/bazaar) - which is a flatpak only store designed for performance. Since the OS is a different layer we can throw away all those packagekit jankfests and start from scratch.
As for the desktop, I worked on Ubuntu for about a decade and wasn't happy with the direction Ubuntu was going at the time. Fedora had rpm-ostree/bootc but didn't know what to do with it so they were just sitting on the tech. So I just combined them, the desktop has an Ubuntu-like layout and vibe.
The clear benefit is that you have one image for everything, whereas local layering in Silverblue doesn't really make sense to me anymore, if you want to handle a bunch of local packages just use a traditional distro. Because doing that in Silverblue breaks just as often as it does in package distros. Pure image mode is the strongest benefit. It's 2025 I refuse to do "post installation crap" that should be automated, bootc lets me do that!
More info here since I'm leaving out a bunch of stuff: https://docs.projectbluefin.io/introduction
Sounded interesting until you got to homebrew. Have you deactivated its telemetry? Also it talks to github often as well?
Like the dino theme.
Hmm so you don't use rpm-ostree? Or ostree at all? Sorry I'm just having trouble finding some of the technical implementation details, seeing a lot of details on the UX though.
Boots currently relies on OSTree, you use OSTree enable base images. But the work is well on its way to transition to composefs which uses kernel native tech to replicate the features need from OSTree, so any systemd enabled distro can become bootc-able, for a bunch of example see: https://github.com/bootcrew
ostree is the library that rpm-ostree and bootc share. However bootc is moving over to composefs as a backend. This effectively makes it distro agnostic and there are communities forming: https://github.com/bootcrew
Fedora still uses rpm-ostree, when you do an update it's pulling from an ostree remote served from a server. bootc replaces that with just an OCI registry. We ship the `rpm-ostree` binary on the systems still. It's still used for things like adding kernel boot arguments.
Here's their diagram: https://bootc-dev.github.io/bootc/filesystem-storage.html
Generally speaking new users can skip the rpm-ostree parts and just start with bootc. I am not an expert in this, there's a rust library in there somewhere. Hopefully someone can help fill in the blanks.
I can answer for me coming from the same boat... exactly zero risk to try, given how easy it would be to rebase back onto silverblue. I didn't have to worry about the codecs Fedora couldn't legally ship so I could remove an overlay, plus I figured bootc was the future and I wanted to see it working.
Sure there is zero immediate risk, I just genuinely don’t know what I would get out of taking on the risk of adding a community maintained middleman into the supply chain. I know, because rpm-ostree, it’s not the same as some random distribution. If there’s nothing to get out of it personally that layering a package or two can’t give me (or better, writing my own simple image).. why?
I’m not saying there isn’t a reason; I’m genuinely looking for it
How quickly and safely are bugs fixed in Bluefin?
It looks like Debian equivalents might be VanillaOS, EndlessOS, and (though not as similar) StarlingX, since all are OSTree-based for atomic updates.
I’m curious what others’ experience is with developing on these- do drivers work out-of-the-box and is it easy to configure, similar to macOS stability with something like brew to get latest packages and apps?
Eventually I’ll probably have to go back to free OSes because things don’t seem to be getting better.
As soon as Fedora/Centos updates their images (pretty much immediately usually as it's upstream of EL), and the CI runs to re-layer the Bluefin changes. They also have Dependabot set up. https://github.com/ublue-os/bluefin/actions
It's just OCI images, like any web-scale project.
I have tried both Silverblue and Bluefin and I realized that I want something in between. So basically Silverblue+codecs+drivers.
Maybe https://github.com/ublue-os/image-template is the way to go when I do my setup next time.
Same but for Kinoite and Aurora. I recently rolled my own image off Kinoite using the template you linked. I highly recommend it! It’s fun, pretty straightforward, and it feels good to have a custom base for your exact needs.
So Bluefin GDX is a good fit for the Nvidia DGX workstations going for 8-15k on ebay?
I don't even do language model stuff I just want a gold computer
Co-maintainer here. When I saw one of these I immediately want to run Bluefin on it.
In spirit I would love to support this, someone with one of these would need to PR in support, but it's usually taking the enablement instructions from NVidia and putting it in a dockerfile. Bluefin is already working well on on the Ampere ARM workstations that System76 sells. Getting it on one of these would be awesome.
Meh. I haven't seriously considered GTK ecosystems since 3 got released. Between the increased usage of screen real estate, feature minimalism as a philosophy, becoming infested with ever more JavaScript that hampers performance, the continuous API instability that strangles extension development, and "my way or the highway" approach to workflows... I just don't get why people like it.
While not mentioned in the post, there is a KDE flavor of the same project called Aurora/kinoite. While it doesn't get the LTS treatment (IMO it would have been the better pick over Bluefin), it's still viable.
https://github.com/ublue-os/aurora
https://getaurora.dev/
Kinoite is not from the same project tho, it's the fedora KDE spin.
[dead]
Well, everyone's different. It's great that Linux caters to all of us.
I prefer Gnome because it does what I need but mostly just disappears and gets out of my way.
I used to love fiddling and customising everything. Plenty of options for that if that's your thing, like KDE.
I love the u-blue stuff I've used so far (Bazzite and uCore) but god do I wish they had one with cosmic desktop. Fedora atomic does, and it looks like u-blue used to (there's an archived repo), but until then I'm sticking with pop-os
I'm a little surprised that an LTS product is based on CentOS 10 stream. Doesn't that have the shortest support?
Each version of CentOS Stream is maintained for about 5.5 years, plenty to qualify as an LTS and significantly longer than Fedora (the base for non-LTS Bluefin).
Shortest support for CentOS, but that's still longer than regular Ubuntu LTS by 6 months
A backported Gnome with a recent kernel definitively needs a current MESA backport.
Mesa is kept current enough in CentOS that a backport isn't necessary. It's currently at version 25.0.7, same as Fedora 41.