Bluefin is an out-of-this-world experience!

Bluefin and Aurora
1

Just finished installing some Linux applications, containers, and setting up few things.

Bluefin is great!
Ready, out of the box, Fedora SilverBlue 38 derivative operating system.
I am impressed!

Background

Started couple of days ago with the installation of Fedora SilverBlue 39, and had a taste of the new world of immutable OS. Unfortunately, the distrobox installation was too brittle aborting the installation of packages in Ubuntu 22.04 and Fedora 39 containers. I reinstalled SB-39 couple of times more but with the same problems.

So, I decided to give Bluefin 38 a try. Although, seemed intimidating for an engineer with no heavy developer experience. I know Docker, VirtualBox, VmWare WorkStation, R, Python, Java, SQL, data science and machine learning packages but never tried experimenting with “specialized” operating systems such as BF-38.

It has been an excellent experience so far. No more brittleness in Ubuntu 22.04 or Fedora 38 OS containers. And what’s more, I was able to make TeXStudio work with texlive. I installed the flatpak for TeXStudio, and texlive with brew. The only trick is to set the options to look at latex, xetex, lualatex, etc., in the new /home/linuxbrew/.linuxbrew/bin/__tex.bin

Motivation

The main driver started when building artifacts (books, blog, papers, etc.) with RStudio Quarto. It is a very good application for combining markdown with R, Python, Julia, and JavaScript. The thing is that relying on the operating system of the physical machine is like trying to cross the Grand Canyon on a wire without any net! So, you end up building virtual machines to isolate the development of the R/Python artifacts. Using Docker container is the other sane option but Ubuntu 22.04 - my preferred OS - is not prepared to handle such chaos of multiple containers or VMs or QEMU oses.

From now on, I just build a new container, or use an old one, to install, for instance, a JavaScript environment to test scripts to be used later in Obsidian.md without disturbing the physical machine, or building a VM or container in the traditional way.

The key thing here is to get out of our comfort zone and try specialized development operating systems.

Thanks to the team that made Bluefin happen!

13 Likes
2

Welcome. I’m new here as well, and having a similarly awesome time with Bluefin! I’ve been using Linux for three decades and haven’t had this much fun in a LONG time!

The Universal Blue discord server has a Bluefin channel, and the members are extremely helpful: Universal Blue

Enjoy!

4 Likes
3

Ah! Another Rstudio and TeX user!

How did you deal with installing Rstudio? Here is my topic where I installed via Distrobox → Fedora container → dnf install rstudio → Export App in BoxBuddy. A bit convoluted, but it works. Unfortunately, I don’t have an Rstudio icon, just a blank page. I then added cran2copr for binary installation of R packages.

I used TinyTex as an alternative to installing a LaTeX distribution, and it worked really well, even outside of Rstudio with an editor like TexWorks. It still gives me access to tlmgr to install new LaTeX packages.

1 Like
4

First, this time with Bluefin/SilverBlue I will try not to alter in any way the OS, by installing R and packages in the host, because with R changing in every version makes code obsolete relatively quick. I think the best strategy is to isolate R/Python projects in their own working environment. So, when one needs them they run, and not failing because of unmet dependencies.

Second, the first thing I did once I installed Silverblue was testing R and RStudio from a distrobox, otherwise no deal. I used an Ubuntu 22.04 distrobox, and R, RStudio, and Quarto run like in any other dedicated machine. You just have to take care of exporting R, RStudio, etc., with distrobox-export --app myApp from the container terminal. But this is not an adequate, universal, reproducible, or permanent solution because you end up with a unique R/Python environment available to the host. Precisely, what we are trying to move away from.

Third, what I am learning from others who want total isolation of R/Python environments from the host and permanently reproducible projects, is this: (i) use devcontainers; (ii) configure and run devcontainers from vscode; (iii) install R, Python, RStudio, Quarto, Linux dependencies, R and Python packages in its own dedicated container (not a distrobox) built with docker; (iv) avoid using RStudio for development and do it instead with vscode; (v) install R/Python extensions in vscode to make it flexible enough. Extensions such as R Language Support, Quarto, radian, etc.

5

Hmmm, your needs seem much more demanding than mine. I just went down the distrobox and container route and that has worked fine, except for the icon.

1 Like
6

I think it works almost the same way. In your case, you will have to manually switch - or maybe not - the appropriate distrobox for your projects. You can have as many distroboxes as you want, providing the physical limitations of your hardware.

I say “almost the same way”, because in my case, with almost a hundred of bookdown/Quarto/R+Python artifacts , if I want them fully isolated and fully reproducible, I will have to have a hundred independent containers. They may not need to exist or run simultaneously but with the Dockerfile and devcontainer.json, they will always be ready to build and run. There might be projects that have plenty of similarities that could share a Docker image; while those very niche and specific may need its own image and container. From this point of view, it is not that “expensive” given the gains in reproducibility, reliability and availability.

It is the kind of same deal with Silverblue immutable. Some things run differently as compared to a standard Linux OS, such as Ubuntu, Debian, Fedora Workstation; other things are excruciatingly difficult to install but the payoff is great given the fact that an immutable OS is in theory - and I am seeing in practice - unbreakable, durable, and everlasting reproducible. Applications do not collide; each app runs in its own lane.