Some lessons learned on installing Bluefin for devcontainers, Docker development

Bluefin
1

Folks,
after a week of experimentation with all the images in the Fedora Silverblue OS line (38, 39, and Bluefin combinations), I am gathering these lessons learned:

  • If you are just testing Silverblue and don’t mind reinstalling or removing the OS, start with any of the Silverblue, or Bluefin distributions or versions. For testing, with any of the Silverblue flavors, you have to be tolerant to experimenting with ground breaking stuff; although the Linux knowledge layer still applies. An idea: the degree of difficulty in Silverblue maybe two notches below dealing with Arch Linux. With Bluefin and Bluefin-DX that friction is significantly reduced. Want to experience pain yourself: go and try installing Docker and make it work together with VS Code in a bare Silverblue distribution!

  • If you are planning to be developing with this installation - as your first and last one -, then pick Bluefin-DX, because it carries all the tools, settings and configuration to start being productive immediately. Docker just works! I started with Bluefin, and although it has a way of switching up to developer mode with ujust devmode, some settings in Docker and vscode are not as reliable as one-shot Bluefin-DX. Maybe not right now but I am sure in the next versions they will be indistinguishable.

  • Not all your typical Ubuntu packages will be available from Flatpak or Flathub, but the majority are. They all work great, but if you some configuration issues, use Flatseal which has a GUI with very ample set of options. There is noticeable change in speed of performance if we compare Silverblue distros with Ubuntu 22.04. You would expect that an immutable OS would be slower, right? Quite the contrary, being Silverblue/Bluefin an immutable operating system, it boots pretty fast. In my machine Bluefin-DX runs 10 times faster than Ubuntu 22.04. Maybe not a fair comparison because 22.04 is much, much slower to boot than 20.04. And also I am guessing that because the immutable OS doesn’t care how much you modify your theme or GUI apps; it will boot fast time after time.

  • Something new to me - that I learned with Silverblue/Bluefin - is that you can “save” the preferred version of Silverblue OS that you are most satisfied with, and then later you can pick it from the boot menu. You do this with a simple command sudo ostree admin pin #, where # is the order of the OS images available when you type rpm-ostree status; It could 0, 1, 2, etc. For instance, this morning I wanted to boot with Silverblue 38 from 20240325, and one click got me back to that OS version.

  • You can switch back and forth between different Silverblue operating systems. Yesterday I installed Silverblue 39 just from the terminal with a one-liner rpm-ostree rebase fedora:fedora/39/x86_64/silverblue. Two days ago, I did the same rebasing to Fedora 38 Silverblue. It is not without its quirks. But I minimized them by creating a user for the new installed OS. For testing is okay but I do not recommend it in your developing machine. At the end of my testing week I have these OS available to me from the boot menu: Silverblue 38, Silverblue 39, Bluefin, Bluefin-DX, and images I saved as my favorites.

  • Installation of Silverblue OSes is pretty straight forward. I love the installer that does not conflict at all with other pre-installed operating systems such Windows 11 and two Ubuntus. I chose three different volumes for /root (40 GB), /home (250 GB), and /var (150 GB). For EFI and /boot/ I just followed the guidelines from Fedora: 300 MB and 1024 MB respectively. /var is very important partition: it is where your system settings live. /etc will be sym-linked to /var/etc, and so forth. Make your partition mappings and mounts against /var/mnt; avoid /mnt or /media, or you could get duplicate entries in some filesystem applications, such as Nemo.

  • The distroboxes are the hidden power or an immutable OS. If you cannot find you favorite package via rpm-ostree search <pkg> , it will most likely work via a distrobox. Pick the OS you are most familiar with. In my case, Ubuntu. If some GUI app doesn’t have a Flatpak, but has a .deb or .rpm file, then install it via a distrobox. I love BoxBuddy, perfect for a Ubuntu dummy like myself. I was able to install Insync, instead of Dropbox, via a distrobox because it didn’t work as a package in Ubuntu or Fedora. GUI packages, such as Flameshot, that don’t work because they conflict with Wayland, they work fine if you install it from a distrobox via Ubuntu. And so on.

  • If you are coming from the macOS world, you will feel right at home with brew, your best friend for installing terminal binaries. If I was able to make it work for Latex and tikZ stuff via TeXStudio settings, it is very likely will work with anything else. Whoever was behind the implementation of brew on this Linux: what a brilliant idea of creating an exclusive user for linuxbrew binaries and packages!

  • I extensively tested Docker and devcontainers and they work extremely well under Bluefin-DX. I tried with Bluefin but Docker+vscode do not work 100% out of the box as Bluefin-DX. My advice: go straight with Bluefin-DX and you will not regret it. There are couple of things that Docker doesn’t like in Bluefin such as opening an X-window in the host running in the container. Bluefin-DX doesn’t suffer the issue and X-windows open like hot knife on butter.

PS. I will continue adding more experiences as I recollect my thoughts.

8 Likes
2

Nice writeup! Mind if I nerd correct a few things?

Not all your typical Ubuntu packages will be available from Flatpak or Flathub

You install GUI apps in the Flatpak format from the Flathub repo, so “as flatpak from flathub” would make more sense. I maintain a list of more repos you can use, but most are development stuff

If you want packages for system stuff, like a VPN app etc., it is important if they are in the Fedora repos, or have a good 3rd party repo. If you are careful, COPR is also a good source.

If you really want Ubuntu packages, Distrobox is there for exactly that. But you explained that below.

They all work great, but if you some configuration issues, use Flatseal

Flatpak apps should not need to be unbroken. As most apps dont support modern standards like portals yet, so they get very broad permissions by default (like filesystem=host). Flatseal is mainly useful for restricting those apps, so that they cannot read your ~/.ssh or ~/.gnupg or other extremely critical stuff.

I maintain a list of modern Flatpak apps. If you find more, please add them!

Quite the contrary, being Silverblue/Bluefin an immutable operating system, it boots pretty fast.

The immutability has nothing to do with boot times. Pretty technical stuff about BTRFS and multiple images available there. It may be a bit slower due to complexity, but Ubuntu preloads Snaps, so…

Also, updates are done at runtime, which ensures boot times are always the same, never waiting for offline updates (like on regular Fedora).

I saw some boot benchmark of TechHut and Fedora (regular edition) was slower than Ubuntu. (Ignore most of the other benchmarks, using Flatpak Edge is crazy uninformed)

because the immutable OS doesn’t care how much you modify your theme or GUI apps, it will boot fast time after time.

The theme is in the home directory which is mutable (=changeable). So until we gets some “reset” buttons in the GUIs (KDE open issue) your settings and changes may build up old crust.

But you can use rpm-ostree reset and reapply your changes (if any) or simply rely on the core functionality of rpm-ostree to know that your system is nearly 1:1 the one tested and built upstream. Its really really great and immensely underestimated, how important that is.

But this is still excluding /etc and /var, so you can very much break your OS. I for example broke screenshots once, because a previous firejail “apply to all apps” command placed override .desktop entries in the home directory.

Due to the philosophy “users can change their settings, themes, entries, fonts, … but not the system!” that Linux systems follow, that immutability is pretty flawed by design without measurements like

  • resetting all settings
  • syncing /etc with upstream

that are currently not available.

It is not without its quirks. But I minimized them by creating an user for a new installed OS.

Important point and easy solution. Thats the issue with a mutable home directory.

In theory you could also use btrfs snapshots, and I hope this will come around some day. btrfs-assistant is a tool that can likely do that.

/etc will be sym-linked to /var/etc

I think that is wrong? /etc is mutable and not symlinked to /var/etc at least on ublue Kinoite-main.

avoid /mnt or /media, or you could get duplicate entries in some filesystem applications, such as Nemo.

I think mounting there would straightup not work. udisksctl, which is an awesome and kinda not mentioned tool used everywhere (like your GUI filemanagers) for privilege-less mounting, mounts filesystems to /run/media/$USER/ which I think is actually /var/run/media/$USER.

GUI packages, such as Flameshot, that don’t work because they conflict with Wayland, they work fine if you install it from a distrobox via Ubuntu

That is odd, as Distrobox apps will run through wayland too. If they would run through XWayland, a screenshot app would not see anything apart from itself afaik.

This is likely a Flatpak issue that should be solveable.

3 Likes
3

Yes, it is wrong. I should have said /opt, /usr/local, /mnt, /root home, /media, and few others. But /etc is not symlinked.

2 Likes
4

I literally just installed Bluefin! Wish I had read this the day before. What are the issues you ran into? Can you provide some colour? Should I ditch everything and reinstall Bluefin-DX from scratch?

5

Hello @akarypid,
there are not really a lot of issues. Probably few. But there was one particularly annoying that I found when I was developing with devcontainers and vscode. When it was the moment of running the container from vscode, I couldn’t get Xwindow to work with the container application. There are several methods to automatically share a GUI from a container to the host. I thought it was something I did wrong , or missing package, or bad configuration. Running GUIs from a Docker container is pretty straightforward but it was not working for me. After I exhausted all the tricks in the bag, I nuked the current installation (Bluefin switched to DX) with a full blown Bluefin-DX from scratch. I know it is a pain to start all over again with the partitions, the installation of essential applications, etc. But it was worth it. After logging in into my new Bluefin-DX, the first thing I did was testing vscode with devcontainers with Docker. They worked perfectly.