if i think about it the only problem with it is dependency management
if i think about it the only problem with it is dependency management
NDoes Flatpaks serve a use case here or could you theoretically get rid of them now that you have systems extensions?
Aof course they do
Aif it can be a flatpak it should be
Abut since we're doing OCI
Esystem extensions don't do any sandboxing; the use-case is more for system files/programs
NThat's a good point.
NI was more thinking about how people complain about RPMs vs Flatpaks.
Aim gonna be thinking about this
Nfrom a user experience perspective, I think the big thing is making whatever we do approachable.
Asolves every issue basically. Just need to lobotomize rpm-ostree to accept custom manifests
Eyeah, any dependency management/resolution would have to be implemented in the tool for downloading/managing local sysexts
Nwhether that be plugging it into a store or making our own tool to install it for them.
Athats what rpm-ostree does already though
Athats the whole point behind it, so you might as well use that
KGood addition to topgrade
Aif we are talking about rpms
Agenerates commits for the deployed packages and merges them to the original ostree commit
BBthat's a significant chunk of the process we're working on here. Even introduces the idea of delivering a sysext via flatpak. Maybe that's not for us... maybe it is.
Aarticle talks about GnomeOS
AGnomeOS uses sysupd
NI did not know about this.
Anot only that, but the systemd dude pushed for ostree to be replaced for it
AGnomeOS used ostree prior to that
Ai spilt the tea hon
A
NTopgrade is such a great tool.
TEndlessOS too
Tnot related sorry
Astill is
Aor did they switch too?
Ti think it's still OSTree
Jhwe skewed all sorts of ways today
Nskew seems to be an eternal problem lol
RClarifying what the ublue-os/cosmic repo is for, to try and prevent the feature requests flowing in.
Please leave your comments if anything can be made clearer.
https://github.com/ublue-os/cosmic/pull/67
Please leave your comments if anything can be made clearer.
https://github.com/ublue-os/cosmic/pull/67
Jsudo mokutil --import secure_boot.der should be public_key.der, just fixed this in bluefin docs after someone reported itJoh actually lemme just recommend
RYeah, that would be best. I'm away for an hour, so will make those updates a little later
Junderstood
EI reported it, https://github.com/ublue-os/bluefin-docs/issues/19
secure_boot.der is still in the Bluefin repo, bluefin-docs is OK
secure_boot.der is still in the Bluefin repo, bluefin-docs is OK
GitHub
NI think it looks great other than the change Jorge asked to make.
Alike the variants and the readme overall
AThe base COSMIC image is intended to be a starting point for users to build their own custom images.I do not like this line as it implies that this image is not ready to use as is
Acan you reword it a bit to say you can use it as is and if not
Awhats missing?
Jthat's the right wording for a base image
Atheres no -main in the name though
Ayou mean bazzite-cosmic would build from this?
Aie whats missing for this image to be used by end users?
NI wouldn't think Bazzite would build from this specific repo. I believe Fedora plans to support Cosmic as an official image at some point.
