I upgraded my main laptop to #Fedora 38. One click in the Software Center, it downloaded everything in about 5 minutes, and the upgrade itself took around the same amount of time. Everything works after rebooting, except the Quick Settings Tweaker and Dark mode switcher extensions, which are not crucial, so I’d say it was pretty damn smooth! I’m always amazed at how simple our desktops have become these days…

Will upgrade the desktop today as well!

Spoke too soon, Resolve doesn’t run, it throws a symbol lookup error linked to libpango. So I won’t be upgrading the desktop just yet, I guess!

Also, this is why I can’t wait for deb, rpm, .run or .bin formats to die, at least for applications. If Resolve was a Flatpak, a Snap or an Appimage, it would have had no issues surviving the upgrade. It would have come with the versions it needs. It would install and run on any distro without additional packages to install manually.

App Developers: use these new formats, you’ll do yourself, and your users a favor.

@thelinuxEXP I don't want to have multiple copies of all the libraries the apps on my system use
@joshix I much prefer using multiple copies and losing about 1Gig of space in total than having to check each program I use after each distro upgrade ;)
@thelinuxEXP @joshix another option is to change distribution! I've been using openSUSE since forever and never had package problems!
@RGBes @thelinuxEXP I'm using Arch Linux and I don't have any problems most of the time. Only AUR packages sometimes break, if I forget to upgrade them
@RGBes @thelinuxEXP @joshix never tried SUSE, but a friend told my their pc at home ran i for quite some time and now she's kinda traumatized by Linux overall 🥴
@RGBes @thelinuxEXP Aww, don't be modest. Embrace the breakage. Add some third party repositories and upgrade major distro versions day one!

@thelinuxEXP @joshix I think this is the modern way of doing things:
1. Steam also installs some libraries like Visual C++ Redist for each game even if you have it already. And the games just work because of that.
2. Coders always use virtual environments (venv) and you're basically having multiple copies of any given library but that will guarantee things will more or less work

This is the right way to do things. The only drawback is taking up more space but as if people are running out...

@joshix @thelinuxEXP I would rather have a few megs of libraries than an application that will no longer open because another app that uses the same library, but an older version, is now borked. Or broken package hell. But that’s just me. The only valid complaints I’ve seen so far is for folks that are worried about storage space, and not conforming to personal DE settings.
@posiris @joshix Yeah, I personally couldn’t care less about that. Disk space is incredibly cheap these days, and themes stopped interesting me a while ago (and you can theme Flatpak apps), so I’m with you on this one!

@thelinuxEXP
The one thing that I loathe is that you'll see many apps pulling in unmaintained dependencies.

Ancient library versions equals lots of possible vulnerabilities. As long as the sandboxing is secure, no problem, but we all know that all programs have bugs. So an exploit will happen at some point.

The only thing I use flatpak for is proprietary software.

Before people start pointing out that my normal installed libs also will have vulnerabilities: I know. But I trust the distro more to keep these up to date, than random people on the Internet.

@posiris @joshix

@jan @thelinuxEXP @posiris @joshix I have the same experience of a flatpak coming with a deprecated environment...

@jan @thelinuxEXP The main problem is that no distro has the resources to maintain and QA every popular application. Nope, not even that one.

From my perspective as a software developer, the distro maintainers are the random people I don't trust. If someone isn't getting their hands dirty in a specific application on a regular basis, how can I trust them to maintain it correctly?

@jamesgecko @jan Yep, that’s also my main concern. I’d much rather use the “right” version of an app, as the developer distributes and packages it themselves, than a third party package maintained by someone who potentially had no part in developing the app at all, and might not test it thoroughly, or only test things they are interested in.

I trust the original developer more than a distro maintainer, but that’s just my opinion.

@thelinuxEXP For me it's the reverse. The distro maintainer is more likely to have a way wider experience.

@jamesgecko

@jan @jamesgecko I’d argue that the developer, knowing and having developed the features and options, is much more likely to test every part of an app, and know how to package it correctly.

But again, that’s subjective.

@posiris @joshix @thelinuxEXP there's also the occasional 'lack of functionality' when packaged as Flatpak. Some can be overcome with granting permissions through flatseal but sometimes that doesn't solve these issues.
@joshix @thelinuxEXP Flatpak only keep one copy of each library version though. So if you have 2 Flatpak app that require a specific version, it is only installed once. So the multiple copies just apply to when apps require different versions of the same library... but that's a good thing if you need your apps to run without issues. It's either that or you don't use the app and wait / hope that the app maintainer makes a version that uses the library version installed on your computer.
@thelinuxEXP
This is why I keep my Fedora install one version behind. Gives them time to work out bugs, RPM Fusion (which I use for hardware-accelerated Mesa) repos are current, and Gnome extensions are less-likely to break.

“I can’t wait for deb, rpm, .run or .bin formats to die”

That's, like, your opinion, man...  

@thelinuxEXP

@demi7en The sentence does start with « I », so, yeah ;)

@thelinuxEXP
For now, maybe you could try a distrobox? Whenever I have an issue like that, that's my solution (assuming no flatpak).

That way, you don't have to wait for it to work in a specific distro. Of course that's just my solution, may or may not work for you.

@mrscientific Does a distro box have full access to the GPU? I would just need it to run Resolve, but withou openCL and the Nvidia GPU, it won’t run :/
@thelinuxEXP @mrscientific I believe that it does have access, but things are more complicated if you're using Nvidia, at least when I last tried.
@that_leaflet @thelinuxEXP @mrscientific I'd go with toolbx rather than distrobox in this case (presumably setting up a Fedora 37 environment). (Distrobox is useful for running a different distro in a container though.)

