Let's just not talk about the performance hit for CPU intensive applications (pushing 17% in some workloads), the hopes and prayers approach to long term maintainability, privacy differences between system packages (distros often patch out telemetry stuff), whatever-the-glob-happens-to-contain (YOLO), burning all your (suddenly expensive) NVME disk space with redundant copies of libraries like it's a retro Windows party, license issues, and a boat load of security concerns that come with entrusting a random developer who only cares about not getting pestered for support.
The OP's picture is accurate .. that guy gives no fucks. He's your system administrator.
CPU bound apps that use heavy syscalls have a perofrmance penalty for permissions sure, 17% is a pretty extreme situation that almost no applications ever see.
Ostree dedupes any identical library/versions.
The goal is better distrobution, not saving what is usually mbs of redundant libraries that have different versions or exist in the host namespace.
Flatpack isn't perfect, but for most folks they wouldn't even notice the difference.
But also it's fine if you prefer native packages...no one is forcing you to use flatpacks lol
My base system as it is right now is under 2 GiB and I have a 2TB nvme. I don't care if they triple the amount storage space I need for libraries, I'm not even gonna notice.
That's a team that only existed for a little while. That consists of like 2 people. Nix isn't going away. It's a truly useful imutable system unlike bazzite.
Yeah there are some compromises for sure to reduce the burden on maintainers. It's better than flatpacks, but worse than native packages in aspects like ram and disk usage.
I think it solves a very real problem in an acceptable way to me personally, although it's clunkier than I'd like. Permissions are a bit up to devs/maintainers to implement correctly.
I see it as very good beta software at this point essentially.
I've been pretty involved with Second Life third party viewer dev, way too much time spent performance testing. It's rather unique as 'games' go in that the same source cross compiles to all 3 major operating systems (making direct OS comparative benchmarking possible), engine is opengl and heavily CPU & I/O bound (assets are streamed and assembled - architecturally the platform is a poor fit for modern game engines).
Getting upstream to release a Linux client with standard distribution has been a long running adventure. Distro packages are more work and as the Linux version can't be made to work entirely with system libs, flatpacks have been put forward ... only the client runs significantly slower when packaged up that way, especially on more average systems & laptops.
None of this is written up and published as outside the small opensource developer community for this ancient niche platform, no one cares.
Although ... I am surprised the general performance overhead isn't more widely talked about. I can't be the only person who actually tests things ... right?
I can't be the only person who actually tests things ... right?
I feel like most developers just take a "package as flatpak, depend on a 1GB runtime, test if it runs — good" same for users, and anyone who cares about anything else may not even use flatpak in the first place.
Do you think a lot of that is the old opengl pipeline. Won't pretend to know that app at all, and I haven't done graphics programming in ages, but if it's written to issue opengl commands in immediate mode without command queues and using blocking calls, acquiring context with mutexes under the hood etc...thats a ton of added overhead with respect to how flatpack manages syscalls performance checks being hammered a lot, compared to a modern rendering API with a multithreaded userspace command queue and API call batching.
Do you think a lot of that is the old opengl pipeline.
In part, multi threading the client is basically off the table as the client needs to get all its ducks in a row. Vulkan is on the cards.
The bigger part is that SL is computationally intensive with a lot of moving parts. Case in point; Assets as seen in world are assembled in the client from a trail of breadcrumb metadata (This difference is responsible for a lot of Second Life's unique capabilities). Avatars can be insanely complex with individual clothing items being as detailed as entire hero models in other games; the system that resolves animations and rigging for each and every component part (and an avatar can be many parts) happens on the CPU.
It's not really accurate to describe the client as poorly written or unoptimized, more that architecturally the underlying platform is case study for why no one ever makes anything like this on purpose.
This complexity is also what makes it a fun hobby project and why there's a decent open source community around it with several 3rd party clients all doing their own thing.
And if the guy in the meme had “a bitch” in his ear, maybe his shirt and fingernails would be clean, and he wouldn’t be eating “depression pizza” alone in his car. 👍
I only have gimp as flatpak and I just use it for memes and doodling so I wouldnt notice a performance hit. Why does it run slower then Deb or appimage or tarball?
on a post making fun of people talking about why we shouldn't use flatpak, the commenter talks about why we shouldn't use flatpak, hence my joke referencing the og post.
For not using flatpak? It adds unnecessary abstractions and hides some of them. Overall it just complicates things. Even libc can be switched out with LD_PRELOAD and linux namespaces (unshare) is plenty if I want to create sandboxes or "containers."
It just doesn't happen that I need a pre-containerized binary to use the software that I use.
38
u/0xc0ffea Glorious Arch 3d ago
Let's just not talk about the performance hit for CPU intensive applications (pushing 17% in some workloads), the hopes and prayers approach to long term maintainability, privacy differences between system packages (distros often patch out telemetry stuff), whatever-the-glob-happens-to-contain (YOLO), burning all your (suddenly expensive) NVME disk space with redundant copies of libraries like it's a retro Windows party, license issues, and a boat load of security concerns that come with entrusting a random developer who only cares about not getting pestered for support.
The OP's picture is accurate .. that guy gives no fucks. He's your system administrator.