| ▲ | Joel_Mckay 3 days ago |
| > installed using Flatpak So essentially people are abandoning the memory/speed efficiency of the .so ecosystem, and seeking exe/msi style convenience... You know... a dump of legacy dll/static-so-snapshot versions with endless CVEs no one will ever be able to completely fix or verify. Should be fun, and the popcorn is waiting =3 |
|
| ▲ | akimbostrawman 3 days ago | parent | next [-] |
| If you ever used flatpaks you would know that they are very noisy about dependencies being not up to date. They also gain substantial amount of security by being sandboxed by default unlike majority of native packages. |
| |
| ▲ | Joel_Mckay 3 days ago | parent | next [-] | | Snap and Flatpaks only real legitimate use-case is legacy compatibility: 1. Current release applications on deprecated OS (Mostly good) 2. Deprecated applications on current OS (Mostly bad) The Windows style packaging architecture introduces more problems than it solves. Fine for running something like Steam games with single shot application instances using 95% of system resources each power cycle, but folks could also just stick with Windows 11 if convenience and security-theater is their preference. Some people probably won't notice the issues, but depends what they do. Arch Linux itself is a pretty awesome distro for lean systems. =3 | | |
| ▲ | akimbostrawman 3 days ago | parent [-] | | >single shot application instances using 95% of system resources each power cycle Source? There is no measurable energy or efficiency difference at least for flatpak on any semi recent hardware. I know that snaps do take couple seconds longer at first start. I prefer flatpaks for proprietary and internet facing applications because of there easy sandboxing capabilities. There is also the advantage on archlinux not needing to do a full system update for a single application. | | |
| ▲ | Joel_Mckay 3 days ago | parent [-] | | People often started here: https://tldp.org/HOWTO/Program-Library-HOWTO/shared-librarie... Getting into why the community argued for years while Debian brought up deb version controlled packaging is a long dramatic conversation. Some people liked their tar ball mystery binaries, and the .so library trend started more as a contest to see how much people could squeeze out of a resource constrained machine. In a single unique application running context, the power of a cached .so reference count are less relevant. As a program built with .so may re-use many resources other programs or itself likely already loaded. > ldd --verbose /usr/bin/bash > ldd --verbose /usr/bin/cat Containerization or sand-boxing is practically meaningless when punching holes for GPU, Network, media and HMI devices. Best of luck =3 | | |
| ▲ | akimbostrawman 2 days ago | parent [-] | | >Containerization or sand-boxing is practically meaningless when punching holes for GPU, Network, media and HMI devices Many applications don't need these permissions and even the ones that do will be much more secure than having full user space access by default. Someone could exploit the system to gain more access vs someone does not need to do anything because they have full access by default. It's like arguing you don't need a root password because sudo is insecure anyway. | | |
| ▲ | Joel_Mckay 2 days ago | parent [-] | | Not really, if some noob deploys janky code they don't understand, than someone will eventually worm it for sure. Containerization has not prevented an uptick in nuisance traffic from Cloud providers, but made it orders of magnitude worse. Qubes, Gentoo, and FreeBSD are all a better place to start if you are interested in this sort of research. Best of luck =3 |
|
|
|
| |
| ▲ | fransje26 3 days ago | parent | prev | next [-] | | https://ejona.ersoft.org/archive/2024/03/03/flatpak-perm-sur... | | |
| ▲ | akimbostrawman 2 days ago | parent | next [-] | | Flatpaks can have insecure permissions which are not only transparent but easily editable. Meanwhile native packages are guaranteed to have insecure/all permissions. | | |
| ▲ | Joel_Mckay 2 days ago | parent [-] | | In general, SELinux profiles use Mandatory Access Control, and not Discretionary Access Control. However, most desktop users find it difficult to understand, and often have bigger problems from reading silly posts off the web. An outdated old package library relies on people understanding/tracking the complete OS scope of dependencies, and that is infeasible for a small team. If someone wants in... they will get in eventually... but faster on a NERF'd Arch install. =3 | | |
| ▲ | akimbostrawman 2 days ago | parent [-] | | >most desktop users find it difficult to understand, and often have bigger problems That is exactly the strong point of flatpaks. It's a lot easier to use toggle in a GUI for permissions than write whole new profiles. Not to mention that many even disable selinux because it is difficult. >An outdated old package library relies on people understanding/tracking the complete OS It takes 0 understanding to copy paste a outdated package warning and report that to the repo listed in flathub. It explicitly tells you as much. |
|
| |
| ▲ | Joel_Mckay 3 days ago | parent | prev [-] | | It seems the AstroTurf'ing folks buried the parent as children often do. But thanks for trying to post actual relevant data on the topic. =3 "Popcorn Music Video" (The Muppets) https://www.youtube.com/watch?v=Gwg5ey6236o |
| |
| ▲ | s_ting765 3 days ago | parent | prev [-] | | Security/dependancy updates depend solely on the specific maintainers. The platform itself doesn't automatically fix the developer or maintainer lethargy in this regard. | | |
| ▲ | akimbostrawman 3 days ago | parent [-] | | Yes obviously but it gives the user a clear alert to inform the package maintainer or remove the package. | | |
| ▲ | Joel_Mckay 3 days ago | parent [-] | | This doesn't work. One will need to time-travel back to a LUG in the early net to understand the sirens song of tar balls =3 |
|
|
|
|
| ▲ | quotemstr 3 days ago | parent | prev [-] |
| But also hilariously still paying the runtime cost of ELF dynamic linking instead of just static linking so at least you avoid, e.g. GOT indirection overhead. |
| |
| ▲ | Joel_Mckay 3 days ago | parent [-] | | Again, static linking would only be useful in a single unique App run and dump scenario. People do link and strip .a sometimes when porting to Windows and MacOS. Some programs take a huge memory and performance hit on non-Linux machines. =3 | | |
| ▲ | quotemstr 3 days ago | parent [-] | | > Some programs take a huge memory and performance hit on non-Linux machines You're implying without stating it (or providing any evidence) that programs perform worse when statically linked than when assembled out of ELF DSOs, even when each of those DSOs has a single user. That makes no technical sense. Perhaps you meant to make a different point? | | |
| ▲ | Joel_Mckay 3 days ago | parent [-] | | An 8kB program loads and runs much faster if the .so it uses is already cached due to prior use. A 34MB static built version will cost that amount of i/o every single instance on a system that did not cache that specific program previously. Also it will take up that full amount of ram while loaded every single time it runs. Inefficient design, but works fine for other less performant OS =3 | | |
| ▲ | quotemstr 3 days ago | parent [-] | | > 34MB static built version I've forgotten how to count that low. Also, static programs are demand paged like anything else. Files aren't loaded as monoliths in either case. Plus, static linking enables better dead code elimination and devirtualization than is possible with an AOT-compiled and dynamically linked setup, which usually more than makes up for the text segments of shared dependencies having been pre-loaded. I'm not sure you have enough technical depth to make confident assertions about linking and loading performance. > =3 The "blowing smoke" emoticon isn't helping your argument. | | |
| ▲ | Joel_Mckay 3 days ago | parent [-] | | If a stripped static linked library saved that much space, than people probably chose the wrong library resources. Sometimes ripping off unreachable areas also has unintended consequences, but stripping debugging resources is usually safe. If .so reuse is low, or the code is terrible... it won't matter much. Best of luck =3 |
|
|
|
|
|
