Thank you for the answers and listening to the feedback.

Your starter steps are exactly what we want the default to be, do you think we should say that more strongly?

Yes, I’d definitely try to make it more clear to the user that the ubuntu/wolfi distrobox is the way to go and that all the other installation methods are just bonus for those who need it.

Also, I think it’s a bit confusing for newcomers whether to choose bluefin or -dx. It seems like dx is always the better option, even if you end up not using all of the extra features

hey, I’m a bit overwhelmed by all the options you provide to install cli programs. There’s nix, fleek, devbox, devcontainers, distrobox, incus, brew and probably even more options.

I just want one preferred way to install my cli programs globally, like on normal distributions, but it is not clear which option is the default one. After digging through posts on the forum I found out that the ubuntu distrobox with apt is supposed to be this default installation environment. Maybe make that clear when someone opens the host terminal on bluefin, or let the bluefin installer give this info to the user.

Even then, projectbluefin.io in the FAQ section suggests that homebrew is the creator’s preferred installation method, not ubuntu. So which one should I use now? On one hand, bluefin’s default DE is GNOME which is very simplified and has one correct workflow, on the other hand bluefin provides a multitude of choices all seeming equally viable, which is more in line with KDE’s philosophy.

Also, why prefer homebrew over something like nix? AFAIK, homebrew leads to the same dependency issues that the traditional package managers have.

Additionally, what is making ublue hard for me is that all the important info seems to be scattered on the ublue website, blog posts and forum posts. I’d really like it if there would be one website which gives clear guidance for people who are new to bluefin (or bazzite etc.). Not explaining all of the possibilites, but just the most important stuff to get started. Just a really dumbed down, compressed version of the existing ublue guides. The users can figure out more themselves afterwards.

Something like:

• install bluefin-dx (not the regular bluefin)
• only install graphical stuff via flatpak
• only use the ubuntu terminal for any terminal stuff, including cli program installation
• do not use the host terminal unless you are doing host administration with ujust or rpm-ostree
• etc.

These starter instructions may not be perfect, but at least then the users have a daily driver they can learn more about over time instead of having to learn everything before daily-driving ublue.

Thank you for all the hard work you guys are putting into this, I’m excited to see the project mature

Thanks, I will try that out. I want to use uBlue as well, but cli program installation has been holding me back.

uBlue also makes nix available via fleek, but the way you describe it it seems easier to just use nix directly

The point is that you can not find most cli programs on Flathub, de facto making Flatpaks unsuitable for cli programs. Snapcraft on the other hand hosts neofetch, dust, youtube-dl etc.

How long have you been using distrobox and which were the biggest painpoints yet?

Flatpak is only for graphical programs

With Nix you have to do everything the Nix way. If a package doesn’t work correctly or is missing you either have to dive deep into the Nix rabbit hole or wait till someone who knows stuff fixes your problem. With nix everything is all or nothing (even more so with NixOS).

Distrobox is the opposite, it embraces variety and gives you as many options/distro environments as it can. Once the missing container bugs are fixed you are dependent on no one to get your packages working.

Also, Nix is usually not the normal way devs package their software, so there always have to be people repackaging the stuff with nix (and updating when the source package changes).

Distrobox gives you access to the environment where the stuff is packaged already, a lot less work is needed to get working packages which should not be underestimated.

The more packages you install with nix the higher the probability you encounter packages no nix expert has cared for recently