The Linux Thread - The Autist's OS of Choice

  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
Retarded Weeb said:
So how to people feel about appimages? From my casual user perspective, they seem to mostly solve the issues with targeting every distro, backwards compatibility, and are convenient to distribute and run, but it feels like they almost never get mentioned in discussions of these things. Flatpaks and snaps I guess are also meant to serve a similar purpose and get talked about more often, but I've so far I've found appimages more convenient, run faster, and are more likely to just work. You can also run them like an installed binary if you stick them in the same folder as one with the same name and permissions (I run ungoogled-chromium this way since apparmor would prevent it from running from appimage otherwise).
Click to expand...
An appimage tries to solve a problem of dependencies, but speaking honestly, if your program needs 20 different dependencies that aren't foundational level libraries like glibc, stuff that can break from day to day, then you've kinda fucked up. Make your application portable.

Appimages are a crutch to doing that. They tie in specific versions of a binary or library to make the application work. Which sounds great for compatibility, but it means that when, not if, vulns and bugs are found in that version they have to re-package and re-distribute a new version, oftentimes with no automatic update mechanism.
 
Angie Wormwood said:
but speaking honestly, if your program needs 20 different dependencies that aren't foundational level libraries like glibc, stuff that can break from day to day, then you've kinda fucked up. Make your application portable.
Click to expand...
This has been a solved problem on Windows since forever. A WinPE program looks for DLL's that it needs in system32, and if it can't find it there it'll look in it's own directory, where you'll usually find all the DLL's that a program needs. These DLL's are hand picked for this particular version of the executable and they will never update or change. The issue is that it leads to duplicated dependencies, AKA "bloat", so Linux decided that it's best to have shared dependencies for software to reduce "bloat". While this might've made sense in the 90's and early 2000's, the moment 1TB system drives became a standard it practically ceased to matter if you've saved a couple of those megabytes per program, and the package manager would probably leave more uncleaned trash behind than Windows' way of dealing with dependencies ever did.

For example, plenty of FOSS on Windows will come pre-bundled with all kinds of DLL's in it's directory, and if it's a portable version, AKA one that also keeps all of it's configuration files in it's directory, then you could move that to another drive and no matter how many times you'd update your OS or do whatever, it'd still run. Meanwhile on Linux, it's a shitshow if it's been made to use a shared dependency that's not version locked and you update it and suddenly everything breaks, or perhaps it's version locked but for some reason the package manager can't pull it because who knows, maybe the distro managers knew better than others and cut those old versions from the repo or ditched them as time went on killing off backwards compatibility because who would need those old packages anyways. Yes I'm talking out of my ass, but those are very much possibilities as for why software would cease to work under Linux.

AppImages are basically Linux's way of copying Windows' way of dealing with software and dependencies, which many rabid purists will consider a bloated sin, to which you should respond by shitting into their mouth. If you do an AppImage right, then it will be much like that portable Windows program. No matter what happens, as long as you're running a Linux kernel, it will work.
 
Retarded Weeb said:
So how to people feel about appimages? From my casual user perspective, they seem to mostly solve the issues with targeting every distro, backwards compatibility, and are convenient to distribute and run, but it feels like they almost never get mentioned in discussions of these things. Flatpaks and snaps I guess are also meant to serve a similar purpose and get talked about more often, but I've so far I've found appimages more convenient, run faster, and are more likely to just work. You can also run them like an installed binary if you stick them in the same folder as one with the same name and permissions (I run ungoogled-chromium this way since apparmor would prevent it from running from appimage otherwise).
Click to expand...
I feel like the concept of appimages is incomplete. It needs to have some sort of matadata file included that lists all needed dependacies, detailed information so that it you put it in a defined folder it gets added to the desktop environment menu, and a update url so that the application management system can notify you when there's an update.
 
Slav Power said:
This has been a solved problem on Windows since forever.
Click to expand...
Yes, you're talking about static vs dynamic linking, thanks for telling me about what I already knew.

It still doesn't solve issues of security, though. Bloat has been a non-issue for decades now and not even in the same line of what my gripe with them is about.

Appimages, as I said, can be done right. However more often than not it's a crutch to the bad or lazy programmer. Path to hell, good intentions, all that.
 
