What images should have what desktop configurations??

[castrojo]

From ublue-os/surface#23

How to handle different Surface variants/DEs? The Surface laptops should have the desktop GNOME/Plasma but for the tablets we should have Phosh/GNOME Mobile Shell/Plasma Mobile.

I don't have one of these so we'll need to start gathering input from folks and then start filing issues after we figure out the how.

[keplersj]

I propose that like Kionite is specific for Plasma Desktop, there should be variants for touch driven DEs like Plasma Mobile and Phosh. I've been using Gnome on my Surface Go for years now and am vary satisfied with it, but understand the appeal of a more touch driven DE on this class of device.

Additionally and tangentially related to this issue, if there is a variant developed for Plasma Mobile there should be a variant developed for the Plasma Bigscreen DE that would serve a similar purpose to the HTPC Bazzite variants.

These seem more relevant to the uBlue project at large, than specific to Surface devices.

[castrojo]

These seem more relevant to the uBlue project at large, than specific to Surface devices.

Yeah the issue with that is we'd multiply the amount of images dramatically if we did it up the chain. Perhaps this would be a good place to start prototyping what it should look like, and then moving the pattern up in places where it makes sense? cc @ublue-os/approver @ublue-os/member

EDIT: Also I wonder if a good middle ground is just adding those specific sessions in the login manager so that the user can pick on the device?

[plata]

Also I wonder if a good middle ground is just adding those specific sessions in the login manager so that the user can pick on the device?

That's basically what I did in https://github.com/plata/ublue-surface: it is Kinoite + Plasma Mobile.

However, I'm not so sure that you'd want this at scale. Plasma Desktop and Plasma Mobile share a lot but GNOME and Phosh or even GNOME and Plasma Mobile? It will become pretty big soon.
On the other hand, we probably don't want to (or maybe even can't) remove the original DE from Silverblue/Kinoite. So unless someone creates something like Kinoite Mobile upstream, it will always be Kinoite + Plasma Mobile.

So: If we do not want to increase the amount of images, the only way can be to layer it on top of the existing images at install-/runtime. I.e. the installer/first boot wizard would provide an option "Plasma Mobile" etc. and then rpm-ostree install the required packages.

At this point, however, we're entering very fundamental considerations of what should be in a distribution and what should be configured/installed by the user. There's a similar issue already with Flatpaks: which Flatpaks should be preinstalled, which are suggested in the wizard, and how can I still keep the advantage that the OS is super tailored for my needs while being general enough for a huge group of users at the same time?

[EyeCantCU]

In my opinion, Phosh and Plasma Mobile should be separate images. Both will require significant adjustments that would interfere with the scope of existing GNOME and Plasma images were they entangled. With that said, I think this is a great idea and I will look into it

I will investigate further, but I suggest we set up a new repository, mobile, that builds Phosh from our Silverblue (or base) images and Plasma Mobile from our Kinoite images

[keplersj]

Phosh and Plasma Mobile as seperate images would also align with their primary purpose as desktop environments for handheld devices (specifically smartphones). The uBlue build pipeline may not be ready for this right now, but I for see a future where it is able to build images for specific ARM SoCs with hardware enablement for specific boards and phones. Imagine postmarketOS but built with cloud-native tech.

I think uBlue is uniquely positioned to fill the role of an immutable mobile phone distro in the future, and that this conversation is even happening is proof of that.

[plata]

That would be really nice.

@castrojo can you elaborate on the limitations regarding number of images? Is it a management problem or do we hit GH actions/GHCR restrictions?

[castrojo]

We're currently not hitting any limits it's more of a human issue. Each option you add doesn't just increase the image pool by 1, it adds an image for 37, 38, 39, with and without nvidia, etc.

And ARM would double the amount of images on top of that. My question is more "Are there enough of people that would use these?" that would make it worth the effort?

[castrojo]

It ends up we're not the only ones! https://www.opencode.net/justinz/oneplus6-fedora-image/-/blob/main/Containerfile

[keplersj]

The OnePlus 6 is a very good example of the model I explained above. The Qualcomm SOC it runs is one of the best supported for aftermarket use with an almost mainline kernel, meaning that not only is the OnePlus 6 & 6T well supported with one kernel but so are phones from a few other manufacturers that use the same SOC. Because the phones themselves require slight differences in init and userspace postmarketOS builds seperate images for them. The uBlue image model would serve very well here. Other examples would include the Allwiner SOCs in the Pine64 products, and the Apple Silicon images built with the Asahi kernel

[keplersj]

Within the context of Microsoft Surface products, adopting ARM images would allow this repo to support the Surface Pro X (https://github.com/linux-surface/surface-pro-x) and eventually the Surface Duo (https://wiki.postmarketos.org/wiki/Microsoft_Surface_Duo_(microsoft-duo))

[plata]

It ends up we're not the only ones! https://www.opencode.net/justinz/oneplus6-fedora-image/-/blob/main/Containerfile

I was aware of this.

It's not quite the same, though, because what they do is just use a Containerfile to build a "regular" Fedora image (not immutable). And it's more a PoC than something close to official (Fedora mobility SIG).

However, I believe that the uBlue infrastructure puts uBlue in a position where we can support such endeavors with tooling and a more formalized approach.

We're currently not hitting any limits it's more of a human issue. Each option you add doesn't just increase the image pool by 1, it adds an image for 37, 38, 39, with and without nvidia, etc.

To minimize the maintenance burden, we should:

• Formalize a strict repository structure (e.g. as outlined by startingpoint) which is followed everywhere such that it's immediately clear which information can be found where.
• Provide all reusable building blocks as plug-and-play modules in https://github.com/ublue-os/bling.
• Turn the GH action files from startingpoint into a real GH action (in a separate repository) which hides all logic and only exposes some parameters. This should also eliminate the need to merge startingpoint.
• Have a set of base images for Silverblue/Kinoite/Plasma Mobile/Phosh/...

(We have most of this at least partially already.)

Ideally, I would imagine that a uBlue repository does not even have a Containerfile but just the recipe plus eventually some scripts/modules which are not useful for any other version.

With this, adding and maintaining a new uBlue version should be pretty straight forward even for people who know nothing about git, scripting and Containers.

The final step would be to not maintain those new versions by the core team but give maintainer rights to others. A feasible approach to achieve this might be something like flathub does, i.e. have a repository where people can create a PR for a new uBlue version, then turn this into a repository.

[xynydev]

Ideally, I would imagine that a uBlue repository does not even have a Containerfile

This would require commiting to the same approach, or even the same tools as VanillaOS, ie. a Containerfile compiler. Could be great, especially if we can work on top of Vib, but would bring us very far in terms of abstraction.

[plata]

With the startingpoint approach, the Containerfile is already empty. It only duplicates some information (e.g. base image) which is already contained in the recipe. So the "compiler" would only replace ~2 variables in a template.

[xynydev]

It doesn't duplicate that information, the information is given as build arguments and there are placeholder values for if someone doesn't pass the correct arguments.

To go containerfile-less, it should be possible to generate a containerfile from scratch, not from a template. With a template, the approach would be very similar to how everything currently works, but worse. This would also require an implementation of COPY for the recipe, which is something Vib already does.