Bluefin - rely on OCI layer sharing for distrobox and devcontainer

Bluefin
1

Of the 3 experiments I have performed so far, this one seems to offer the best balance of features and HD space utilization.

Problem Statement

As a developer using one of the bluefin-dx bootc images, I would like:

  • a set of OCI images that can be used for both distroboxen and dev containers

  • manage the versions of tool chains between development projects as they are encountered in a single place

  • e.g., the version of zig should be the same in a devcontainer and corresponding distrobox

  • but multiple versions of zig can be accomplished with multiple image tags (e.g., 0.13 vs nightly)

  • the version is managed by changing the value of a single ARG or shell variable (as appropriate)

  • such that most of the layers (think HD space utilization) will be shared between the distrobox and devcontainer

Please see klmcwhirter/oci-shared-images for more details and a sample implementation of this idea.

2 Likes
2

This would be very nice indeed
I hope it also works in Aurora.

3

@Blaise , I haven’t tested Aurora, but the concepts are general enough that they should not even be Fedora specific. Just my sample implementation relies on things like dnf. But those things should be easy to change.

FYI - I am using bluefin-nvidia-dx:stable and see there is an aurora-nvidia-dx.

And I make no assumptions about the base on purpose. That is kind of what started all of my experimentation. I have been challenged by bluefin to rethink all of my assumptions about working with and managing a linux development workstation.

Please do let me know what you find!

I have been wanting to do an rpm-ostree rebase ... to something else just to see how it goes.

1 Like
4

A few months ago I did rpm-ostree rebase from bluefin to aurora and was so fast that I stared at the screen, waiting for it to finish. It was already done and it took me a while to notice that the process was complete.

1 Like
5

Very cool. I guess that is one of the benefits of this bootable container approach to OS delivery.

I’m mildly concerned about mods in /etc (for example), but they have been few and minor in my case.

Thanks for sharing your experience!

6

Looking at your README, can I just say that I appreciate the way you write up the project, describe the requirements and summarize the work towards the various goals ad track your findings.
I wonder if it’s informed by some particular training in lab techniques or engineering. It’s more structured than what I’m used to seeing among software developers.

7

Thanks for the kind words. I have been writing in various formats since about 10 years old. It is a passion of mine. Also, I have had a lot of experience working on and leading large projects in various capacities. At one point I had 2 technical writers working for me. I have also worked with some really good BA’s and BSA’s over the years. The combination of those experiences helped me to learn how to put myself in the user’s perspective. I.e., if I were that person, what would I need?

I have also done years worth of writing for organizational news letters, 10+ years as a Solution Architect, built and ran a QA department, etc. I have had a rich and rewarding career.

To answer the question - pretty much on the job training. I made a point to accept challenges as they presented themselves; taking them as an opportunity for growth.

I guess I learned a few things over the years. :wink: