@ljrk No idea. It’s just a thing that’s broken but is apparently a fact of life and so we go through this dance every time there’s an upgrade. Ideally, I wouldn’t have to know or care about rpm-fusion at all :)
@ljrk Ooh, if that works, they should incorporate that into the official rebase instructions on @fedora magazine so folks don’t have to keep running that command.
Just rebooted and I’m up and running with Fedora Silverblue 40.
(Just tried reinstalling mozilla-openh264 – so videos work in Firefox – but it failed with the same error. Not a big deal, I’m using @Vivaldi as my main browser these days anyway and I guess the Fedora folks will fix this in time.)
More importantly, I wonder if the screen reader has been fixed yet. (Yes, Fedora ships with a broken screen reader.)
@aral@Vivaldi nice 🙂 I've been running a fedora 39 install for a while now (with similar hardware specs) and it's terrific and totally stable and does everything... Silly question: what is a screen reader? 🤔Wondering now if mine is broken but then again I'm not aware that I've got one... 👍
@MarkDW It’s what some people who need visual assistance use. It reads the screen and can be controlled with keyboard shortcuts. The latter bit is broken in Fedora by default.
@aral I'm not involved with #Fedora, but presumably there's a release process that is written somewhere.
This sounds like a bug in not just the software, but also the release process. Perhaps the way to tackle the software bug is to fix the release process so that alarm bells ring before next release.
Grabbing prerelease images and testing and raising bugs in the run up to release might provoke some action - if you have the time to do that. someone clearly needs to!
@aral Unrelated question, how have you liked the atomic desktop for development? I'm thinking about using Fedora Kinoite 40 and while I like the idea, I'm not sure how it goes in practice. Are you doing software development using Toolbox or Distrobox?
@ggpsv@aral I found both approaches not really ideal since I then still need to maintain the toolbox, keep it updated, etc. Of course you can go farther by effectively building your own toolbox images in CI but that was overkill to me.
But I use the following setup: VS Code (yes, unfortunately necessary, right now) with the remote development extensions as Flatpak with the podman Flatpak Extension. Allow VSC to access the host containers.
Now you can create development containers from a Flatpak'ed VSC which are custom tailored to whatever development tools you need for any given project.
The tooling of VSC is open and just called "development containers". Unfortunately, support for it is lacking a bit outside of VSC, although I really do like the concept.
Alternatively use GNOME Boxes which AFAIK has a different mechanism.
@ljrk@aral I went ahead with workstation 40 KDE for now while I get used to things, but I'm replicating my workflows as if it were an atomic desktop. I plan to switch over once I get a hang of things.
Mainly, using flatpak for all gui apps, installing from dnf only the things that I'd layer (for example, tailscale), and try to use toolbox for everything else.
@ggpsv@aral That's how I mostly use my other Arch system which I installed... uh, a decade ago and don't bother to move to Silverblue :'D
I've basically removed a lot of the non-base system and moved everything to containers and other Flatpaks, harmonizing my Arch and my Silverblue workflow.
@ggpsv I work mainly in the host system and I have a distrobox container for building stuff in when I need to build from source. But that’s about it. I usually stick to Rust apps or Go apps for CLI apps (tried homebrew but it can mess things up) and otherwise I try to stick to Flatpaks and have a couple of things layered.
(And then restart your system, of course. You can always roll back to your older pinned version of 39 should anything go wrong. Also, although not required, it’s always a good idea to install the latest updates in the current version of the OS before rebasing.)
Add comment