Bluefin is feature complete

Alright everyone! It took way too long to get here but Bluefin is feature complete. All the major surgery is done, the plan now is to chill from now until end of April and wait for Fedora to release. Then we’ll have a party as we flip the switch. Please continue to file bugs and give us feedback as you tame your new raptor!

ujust brew

What is now Bluefin 39 will become the new gts, and this will be the default. This is the Linux I’m going to give to my friends! Those of us on :latest will move on to F40 and continue forward. And then the circle of life will continue.

The last major change - brew is back

Some backstory:

For a long time we rolled with brew available on the host. This led to problems that took a while to surface, mostly conflicting with the host’s path. So if you brew install ffmpeg it would pull in a library and flatpaks would break (lol). Two nights ago @bketelsen found a way to put brew on the host but in a way that won’t conflict with the host paths. We’ve put this through a bunch of testing and it’s working awesome. It’s working awesome indeed!

What does this mean?

So where does brew fit? Well, we’ve eliminated most of the need to care about cli packaging. The blog covers most of the details but the system packaging is already out of the way. That leaves flatpaks for GUIs and then we need CLI apps. And people still want them on their host and don’t want to use a container. brew has just about everything and a large part of our target audience is already using it. Feels like a nobrainer.

Then you won’t need to layer to add neovim, btop, and all that other stuff. It’s already tied into ublue-update so that’ll be automatic.

And that’s it. Flatpaks and homebrew. And then everything else distrobox has you covered and with ptyxis and boxbuddy together in there that’ll be a way better experience than most people get ootb with this stuff.

But it is not The Final Shape

I call the completion of the next generation linux The Final Shape. This refers to what the end form looks like. Brew is still a stopgap, we gotta put gcc on the image for crying out loud, sacrifices have been made.

The team has been investigating using systemd-sysext as a means of extending Bluefin so that we can have one base image, and then bolt on things like -dx, etc. This would reduce the image count and size, and would let us do all sorts of awesome things without needing to touch the base OS. Add an atomic layer that you can bolt on (no reboots needed) and go to town.

Hence some of us now believe that bluefin-cli and the rest of -dx will move to being sysexts, and bketelsen is the one leading that charge if you’re interested. This will let us source the CLI experience from wolfi and that gets us all the latest things we want at the system layer.

This will take time and baking as the feature is fast moving upstream. So that will all be future work, in the meantime we’re good enough. Many things that we have now didn’t exist when we started. All we had was distrobox. Now we have ptyxis, boxbuddy, quadlets, systemd-sysext, wolfi and, brew along with a whole bunch of other stuff. :smiley:

Last Tidbits

There’s some loose ends to tie up, we need zsh support for the brew stuff, and whatever else you find and file. Thanks Hikari!

And Docs! A reminder that all the docs are wikis so you should be able to pop in and fix em up, or feel free to write up a thing and tag it with documentation. Gonna need some help on this one!

Anyone have any questions or comments?



How do system extensions fit into the atomic model? I know we’re not dealing with individual packages still, but it seems like we’re dealing with two main layers?

Here’s my understanding of how this works. There’s the atomic image and then however many atomic extensions you add. Then you have your home directory which can change, flatpaks, and containers.

What is the possibility of breakage between an updates that came from the atomic image vs the extensions? Is it just reduced risk of breakage compared to updating individual packages as we do in the traditional model?

Yeah, this is how it is conceptually. As far as your other questions that’s what we need to find out. It’s a rabbit hole, but this is a good start:

1 Like

Oh I should have added, all the distroboxes are set as well. The Ubuntu and Fedora ones could probably use a quality pass if someone wants to take a look. bluefin-cli is in a great spot with the quadlet too.

Given these exciting recent developments with systemd-sysext and Homebrew on the host, what’s the updated vision for the intended relationship between Homebrew and bluefin-cli? e.g. will bluefin-cli continue to come with Homebrew? If so, will bluefin-cli’s Homebrew share configuration/state with Homebrew on the host; or if not, what will be the recommended way (if any) for end-users to add more programs in the bluefin-cli container on top of what bluefin-cli already provides by default?

Also: when should we prefer to add CLI tools in bluefin-cli rather than via Homebrew the host? Or will Homebrew-on-the-host be the primary recommended way to add CLI tools from now on?

And finally: what is the likelihood that Homebrew-on-the-host, being a stopgap, will be deprecated after bluefin-cli-via-sysexts ships as The Final Shape?

(for context, I’m planning to migrate away from aqua since Bluefin’s endorsement of it as a workflow seems to have been removed/deprecated with the removal of the just aqua command in PR 852 - so I want to understand what I should be migrating to, and whether I should migrate soon or continue waiting for things to settle down first)

Not sure yet on any of this part. Part of the reason we went down that path is because brew on the host was not an option. But now if you’re getting the same stuff anyway … I’m just gonna run with both for a while and see what people say.

I think this is the way to go. You can give this to a linux user who has never used an atomic system this and it’s not that far of a leap. They can remove one of the biggest things people complain about – that their system package manager is weird and needs a reboot. Now they can install btop or whatever and be happy.

Unless there’s a technical reason I don’t see any reason to ever remove it. It’s a strong community with tons of adoption, it’ll just be a thing that will need to be there.

The more I think about it the more of an advantage it becomes. Major distros aren’t going to enable this out of the box, their incentive is for us to use their distro packages. If all we did was be the OS that ships homebrew then that’s a good market to serve because that’s a lot of developers. :smile:

I appreciate your willingness to try it out! Yeah, it’s fun to experiment with them. I think this will be fine.

1 Like

Ooooh, another way to think about it is, bluefin-cli will just be rolled into the system. It’s a system extention but that will be transparent to you. So your host will be fedora but have the wolfi components etc for your shells, eza, atuin, starship, etc. so we get all of that stuff real fresh installed at the system level.

Then brew will handle all of the user’s stuff.

1 Like

Oh wow. I didn’t know about systemd-sysext. Sounds like a match made in heaven. I’m really exited about this. Thank you so much!

This will be really useful with permutations like -dx -framework -sway -whatever

1 Like

Can the extensions feature be thought of as two atomic puzzle pieces that will click together in an atomic way?

1 Like

@Joseph_of_Earth To quote the manpage:

During boot OS extension images are activated automatically


Note that there is no concept of enabling/disabling installed system extension images: all installed extension images are automatically activated at boot.

All sysexts are applied in one step. From a technical standpoint there is a short time span during boot when the sysexts are not mounted yet, but that probably doesn’t count, right?

1 Like

love the profile pic @stego :stuck_out_tongue_winking_eye:


Added some quick instructions on what needs testing here: Reporting bugs and issues

This could’ve saved me hours of work. I was trying to figure out why bluefin-cli isn’t working. Works GREAT now though

Please add documentation for dotfiles though

Which dotfiles do you mean?

I want something ‘next-gen’ for my desktop distro and not sure if I should start using Bluefin or NixOS. NixOS is lately getting a lot of hype and don’t understand why Universal Blue and Fedora atomic desktops not so much.
Thanks for your work

Has the ‘News’ section of Universal Blue website been deprecated?

yeah you can follow the announcement tag for news: Topics tagged announcements

Will ujust brew be available on Bazzite?

Yeah hoping to move it into the config repo so it’s everywhere, just haven’t found the time.

Great, I’m looking forward to it :slight_smile: