4 ms·

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 m

by xvilka 5y ago

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!

0x0nyandesu 5y ago
Agreed
deleted 5y ago
[deleted]
OneTimePetes 5y ago
Should have performance indicators with every app - the kids who grew up on the performancelandfill slopes of the Mount Moore would have a hard time explaining away there whatsapp clone needing the same % as a major application. 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.
exikyut 5y ago
Doubling performance, no. But doubling memory size... kinda. 8-16GB is kind of the baseline now. Laptops with 64GB are increasingly common in certain niches. This being said, I do see these systems that basically just double down on adding layers for layers' sake as more disruptive than systemd.
cardanome 5y ago
Higher memory consumption as a trade off for developer convenience might be questionable in many cases but here it is to increase USER convenience. What are developers supposed to ship their apps with? Make packages for every Linux distribution under the sun? Flaktpaks and Appimages solve a real problem. The current alternative is NOT being able to use the specific software at all because you don't have the right version of Ubuntu. Maybe Guix/Nix are solutions for some of the pain points of traditional package management. And yes, libraries really need to focus on backwards compatibility. In the meantime, AppImage/Flatpack gets the job done. I am not out of luck when my distro does not offer the right package with the right version.
- xvilka 5y ago
  Static linking is always an option. It even can benefit from LTO and PGO this way.
dxuh 5y ago
Fight it yourself. Find a solution that's easy for developers and users and everyone will use it. It's very simple, actually (though not easy).

by xvilka 5y ago

0x0nyandesu 5y ago

Agreed

deleted 5y ago

[deleted]

OneTimePetes 5y ago

Should have performance indicators with every app - the kids who grew up on the performancelandfill slopes of the Mount Moore would have a hard time explaining away there whatsapp clone needing the same % as a major application. 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.

exikyut 5y ago

Doubling performance, no. But doubling memory size... kinda. 8-16GB is kind of the baseline now. Laptops with 64GB are increasingly common in certain niches. This being said, I do see these systems that basically just double down on adding layers for layers' sake as more disruptive than systemd.

cardanome 5y ago

Higher memory consumption as a trade off for developer convenience might be questionable in many cases but here it is to increase USER convenience. What are developers supposed to ship their apps with? Make packages for every Linux distribution under the sun? Flaktpaks and Appimages solve a real problem. The current alternative is NOT being able to use the specific software at all because you don't have the right version of Ubuntu. Maybe Guix/Nix are solutions for some of the pain points of traditional package management. And yes, libraries really need to focus on backwards compatibility. In the meantime, AppImage/Flatpack gets the job done. I am not out of luck when my distro does not offer the right package with the right version.

xvilka 5y ago
Static linking is always an option. It even can benefit from LTO and PGO this way.

dxuh 5y ago

Fight it yourself. Find a solution that's easy for developers and users and everyone will use it. It's very simple, actually (though not easy).