Betonhaus said:
I feel like the concept of appimages is incomplete. It needs to have some sort of matadata file included that lists all needed dependacies, detailed information so that it you put it in a defined folder it gets added to the desktop environment menu, and a update url so that the application management system can notify you when there's an update.
Click to expand...
I looked into this since I was curious. Appimages have metadata, its a XML file inside the AppImage (usually in usr/share/metainfo/). For desktop launchers there is a daemon that watches defined directories so you can make a "Programs Files" directory just like on Windows and it will then integrates any AppImages it finds from there into your desktop menu. Similar to that is one called AppImageLauncher which defines that directory as an "Applications" folder in your $HOME directory. That one also has an update manager. Might try the daemon if it works recursively, I always liked Program Files with its dedicated folders over the giant cluster of files you see in certain places on *NIX.

As for management and dedicated updaters there is Gear Lever, the app I was talking about which is a GUI manager that integrates AppImages and can handle updates for them but it's only a flatpak on second look, so no thanks. There is also something called Zap apparently. It's a CLI manager with a small daemon that periodically checks for updates. So there seems to be some solutions attempted, can't speak to the quality of them but I might try some esp the daemon by the creator of the format.


EDIT: Disregard the other projects, this is the most featured and up to date package manager for Appimages.
 
Last edited:
Betonhaus said:
can notify you when there's an update.
Click to expand...
That's the best part. They don't do that, and you never come back to something automatically updating into a broken version. And there's nothing nagging you(except sometimes the app itself).
 
Slav Power said:
This has been a solved problem on Windows since forever.
Click to expand...
Except that it's doubly fucked with .net Core. If you have an application or service that a publisher has compiled with a dependency on a specific insecure version, you can't even override that with an assemblyBinding app .config entry anymore. Absolutely horrendous
Retarded Weeb said:
So how to people feel about appimages? From my casual user perspective, they seem to mostly solve the issues with targeting every distro, backwards compatibility, and are convenient to distribute and run, but it feels like they almost never get mentioned in discussions of these things. Flatpaks and snaps
Click to expand...
Appimages are the least bad way of not packaging things properly. They're just static binaries with extra steps, but at least they don't actively make things worse like snaps do.
 
Ahriman said:
KDEbros, we keep winning.


Click to expand...
Next release is rumored to be even more exciting, as KDE just announced that Plasma 6.6.x is going to be shipping with an alias for the system settings with winver:

1761513655301.png
(src)
This surely must mean that the Year of the Linux desktop is soon to be upon us. - But in all seriousness the 6.5.x update has been pretty smooth sailing for me so far. They should just focus on performance and bugs now as the first dude says, the desktop is fine as it is for most users now. It's already pretty good on performance and bugs though to be fair, at least in my use.
 
⠠⠠⠅⠑⠋⠋⠁⠇⠎ ⠠⠠⠊⠎ ⠠⠠⠁ ⠠⠠⠋⠁⠛ said:
Appimages are the least bad way of not packaging things properly. They're just static binaries with extra steps, but at least they don't actively make things worse like snaps do.
Click to expand...
That I think is the best way to describe them.
DavidS877 said:
That's the best part. They don't do that, and you never come back to something automatically updating into a broken version. And there's nothing nagging you(except sometimes the app itself).
Click to expand...
It's good as far as maintaining a working version goes. However when you don't update your appimage because of security vulns present in older static libraries and binaries, that presents a risk. There's a tradeoff here.
 
Get Phobo said:
Oh boi. Does it at least come with stuff people have actually asked for, like a blank screen saver?
Click to expand...
"blank screen saver"

I know it is bad to bite the bait... I know it is... but... good fucking God... this fucking post bewildered me, to the point that I just have to stand in awe at just how utterly fucking retarded this post is.
 
No, that would be monitor standby. Instead, OLED users asked for a simple screensaver that would just display black to prevent burn-in. Like the one that has existed on Windows since always.
 
DavidS877 said:
If only Linux Unix X11 has had a way to blank the screen since the 1980s.
xset -dpms
xset s 300
And done.
Blanking, of course, came before DPMS.
Click to expand...
Plasma with Kwin can do it too with kscreen-doctor :

kscreen-doctor --dpms off # off
kscreen-doctor --dpms on # wake

I would imagine that is how PowerDevil turns it off after idle.
 
Betonhaus said:
but can you reliably unblank the screen?
Click to expand...
You would need to have it set up with the method you used to handle idling. But if it's set up properly yes. It works fine. But for instance.

If you set it up with something like swayidle, and you don't realize that on awakening you need to have it unblank the screen, and you only have it set to blank it. You will get stuck with a black screen until you reboot. But that's user error in that case.
 
You must log in or register to reply here.
Back
Top Bottom