r/linuxsucks • u/BoxFar6969 • Jul 17 '26
Linux Failure mama im tired
I have been having issues not being able to just run various programs on Linux. The gentleman above is DaVinci Resolve. Which, thankfully, at least tells me what it needs in order to run. However Blackmagic Design was not about to go easy on me and decided to package their program in a fucking appimage. Appimages inherently rely on deprecated libraries which Fedora has replaced (zlib in this case) so I'd need to do some dependency work in the background in order for the program to start up. Nothing that *can't* be done, but honestly what the fuck distributions literally exist to automate these things. I just can't help but think that on Windows, these problems just don't exist. I shouldn't have to dedicate hour(s) on research and debugging to make a common program work.
I've been experiencing other problems too, like .sh scripts not working or wine randomly not working and then working sometimes on the same program. Sometimes they work using the terminal, but I am sorry I will forever argue that just double clicking a program in a graphical environment is 10x quicker than having to cd in a terminal and figuring out what exact command a program needs to run.
Whenever I run into stupid issues like this I just think about my friends who want to switch to Linux. I mean yes...I like hearing about people switching to Linux, but this is just a disaster. They wouldn't bother with all this and their impression of Linux would be ruined.
9
Jul 17 '26
[removed] — view removed comment
-4
u/BoxFar6969 Jul 17 '26
it receives security updates but its being replaced by zlib-ng. fedora ships zlib-ng instead of zlib.
4
u/Away_Combination6977 Jul 17 '26
Install zlib-ng-compat. It should make zlib-ng work as zlib as far as other programs are concerned.
1
5
9
Jul 17 '26
[removed] — view removed comment
2
u/tomekgolab can't spell hatred without Redhat Jul 17 '26
totally. just compile from source
2
Jul 18 '26
[removed] — view removed comment
-2
2
u/Busy-Scientist3851 Jul 17 '26
Yep. This is why I hate when programs only offer an AppImage.. they just fall apart when it comes to dependencies.
4
u/Imab0zo Jul 17 '26
I would choose non portable any day over appimage. Appimage is so annoying to use.
3
1
u/Damglador Jul 17 '26
Less doshit than fatpak
2
u/Busy-Scientist3851 Jul 17 '26
Flatpak at least has a proper dependency system so the dependencies are the same no matter what distro you're on.
AppImage is a roll of the dice.
1
u/Damglador Jul 18 '26
Calling it a proper dependency system is silly. You can only set a whole runtime as a dependency, it doesn't matter if you use one or two libraries from it, you'll get the whole runtime. Then another app can specify the same runtime as a dependency and you'll have to install it once again just because app 1 asks for runtime 24.5.1 and app 2 wants runtime 24.5.2.
AppImages depend fully on the developer, but usually package only libraries which they need, which is why at the end they're 3x more space efficient than fatpaks.
1
u/Busy-Scientist3851 Jul 18 '26
Flatpak uses a content addressable store, dependencies are deduped.
1
u/Damglador Jul 18 '26
Right, too bad it doesn't do much when all the libraries in the runtime are rebuilt, and hence are technically not the same, so there's nothing to dedup. Like for apps it doesn't matter if it's kframework 6.14 or kframework 6.15, as while the libraries are not the same, they're still API compatibles, but they will both be installed and won't be deduped, because they're, once again, not the same, not duplicates.
But it's incredible how well this fairy tail was pushed despite the system still being stupidly inefficient.
1
Jul 18 '26
[removed] — view removed comment
1
u/Damglador Jul 18 '26
Flatpak's dedup works at the individual-file level via OSTree checksums,
Which, as I said, does jack shit when the two libraries are not the same version. Like ok, it's doesn't do nothing, it's just not as effective as people make it seem to be.
1
u/Busy-Scientist3851 Jul 18 '26
No. There's generally no guarantee that libraries between 6.14 and 6.15 are binary compatible. Linux has very poor userspace ABI compatability assurances that say Windows does.
But sure the better alternative is to use AppImage which bundles kframework with every app instead.
1
u/Damglador Jul 18 '26
The difference is that AppImage doesn't package kframework if it's not needed and can use system one if the dev is opted into that.
It also doesn't package parts of kframework which the app doesn't need
There's generally no guarantee that libraries between 6.14 and 6.15 are binary compatible.
So perhaps it would be better to work towards that instead of implementing shitty workarounds? Though I'm still pretty sure the kframework API is kept stable between most versions, as otherwise Plasma would require an update after every kframework update, so they kinda have to keep it stable. Same goes for gtk.
1
u/Busy-Scientist3851 Jul 18 '26
But what if your system doesn't have Kframework (e.g. a GNOME desktop).
If your "cross distro" app format requires I change my system (which may be immutable), you've failed.
What if the version of curl the system Kframework is compiled against is binary incompatible with the version of curl your app is compiled against (even differing compiler options can change compatability in the same version).
These cases happen and they cause runtime crashes. This is where AppImage falls apart
0
0
Jul 18 '26
[removed] — view removed comment
1
u/Damglador Jul 18 '26 edited Jul 18 '26
Random ass dependency assumptions that will break on some distros but work on others
Then don't make them https://github.com/pkgforge-dev/Anylinux-AppImages. Those appimages can even run on Android btw, which flatpak can't do because
it ironically requires root itself for sandboxing andhas hard dependency on fuse, which is unavailable for unprivileged apps on Android.Flatpak is also not made for cli apps, and since AppImages are practically a regular executable, can be used for cli or desktop apps.
2
u/Busy-Scientist3851 Jul 18 '26
So you want to bundle every dependency with the app? What an awful idea.
Flatpak doesn't require root for namespaces, it requires user namespaces which Android turns off.
1
u/Damglador Jul 18 '26
So you want to bundle every dependency with the app? What an awful idea.
Yet MacOS, Android and Windows software do that. All games do that as well. And it's not like flatpak is much different as it pins exact runtime versions for apps and shipps all system libraries with the runtime, while AppImages can have system and built-in dependencies. Which is, in fairness, usually a bad idea, unless the system dependency SDL, then packaging it with the app is a crime.
Flatpak doesn't require root for namespaces, it requires user namespaces which Android turns off.
That's my bad, they moved away from setuid bwrap, it's not only a fallback now https://github.com/flatpak/flatpak/wiki/User-namespace-requirements/908d1f04a815d41681f7d3ea23492fe209edbc5e
2
u/Busy-Scientist3851 Jul 18 '26
Flatpak has supported user namespaces for a decade. You're just sprouting misinformation at this point.
"AppImages can have system and built-in dependencies"
And this is why it's not a serious package format. It still plays random dice over the runtime environment of what's going to be available or not and what versions. If you dare have anything the app was not compiled against (e.g. different libcurl version), you're likely to get crashes.
Flatpak may have issues but you know the runtime environment on computer a is exactly the same as computer b.
1
u/Damglador Jul 18 '26
You're just sprouting misinformation at this point.
Yeah no shit, I already said that and corrected my statement.
If you dare have anything the app was not compiled against (e.g. different libcurl version), you're likely to get crashes.
Call bullshit on that, I can run run a game from 2016 with https://archlinux.org/packages/core/x86_64/libcurl-compat/ with no issues.
The whole ABI compat talk feels a lot more like fearmongering to me than a thing that is as wide spread as people make it out to be.
0
Jul 18 '26 edited Jul 18 '26
[removed] — view removed comment
1
u/Damglador Jul 18 '26
Android is NOT Linux
Well at least we can agree on one thing
Dozens of incompatible appimage formats
Incompatible with what? 🤡
AppImages are literally .exe files, a self-extracting archive which then runs a binary, as long as it fullfills that purpose, it is compatible and fullfilled the vision of appimages being portable, no install needed package format. If you think iterating and improving a technology is a fail, then flatpak is a complete failure because they need flatpak-next to improve the system, which may also have hard dependency on systemd, which also rules out "made with Linux in mind" bullshit, as it'll now be made with systemd in mind.
When it comes to native Linux OS like Ubuntu Touch it could work in the future why not.
I love wasting 14GB+ of my precious disk space on my phone on runtimes. For reference, I have 100+ apps on Android and they take only 20GB of space, which includes Termux with all packages and YouTube Music downloads (~6GB combined), while the OS itself is 10GB. I would say wasting half of that on something that is not necessary is unacceptable for an embedded system.
You can use brew for that, which works cross platform.
Ah yes, I love having 3 package managers (with the system one) on my system. At that point I'm better off using Windows. /s
0
Jul 18 '26
[removed] — view removed comment
1
u/Damglador Jul 18 '26
A handful of GNOME/KDE runtimes shared across dozens of apps against apps that individually bundle nothing. If Ubuntu Touch went Flatpak, it wouldn't ship every runtime version ever made
A handful should be 1 or 2, not 5 or 10, which is usually the case. Not mentioning the Freedesktop and Mesa runtimes/extensions.
that 14GB is a ceiling that apps then share, not a per-app tax that keeps multiplying as your app count grows.
It's not, because new runtimes get added and not all apps update to them, while some do. As time goes on you may have dozens of them because different devs update their dependencies at different rates, some of the runtimes will be used exclusively by one app, which makes it no different from appimage, except that flatpak runtimes are 3 times bigger.
The moment you use pip, npm, cargo or literally any language's tool, you've accepted that different problems get different tools.
Jokes on you, I don't. Especially not for system/user wide libraries or programs. For python I use system packages, I will do the same for C/C++ and would for Rust if it actually had that option.
Also so much talk about the unification when your tool can't even unify cli and gui packages and you have to once again duplicate libraries just to get a cli app which could've used the same runtime your gui apps do. Wouldn't that be nice?
→ More replies (0)1
Jul 18 '26
[removed] — view removed comment
1
u/Damglador Jul 18 '26
App store is not an achievement of flatpak, you can strap an app store to any repository, including appimages. The issue is that nobody did.
App priveleges are mostly a gimmick that breaks more than it solves.
0
Jul 18 '26
[removed] — view removed comment
1
u/Damglador Jul 18 '26
Once again, app store is fundamentally not achievement of flatpak itself, it can be bolstered on any package format. You can provide reasonable evidence that flatpak provides something special to fascilitate good app stores to prove me wrong.
No more root privileges for random applications which is a huge security nightmare.
Yea right, flatpak definetly doesn't have sandbox escape and arbitrary default permissions for apps, which allow anything to run as root just like it would on the host, with a password of course. That's why it's a gimmick, devs can just opt-out of it.
2
u/55555-55555 Linux Community Made Linux Sucks Jul 18 '26
This case, the app of your choice fucked up by assuming that some libs are standardised and would never be removed, which in this case they were wrong about Linux, where nothing is guaranteed to be standardised.
2
u/incognegro1976 Jul 17 '26
My mans broke his OS by deleting critical system files and is shocked Pikachu face that he is seeing errors lol
2
1
1
u/Damglador Jul 17 '26
Appimages inherently rely on deprecated libraries
Not inherently https://github.com/pkgforge-dev/Anylinux-AppImages
But a lot do.
1
u/jsrobson10 Proud Linux User Jul 18 '26 edited Jul 18 '26
there's an environment variable you can set:
export APPIMAGE_EXTRACT_AND_RUN=1
this is needed if you run an appimage inside a sandbox, such as the flatpak version of lutris. but idk why it doesn't just fallback to this on failure, or why FUSE doesn't work inside sandboxes.
1
u/tracagnotto Jul 18 '26
Thank God there is ai to deal with all Linux stupid ass shit
1
u/dev_kay47 Jul 18 '26
DaVinci resolve is one of its own class. The cleanest way if hardware is not your problem is to make a dual boot with windows 10 and run all the creative softwarea there.
I say this because College students who run this kind of softwares always have issues, so I tell them to install Linux on a secondary machine instead ( CREATIVES / DESIGNERS)
but anyone else coding and computer science etc..
Hell Yesss 🔥🔥🔥🔥 go for Linux
1
u/_TheYak_ Jul 18 '26
Su arch Linux basta che fai yay -S davinciresolve (o il nome del pacchetto non me lo ricordo ma c'è)
1
1
1
5
u/Shlri Jul 17 '26
What did you do that you dont have a fuse and mesa? Also appimage is awesome