@abstrm @that_leaflet @thelinuxEXP
Yeah I think you need to do a few things like have an nvidia flag to get it working, though I haven't had to do it myself.

As for toolbox, my personal preference is to just use a distrobox because of the export feature, so I haven't used toolbox.

@thelinuxEXP I wonder how flatpaks work together with hardware acceleration. If the flatpak is made for kernel version 6.1, would it work with 6.2 or 6.0 or older versions?
@thelinuxEXP I do wish theming integration was better.
@thelinuxEXP I disagree. I prefer traditional package management. I've never had any troubles therein. And I just upgraded from Debian 11 to Debian 12 without any hiccups or anything breaking.
@thelinuxEXP
Why those 3 & not a precompiled #Nix? (#NixOS)

@thelinuxEXP

Steam flatpak is currently broken as well I'm not sure why, but there is a thread on the forum with no resolution: https://discussion.fedoraproject.org/t/steam-flatpak-not-working-on-f38-beta/80727/8

Steam Flatpak not working on F38 beta?

Interesting, running Steam from Flathub works just fine for me on latest F38. I have a laptop with Intel gpu. I tested both Wayland and X11 GNOME sessions. $ flatpak info com.valvesoftware.Steam | grep -A4 Commit Commit: a4c6945dc1cb48472fae369277a4350c9592c5d26239243bd06afc183da3dd7c Parent: c67a900e23d514cb308148c24638cb7316a20643c32049b0a8e2818ed1d4f62c Subject: Update 2 modules (d044c440) Date: 2023-01-31 06:36:30 +0000 Terminal output: $ flatpak run com.valvesof...

Fedora Discussion
@thelinuxEXP @fedora there is a problem it seems
@hhg a problem with third party software that from memory is just a .run file from the developers website. @thelinuxEXP @fedora
@justinz @thelinuxEXP @fedora I was only mentioning them in hopes they might have a solution. Sorry if it came out as a reproach
@hhg @thelinuxEXP @fedora all good. I imagine it just needs to be reinstalled with maybe a newer version that links to the right symbols.
@justinz @hhg @fedora Might be! I’ll try uninstalling and reinstalling it, that worked before when I had an issue
@justinz @hhg @fedora Well, that didn’t work. I’ll wait for that to be solved before I upgrade on my desktop, I can’t work without Resolve!

@thelinuxEXP

You could move all glib2 libraries in /opt/resolve/libs to another folder, say /opt/resolve/libs/_disabled, for example, so that resolve picks system-provided glib2 and pango and starts working again.

@julieninthesky That’s what I did, but it’s hacky and might create problems down the line, so I’ll have to do some testing!

@thelinuxEXP

Better than nothing, until a proper upgrade 😁

@thelinuxEXP

And in the meantime, you could maybe try building the flatpak yourself : https://linuxconfig.org/how-to-create-a-flatpak-package 🤔

@thelinuxEXP hopefully they can resolve this issue soon.
@thelinuxEXP je viens de lancer la mise à jour 😂😅🤞
@thelinuxEXP can you pop the full error line in here so we can have a look? If you're not, try running from a terminal and see if there's any other valuable info you can paste.

@justinz Thanks!

Here is the error:

/opt/resolve/bin/resolve: symbol lookup error: /lib64/libpango-1.0.so.0: undefined symbol: g_string_free_and_steal

Resolve uses their own glib2 related libs (libgio, libglib, libgobject, libgmodule) but they use the system’s libpango, which seems to lead to an incompatibility.

Moving resolve’s own libs out of their directory fixed the problem (but it might create other problems in the future, of course)

@thelinuxEXP Ah OK yeah, it's hard when developers mix and match between their own libs and system libs. I've had trouble with AppImages before and the same issue. Glad you got it working. Maybe one-day Resolve could ship a Flatpak or something to make it a bit better with auto updates and maybe package all the libs into their own flatpak run-time.
@thelinuxEXP yep 👍 my extensions worked just fine (dash to dock, vitals)
@denzilferreira @thelinuxEXP I’m giving gnome a try with dash to dock as well. I didn’t like the default where the dock is only visible from the workspace picker and didn’t think that I could change it so mostly I have been using kde. Kde still has some weird drawing issues so while I prefer kde I might stick to gnome in the end.
@thelinuxEXP Same here! Update was smooth sailin' all the way through! This is why I stay away from #Windows.
@thelinuxEXP you can get the quick settings tweaker to work if you edit the manifest and add 44. It mostly works on the new version
@thelinuxEXP Nice, I've updated yesterday when it released, and it was pretty dang smooth. I had a good experience and just a few crashes when I put to sleep the laptop, but for a desktop I am pretty sure everything will be rock solid as always.
@thelinuxEXP You can disable version checking for each extension that is "incompatible", and check to see if it works regardless!

@thelinuxEXP Not used my laptop since 38 dropped, but not surprised it was a smooth experience.

Only installed Fedora on the laptop a few weeks ago but really impressed with how slick it feels. Like, borderline 'non-tech-savvy relatives' level of ease of use. And so polished and enjoyable to look at - which is a big plus for many people who are not tech hobbyists.

Really feels like a premium product, and kind of tempted to install it on my mother's laptop 😄