Prototyping the Bluefin-cli experience

Bluefin and Aurora
1

Alright everyone, so far this cycle we’ve been concentrating on finishing up the developer experience for Bluefin-DX, today I’d like to give you a quick status of the command line experience.

The Ptyxis Terminal

We are shipping the Ptyxis in the F39 builds and newer, which has automatic built in support for toolboxes and distroboxes. Users can quickly fire up a host terminal if they need to do host-level things but we’re adding more host-exec functionality in our distroboxes to make this less of thing.

The plan for distroboxes

We’ve always shipped Ubuntu as the “default” distrobox, along with Fedora. There will be no changes here. I still need to go back and polish up the distrobox.ini, but generally speaking these boxes are complete.

The bluefin-cli distrobox

After lots of false starts, we finally have a decent bluefin-cli container. This is our attempt at shipping the perfect toolbox container that has everything any linux admin could ever want.This will be one of the options the user can choose on first run. You can try it this way:

distrobox create -i ghcr.io/ublue-os/bluefin-cli -n bluefin

This will make a bluefin distrobox for you. This is a WolfiOS container designed to hold brew and is intended to be your terminal experience. At some point this will be managed via a systemd quadlet on your system and will automatically show up in your Ptyxis terminal when you enable it (but we’re not there yet). But you can start to use it today!

How it will behave

On a fresh install you’ll run Ptyxis and a dynamic motd system will ask you to enter a command to configure your distroboxes. After you do this the bluefin-cli quadlet will be enabled. This will pull the container, and will automatically update and destroy the container daily via the podman-auto-update.service. You’ll get a freshly built container built from scratch regularly – no inplace upgrades. No pets. :smile:

The wolfi container contains brew, which is where you can install your CLI apps from. ncspot, btop, zellij, ollama, and whatever other CLI tools exist in homebrew. We picked homebrew because it has just about everything and uses OCI blobs for transport, which means plenty of mirrors and bandwidth. Both Homebrew and WolfiOS also automate large portions of their packages so that we can get the newest versions of everything.

The packages you install via brew will survive the container’s destruction thanks to @M2 keeping the brew package state outside of the container. So your base wolfi container will always be up to date, and brew always ensures its packages are up to date. if you’re not familiar with brew then I’ll make sure to link to the brew bundle subcommand so that you can always save your package list and keep it synced however you want.

What’s left to do

The motd, quadlets, and lots of “wiring it up” is left to do, but the box is working well enough now to widen the net. We will be blinging it up a bit with starship and some colors.

Additionally there is a “blank” wolfi-base container in the repos with the minimal amount of packages you need to make your own distroless container. As wolfi continues automating the world more and more packages can just come via apk and via your personal container for that nice clean experience. In the meantime brew can fill that long tail of packages. Personally I’ll be filing issues in wolfi to have them add the packages I need every day so that I can just run all my computers from my perfect container. Wolfi has been very responsive to packaging requests so dive if you want to learn how!

Source Code and Getting involved

Here’s the toolbox repo that contains the toolboxes. Issues and ideas are welcome here or in the issue tracker.

References

Consolidating a few threads from here:

Happy to answer questions! Did I miss anything?

8 Likes
2

We got some interesting feedback on Lemmy wrt. CLI installation. Anyone have opinions on this? (I responded on lemmy)

3

It’s sort of a matter of target, from my perspective.

Generally speaking , the folks that are interested in leveraging the -dx stuff, largely are going to be folks that are fairly comfortable with doing things in a cli.

Can the documentation on how to do things be better? Sure (But that’s hardly a new issue in the FOSS world, or even software in general)

Creating some sort of unified GUI interface for all of the potential ways to install software could probably be done, but I can’t see where it would be particularly “easy”.

As far as Flatpak only being for GUI Applications? I think that’s a plus, frankly. It gives Flatpaks a focus, that snaps lack, to my way of thinking.

I mean, technically, I don’t think there’s really anything stopping anybody from packaging up something that’s only CLI/TUI in a flatpak container, but that’s all it is, is basically replicating the functionality of distrobox/toolbox/docker/podman

4

I’m also working on a 10m “how to use this thing” video
@jorge

(make it 20m! :laughing:)
Looking forward to it and definetly YES to:

do you think we should say that more strongly?

and maybe it’s worth re-explaining for the new comers (I know there are the older videos) what’s this project about, its intricacies and uniqueness… especially for the people new in the cloud world!
thanks!

1 Like
5

Yes, I think this is an issue for people new to cloud native. There’s this idea that “one package manager for everything” is the right way to do it.

We explicitly split them because we purposely don’t want the system and the workloads to mix unless they’re talking through APIs like portals or the container runtime. We purposely try to remove as much host packaging maintenance as possible (ie. the need for the user to use a system package manager is removed) IMO maybe we should just call out antipatterns like flatpak CLIs.

1 Like
6

Ok I’ve changed some parts of the bluefin-dx page to be more strongly worded about “the right way to hold it”: Bluefin-dx - The Bluefin Developer Experience

I think splitting out the Machine Learning stuff into it’s own page will help streamline this more, thoughts on that? I’ve cut out the ubuntu container part entirely, put devbox at the bottom under optional, and moved devpod to just be under vscode to streamline it a bit. Thoughts on this?

1 Like
7

One question I have, is about the automatic destruction and update of the containers: what’s the workflow for handling long running terminal instances that are using those containers? I tend to have a handful of terminals that stay open nearly perpetually, more often than not have an in-progress project (e.g. code in a text editor) that would potentially lose data if the container were to be abruptly destroyed.

Would this just be down to me ensuring there’s no volatile data in a current terminal/container (probably a good practice I should do anyways I suppose) or is there some mechanism to avoid destroying actively used containers?

1 Like
8

hey @j0rge,
good re-write, way clearer and applicable.
caught a dead link:

Here’s an example distrobox.ini file

great ressource: Ultimate Guide to Dev Containers

9

hey @colinshrubs , I assume your talking about distrobox when you talk about containers right? I’m interested in the solution as well.
I was also asking myself this questions about devpod, how to recover the data… :thinking:

10

Should be fine unless you log out or reboot, so the behavior should be the same as it is with a host terminal. EDIT: upon further investigation it seems the podman-auto-update docs say that it does restart container. Does anyone have time to test this? M2 thinks we should alter the behavior if it’s triggered via the update service.

11

Just a quick preview of how it’s coming so far. Here’s what the host, ubuntu, and fedora terminals will look like.

Some of you may have been experiencing the churn in the Prompt terminal lately, thanks for your patience and feedback!

image
image1920×804 167 KB

If you want to test drive the colors the blue one I’m using for Fedora is called “Elio” and the ubuntu one is called “Clone of Ubuntu” (lol). Bluefin-CLI is using Catpuccin Dynamic.

3 Likes
12

Dang, that looks pretty nice

1 Like
13

Where does the “Catpuccin Dynamic” theme come from?

It’s not on their website: https://catppuccin.com/
They only list “mocha”, “macchiato”, “frappe”, and “latte.”

It’s also not in the Ptyxis repo (also just has those 4): src/palettes · main · Christian Hergert / ptyxis · GitLab

Google search just leads back here.

14

Oh, just found the relevant commit… feat: Add modified Catppuccin theme with dark/light support as the de… · ublue-os/bluefin@507ae9a · GitHub

So, it’s just a combination of the Light and Dark (“Latte” and “Mocha”) color schemes from Catpuccin.

15

Yepp. There are only handful of themes that change automatically between light and dark theme. We added that theme.

As you can see it’s not too difficult to add your own dynamic theme that toggles between light and dark!

1 Like