Bluefin as a systemd system extension.

[castrojo]

updatectl enable bluefin on a GNOME OS system would be a cool idea. Is there any tooling we could use to turn the combo of common, brew, artwork, etc. into a sysext?

We've been discussing wether a Bluefin ddi image is a good idea. I think having one is cool, I take a "we have to make one of everything and then see what they feel like in production for a while" approach so I think we should do one.

However just bolting on Bluefin onto GNOME OS and getting the same result is also a very appealing proposition. It does have an installer already. 😄

EDIT: Brainstorming with Adrian and came up with this: "Bluefin is a developer experience for GNOME" and wanted to add it here. That sounds awesome to me. We just become a turbo button for GNOME OS and then we'll be done!

[AdrianVovk]

From a GNOME OS perspective this should be doable, I don't see why not. I like the idea. It's a very traditional distro move to fork an upstream OS (and all the maintenance burden that brings) just to apply some customizations on top, and we have cool tech that lets us avoid that now

I do have a slight twist to the idea to offer, though. updatectl enable bluefin would mean that upstream GNOME OS needs to ship some config files for Bluefin. While that's something we can think about, it's also not required.

Basically, you could instead ask the user to download a sysupdate .transfer file and put it into /etc/sysupdate.d. That makes the current OS installation "incomplete", and the next updatectl update will "complete" it by downloading and applying the Bluefin sysext.

This is, quite literally, the same mechanism as sysupdate features. All updatectl enable/disable does is tell sysupdate to ignore or not ignore some .transfer files built into the OS image. But by dropping a .transfer file into /etc/sysupdate.d, you've essentially enabled a feature that wasn't there before

I'm pretty sure that once you do that, it will even ignore updates on GNOME's CDN until you have published a corresponding version of your sysext. This lets you do quality control. Alternatively, you can choose to not delay GNOME OS updates by dumping the .transfer file into /etc/sysupdate.bluefin.d instead. That decouples the version of your sysext from the version of the host system, and then the host system will update beneath your sysext. This comes with ABI stability implications though, so it would probably only work on GNOME OS stable branches

[AdrianVovk]

BuildStream, btw, should have no problem doing this. Really not much even changes: you can still junction off of gnome-build-meta. Just rather than spitting out a full OS image, you have it spit out the files you installed on top. You could even have the same bst project spit out both bootc and sysext, from the same build definitions! (We do this kind of thing upstream, after all. The GNOME OS buildstream project is the same project that spits out the OCI images for CI, and it's also the same project that spits out the GNOME Flatpak runtimes)

[castrojo]

It's a very traditional distro move to fork an upstream OS (and all the maintenance burden that brings) just to apply some customizations on top

You should have said that before Jordan showed me BuildStream. I do think this (EDIT: sysext specifically) should be the path forward. But also we need to have some production experience with BuildStream because it's also a dependency of GNOME OS so we need to become proficient with it. The endstate will just be everyone in GNOME OS.

updatectl enable bluefin would mean that upstream GNOME OS needs to ship some config files for Bluefin. While that's something we can think about, it's also not required.

Ok so I can't stop thinking about this idea and if you think about it, it would be the most efficient path. This is our Final Shape.

So I think this model looks like this, AND comes with a built in conformance program, which I think has a ton of benefits. The website for Bluefin says "The best of both worlds: the reliability and ease of use of a Chromebook, with the power of a GNOME desktop."

All I really want to do is build a product right? I want something for my dad and something that gives me access to all the latest OSS tech, my lively hood depends on it! So instead of "distros shipping GNOME" I wanna say "Experiences that GNOME ships". It would look something like:

Some official list of "Experiences for GNOME." People could make their own. People are making individual operating systems because they want different tweaks and wallpapers. So flip it on it's end. GNOME is very, very, good at being customized by automation, it's a hidden superpower. If we wanted to we could ship every variation of style desktop, the tech is all there.

People are arguing about middle click paste, it's like one check box. This lets people ship entire experiences. If you want an old school feeling GNOME someone will make one. It's way better than having people staying on old versions of GNOME in distros. Give them the modern OS part but enable people to manage their little ways of using GNOME.

So, a GNOME Experience would have certain things:

• Explicit boundaries so that the OS people know what's their domain, and the experience/product people have the flexibility to meet their needs.
• GNOME sets the rules, that's the value to being on this list, the participants choose to be there and let GNOME OS handle the business, with input in the usual healthy OSS manner, and so on.
• Distros already ship GNOME, it can just leave those existing relationships where they are, this is additive.
• It allows GNOME to concentrate on Core.

But also the one thing to top it off is to have some capability in the installer for custom branding. Bluefin is a product, I am a GNOME reseller for a specific audience of over 15 million developers, give me the cool product to go get them. And also I just bought like 1000 stickers for SCALE so I'm already committed. 😄

Happy to hear more thoughts from others!

[castrojo]

BuildStream, btw, should have no problem doing this.

I thought that's what we were doing, lol @alatiera knows.

[castrojo]

Bazzite is way closer to a distro than we are but GNOME OS + OGC Kernel + the rest of Bazzite would be a killer variant.

[castrojo]

Further improvements can be a tier system. Make up some fancy title for the pure upstream experience. This should solve the distro vs. upstream thing that people love to fight about. This is an infrastructure-first world, we can all have our cake and eat it too.

• Every project should be able to revert to pure upstream mode that is clearly documented, etc.
• A low tier one so that things like "GNOME Throwback Live CDs" and stuff have a place that they can get organized
• a catch all for "Yeah, someone used GNOME, that should be in a museum" for those cursed POS systems at Lowes running some old rhel version.
• Systems that were compromises had to be made or maybe it's something that's only partially using GNOME tech or some hybrid desktop thing. Cool stuff. It helps all GNOME using things to have their place in the ecosystem.
• Something that gives LTS distros a win. They're always going to ship old stuff that's their whole thing, and it also pays for everything. Call it Enterprise Grade GNOME or something equally terrible. Something that says "this is not the latest and greatest, you paid for this experience." But they paid for it because that's what they want. Sounds fine to me lol.