You can "just use" KDE too. The default are actually less insane than gnome, it's easier to use.
The idea that more functionality makes software less usable makes no sense to me. No, it's more usable.
Its like when people argue that iOS not allowing anything other than safari is a good thing.
Okay... how? Because if you like safari, nothing changes for you. You just keep using it. You wouldn't even be able to tell.
Similarly, if you like KDE you can just... use it. You don't actually have to change anything. There's no gun to your head. If you're the type of person who just takes software and uses it, then great - you don't need Gnome for that. KDE is actually better at that, IMO.
Hi Jeff, I'm a linux ambassador for Framework and I have one of these units. It'd be interesting if you would install ramalama in fedora and test that. I've been using that out of the box as a drop in replacement for ollama and everything was GPU accelerated out of the box. It pulls rocm from a container and just figures it out, etc. Would love to see actual numbers though.
This is my impression - if you explicitly don't want to use toolbox or devcontainers I don't think you're on Bluefin's happy path at all, and the maintainers don't seem concerned enough by that to improve other experiences.
No but Bazzite DX is almost done so we can start working on Bazzite GDX soon, which is going to be our game dev image. Though hopefully as more things become flatpak native ideally someday the idea of specialized images won't be so necessary.
There's also https://github.com/gomuks/gomuks/tree/master for golang folks (although it's currently doing a transition to being a web client... and then back to being a TUI apparently)
> An OSTree based atomic system is pretty close, although there is some added complexity.
The author mentions this as well but there's no details there. We've been shipping chromeos-style images with universal blue for over 4 years and the ostree parts are invisible to end users. What do you feel takes away from the user experience?
Thanks for your work by the way, I'm a happy uBlue (Bazzite) user.
I think my main concern is something like a known OSTree design issue around UID/GID drift, there was a bug that was partly fixed in 2023 but the issue comes from OSTree assigning known UIDs from the deployment once created, but this may not map to the proper UID on the system the deployment is being blasted to. You can get improper ownership out of this.
Not something I've ever encountered myself, but if I were developing an embedded device it seems like one less thing to worry about.
For the confusion around verified publishing, this is something the CNCF encourages artifact authors and their projects to set up. Here are the instructions for verifying your artifact:
You can do the same with just about any K8s related artifact. We always encourage projects to go through the process but sometimes they need help understanding that it exists in the first place.
Artifacthub is itself an incubating project in the CNCF, ideas around making this easier for everyone are always welcome, thanks!
> We always encourage projects to go through the process but sometimes they need help understanding that it exists in the first place.
Including ingress-nginx? Per OP, it's not marked as verified. If even the official components don't bother, it's hard to recommend it to third parties.
I think that's about 20% of the complaints in this thread: there isn't an official/reference implementation of just any of the components, because it matters a great deal what functionality you already have lying around versus needing to bring with you
> Say, including the signing keys for Chrome's 3rd-party repo statically instead of fetching them over the network.
This is a fantastic idea, it sucks to have an upgrade blocked by a slow repo, if you wouldn't mind filing an issue or sending a PR I'd love to have this. Thanks for the feedback!
> It uses 20 different copr repos (granted, half are their own), and I didn't count how many packages. Best I can tell, none of the versions are pinned.
Contributor here, we've been working on this diligently over the past cycle (the rest of the org is mostly done, Bazzite is largest so we're only getting to it now). We're hoping to be done over the summer with published SBOMs and all that good stuff.
That's good to hear; I'm definitely a fan of SBOMs. But it doesn't fully address the risk introduced with automatic selection of the latest package version. If a package has no dependencies, for example, the SBOM wouldn't change if it were compromised with something that's compiled in to the package...
And I like linux because there are plenty of people who also do not care about this and want to just use their computer.
reply