this post was submitted on 05 Jul 2024
730 points (93.9% liked)

linuxmemes

21188 readers
878 users here now

Hint: :q!


Sister communities:


Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
  • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
  • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.

  • 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] 31 points 4 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 4 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 4 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 4 months ago (1 children)

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

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

    Can I sudo apt upgrade my installed flatpak apps?

    [–] [email protected] 3 points 4 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 4 months ago (2 children)

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

    [–] [email protected] 21 points 4 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 4 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 4 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 4 months ago

    emerge sec-policy/selinux-*

    [–] [email protected] 14 points 4 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 4 months ago (2 children)
    [–] [email protected] 7 points 4 months ago

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

    [–] [email protected] 5 points 4 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 4 months ago (1 children)

    We're both saying that it's centrally managed

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

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

    [–] [email protected] 1 points 4 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 4 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 4 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 4 months ago* (last edited 4 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 4 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.