drwankingstein @ drwankingstein @lemmy.dbzer0.com

Posts

0

Comments

465

Joined

2 yr. ago

as much as I love guns, why the fuck was this posted here?

That one guy, In fact, being many one guys.

awful name

I think you mean a great name

Nice, will for sure look at these when I get the chance

only to the begging of the rim

I hate applications that use github only as an issue tracker

I'm not sure. It would be nice if they did though.

touchscreen support doesn't seem like its quite there yet, but otherwise happy with hiw snappy it is

Yes. I have had many bugs with it, I recently changed to organic maps and have no complaints

Literally never heard of it let alone know anyone who cares...

Interesting, ill have to look into it for sure then

First im hearing of restic, Haven't looked too much into it but it seems like it could be an alternative to rclone for me in some aspects

oh boy here we go I strongly disagree with this article

While complex .tar archives (like firefox) may seem messy, they integrate many different things. An installer script takes care of placing a .desktop entry, you can have an updater script, a LICENSE, README and more. Those are all missing with Appimages.

.tar ARE messy, sometimes they don't work right, dep conflicts, etc. An installer script can be shipped with an appimage anyways. Moot point IMO

Apps installed with the system package manager get their .desktop Entry in /usr/share/applications, installed Flatpaks get their entry linked to ~/.local/share/flatpak/exports/share/applications/, user overrides and other installs can be put in ~/.local/share/applications/.

Appimages have no desktop entry, so they have (currently) no icon on Wayland and they don't appear in your app list. Desktop entries are a standard, used by everytthing but Appimages.

see above

Instead users follow strange habits like placing the files on their desktop, which is a highly discouraged "Windows workflow" (symbolic image) and not even supported on many Desktop Environments, most notably GNOME.

Who discourages it? I personally prefer this myself, lack of desktop icons is a common complain for stuff like GNOME...

This is both a usability and a security issue. Traditional Linux apps, even if they are cross platform, don't have updater services, as package managers are way better at doing that.

I disagree that this is better. A personal issue but I Much prefer when apps can update themselves.

This means, packing as an Appimage either requires to implement an updating service, on a platform that doesn't need that, or to have no updates at all.

Instead users need to follow an RSS feed, get a mail, or manually check for updates, which is horrible UX. Then how do they update?

Is this really a massive issue? There have been appimage stores in the past. Self updating appimages really isn't that hard either. If this was a massive issue, you could do something like obtanium for android which could easily automate the process.

Appimages don't even have a central place where you can find them, not to mention download them. This is extremely insecure. Modern Application stores and every well made Linux repository uses cryptographic (mostly gpg) verification, which secures the authenticity of the software. You can be sure you downloaded the real package.

I'd argue it makes little difference. But yes, Downloading things from the internet is more unsafe then downloading from a repo or a "curated" service. So we can grant one here.

There is no updating mechanism. On Android you may also update by downloading .apk files, but once installed, the .apk needs to be signed with the same key, otherwise updates are blocked. With Appimages... you just delete the old .appimage file, download the new one, change the name to remove the version and hope your .desktop entry didn't break.

This is how you get malware.

the risks seem blown out of proportion here. As long as you are downloading from the same place, the risks are significantly smaller in reality, not gone, but smaller.

They are not well maintained

There is a well known "bug" on modern Ubuntu, where Appimages lost their "works on every Linux Distro", because they are built for the outdated libfuse2, while Ubuntu now uses libfuse3. The fix is to install the outdated version of libfuse (!), and this is still not fixed.

An application format, that is incompatible with the latest version of its core dependency, is broken.

This is a very minor issue, i've had way more issues with traditional repo packages then I have had with appimages.

Lack of Sandboxing ...

I find this to be a benefit myself, I have had countless headaches with flatpak applications and their sandboxing. everything from devices not being recognized, weird storage issues and more.

Random location ...

Another moot issue. $HOME/.local/bin is an XDG standard, so unless we pretend that XDG standards aren't "one of the major standards" this is just wrong. https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

Duplicated libraries

Appimages bloat the system. They include all the libraries they need, and unlike system packages or Flatpaks, they don't share a single libary. If users would really install every Software as Appimages, they would waste insane amounts of storage space.

This also completely discourages efficient and up to date packaging, and the attached risk of outdates libraries is hidden away in that .appimage archive.

and? When you need only a couple appimage files, space I find is smaller then flatpak, it only becomes when you need a lot of applications.

Appimages are not needed Flatpak solved many Linux desktop issues at once ...

None of these provide reasons as to why appimages aren't needed. Appimages still offer a lot, for one I can just download and run it I don't need to worry about installing and uninstalling application when I just want to try it, I don't need to muck about trying to get an app into flathub or starting my own repo, when a user has a problem, I can just tell them to run the new appimage instead of trying to get them to compile it.

Appimages also let me do fine grained control over the dependencies. No unexpected runtime updates, I can compile the deps with flags/features I want to support, and disable flags/features I don't want to support, Users don't need to download a stupid appstore or use CLI (not a single appstore i've used to date isn't hot garbage, I hope cosmic-store will be different).

not sure why I need to care when this is a video on gnome...

for sure. I managed to power through but it didnt get better at all

I agree with a lot of the points LTT had, I was pretty excited for this video when I saw it. But the response was just complaing and excuses instead of just being nice and simple "here's the issue you had, We can either fix it, or can't for these reasons..."

im 50:50 on it, it's a good upgrade feature wise and the price is decent. I would like to see more perf out of it, but thats a full float vs half float thing

the a380 is known to be more or less the same performance as a rx580 on windows right now, lower performance for full float ops, and higher perf for half float ops, but you do have a newer feature set, so It really shouldn't come as a surprise that it would preform in the same ballpark as the rx580,

as I said it is lower then expected performance, meaning performance on windows is higher, but this should really not come as a surprise IMO. Linux has less development effort being done to it, and there haven't really been all that many bug reports, of which I'm guilty for as I havent been reporting bugs i've come across.

its been ok, some things still have issues, I get graphical glitches and lower then expected performance in genshin, not sure if this is a dxvk or an anv thing, but it's not too much lower. It is a bit lower then my rx580 4g in the second slot however

flameshot has been buggy as balls for me, hardly ever get it working, I for one will welcome a new tool