this post was submitted on 05 Jul 2024
743 points (94.0% liked)

linuxmemes

20686 readers
805 users here now

I use Arch btw


Sister communities:

Community rules

  1. Follow the site-wide rules and code of conduct
  2. Be civil
  3. Post Linux-related content
  4. No recent reposts

Please report posts and comments that break these rules!

founded 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 30 points 2 months ago (5 children)

If you're separating your application from the core system package manager and shared libraries, there had better be a good and specific reason for it (e.g. the app needs to be containerized for stability/security/weird dependency). If an app can't be centrally managed I don't want it on my system, with grudging exceptions.

Chocolatey has even made this possible in Windows, and lately for my Windows environments if I can't install an application through chocolatey then I'll try to find an alternative that I can. Package managers are absolutely superior to independent application installs.

[–] [email protected] 54 points 2 months ago (1 children)

Typically Windows applications bundle all their dependencies, so Chocolatey, WinGet and Scoop are all more like installing a Flatpak or AppImage than a package from a distro's system package manager. They're all listed in one place, yes, but so's everything on FlatHub.

[–] [email protected] 2 points 2 months ago

This is true, the only shared libraries are usually the .NET versions, but so many apps depend on specific .NET versions that frequently the modularity doesn't matter.

[–] [email protected] 32 points 2 months ago (1 children)

I'm not sure where you're getting the idea that Flatpak aren't centrally managed...

[–] [email protected] 2 points 2 months ago (1 children)

Can I sudo apt upgrade my installed flatpak apps?

[–] [email protected] 3 points 2 months ago

No, because they're not apt packages. You can, however, flatpak update them, and you don't even need sudo since they're installed in the user context rather than system.

[–] [email protected] 25 points 2 months ago (2 children)

I think containerization for security is a damn good reason for virtually all software.

[–] [email protected] 21 points 2 months ago (1 children)

Definitely. I'd rather have a "good and specific reason" why your application needs to use my shared libraries or have acess to my entire filesystem by default.

[–] [email protected] 4 points 2 months ago (1 children)

Using your shared libraries is always a good thing, no? Like your distro's packages should always have the latest security fixes and such, while flatpaks require a separate upgrade path.

Access to your entire filesystem, however, I agree with you on.

[–] [email protected] 4 points 2 months ago

I only use rolling releases on my desktop and have ran into enough issues with apps not working because of changes made in library updates that I'd rather they just include whatever version they're targeting at this point. Sure, that might mean they're using a less secure version, and they're less incentivized to stay on the latest version and fix those issues as they arise, but I'm also not as concerned about the security implications of that because everything is running as my unprivileged user and confined to the flatpak.

I'd rather have a less secure flatpak then need to downgrade a library to make one app I need work and then have a less secure system overall.

[–] [email protected] 3 points 2 months ago

emerge sec-policy/selinux-*

[–] [email protected] 14 points 2 months ago (2 children)

I think stability is a pretty good reason

If an app can't be centrally managed

Open Discover, Gnome Software etc -> Click update?

[–] [email protected] 10 points 2 months ago (2 children)
[–] [email protected] 7 points 2 months ago

And with topgrade you can even upgrade flatpaks and your distros repos in one go

[–] [email protected] 5 points 2 months ago (1 children)

I'm now confused if they're saying that flatpak is centrally managed or not. To me it seems centrally managed, both the flatpak ecosystem but your whole machine (repo packages, firmware, flatpak) if you use those app stores. I might've misunderstood what they said.

[–] [email protected] 2 points 2 months ago (1 children)

We're both saying that it's centrally managed

[–] [email protected] 1 points 2 months ago

Fuck, I took both the wrong way. Sorry about that

[–] [email protected] 1 points 2 months ago (1 children)

Oh no, no GUI nonsense. Single, simple shell command update for the whole system so that it can be properly remotely managed, please. Something equivalent to sudo apt upgrade

[–] [email protected] 1 points 2 months ago

I've written a small script that does all the updates (repo, flatpak, docker), verified the packages, does cleanup and shows if stuff needs rebooted. Handy. That way I can do everything from one short command

[–] [email protected] 9 points 2 months ago (1 children)

Flatpack can be centrally managed, it's just like a parallel distribution scheme, where apps have dependencies and are centrally updated. If a flatpack is made reasonably, then it gets library updates independent of the app developer doing it.

"App image" and " install from tarball" violate those principles, but not snap or flatpack.

[–] [email protected] 1 points 2 months ago* (last edited 2 months ago) (1 children)

Um, if it's "parallel" (e.g. separate from the OS package manager) then it's not centrally managed. The OS package manager is the central management.

There might be specific use cases where this makes sense, but frankly if segregating an app from the OS is a requirement then it should be fully containerized with something like Docker, or run in an independent VM.

If a flatpack is made reasonably, then it gets library updates independent of the app developer doing it.

That feels like a load-bearing "if". I never have to worry about this with the package manager.

[–] [email protected] 3 points 2 months ago

Define "the OS package manager". If the distro comes with flatpack and dnf equally, and both are invoked by the generic "get updates" tooling, then both could count as "the" update manager. They both check all apps for updates.

Odd to advocate for docker containers, they always have the app provider also on the hook for all dependencies because they always are inherently bundled. If a library has a critical bug fix, then your docker like containers will be stuck without the fix until the app provider gets around to fixing it, and app providers are highly unreliable on docker hub. Besides, update discipline among docker/podman users is generally atrocious, and given the relatively tedious nature of following updates with that ecosystem, I am not surprised. Even best case, docker style uses more disk space and more memory than any other option, apart from VM.

With respect to never having to worry about bundled dependencies with rpm/deb, third party packages bundle or statically link all the time. If they don't, then they sometimes overwrite the OS provided dependency with an incompatible one that breaks OS packages, if the dependency is obscure enough for them not to notice other usage.