helloSystem Publishes New Experimental Build Based On FreeBSD 14.0

[dragon321]

AppImage is marvelous. Sadly money speaks louder and we are chained to Flatpak and Snaps.

Neither Red Hat or Canonical are paying to use Flatpak and Snap instead of AppImage. AppImage is indeed very convenient but it replicates one of the biggest Windows issue - library hell when every application has their own copy of same library.

[Alexmitter]

AppImage is marvelous.

Sadly money speaks louder and we are chained to Flatpak and Snaps.

The usual complaining and seeing a conspiracy behind it because some companies decide to sponsor some technology.

where libraries inside the PBIs were mapped ( trough hard or soft links ) into the usual Unix directories, so it was possible to share them to a certain degree.

Hey, its basically like Flatpak that does basically exactly that. Just that it happens inside a fakeroot because ya know sandboxing.

[pabloski]

Hey, its basically like Flatpak that does basically exactly that. Just that it happens inside a fakeroot because ya know sandboxing.

since when Flatpak dynamically searches for already installed dependencies and skips the installation process for the ones already preinstalled? heck it doesn't even install anything, not even creating hard links to dependencies

if you create two bundles with 90% of the resources being the same, it will happily open both bundles, with the obvious redundancy

so no, I am not whining, I know how these things work and I see no one has solved the biggest problem yet

[pabloski]

Neither Red Hat or Canonical are paying to use Flatpak and Snap instead of AppImage. AppImage is indeed very convenient but it replicates one of the biggest Windows issue - library hell when every application has their own copy of same library.

I am not saying they are paying to use their packaging systems, but they spend money to pay engineers to work on them. AppImage has no such luxury.

As for dependency hell, Flatpak and Snap don't solve it. They just "force" you to use bundles, that are a bunch of libraries ( specific versions ) that must be present in order to constitute the base environment for the program to run. But heck, this is something we could have done in the base Linux systems, by enforcing that specific dependencies must be present. And obviously by using symboling versioning, like glibc does for example. At least this way you can have strong retrocompatibility guarantees.

Systems like Flatpak and Snap are just promoting the same kind of bloating containers are. The concept is the same as of AppImage, "pack everything the program needs in the same bundle". But at the extreme this is just what static linking is all about. This is the reason why Go's architects decided to not implement dynamic linking at the beginning.

If you want to be super flexible in the choice of dependencies, you will get fragmentation. Microsoft tried to solve it and got a massive dependency hell. Others too. And others just admitted it is impossible and did go the "bundle" route ( Apple is famous in this sense ).

[DumbFsck]

Neither Red Hat or Canonical are paying to use Flatpak and Snap instead of AppImage.

Disagree on Snaps. Knowing you have a large slice of the market and telling partners "if you want your code running on client's servers running our code, you better adopt Snap" is sort of like paying people to use it. (although my guess is that this conversation went very different, and that most likely the majority of vendors would gladly adopt snap anyway, as it makes their life easier or so I heard). This is a mischaracterisation and overexageration, to the point of being cartoony - but it is just to show a point and not to represent my opinion of reality (sorry for all these disclaimers, it's just that I don't want people to think I think of canonical as some mustached top hat wearing villain. Far from it).

Agree with everything else though.