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.

I’m pretty sure sbin originally meant static binaries and not system binaries lol

posix sh + awk for manipulating data?

It makes me mad to see the current state sway is in, I even bought an AMD GPU for nothing.

I really don’t know lol

Increasing the max_map_count is needed for some Steam games, iirc Arch is now dong this by default.

iirc the dirty_bytes settings prevent the system from hanging if there is too much disk IO

And setting transparent_hugepages to madvise was something I did when archlinux had this bug in the kernel: https://old.reddit.com/r/archlinux/comments/1atueo0/higher_ram_usage_since_kernel_67_and_the_solution/

It was eventually fixed but I later ran into the issue again and I decided to keep it on madvise.

Here is what I ended up using for my sysctl conf, iirc I got some of these from popos default config:

vm.swappiness = 180
vm.page-cluster = 0
vm.watermark_boost_factor = 0
vm.watermark_scale_factor = 125
vm.dirty_bytes = 268435456
vm.dirty_background_bytes = 134217728
vm.max_map_count = 2147483642
vm.dirtytime_expire_seconds = 1800
vm.transparent_hugepages = madvise

nvm I just noticed that the issue is that I had the gcompat package installed in alpine, which fixes that issue you just had, I don’t know if chimera has something similar to it.

That’s interesting that it doesn’t work, iirc the biggest difference of chimera is that it uses musl like alpine does.

Can you extract the appimage with --appimage-extract flag and run the AppRun that’s inside of it directly? Or that also fails?

Isn’t lite-xl in your distro repo?

You likely saw this already, but if you haven’t: https://www.reddit.com/r/Fedora/comments/mzun99/new_zram_tuning_benchmarks/

I use lite-xl, it has been very good, but I’m not a Go developer though.

They also release an appimage and I just did a quick test on a alpine container and it works, so it should work on Chimera as well.

I will just leave mine here as well

https://www.youtube.com/watch?v=HhZ_HnqkJoo

would you suggest XDG or creating Symlinks?

You can do both, and both are easy.

The user-dirs.dirs file contains something like this:

XDG_DESKTOP_DIR="$HOME/Desktop"
XDG_DOCUMENTS_DIR="$HOME/Documents"
XDG_DOWNLOAD_DIR="$HOME/Downloads"
XDG_MUSIC_DIR="$HOME/Music"
XDG_PICTURES_DIR="$HOME/Pictures"
XDG_PUBLICSHARE_DIR="$HOME/Public"
XDG_TEMPLATES_DIR="$HOME/Templates"
XDG_VIDEOS_DIR="$HOME/Videos"

For example if you mount the disk in /media/dirname, it would be something like this, I’m giving it a external-drive name in this example:

XDG_DESKTOP_DIR="/media/external-drive/Desktop"
XDG_DOCUMENTS_DIR="/media/external-drive/Documents"
XDG_DOWNLOAD_DIR="/media/external-drive/Downloads"
XDG_MUSIC_DIR="/media/external-drive/Music"
XDG_PICTURES_DIR="/media/external-drive/Pictures"
XDG_PUBLICSHARE_DIR="/media/external-drive/Public"
XDG_TEMPLATES_DIR="/media/external-drive/Templates"
XDG_VIDEOS_DIR="/media/external-drive/Videos"

And for the symlinks, if the drive already has the Desktop, Documents, etc directories. It is as simple as this:

ln -s /media/external-drive/* $HOME

That will symlink all the files in the drive to your $HOME

I suggest you do both because you might run into a program that doesn’t follow XDG user directories.

If you want my answer, this video sums it up pretty good: https://www.youtube.com/watch?v=x9qCqRTEVz0

More recently fedora pulled this move which causes headaches to everyone: https://gitlab.com/gnuwget/wget2/-/issues/661

To this day I notice that there is some skepticism with Btrfs, and I think it is because fedora also pushed it early.

Btrfs snapshots made me stop using ext4 all together.

Folders? you mean directories 👀

Mount the disk (if you ask me at /media/nameofdir) and configure ${XDG_CONFIG_HOME:-~/.config}/user-dirs.dirs (99% of that time that would be the .config dir in your home lol) and define each XDG_***_DIR= to the respective directory in the path of the mounted disk, no need to make symlinks, though you might need to because there is likely many apps that don’t follow xdg specs.

I would really appreciate a GUI way

I know gnome-disks has a GUI way to change the mount options, I don’t know how good it is though.