Arch for many, many years. Absolutely zero reasons to switch. I used to distro hop alot back in the day but I don’t bother with that anymore. I need a system that works and Arch gives me exactly that.
I assume you mean Debian for ideology, not Sid, unless you have strong feelings about breaking toys
but is that because of the community nature of Debian, or because default it’s free software only? Guessing the former, since there are other options for the latter
Mint on my desktop, decided to try out Tumbleweed on a cheap laptop. KDE wasn’t for me / wasn’t reliable enough, but I’m happy with Gnome. I haven’t needed to use Flatpacks though.
Might try MicroOS on the servers, I like the idea of an immutable distro so less can go wrong during updates, and I run all services as containers anyway.
I was experimenting with the Cadence tools from KXStudio. These are mostly made for JACK, but PipeWire has a JACK interface so it should work. It’s similar to helvum, but with more options.
Not sure right now which one (maybe Carla), but one of these programs also support adding sound effect nodes that have their own GUI! You probably want to use it in multi-client or patchbay mode
My audio set up is using jack on Ubuntu. If I were to start using pipewire, does it replace jack? Or do you use it alongside jack? I use mostly ardour, hydrogen, renoise and bitwig.
qjackctl will actually connect to pipewire, I use its graph window a lot to route audio when the default volume control isn’t enough. But yeah it does (or can) replace jackd.
I’ve been running Fedora Silverblue on nearly all of my PCs for about a year now and overall it’s been great.
Automatic and unobtrusive updates for the core OS and user apps (everything happens in the background without interaction; flatpak updates are applied immediately, and OS updates are applied at next boot)
I can choose to apply many core updates immediately, but rarely do
Atomic OS updates means that everything must be installed successfully or none of the OS updates are applied, which prevents a partially updated system
Being an image-based distro, I can and do easily rebase to Fedora’s test/beta/remix releases, and just as easily rollback, or run both stable and beta releases side by side for testing purposes
Being image-based means there’s no chance of orphaned packages or library files being left behind after an update, resulting in a cleaner system over time
In the event that anything does go sideways after a system update (hasn’t happened yet), I can easily rollback to the previous version at boot
Some elements not unique to Silverblue but part of its common workflow:
Distrobox/toolbox allow you to run any other distro as a container, and then use that distro’s apps as if they were native to your host system; this includes systemd services, locally installed RPMs, debs, etc.; I use distrobox to keep most of my dev workflow within my preferred Archlinux environment
Flatpaks are the FOSS community’s answer to Ubuntu’s Snaps, providing universal 1-click installation of sandboxed user apps (mostly GUI based); Firefox, Steam, VLC, and thousands of other apps are available to users, all without the need for root access
My only complaints about Silverblue are more to do with how Flatpaks work right now, such as:
Drag & drop doesn’t work between apps, at least not for the apps I’ve attempted to use; for example, dragging a pic into a chat window for sharing; instead, I have to browse to and select the image from within the chat app
Firefox won’t open a link clicked within Thunderbird unless the browser is already open, otherwise it just opens a blank tab
Many flatpak apps are maintained by unofficial volunteers, and this isn’t always clear on Flathub; I view this as a security risk and would prefer to see a flag or warning of some kind when a flatpak is not maintained by the official upstream developer
That said, I’m confident that these issues will be addressed over time. The platform has already come a long way these past couple of years and now that the KDE and GNOME teams are collaborating for it, things will only get better.
Like I said though, overall Silverblue has been a really great user experience, and as a nearly 20-year Linux veteran it has really changed the way I view computing.
Do you have to watch a loading screen while system updates are applied like on regular Fedora or is it in the background?
Many flatpak apps are maintained by unofficial volunteers, and this isn’t always clear on Flathub; I view this as a security risk and would prefer to see a flag or warning of some kind when a flatpak is not maintained by the official upstream developer
On flathub.org there’s a blue checkmark for apps maintained by the devs
Do you have to watch a loading screen while system updates are applied like on regular Fedora or is it in the background?
The image is downloaded and staged in the background of the active session. Upon reboot, the session seamlessly defaults to the staged image. For flatpaks, the updates happen immediately and without the need for a reboot.
On flathub.org there’s a blue checkmark for apps maintained by the devs
Aha, that must be one of the newer features implemented from the beta portal they’d been working on. I’m glad to hear it, and overall I hope to see more official upstream devs come on board with the platform (Signal, I’m looking at you).
The image is downloaded and staged in the background of the active session. Upon reboot, the session seamlessly defaults to the staged image. For flatpaks, the updates happen immediately and without the need for a reboot.
That’s great to hear. Maybe I’ll give Silverblue a try
The flatpaks will continue to be updated by the backend system, but you’ll no longer have to deal with the sluggish frontend UI to keep things up to date.
Yeah I kind of realised that the instructions assumed I had already upgraded, will try to keep track of new updates better in the future. So for sake of completion here’s how I solved it in the end:
Ran into conflicts: file /usr/lib64/libopenh264.so.2.3.1 conflicts between attempted installs of openh264-2.3.1-2.fc38.x86_64 and noopenh264-0.1.0~openh264_2.3.1-2.fc38.x86_64
Solved it with exclusion: sudo dnf -v system-upgrade download --releasever=38 --allowerasing --exclude=openh264.x86_64
Fonts and glitches are gone, got some broken deps instead. So if anyone got a suggestion for that instead let me know. Otherwise I’ll do as it suggest –best --allowerasing’ and see what else breaks:
<span style="color:#323232;">Problem: The operation would result in removing the following protected packages: plasma-desktop
</span><span style="color:#323232;">================================================================================
</span><span style="color:#323232;"> Package Arch Version Repository Size
</span><span style="color:#323232;">================================================================================
</span><span style="color:#323232;">Skipping packages with conflicts:
</span><span style="color:#323232;">(add '--best --allowerasing' to command line to force their upgrade):
</span><span style="color:#323232;"> kde-settings noarch 38.2-5.fc38 nobara-baseos-38 33 k
</span><span style="color:#323232;"> libkworkspace5 x86_64 5.27.8-1.fc38 nobara-baseos-38 115 k
</span><span style="color:#323232;"> libkworkspace5 x86_64 5.27.9.1-3.fc38 nobara-baseos-38 115 k
</span><span style="color:#323232;"> plasma-workspace-common x86_64 5.27.8-1.fc38 nobara-baseos-38 41 k
</span><span style="color:#323232;"> plasma-workspace-common x86_64 5.27.9.1-3.fc38 nobara-baseos-38 40 k
</span><span style="color:#323232;"> plasma-workspace-libs x86_64 5.27.8-1.fc38 nobara-baseos-38 2.2 M
</span><span style="color:#323232;"> plasma-workspace-libs x86_64 5.27.9.1-3.fc38 nobara-baseos-38 2.2 M
</span><span style="color:#323232;"> plasma-workspace-wayland
</span><span style="color:#323232;"> x86_64 5.27.8-1.fc38 nobara-baseos-38 70 k
</span><span style="color:#323232;"> plasma-workspace-wayland
</span><span style="color:#323232;"> x86_64 5.27.9.1-3.fc38 nobara-baseos-38 70 k
</span><span style="color:#323232;">Skipping packages with broken dependencies:
</span><span style="color:#323232;"> kde-settings-plasma noarch 38.2-5.fc38 nobara-baseos-38 13 k
</span><span style="color:#323232;"> plasma-lookandfeel-fedora
</span><span style="color:#323232;"> noarch 5.27.8-1.fc38 nobara-baseos-38 403 k
</span><span style="color:#323232;"> plasma-workspace i686 5.27.8-1.fc38 nobara-baseos-multilib-38 15 M
</span><span style="color:#323232;"> plasma-workspace x86_64 5.27.8-1.fc38 nobara-baseos-38 15 M
</span><span style="color:#323232;"> plasma-workspace i686 5.27.9.1-2.fc38 nobara-baseos-multilib-38 15 M
</span><span style="color:#323232;"> plasma-workspace i686 5.27.9.1-3.fc38 nobara-baseos-multilib-38 15 M
</span><span style="color:#323232;"> plasma-workspace x86_64 5.27.9.1-3.fc38 nobara-baseos-38 15 M
</span><span style="color:#323232;"> plasma-workspace-x11 x86_64 5.27.9.1-3.fc38 nobara-baseos-38 68 k
</span><span style="color:#323232;"> sddm-breeze noarch 5.27.9.1-3.fc38 nobara-baseos-38 440 k
</span><span style="color:#323232;">
</span><span style="color:#323232;">Transaction Summary
</span><span style="color:#323232;">================================================================================
</span><span style="color:#323232;">Skip 18 Packages
</span>
Yeah I forgot to mention that I’ll not be using dnf manually but rely on nobara-sync. But I must stress that I already did that before this issue, BUT I followed advice on nobaras own website where the solution was to use dnfand I still ended up with this problem. The real issue was still my own though, I should have upgraded to Nobara 38 before trying the workarounds, since 37 isn’t supported any more.
It un-fucked itself thankfully, I haven’t done anything to resolve that issue. But when I ran the update today it went well with several new packages. Which means Nobara or Fedora pushed some changes to packages in the repos.
Every time you’re excluding something you’re excluding updating a package, while updating all the others. Then if the new packages depend on the newer version of the package you didn’t upgrade by excluding it, things break. That’s what’s happened here. Every time you use exclude to upgrade something you’re essentially breaking your system worse. That’s what the other person means by “partial upgrading”
And now that message says it’s going to completely remove your desktop environment so you’re gonna have no desktop, just a cli shell.
At this point the easiest thing would probably be to back up your home directory and whatever else you want to keep and just reinstall the system. Any other process to try and fix it is going to require more trouble and time than it would take to just reinstall unfortunately. There may not even be a way to successfully unbreak your system.
I’m about ready to hop back in and daily drive Linux again after the nightmare that was attempting debian w/KDE plasma and Wayland. I have a Nvidia GPU on my laptop and for some reason I did not have luck at all after moderate success daily driving opensuse tumbleweed and kubuntu for a while.
I’m admittedly looking to onboard myself to the gnome workflow and leave the comfort of the windows style desktop environment experience. Gnome seems a bit more polished and stable than KDE plasma but it’s interface isn’t intuitive to me yet.
Ideally I’ll be using Debian or Arch when the time comes for me to dive back into desktop Linux.
KDE fixed a lot of Wayland bugs over the last months and especially with the upcoming launch of Plasma 6.0, so I’d give it a try again now or in half a year.
Nvidia also constantly fixes the problems with their Wayland support so it’s only getting better. Debian doesn’t have recent enough packages to have a good KDE Wayland experience.
Gnome Wayland doesn’t support features like vrr/adaptive sync or tearing, so it isn’t a good gaming experience. Otherwise it’s great.
Yeah I imagine the struggles I had with Debian had something to do with enabling proprietary drivers and firmware and leveraging those. Before getting those drivers, the default nouveau drivers were awful, the performance was comically bad.
I’m also not a Linux power user though, so for sure any or all of the above could be meatware issues.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.