I'm frankly astonished with how easy it was to rebase my Kinoite (KDE Plasma) system to Silverblue (Gnome). The only issue I had was one icon not rendering properly! (Which seemed to resolve itself on reload.) #linux#silverblue
Rebased my #silverblue install to #fedora39 to check out #gnome45 ahead of its release. "Rebasing" is such a scary word compared to how incredibly easy and safe this was - just rebooted and there it was. If anyone is not yet convinced that #immutableLinux workstations with atomic upgrades and painless rollback are the future, you should try this!
Are you making a video or a podcast about Fedora Silverblue, Kinoite, Sericea, Onyx, IoT or CoreOS ? Feel free to reach out on the Fedora discussion forum! We can help you figure out issues or answer questions you may have with those "new" variants.
If you prefer, you can also reach out directly to me. You might also want to reach out to @jorge (Universal Blue) or @sfalken (openSUSE MicroOS, Aeon, Kalpa).
Fooling around with #container technology, #Flatpak and #toolbx again, together with #vscode on #fedora#silverblue. The "current" approaches seem to either be using a lot of custom scripting and hooks with https://github.com/owtaylor/toolbox-vscode/ or try to hook into the toolbx container through VS Code's "Dev Containers" feature using com.visualstudio.code.tool.podman. The former is highly complex and (IME) prone to breakage, the latter runs into a lot of limitations. There's finally the option to install VS Code within the toolbox but that's kinda... ugh.
While toying around I noticed that I don't actually want to have the VS Code "run" or "connect" to the toolbx. Actually, I only want to have the integrated VS Code terminal "run" in the context of the toolbx, the "actual development" would either happen through the standard Dev Container feature with a container *for that project *(instead of re-using the toolbx container) or using Flatpak SDKs with the Flatpak extension, if publishing directly trough Flatpak like GNOME Builder does.
I'd honestly be much happier with #Fedora#Silverblue and its variants if it just used Distrobox. Instead, they use Toolbox which doesn't feel nearly as full-featured. Maybe I'm just not getting it, but it feels like it's not as good as Distrobox.
I'm several weeks into being unable to run Steam games on my Ubuntu laptop. It appears to be an issue with Wayland and I'm beyond frustrated. I don't want to boot over to Windows.
I have really started developing an interest in immutable Linux distros. In particular, as a Fedora Workstation fan, I’m interested in Fedora Silverblue. Having having a reliable, ABI/API stable os that is also leading edge sounds really good!
I just need to figure the best way to install DAW host and plugins to get the best performance and reliability. I’m suspecting Fedora Toolbox is probably the way to go, but I’m not 100% sure yet.
It does indeed appear that installing into a toolbox environment is the best way to go for setting up a non-Flatpak packaged DAW in an immutable distro like Fedora Silverblue (SB). There are people who have successfully done this.
It is by no means the only way to do it, but installing to rpm-ostree seems to defeat the purpose of using SB, and Flatpaks require whole industry buy-in to make DAWs and plugins work together.
I don't like #flatpak apps. I find them somehow buggy, like #nextcloud on #fedora#silverblue. While I start if from icon, it says it's offline, and menus don't work. When I start it from cmdline flatpak run... it starts but menus still are gray. What causes this? Some missmatch of #gnome libs or #qt libs as nextcloud might use those?
I'd like to write migration scripts to move data from the old laptop to the new one. It would move #flatpak app data over, reinstall flatpaks there, move #Toolbx containers, perhaps desktop settings, too.
But maybe something like that already exists and I don't have to start from scratch. Any idea?
Hat jemand von euch schonmal MicroOS oder Silverblue für längere Zeit als Hauptsystem genutzt? Ich würde mich riesig freuen wenn Ihr euch per Mail oder PN meldet. Wir suchen nach Erfahrungen.
Just reinstalled my desktop computer with #fedora#silverblue after many years with Ubuntu. The latest Ubuntu 23.04 had weird kernel crashes w/ my Radeon graphics and I’m not entirely sure if it’s not a hardware problem but so far I’m pretty happy with silverblue. My desktop is just Gnome w/ a bunch of flatpaks anyways so why not try something that is optimized for this use case.
and any gnu distro that hypothetically gets traction mainstream is probably going to look more like chromeOS anyway, #immutable like Fedora #silverblue / #kinoite or even #SteamOS
My college-bound child has a frame.work laptop DIY edition coming soon. We're preparing now by installing Fedora Silverblue on the SSD we already have. I put the SSD into a USB NVMe housing, attached it to their existing Fedora system, then guided them through setting up a virtual machine and installing Silverblue inside the virtual machine.
Sadly, libvirt-manager doesn't support directly attaching a device to a VM. So we added a dummy qcow file in VM setup, chose to configure before booting, deleted the dummy device and its associated qcow file, and then booted. Waited at the boot prompt, ran virsh attach-disk silverblue38 /dev/sdb vda in a root terminal, and then let it boot into the installer.
In the installer, it was just like installing on bare metal, except that we didn't have to set up WiFi, since it was using the host system's networking.
When the new laptop arrives, we'll stop the VM, mount /var/home (because Silverblue) on the host system, copy the /home content from the host system to the new drive, and when we drop the SSD into the frame.work laptop, it should just boot up into a working system.
One #silverBlue annoyance is that if you are doing manual partitioning (in this case, reserving disk space in case the school unexpectedly creates a need to run Windows at some point), there's insufficient guidance on partitioning. The documentation points out that the installer doesn't know about Silverblue limitations, and so describes what partitions/file systems you can and can't create, but has nothing on expected sizes. Hopefully we guessed right. 🤞
And @cassidy has an image that's a modified version of stock GNOME with some tweaks — it's a good example of how to have something similar to Silverblue but with adjustments "baked in".
OC Steam freezes after suspend
Hi,...