I’m curious, what makes AppImage a good choice for the lazy developer? Is it easier to create?

The appimage is basically just git clone -> make -> make install DESTDIR=/path/to/AppDir -> wget appimagecreationtool and finally appimagecreationtool /path/to/AppDir and that’s it you have your appimage.

appimagecreationtool being several tools that can create the appimage from an AppDir, like linuxdeploy, linuxdeploqt, go-appimage, etc

And that on itself isn’t complex either, it if basically running ldd on the binary, then copy those libraries into the AppDir and finally run patchelf to patch the paths in the binaries and libraries, suyu uses a deploy script instead of using those tools, which I’ve recently forked and began expanding.

I don’t know how easy it is to make a flatpak or snap, but I do know the dev of zen browser hates dealing with the flatpak and iirc right now the flatpak is outdated as result.

EDIT: Also lite-xl has been making a flatpak for like 2 years and it isn’t ready yet.

Glad you like AM.

. If you end up with 4.7GB for runtimes, that’s basically nothing these days

Yes but that wasn’t the original comment I replied to was about.

163 flatpaks and the runtimes used 8.7GB

163 flatpaks using 8.7 GiB means that the average flatpak is using 54.6 MiB.

That’s good the other time I got this linked: https://tesk.page/2023/06/04/response-to-developers-are-lazy-thus-flatpak/#but-flatpaks-are-easier-for-end-users

Which is no good as in that example there was 173 flatpaks using 27.66 GiB, average 160 MiB, while in your case the average flatpak is using 91 MiB.

This is what I have with appimages:

In this case the average appimage is using 69 MiB, though there is one outliner which is the Steam appimage that I have there (470 MiB) which is an entire conty container with its own video drivers and everything, without it the average would be 56 MiB.

I know this doesn’t matter these days but once again that wasn’t what the original comment was about.

Well we are talking about two gigs, after all. Unless you’re using an embedded system, it’s not a much of a concern if you ask me. But it is more, true

Thanks for the link showing an average flatpak using 54 MiB though, didn’t think it was possible lol.

WAIT I just took a deeper look at the link, isn’t that guy just showing the runtimes without the applications using 8.7 GiB?

I tested installing some web browers, kdenlive, yuzu and libreoffice and without knowing I ended up with 3 different runtimes and the total storage usage (with deduplication) was 4.79 GIB.

Meanwhile with 33 appimages that I have (which includes same flatpak apps I mentioned) are using 2.2 GiB.

It doesn’t matter if they share if in the end they end up using several times more storage than the appimage equivalent.

Isn’t the gnome runtime alone 2GiB? You know how many appimages that is?

Not to mention you are unlikely to only use one runtime.

In the old days distros used to separate the location of binaries in several places like /bin /sbin /usr/bin and /usr/sbin there was this idea that system binaries would go in /sbin while the rest in /bin and the similar dirs in /usr were so that you could mount a separate drive to store more binaries. This is from a time where storage was an issue.

These days distros usually just symlink all those locations to /usr/bin with the exception of fedora, which still keeps some split.

However it seems they will finally merge the remaining dirs in fedora 41: https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin

(once Flatpak get that too, there is no valid reason for snaps to exist).

They said they will not fix it due to “security concerns”

Isnt fedora like the last distro that doesnt symlink /bin and /sbin to /usr/bin?

I think this is a limitation of i3, because I also had a similar issue with another script.

For example on my polybar I have this when changing the volume:

scroll-up = pulsemixer --change-volume +5 --unmute --max-volume 100 && pactl list sinks | awk '/State: /{flag=1} /dB/ && flag {printf("%.0fdB", $7); exit}' | xargs -I {} dunstify -r 11 -t 1000 "Main Vol: {}"

scroll-down = pulsemixer --change-volume -5 --unmute --max-volume 100 && pactl list sinks | awk '/State: /{flag=1} /dB/ && flag {printf("%.0fdB", $7); exit}' | xargs -I {} dunstify -r 11 -t 1000 "Main Vol: {}"

It has no problems running, however I also wanted to do the same with i3 when I press the volume keys on my keyboard and i3 can’t do it, I had to make it a script file and point i3 to it for it to work.

But why do you want it in one line in the first place? Multiline scripts have no performance drop, and they are more readable.

I prefer to have all i3 settings on one config file, that is easier for me, it is just one file that I need to backup and also one file that I need to edit when changing things.

On ther other hand if the scripts are their on individual files, I have to make sure that the script has the permission to run, put the script on its place, etc.

I also have a keybind to open my i3config so I can do quick changes to it on the fly, while if every script had its own file I would need to navigate thru each one individually.

For example I recently began testing voidlinux and on void my monitors have different names than on arch, so my i3config didn’t work by just being dropped in I had to edit the file.

To do so I just told mousepad to find all instances where the name DP-1 is and replace it for DisplayPort-0, same for DP-2 to Display-Port-1, etc, etc.

If my monitor settings had been its own script file that i3 ran, I would have also needed to open it and edit it.

That is why I would prefer to have the scripts on the i3config, not a big deal but if it is possible I would like to know for the cases where it doesn’t work.

I also have the UR20.

I use my ksc75 daily with the headphone jack.

Try using yuzu-mainline-git from the aur and change your compile flags (edit makepkg.conf) to match=native mtune=native and O3. That gives a 15% boost in totk.

Also use zram instead of zswap as that that causes terrible stuttering on yuzu if you are short of ram. The usual recommendation is to use zstd compression but I can tell you that lz4 performs better on yuzu.

“sudo pacman -S zram generator” then “sudo nano /etc/systemd/zram-generator.conf” and paste this:

[zram0]
zram-size = ram
compression-algorithm = lz4
swap-priority = 100

Also make sure you are running gamemode with yuzu. Same with steam games.

I moved from a gtx 1060 to an RX580 and it has been terrible, recording in obs is horrible to the point that the cpu yields better results and now a recent kernel version broke the power meter on all the polaris gpus.

As long as you only keep the Manjaro repos in your system, it is like using it on Arch, which even you Arch the Aur isn’t perfect.

Because the Manjaro repos don’t sync at the same time with the Arch repos, you might not be able to install/update some Aur packages as the version of X dependency might not match during that time.

But literary, Manjaro has been the most stable distro I’ve run, even more stable than Arch that recently broke on my system and required manual intervention because of their recent changes on their repo migration.

Try manjaro, and hear me out here:

Manjaro is actually the only distro that I would recommend to a beginner, actual beginner in this case is someone that should not be running a single terminal command to get their system to work (which is what people are expecting to do when they tell you to use Endevour or CachyOS lol)

WIth ubuntu/debian based distros you will either have to deal with installing flatpaks/snaps, which come with their own set of issues like not following the system theme, using the wrong system font, issues accesing the internet, issues accesing the home directory (yeah steam flatpak can’t be placed in the home directory lol).

You could try adding PPAs which is not something I would recommend a beginner to do.

Also some games like BeamNG hate having irqbalance, which usually comes by default on debian based distros.

On the other hand Manjaro already ships with pamac which is their GUI store that supports everything, including Aur packages which means 0 issues having to deal with broken permissions or theming if you want to install apps that are usually not found in the official repos.

Their own official repo even includes brave-browser and fastfetch, two apps that I use that are usually very hard to find in other distros.