11–20 of 410 posts
Right! Time to pushback against these developers who uses Flatpaks, Appimages, Snaps, Electron, etc. We are no longer in the world of doubling performance and memory size. Even more, nowadays people are conscious of the power usage. Time to fight the bloat!
If you are a Linux distribution maintainer, please understand what all of
these solutions are trying to accomplish. All your hard work in building
your software repository, maintaining your libraries, testing countless
system configurations, designing a consistent user experience… they are
trying to throw all of that away. Every single one of these runtime packaging
mechanisms is trying to subvert the operating system, replacing as much as
they can with their own. Why would you support this?
The article bashes Flatpak portals as complex but otherwise doesn't make any solid arguments against them. That's important because it's easily the most important remaining problem to solve to get an effective sandbox. I actually like that for apps that have no business reading any files on my system they simply cannot do so. Sure, you can point to apps like GIMP and such that have chosen to give access to the file s…
The problem is that we still need a solution to stop hacked apps from calling fopen() on unrelated files. The article ignores how bad the native runtime security solutions are - SELinux is nigh unusable, no distro has many apparmor profiles, etc.
Flatpak and snap use containerization because Linux's security modules aren't common across distros and aren't very usable.
Right! Time to pushback against these developers who uses Flatpaks, Appimages, Snaps, Electron, etc. We are no longer in the world of doubling performance and memory size. Even more, nowadays people are conscious of the power usage. Time to fight the bloat!
Yeeh, who enter the plateau, abandon all hope you will get away with leaky abstractions.
Wish the lazy bloat-load was build as architectural pattern into apps. It only installs when you actually use it.
To be fair, as a daily user and (to some extent) app developer, in my experience Flatpaks have solved the problem of library fragmentation and app distribution on Linux. While my experience on Snaps was mostly negative (due to bugs, virtual "loop disks" per every app affecting the system performance, etc.), I found that Flatpak finally lets me install essentially any app on any distro. For example, the Elementary OS…
Nah they take up too much disk space. Rather use Gentoo
Earlier quoted context omitted.
Nah they take up too much disk space. Rather use Gentoo
Not sure if you misunderstand what Flatpak is or if you are really suggesting to ship a entire distribution for your users to install if they want to use the application you're delivering to them.
To be fair, as a daily user and (to some extent) app developer, in my experience Flatpaks have solved the problem of library fragmentation and app distribution on Linux. While my experience on Snaps was mostly negative (due to bugs, virtual "loop disks" per every app affecting the system performance, etc.), I found that Flatpak finally lets me install essentially any app on any distro. For example, the Elementary OS…
However the conclusion still holds imo, both are bad.Not necessarily because they haven't partially solved what they tried to achieve, but because they are being pushed instead of provided as alternatives to good-old package managers or binaries.
Though technically older than both, AppImage is more recent in adoption compared to both Flatpak & Snap, and yet 95% of the time i had absolutely no problem using AppImage(with the small caveat that desktop integration is less polished, and i use a neat tool called AppImageLauncher to 'install' them). I know it's an apples to oranges comparison and AppImage is not a package manager, but the point still stands.
For e.g. - firefox (https://www.mozilla.org/en-US/firefox/all/#product-desktop-r...). Win64 installer is 50mb. MacOS installer is 130mb. Linux 64-bit is 70mb.
Same is the case with Chrome - https://chromeenterprise.google/intl/en_US/browser/download/... . Windows MSI is 79mb. OSX PKG for the same is 195mb.
So by that measure - OSX has already lost right ? The entire package-everything-together has won in probably one of the largest OS ecosystem that exists today. Size does not matter... mom-proof experience does matter.
>How much progress could we make if Steam deprecated their runtimes, abandoned containerization for new games, and let all new games just use the native system libraries? How loudly do you think gamers would complain if a distribution upgrade broke their favourite game?
This OTOH does not exist. Linux gamers are 1% of either the gaming market or the desktop computing market. All gamers either dual boot windows...or android. Even for those who game on Linux, they do it on an abstraction layer like Wine. Which is what Valve maintains - https://github.com/ValveSoftware/wine and https://github.com/ValveSoftware/Proton
Valve only needs to maintain wine & proton for a distribution. The games themselves ? well, they are windows only. Nobody compiles for Linux.