@hermmm you should be able to rekickoff the PR builds, lmk if you want me to do it tho
@hermmm you should be able to rekickoff the PR builds, lmk if you want me to do it tho
CAlso - never before have I seen OS devs move a tenth so fast to address usability concerns, UX, and reliability. It's already made a huge difference for me personally, and it's exactly the sort of thing I aspire to and built my major around. I really appreciate it and I look forward to having time to contribute more directly
JWe're able to move fast because we're leveraging some of the best features of containers, which is making a build system that's relocatable, easy to offload onto other hosts, can be structured in whatever makes the most sense for our needs, and is easy to normalize with one pull spec composing an entire file tree compared to having to test against any number of package configurations
DUblue feels like the future of linux desktop
CGood stuff!
Jyeah it's easier when you start from scratch
JSemi-relevant, but we're able to piggyback off of the shoulders of tech giants in the best way possible https://xkcd.com/1988/
Jplus we can move faster than fedora because we don't have to use pagure, bugzilla, etc. 
MI absolutely agree with jstone, but appreciate your sentiment. This wouldn't have really been possible 2 years ago - it's right at the edge of a tipping point in how we build desktop distros
DImagine if ubuntu switch to same model as silverblue rn
With OCI image etc
With OCI image etc
Jthey won't
Jthey won't even finish ubuntu core desktop so they're mostly actively avoiding it outside of iot
DUbuntu core desktop is planned?
Jyeah it's been around for years
JGitHub
Contribute to canonical/ubuntu-core-desktop development by creating an account on GitHub.
Cthat is... a sad-looking preview, for what it represents
DLast update is 1 month ago
Jyeah it's only a side thing
Jbut also who knows what's private
JCanonical's take: "what if we deployed a distro as a bunch of containerized images that get updated side-by-side?", Silverblue's take: "what if we deployed a distro as one containerized image that gets updated in one place?"
CHeh
Sounds about right
Sounds about right
DSilverblue way sounds better
CNormally it would sound worse to me
But the way it's implemented makes it far better
But the way it's implemented makes it far better
CBecause it does the opposite of sacrifice modularity to achieve that singular image
JI think snap has a weakness that its developers weren't "brave enough" to go all-in with snapifying a distro. If they decided to have an entire OS as one big snap, it would basically be a much less efficient ostree
JThey probably didn't know how to make large images that could be extended like how rpm-ostree can install layered RPMs, so the next best thing is to break up a distro into a bunch of snaps
CHonestly I think it feels a lot cleaner and more reliable to just have one big eldritch monster I have to go to special effort to even see which does everything from running the DE to browsing to text editing to who knows what, instead of having a hundred snaps cluttering several obvious places for a few apps and a bunch of pieces of an OS
CEventually I'll unlayer a bunch of that, once I figure out why distrobox refuses to integrate
XI think I did it, nothing changed though.
Jk I'll take a look in a bit
Jalright, lunch and then github time!
JOh hey, does github CI go faster if it's pulling images from ghcr.io instead of quay.io? I'd imagine there'd be a higher chance of getting a cache hit if it's pulling images that're on the same host
JI didn't notice one way or the other when we switched out the images
J@KyleGospo heya after I review and merge herm's stuff into base I'm thinking just removing vanilla's thing from the base image, keep 37 with herm's improvements and then basically call it "finished", but then do 38 with the new wizard, etc.
JCan you keep the copr building it though?
Kyep, won't touch that
Jalso
JI was doing GHA stuff last night, there's tons of ways to have github build and host RPMs
Jsigh
Jthis permissions problem makes testing impossible
JIt can't push any packages into the registry
MIt feels like a critical blocker
HMy next step for Vauxite would be creating flatpaks for common Xfce desktop packages
HAnd somehow getting them to be installed by default and removing the GNOME ones
Hanyone here have experience creating flatpaks?
JI don't, but I found in the installer that it installs 0 flatpaks, so when we make an ISO we don't have to rip out stuff, we can just add what we want, which will be a welcome change, heh
DAfaik some of xfce apps is already available on flathub
Jmaybe we can drum up some support "vauxite is looking for help flatpakking up some xfce apps, anyone wanna help?" or something?
D@theevilskeleton
Hyeah there's like two or three of them.
HI think I can figure it out on my own. Shouldn't be rocket science or anything. I'll look for docs on creating flatpaks.
