![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://lemmy.ml/pictrs/image/q98XK4sKtw.png)
Here’s the repo: https://github.com/ublue-os/bluefin and the intro doc outlines some of the features. We include all the codecs from rpmfusion and use negativo17 for the nvidia drivers.
Here’s the repo: https://github.com/ublue-os/bluefin and the intro doc outlines some of the features. We include all the codecs from rpmfusion and use negativo17 for the nvidia drivers.
Yeah checkout ucore, which is derived from CoreOS instead of Silverblue: https://github.com/ublue-os/ucore
What kind of printer? What’s the name of the package that got it working? We can add printer drivers pretty easily.
Hi! Universal Blue co-maintainer here, here’s the TLDR. You’ve got the basic descriptions right, “Universal Blue” is mostly the parent organization that holds everything in github.
We take Fedora’s Atomic OCI images and customize them for different use cases (Aurora, Bazzite, and Bluefin) and then publish base images so people can make their own versions of whatever they want. So if you wanted to take Silverblue, Kinoite, and make your own custom image you can mostly just grab whatever you want and shove it into an OS image. Bluefin started off as a “fix me” script for Silverblue that added all the stuff I wanted and then once I was shown what Fedora wanted to do with it the natural progression was to just make it a custom image. We just released 3.0 a few minutes ago actually!
Basically in Fedora 41 the tech will become more widely available with official OCI base images and better tooling. We just decided to start way earlier in the process so we could get all the automation out of the way, build a community, get familiar with it, etc. Happy to answer any other questions you may have!
Flameshot is 3.6MB on disk according to flatpak info org.flameshot.Flameshot
ublue co-maintainer here. I go over a bunch of the reasons here: https://www.ypsidanger.com/homebrew-is-great-on-linux/
Namely we needed a way to complement Flatpak and brew was a natural fit. It’s an ecosystem reason not a technical one. It has everything we need and a good deal of Bluefin’s target audience are already using it on mac. So for us it’s an easier lift to just add homebrew and move on to larger problems.
Plus it’s nice that they’re working with the openssf to secure the supply chain pipeline, and it’s nice that everything is in github where we can inspect it, use the same tooling we use for the OS, etc.
I’m unclear how mature the project is and whether it will be updated in a timely manner long term
ublue and bluefin co-maintainer here, we’ve been around for a while now (3rd birthday coming up!) and have been around in a more unofficial capacity for longer.
Bluefin is feature complete and is in maintenance mode, it’s just going to get updated in perpetuity to 41, 42, etc. We invested in automation first so most of the maintenance is automatic and it doesn’t take much for our team to do it. Right now most of our major ticket items are waiting for things to finish landing in upstream Fedora, most of which are targetted towards F41. A good portion of the team have been around in OSS for a long time and a bunch of us work in the industry and depend on Bluefin for our jobs, so much so that we have a great working relationship with Framework, so we’re supporting those laptops as a community option for them.
Aurora is relatively new, coming in just as Plasma 6 landed in fedora. Most reports with issues we get for it are things like it being a new major release, wayland/nvidia issues, etc.
Hopefully that answers some of your questions, if you have more feel free to ask!
I disagree on your view about the Fedora atomic spins, especially universal blue. Who cares if the underlying OS downloads as one big image. It all happens in the background, you don’t notice that. Everytime you reboot, you are on an updated system.
Universal Blue co-maintainer here, this is a temporary situation, efficient downloads are coming, I’m actually at the Red Hat Summit and have been discussing things with the right engineering teams. This involves an intersection of podman, ostree maintainers etc. all aligning on it. It’s definitely a priority for them to fix this.
We’ve pushed pretty hard and pretty fast on the cloud native model, part of it was convincing people that this was a thing that users want, they hear us loud and clear now, it’s going to be an awesome year.
installs all those things and sets things up properly on a standard fedora install?
That’s exactly what all universal blue images do. It’s just that setup is done every single day in github from scratch and stamped out as an image so that the end result gets to your computer as a finished deployment artifact. Leads to better update reliability, built in rollback.
The biggest benefit is that it’s easier for a community to fix the fast moving gamer stuff as a config layer on top of a distro that’s delivered this way than me having to manually figure out what component of my gaming setup changed that week.
being a mutable minimal CentOS. So all the linking and making immutable would need to be done.
No it’s designed to be consumed as a base image for ostree enabled OCI containers.
This requires the presence of rpm-ostree and a kernel, which are both missing in the CentOS Stream image.
There are ostree-enabled OCI containers of centos if you know where to look. :D
This should be enough until they start publishing official ones, never used it:
https://quay.io/repository/centos-bootc/centos-bootc-dev?tab=tags
I’m not a security expert but I do know that the Homebrew is working with openssf on security: https://openssf.org/blog/2023/11/06/alpha-omega-grant-to-help-homebrew-reach-slsa-build-level-2/
Boxkit predates wolfi so it’s still alpine, I’ll probably replace it at some point but most of the forks of boxkit are because people want the premade github actions and they end up replacing it with whatever distro they want anyway. The wolfi connection is because I know the people who work there (including a ublue maintainer) and we have similar goals/ideas on how linux distros should be put together. My ideal dream is a wolfi userspace systemd-sysext on top of fedora base, then we can have our cake and eat it too!
We’re not security experts but lots of us work in the field and that gives us access to peer review from experts when we set things up. We sign every artifact with sigstore so users can verify that the code used in github is what’s on their image, that sort of thing. And most of our practices utilize CNCF governance templates that lots of other projects use.
Been there and done that. It’s better to just not have the host OS break in the first place.
My Ubuntu installs are extremely reliable, both on desktops and servers.
Probably because you’re an experienced user, not everyone has the same skillset.
mozillavpn
I would just overlay this, that’s what it’s there for, there’s no need to do a full new image for VPN stuff.
We use quadlets to manage those containers: https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html
As others in the thread have pointed out just having systemd manage them is the way to go, it’s a nice combo!
What package is it?
Flatcar linux (this is what I use for my NAS/homeserver) and CoreOS are both good.
edit: OpenSUSE has microOS: https://microos.opensuse.org/
We probably won’t (we’re not looking to grow that much anymore), but I think someone should definitely take either portainer or the proxmox stack and just slap it on top a CoreOS image with a user friendly installer and make a killer SMB server.