I need to test the image but their PR can't push to the registry
I need to test the image but their PR can't push to the registry
Jideas?
XWhat yall talked about with the composability / eating our dogfood sounds fantastic, especially as the current selection of non-nvidia images feels very GNOME-oriented.
XAlso: Thanks for adding me to the org!
XYeah, I locally built the image and everything seems to work. Just can't figure out how to rebase without it being in a registry. Don't know why the push fails, thought that was intentional. I don't think anything I changed should affect that.
JI sent an invite, accept it and then it should work, I just put you in the org
CInteresting! The idea occurred to me for two reasons:
- There were already a lot of parallel images, then when I mentioned steam-devices y'all went from it to udev rules to all udev rules to codecs to app bundles to a modular repo system, and the potential image count/complexity ballooned. A unified installer seemed like a great way to manage that complexity in the user space. If you offer base, Silverblue, Kinoite, Vauxite, and two or three more options, that last one dramatically cuts the chance that someone will ever choose any of them over another distro. Big hazard in marketing and the psychology of decision making in general. One installer for all of them with no-selection defaults alleviates it
- Regardless of necessity, it's a relatively "simple" type of feature which at least Windows if not Mac users expect, and it's a lot less imposing as a first step than working from the command line. I would hope that it somewhat bridges the gap of what users somewhat arbitrarily think of as polished and indicative of a consumer-ready operating system due to familiarity and availability heuristics
Jwell, tbh, the udev-rules have been there since the beginning, it was only just a scratch container tho
CMuch more robust now, I think 
CTLDR: Excellent work, green flags from all four of my fields and maybe a big edge for Fedora
J@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
