Samueru_sama

https://github.com/ivan-hc/AM

Wouldn’t mind basically adding to a command or cron for something like apt-get get upgrade && flatpak update && something

iirc topgrade has support for AM, so you can do all at once with AM included.

Well if you still insist. Just went to check how big is the GNU coreutils as a single static binary, it is 2.3 MiB in size

check it out: https://pkgs.pkgforge.dev/repo/bincache/x86_64-linux/coreutils/nixpkgs/coreutils/

The overall uutils suite is faster then GNU Coreutils already and will only get better

just did a quick benchmark.

uutils cat is 2x slower.

This is the unknown-linux-gnu release, the musl one is likely slower but didn't check.

fair, in that case the comparison is even since busybox provides a shell, awk, grep, wget among other 395 utils, uutils it is 115.

The utilities in BusyBox generally have fewer options than their full-featured GNU cousins

Note: GNU cousins, not GNU coreutils.

GNU awk, GNU grep, bash, wget, etc will give you a lot more features than the busybox equivalents. However the uutils nor coreutils implement those features at all.

If anything the comparison is not being fair to busybox because busybox implements a lot more utilities.

That’s not a fair comparison at all. Busybox is specifically optimized for size, and to accomplish that, leaves out a large number of GNU compatibility features

Such as? busybox provides a nice interactive shell, awk, bc, wget and much more. I know GNU awk has a lot more features than posix awk but awk is not part of the uutils anyways.

busybox also implements [[ from bash, none of this is provided by uutils or coreutils.

EDIT: busybox also provides grep while the uutils/coreutils don't.

I’ve built it that way now and that puts it under 7 MiB; still much larger than busybox, but it shows how much the optimization choices matter.

I'm assuming this uses -Os which means performance hit, (iirc busybox also uses -Os so it is fair comparison), still we are looking at 7x larger binary.

whereas Rust binaries are statically linked by default, meaning that the binary is actually self-contained.

rust still produces larger binaries even if you compare it to static C binaries.

Take for example busybox, you can compile all of it as a single 1.2 MiB static binary that provides 395 utilities including wget.

Meanwhile the uutils static musl binary is 12 MiB and only provides 115 utilities.

AppImages may not run, sometimes due to libc, sometimes due to fuse. Technobabble for the common user.

The worst part is, the new formats are NOT compatible with the old ones. Of course. So if you want to use snaps or Flatpaks, you must ADD to your operating system. Instead of having just one package manager like zypper or apt, both the command-line utility and the equivalent GUI store, now you have two, maybe three competing software tools. This adds complexity and overhead.

This is fixed if you package your appimages properly and use the static runtime which was existed for over 3 years already...

I do that here: https://github.com/pkgforge-dev/Anylinux-AppImages

Here is GIMP3 packaged on archlinux running on ubuntu 10.04

In this case the issue is with 100% on flatpaks side that they decide to ship and download the entire nvidia driver again instead of using the one of the host. Note both snap and appimage do not do this, they use the nvidia driver of the host.

There is no reason to have to download the entire nvidia driver again, distros cannot modify it as it is against its license.

Also even outside of nvidia you are still going to have troubles in games with flatpak if what you are using requires a recent version of mesa

That's the real location of the certs, but once again they usually make a symlink in /etc/ssl/certs/ca-certificates.crt

One library that is problematic is p11-kit, this one usually comes with a different path to the certs hardcoded and does not respect env variables unless it is compiled with a specific flag which no distro uses.

So I had to do this hack to fix that library.

Most distros have /etc/ssl/certs/ca-certificates.crt, sometimes it is a symlink but that location is there in ubuntu, alpine, fedora and arch.

edit: Also you can usually change this location with an env variable.

You can sandbox the neovim appimage with AM and then it will ask you what locations you want to give access to. https://github.com/ivan-hc/AM

am -i nvim

am --sandbox nvim