I uninstalled some GNOME apps (guessing this is related), and when trying to launch osu!'s AppImage I was getting dlopen(): error loading libfuse.so.2 AppImages require FUSE to run. fuse was installed, so I didn’t go further with that.
I did --appimage-extract on it, cd’d into the main folder, dragged-and-dropped the executable conveniently named osu! onto Terminal, and it worked no problem.
The AppImage being an AppImage itself wouldn’t run conveniently, but manually extracting and running it the hard-way worked fine
Fedora does not seem to have a package named libfuse2.
Installing fuse should also pull in the fuse-libs package which is what provides the libfuse.so.2 file that seems missing
You can identify that with dnf provides '*/libfuse.so.2'
$ dnf provides */libfuse.so.2
Last metadata expiration check: 1:15:10 ago on Tue 29 Oct 2024 07:48:31 AM CDT.
fuse-libs-2.9.9-21.fc40.x86_64 : File System in Userspace (FUSE) v2 libraries
Repo : @System
Matched from:
Filename : /usr/lib64/libfuse.so.2
Filename : /usr/lib64/libfuse.so.2.9.9
I am using Workstation, and found both fuse and fuse-libs installed by default. It seems likely that is standard for most desktops, including the atomic versions.
Sometimes it breaks, e.g., after 4 or more in place upgrades when new and old configs start getting into conflict. I use FW on my desktop PC, normally update existing install, but over time it gets messy, even I try to maintain package “hygiene”.
I also have Fedora Silverblue installed to my Framework 13" AMD and ~2 weeks ago an update made my system unusable. At the time I had no time to troubleshoot the case, thus I simply rolled back the last update (one CLI command), rebooted and my system was in fully working order as if nothing has happened. I believe it would take much more effort to rollback regular FW.
It’s fuse-libs I needed (AppImage loads fine after installing fuse-libs-2.9.9-22.fc41.x86_64)
What I don’t quite understand is why exactly that’s needed when extracting it worked without it (implying file access within the AppImage doesn’t directly need fuse), and that there’s some mechanism enforced to need fuse to run it even when it works fine without it.
Basically, AppImage’s abstraction was an active issue and solved by removing its abstraction
I don’t think I’ve ever needed to do 4+ in-place upgrades or ever ran into any config conflicts.
I do daily dnf clean all/update Server and Workstation and never ran into a config conflict or any updates breaking something on next-boot 2016-today. As long as the distro maintainers are pushing stable updates, I trust broken updates not to be a problem!
That’s my main issue with the idea of Silverblue; rolling back something that breaks without having to involve the gritty-details of figuring out how to fix it manually However, having no time to troubleshoot it proper and being able to get back-to-productivity quick is nice!
I’d rather tackle the issue on the spot fresh so it doesn’t get procrastinated or randomly fixed or affected by something else later.
If I had something similar happen, I’d probably try to see what happened and how to undo it (hopefully something easy like selecting an older kernel in GRUB temporarily but I feel chroot might need involved), and worst-case if I couldn’t get it back booting, I’d boot a LiveUSB, back-up, and reinstall.
I’d be motivated to fix it before reformatting because I like learning about new stuff, and I’m sure if the boot issue wasn’t as-easy as selecting an older kernel, there’s probably something new to learn about on how to fix it
If it happened again after a fresh install, I’d try openSUSE TW, and if it worked there, I’d have hard questions for Fedora and probably distro-hop.
Fedora Desktop OSes (incl. Atomic) are general purpose OSes. Not all users want (or sometimes can due to time constraints) troubleshoot issues. In such situation the priority is to get the working system back ASAP. And with Atomic it is easier. I’m not saying FW is flawed somehow, but for Average Joe this is much harder.
That color scheme choice of making RPM look like a worse choice than Flatpak is quite an intentional sway. Not sure what the Green check is supposed to convey against the stronger red though, and guessing the gray one means what’s installed?
I’ve always used dnf and avoided GUI package managers (had bad experiences back on Ubuntu/Kubuntu 6-8 days with Synaptics/etc) and never saw that UX until now
I saw GNOME Resources mentioned on a blog recently, went to try it, and saw they only delivered it officially via Flatpak (I’m aware of the unofficial Copr).
I understand it’s their choice, but I don’t like the concept of using Flatpaks and feel that decision is enforcing an App Store something similar to Android/iOS shenanigans. But mainly I feel like there’s a push somewhere to distribute Linux apps only as Flatpaks, and I’m not a fan of that.
I still consider Flatpaks being a largely separate app delivery system, and don’t like the idea of having to enable its infrastructure on-top of Fedora’s default dnf management. I don’t believe I require its features (sandboxing done by OS security/SELinux, libs done system-wide), and believe mostly anything other than deb/rpm or just tar’d binaries is adding a layer of complexity as a compatibility layer.
I mostly approach this all-or-nothing, so on the other hand I’m not totally against Flatpaks if it was the only package management system on the OS, or if it’s use was OS-wide and integrated in a manner to not notice it.
I like Ubuntu’s approach to Snaps in that they were confident enough in it to force it desktop-wide even to Firefox. I saw some GPU driver switcher for Steam Snap that was also pretty cool (being able to use oibaf/kisak drivers for Steam games only instead of system-wide).
While that’s cool for desktop, I’m not sure what Snap offers for me on Server. I like being able to change OS environments for my server stuff and rely mostly on a basic LEMP stack being available. With Snap on Ubuntu Server, I’d have to tailor specifically for Snap, or go traditional with debs. Tailoring for Snap is basically a lock-in to Ubuntu that I don’t want to entertain, so since my server stuff is traditional, and I like consistency, that makes Ubuntu not ideal for my set-ups.
Flatpaks on Fedora Workstation still feels optional, and I do rpms desktop and server no problem. I’m more into the idea of tailoring stuff to Flatpaks on Server vs Snap since Flatpaks is a mainstream standard at this point, but also don’t prefer to do so since distros still provide a LEMP stack nicely as standard packages.
Basically, I like consistency and have no reason to entertain Flatpaks yet.
My main concern with flatpaks is the need to use various runtimes for each as well as some excess bloat in storage with the needed libraries etc. that make it possible to run apps that are only available for an older version than it is installed and operated on.
Just on my system when the only external packages I have installed are the nvidia drivers I see this.
$ flatpak list --runtime
Name Application ID Version Branch Origin Installation
Fedora Platform org.fedoraproject.Platform 40 f40 fedora system
Fedora Platform org.fedoraproject.Platform 41 f41 fedora system
Mesa org.freedesktop.Platform.GL.default 24.2.5 23.08 flathub system
Mesa org.freedesktop.Platform.GL.default 24.2.5 23.08 flathub user
Mesa (Extra) org.freedesktop.Platform.GL.default 24.2.5 23.08-extra flathub system
Mesa (Extra) org.freedesktop.Platform.GL.default 24.2.5 23.08-extra flathub user
nvidia-560-35-03 org.freedesktop.Platform.GL.nvidia-560-35-03 1.4 flathub system
nvidia-560-35-03 org.freedesktop.Platform.GL.nvidia-560-35-03 1.4 flathub user
openh264 org.freedesktop.Platform.openh264 2.1.0 2.2.0 flathub system
openh264 org.freedesktop.Platform.openh264 2.1.0 2.2.0 flathub user
Adwaita theme org.kde.KStyle.Adwaita 5.15-23.08 flathub system
Adwaita theme org.kde.KStyle.Adwaita 5.15-23.08 flathub user
KDE Application Platform org.kde.Platform 5.15-23.08 flathub system
KDE Application Platform org.kde.Platform 5.15-23.08 flathub user
QGnomePlatform org.kde.PlatformTheme.QGnomePlatform 5.15-23.08 flathub system
QGnomePlatform org.kde.PlatformTheme.QGnomePlatform 5.15-23.08 flathub user
QAdwaitaDecorations org.kde.WaylandDecoration.QAdwaitaDecorations 5.15-23.08 flathub system
QAdwaitaDecorations org.kde.WaylandDecoration.QAdwaitaDecorations 5.15-23.08 flathub user
QGnomePlatform-decoration org.kde.WaylandDecoration.QGnomePlatform-decoration 5.15-23.08 flathub system
QGnomePlatform-decoration org.kde.WaylandDecoration.QGnomePlatform-decoration 5.15-23.08 flathub user
I will never understand the “flatpak is bloat” argument. I have a 128GB SSD. I use less than 25GB of space total (according to Nautilus) if I install all my apps with Flatpak. And that space includes the four-point-something Asset Pack for the Unofficial Homestuck Collection, about 2GB of dumped games, and the files I’ve saved. Admittedly, a lot of my “really important” data lives permanently on external storage, but saying “Flatpak is bloat” seems just as ridiculous as declaring “systemd is bloat”. It’s not like every app duplicates the runtime or something. Steam games target their own set of libraries (Steam Runtime) and nobody seems to care. Dunno why Flatpak is an issue.
genuine question, is btrf snapshot reliable as rpm-ostree from atomic variants ? asking because i couldnt have a linux distro without a mecanism like this, and if btrf snapshot is as good as atomic i would have more freedom to look other possibilities
I recall something not too-easy to workaround for still needing to use the Sniper runtime, but maybe one of these days I can get it with native Fedora libs. I really don’t prefer the concept of running stuff inside of stuff if it can be avoided
Heh I ran flatpak list --runtime just to make sure everything looked good, and yep nothing shown
Is that saying that the runtimes are installed to both the user and system? Like duplicating files for root Flatpak and user Flatpak? If so, I absolutely wouldn’t put up with that On the one hand I imagine if the packages are 1:1 then maybe filesystem dedup would tame that a bit; on the other hand I’m not sure if that’s a thing outside of Btrfs on Fedora (I use ext4, XFS, or F2FS). Either way I don’t think I’d let that happen unchecked.
Steam is a unique case in that it has to run as 32 bit. As long as the same app is available as rpm then comparing the usage shows a difference.
Installing the rpm uses minimal space since it does not need a runtime and uses system libraries so no extra space is required. Installing the same app as a flatpak does cause bloat with both runtimes and often differing libraries.
Flatpaks are not as bad as appimages in this respect but do use more space than most equivalent rpm apps.
Of course, flatpaks do have a use, especially with the atomic versions of fedora, but on limited storage systems can be problematic for users.
IDEs seem to be one of those things that doesn’t work well with Flatpak.
Zed Flatpak is straight up escaping the sandbox.
VSCodium Flatpak needs extra steps to use host shell, and needs Flatpak SDKs for headers. It has full filesystem access but the path is different. IIRC I tired it once but had a bunch of errors (includes, commands, lsp…), vs. rpm package that “just works”.
Off-topic, but Zed has a really spooky CLA, if you haven’t looked. (To make matters worse, Zed wasn’t even libre until very recently.)
I’ve backed up the main GitHub organization here on GitHub. A Zed employee (not speaking for Zed Industries the company, but in a personal capacity, obviously) suggested me to back up the plugins org as well, which I’ll do some time this week.
After the lovely conversations I’ve had on Mastodon with a couple folks who work to build Zed, they all seem very friendly and were all happy about the backup, which surprised me. No ill will on my part toward the team, just the CLA.
VScode work perfectly so does VScodium I just don’t use host as development editor as flatpak on host and using dev containers to do development with toolbox works like a charm
Other o have used 2 years is JetBrains with toolbox app it is app images format and just works on host and containers and it has free IDEs now also
I just prefer VSCODE more on container development since it is so much easier to setup and will use it until I find something better
As using immutable/atomics it needs that change thinking and approach brain to find best for you… It took almost 2 years for me to find and learn how to use it as I want and apps are 90% there now how I want and everything keeps improving
I have layered only VPN and NVIDIA drivers rest are flatpaks and then containers if I need development or like DaVinci Resolve stuff
