We need another layer: A case for the "Use Case" Image

[castrojo]

(This is labelled as a concept, which is an inprogress idea or proposal, it is not resourced or scoped so mostly just a collection of ideas. Over time it might move to a proposal)

This was initially my attempt to pitch that we should be making "developer edition" versions of our images for ourselves. You run the one with all your libvirt, vscode (because people want it this way anyway, but that's a discussion for later) and some other heavy stuff, and like, why not.

The idea being is that this fixes the "Linux IT Mom/Dad" use case. If you're like me then shout out! I need more bling but I also have a bunch of family and friends PC that I get stuck doing IT for, so it's basically a list of packages is the only difference, since we have every desktop image anyway. So your image ends in -dx, and we double the amount of images we make, yolo!

But then discussion became more about just solving the use case. I see most of the forks that people are making and while you think most of them would be outlandish most of them are people who just need a handful of changes.

Someone on this forum has asked if we should make an image just for machine learning and our default has always been like "nah we want to be vanilla Fedora mostly". But now we have that, so like, why not just let people clump around images for specific use cases, and if we run into resource limits we'll figure something out. But we should have some level of commitment or if you're an expert in the field.

And I brought an example:

@A-Lovett ended up being a beta tester. Like maybe you know how to Linux but you just don't know how to map that to this new thing, but if Universal Blue gave you the setup and you could team up with people, it sounds like a powered-up version of what SIGs do today!

So we made Cinnamon in not a lot of time, and it was "bursty" work, just some initial setup and then it's basically done, and then everyone shares in the maintenance of the thing upstream which so far has been pretty automatic now that it's set up:

[castrojo]

And then to solve the Linux IT Mom/Dad use case we'd have to have nice Cockpit configs between your images and someone would want to solve that and then voila, personal Chromebook killer with full blown "Linux" distros.

And then maybe the Joe Ressington, the shaking fist at cloud guy would have no choice but to tell us how to design it, because it'd be literally be "run your own everything", and with ublue-os/forge you can do 100% self hosted.

[castrojo]

And then for the implementation, what about a github action that took inputs of:

• list of 3rd party repos
• list of packages
• yafti configs
• justfiles (this would be so useful for the more technical use cases)
• an ability to apply a band aid for special cases

Then reuse the existing build process we have. Then everyone can just use it with minimal maintenance on their part, and then it'd also be usable outside of ublue-os for people who want to do their own thing.

[bigpod98]

all we need to do is write it i guess

[xynydev]

what about a github action that took inputs of:...

That's basically startingpoint, or what it strives to be. The inputs are all just handed by the recipe and read by build.yml, build.sh and the Containerfile. Sure, it would be nice to transfer some of that logic to the GHA, which could then be reused. I like startingpoint as it is though, partly because a power-user can see everything that goes into it and modify the build files and all that.

I've also daydreamed of a program that just took in the recipe and spit out a folder with a Containerfile or a finished image it could push to GHCR. Since the heavy lifting happens in the Containerfile and related build steps, it wouldn't be too hard to replace the GHA with a custom program, though as long as GHA is the only environment that it needs to run it that would be counterproductive.

[JohnAtl]

And then for the implementation, what about a github action that took inputs of:

* list of 3rd party repos

* list of packages

* yafti configs

* justfiles (this would be so useful for the more technical use cases)

* an ability to apply a band aid for special cases

Then reuse the existing build process we have. Then everyone can just use it with minimal maintenance on their part, and then it'd also be usable outside of ublue-os for people who want to do their own thing.

This sounds very Nix-ish.

[castrojo]

Also purposely putting this as nice-to-have, medium-to-low as we're trying to chillops a bit more, so let's let this one bake for a while.

[bsherman]

chillops, ftw

[bsherman]

I like the idea a lot! I just want to make sure we have the foundation solid... Sounds like this will be some set of images building on top of.... main and nvidia... perhaps from a new common "dx" repo...

Also, we have akmods in progress right now... I'd like to land that before moving forward here. It's part of the core, hardware-enablement, goal, but still has some things to work out... cough cough like signing keys. 😉

[xynydev]

I don't want to ruin yall's fun, but I personally would not consider using such an image (unless it added something crazy cool useful) due to the following reasons:

• It would probably include something ootb that would be cluttering my box
• It might install something (like VSCode, as noted by jorge) on inside the image, when I'd rather use it inside a Distrobox for supreme integration
• It probably wouldn't contain anything that I couldn't add to my own custom image, which I would have either way because I like to tinker

This isn't denouncing the whole thing, but I feel like even a -dx image with common components would be more custom image territory (like a bluefin-dx) than a common image.
I also see creating Distrobox images as a better alternative for the dx on "immutable" distros than creating images with everything bundled in.
The valid case for something I do see being inside a common image is libvirt and all that virtualization jazz.

[castrojo]

The solution for you is pretty easy, you would just not use those images. 😄