Lup Yuen Lee 李立源 @lupyuen@social.cleverlibre.org

@cstanhope @lupyuen Yeah, it's unfortunate. Many Flatpak advocates including myself characterize this issue as being part of a 'transition' in the Linux desktop: Many apps weren't built for the Flatpak sandbox, so they heavily demand permissions. With time, more will hopefully adjust their standards to comply.

I'll add an edit to the article that explicitly points out that while Flatpak has sandboxing capabilities and Flathub encourages people to use them, Flatpak itself doesn't mandate them.

@lupyuen I have a bias as I have long benefited from the traditional Linux distro model, and I have never encountered "depdency hell" on Linux *except* when I attempt to install 3rd party software (whether built from source or as a binary) outside the distro's channels, which is not unexpected.

But I will not pretend there are not issues, or rather, tradeoffs made in that model. Flathub may help, but all those new packages feel a bit like:

https://xkcd.com/927/

@lupyuen Also, when extolling the virtues of sandboxed containers and explicit permissions of flatpaks, this seems like a *really* big caveat to not gloss over:

"It’s important to mention that many apps on the biggest Flatpak app store, Flathub, aren’t sandboxed particularly well."

@Suiseiseki

> First, it will never be the year of the "Linux desktop", as Linux is only a kernel and doesn't operate on its own.
Did you mean systemd/Linux?

Cant say this makes sense. Obviously linux needs many things to run and doesnt run on its own. It needs systemd, gnu userland, a x86 cpu, a motherboard, electricity, etc.. we dont say "Today is the year of linux, systemd, x86, motherboard, electricity"... we just say linux.

why, because its the component we care about in this discussion. We are sayi g "is this the year desktops finally start using linux as its kernel".

@lupyuen

@lupyuen First, it will never be the year of the "Linux desktop", as Linux is only a kernel and doesn't operate on its own.
Did you mean systemd/Linux?

I tried to read that article, but the example it gave was installing the proprietary malware known as steam, so I stopped reading.


The fact is, the kernel, Linux's SYSCALL ABI for each architecture does not change once it is stabilized.

You can run a statically linked elf from 1998 that only uses Linux SYSCALLs and it'll work today.

But, generally binaries are dynamically linked for security and sanity reasons and so you can't just copy those between systems and expect them to work.

Even so, generally libraries like glibc are forwards compatible, but you can't expect the ABI to be the same after 20 years - only the API.

As a result, the real packaging solution is to compile from source and let the compiler and build scripts to the rest.

Gentoo-libre and Guix is an example of how to properly manage packaging.

Really, you only have issues with packaging when it comes to using proprietary malware, as you can't compile software you only have the binaries of, as a result, the real solution is to just not use proprietary malware.

I can’t wait to read them. I have a few of those lanterns in safe places, with rolls of wicks and a little fuel stored up too. I’ll be happy to see what other insights your articles and or posts, will illuminate.

@lupyuen kinda reminded of the time microsoft tried to put that 'strong naming' thing in to .NET, which was something like including the signature of a library when you marked it as a dependency.