Samueru_sama @ Samueru_sama @programming.dev

Posts

0

Comments

66

Joined

1 yr. ago

appimage hasn't depended on libfuse2 (or any libfuse) since the static runtime came out in 2022.

The issue is that some projects haven't updated to it, most notably electron builder:

https://github.com/electron-userland/electron-builder/issues/8686

never integrate well on the system, and run unsandboxed.

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

You have sandboxing and perfect integration, including adding the binary to PATH.

flatpak still ends up using +4x times the storage equivalent of appimage, comparison with flatpak dedup checker for ~20 common GUI apps:

And btw I need to update this comparison, a lot of the appimages on the right got a lot smaller lately.

The flatpak runtimes are huge, the GNOME runtime alone is over 2 GiB so that's +20 appimages.

Most flatpak runtimes only have 2 years or support, or in the case of the GNOME runtime 1 year lol.

So yeah you have a "stable" target for a few years at most, then the new runtime comes, breaks something and the project ends up using an EOL runtime, like OBS or more recently prusa slicer.

So… why not create a secure script repository? On a central website you would create an account for a project and submit a script. On the other side we would provide a binary client that will download and execute the script (we can call it grunt from get and run it). So as a user you would run for example grunt rustup and it would get and execute the script created by rustup project. I imagine it shouldn’t be that difficult to add a tiny package to the major distros.

https://github.com/pkgforge/soar

However instead of running scripts on your machine, soar runs them in CI and stores the binaries for you to download.

👀

If you have binary that is hardcoded to look for some files/libs in a certain path, you can overwrite that path with sed directly lol. You just need to make sure to keep the string length the same.

sed -i s|/usr|././|g will change /usr for the current working dir for example.

All the issues bazzite has with the Steam flatpak are solved by this AppImage

rip chimera.

They have a Glfw build, it is a lot smaller and faster but they don't want to support it.

Unfortunately they decided to use the slow bloated mess that is GTK4.

https://github.com/ghostty-org/ghostty/discussions/5592#discussioncomment-13186436

I'm not, it's a vm that I use to test.

There is quite a lot of systems still stuck on kernel 2.6 that can't be updated, so it is always nice to make sure what I do can work on such.

it allows the same packages to run on any Linux kernel (any Linux distro). That is pretty useful.

flatpak itself depends on namespaces, so saying that it works on any kernel is quite a stretch.

Can flatpak do this? This is a GIMP3 appimage running on ubuntu 10.04 without any container:

The kernel is so old that even the appimage runtime itself complains of missing functions and has to fallback to a workaround.

UPDATE: flatpak can't work because bubblewrap itself can't:

PR_SET_NO_NEW_PRIVS is only available since kernel 3.5

The issue is arch and not us. They are building fastfetch without SQLITE3 and then we get people asking why the package count of fastfetch doesn't display soar pkgs... All we can do is just tell people to not use fastfetch from the arch repos.

All archlinux has to do is change this line from OFF to ON

Be aware the sandbox of flatpak is not safe for web browsers, specially firefox based browsers:

https://seirdy.one/notes/2022/06/12/flatpak-and-web-browsers/

https://librewolf.net/installation/linux/#security

https://github.com/uazo/cromite/issues/1053#issuecomment-2191794660

omg I cannot fucking believe that while I was typing this I just saw another distro package nonsense:

There is this very good tool called soar which I use for static binaries. (It also has support for appimages but to be honest it is not as good as AM rn).

Well we just got a complain that fastfetch is not displaying the package count of soar, which fastfetch is able to do.

Turns out this is because the archlinux package is built without SQLITE3 which is needed for that feature to work 😫

And what's worse is that account registrations are disabled in the archlinux gitlab, so I have to jump thru some hoops to get a basic bug report filed...

I want full-scale applications that are so big they have to use system libraries to keep their disk size down

Linux is in such sad state that dynamic linking is abused to the point that it actually increases the storage usage. Just to name a few examples I know:

most distros ship a full blown libLLVM.so, this library is a massive monolith used for a bunch of stuff, it is also used for compiling and here comes the issue, by default distros build this lib with support for the following targets:

    
-- Targeting AArch64
-- Targeting AMDGPU
-- Targeting ARM
-- Targeting AVR
-- Targeting BPF
-- Targeting Hexagon
-- Targeting Lanai
-- Targeting LoongArch
-- Targeting Mips
-- Targeting MSP430
-- Targeting NVPTX
-- Targeting PowerPC
-- Targeting RISCV
-- Targeting Sparc
-- Targeting SystemZ
-- Targeting VE
-- Targeting WebAssembly
-- Targeting X86
-- Targeting XCore

  

Gentoo used to offer you the option to limit the targets and make libLLVM.so much smaller, but now rust applications that link to llvm have issues with this with caused them to remove that feature...

Another is libicudata, that's a 30 MiB lib that all GTK applications end up linking to for nothing, because it is a dependency of libxml2, which distros override to build with icu support (by default this lib does not link to libicudata) and what's more sad is that the depenency to libxml2 comes because of transitive dependency to libappstream, yes that appstream that I don't even know why most applications would need to link to this.

And then there is archlinux that for some reason builds libopus to be 5 MiB when most other distros have this lib <500 KiB

Sure dynamic linking in the case of something like the coreutils, where you are going to have a bunch of small binaries makes sense, except you now have stuff like busybox which is a single static bin that acts as each of the different tools by checking the name of the symlink that launched it and it is very tiny at 1 MiB and it provides all your basic unix tools including a very good shell.

Even Linus was surprised by how much dynamic linking is abused today: https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=RcUSmQg@mail.gmail.com/

To pick how I’m going to install something,

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

I have all these applications using 3.2 GIB of storage while the flatpak equivalent actually uses 14 GiB 💀: https://i.imgur.com/lvxjkTI.png

flatpak is actually sold on the idea that shared dependencies are good, you have flatpak runtimes and different flatpaks can share, the problem here is that those runtimes are huge on their own, the gnome runtime is like 2.5 GiB which is very close to all those 57 applications I have as appimage and static binaries.

but it doesn’t actually make it easier for me, it just makes it easier for the packager of the software

Well I no longer have to worry about the following issue:

• My application breaking because of a distro update, I actually now package kdeconnect as an appimage because a while ago it was broken for 2 months on archlinux. The only app I heavily rely from my distro now is distrobox.
• I also get the latest updates and fixes as soon as upstream releases a new update, with distro packaging you are waiting a week at best to get updates. And I also heard some horror stories before from a dev where they were told that they had to wait to push an update for their distro package and the only way to speed it up was if it was a security fix.
• And not only you have to make sure the app is available in your distro packages, you also have to make sure it is not abandoned, I had this issue with voidlinux when I discovered the deadbeef package was insanely out of date.
• Another issue I have with distro packages in general is that everything needs elevated rights to be installed, I actually often hear this complains from linux newbies that they need to type sudo for everything and it doesn't have to be this way, AM itself can be installed as appman which makes it able to work on your HOME with all its features. And you can take your HOME and drop it in any other distro and be ready to go as well.

AppImage is meant to be updated using the embedded zsync info the runtime, that is the user should never have to open the app to update it.

The user needs to have something like AM, appimagelauncher or appimaged that is then able to parse the info and update the appimages using appimageupdatetool

This method also provides delta updates, meaning it doesn't download the entire app but only a diff, see this test with CPU-X where it downloaded 2.65 MiB to update the app:

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

AppImage is meant to be updated using the embedded zsync info the runtime, that is the user should never have to open the app to update it.

The user needs to have something like AM, appimagelauncher or appimaged that is then able to parse the info and update the appimages using appimageupdatetool

This method also provides delta updates, meaning it doesn't download the entire app but only a diff, see this test with CPU-X where it downloaded 2.65 MiB to update the app:

Or even just Flatpak.

AM was started because flatpak sucks.

• With flatpak devs can't agree to use a common runtime, so the user ends up with a bunch of different runtimes and even EOL versions of the same runtime, making the storage usage 5x more than the appimage equivalent and this is much worse if you use nvidia which flatpak will download the entire nvidia driver again.
• flatpak could not bother to fix the hardcoded ~/.var directory, something that AM fixes by simply bind mounting the existing application config/data files to their respective places when sandboxing which yes it is able to sandbox appimages with aisap (bubblewrap).
• flatpak threw the mess of handling conflicting applications to the user, so you have to type nonsense like flatpak run io.github.ungoogled_software.ungoogled_chromium, AM just puts the app to PATH like everyone else does, even snap doesn't have this issue.

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