I’m admittedly yelling at cloud a bit here, but I like package managers just fine. I don’t want to have to have a plurality of software management tools. However, I also don’t want to be caught off guard in the future if applications I rely on begin releasing exclusively with flatpak.

I don’t develop distributed applications, but Im not understanding how it simplifies dependency management. Isn’t it just shifting the work into the app bundle? Stuff still has to be updated or replaced all the time, right?

Don’t maintainers have to release new bundles if they contain dependencies with vulnerabilities?

Is it because developers are often using dependencies that are ahead of release versions?

Also, how is it so much better than images for your applications on Docker Hub?

Never say never, I guess, but nothing about flatpak really appeals to my instincts. I really just want to know if it’s something I should adopt, or if I can continue to blissfully ignore.

  • onlinepersona@programming.dev
    link
    fedilink
    English
    arrow-up
    3
    ·
    33 minutes ago

    Adopt nix and you will be able to ignore it forever! 😉

    Seriously though, as others have said, use whatever fits you best. I avoided snaps and flatpaks due to the increased size requirements. So many things were duplicated for no apparent benefit (to me). However, with their introduction of permissions and portals, it does seem like a safer option. Although, we’re in a phase right now where not everything is flatpakked and applications trying to talk to each other is a pain (keepassxc unable to talk to flatpak firefox librewolf, chromium, etc.).

    Now that I use nix, I have a whole bunch of other problems, but at least getting packages is quite low on the list.

    Anti Commercial-AI license

  • d_k_bo@feddit.org
    link
    fedilink
    arrow-up
    7
    ·
    edit-2
    1 hour ago

    As someone who develops an distributes a small application exclusively on Flathub, I prefer that everyone uses the exact same package on every system. That way I know that if something doesn’t work, the issue should be easy to reproduce.

    Recently, there was a situation where a user indicated in the comments of a release announcement that a newly introduced feature “doesn’t work”. It turned out that they installed a third-party package from the AUR (that wasn’t updated yet) without knowing that this isn’t the official and up to date version.

  • dingdongitsabear@lemmy.ml
    link
    fedilink
    arrow-up
    3
    ·
    edit-2
    2 hours ago

    it comes down to how you use your system. if you’re fine using is as described and you’re on a distro that gets newest versions, keep on truckin’.

    for me, I hate rebooting. I like to leave my system and return to it, be it laptop or desktop, and continue where I left off. sometimes that goes on for days, sometimes weeks. that’s virtually impossible when updating both system and app stuff constantly, i.e. to get new apps you also get new kernel, mesa, plasma, whathaveyous.

    so I keep my system stuff that’s handled with the package manager and my app stuff separate. almost all of my GUI apps are flatpak and they are on a systemd timer so they get updated daily. my systems don’t bother me with update alerts, don’t do shit in the background and that’s how I like it. once a month or so I do a system upgrade and reboot.

  • kixik@lemmy.ml
    link
    fedilink
    arrow-up
    4
    ·
    2 hours ago

    FLOSS used to include the ability to build software. Perhaps that’s not important anymore but now a days some developers don’t attend problems with their build recipes because they only consider what they release through binaries, whether on flatpak or whatever other binary repository they like. At least I dislike that, it’s ok to me some or most users would prefer to grab a bloated binary rather than building anything, but that doesn’t mean forgetting about those actually wanting to build from source, or wanting to use shared libraries and software from their distros, actually that’s a requirement for free/libre software repositories. Not sure if the tendency is to move the gnu+linux users into app stores like the ones on windows, now ubuntu snaps, android play store and the like. Sure there’s more security with sandboxing, but nothing one can’t get with firejail, and if wanting MAC as well then firejail + apparmor for example.

    At any rate, just my little rant. And if you’re wondering, I use AUR on Artix, and I really hope I won’t have a need for a flatpak stuff.

  • Decker108@lemmy.ml
    link
    fedilink
    arrow-up
    23
    ·
    4 hours ago

    Sure you can! Just run alias flatpak=snap and you’ll be golden.

    (I’ll show myself out…)

  • ColdWater@lemmy.ca
    link
    fedilink
    arrow-up
    2
    ·
    2 hours ago

    Arch based distros (except for Manjaro) has every FOSS and some proprietary software on the AUR

  • Arthur Besse@lemmy.mlM
    link
    fedilink
    English
    arrow-up
    28
    arrow-down
    4
    ·
    edit-2
    6 minutes ago

    Downsides of distro pacakges:

    • someone needs to package an application for each distro
    • applications often need to maintain support for multiple versions of some of their dependencies to be able to continue to work on multiple distros
    • users of different distros use different versions of the application, creating more support work for upstream
    • users of some distros can’t use the application at all because there is no package
    • adding 3rd party package repos is dangerous; every package effectively gets root access, and in many cases every repo has the ability to replace any distro-provided package by including one with a higher version number. 3rd party repos bring the possibility of breaking your system through malice or incompetence.

    Downsides of flatpak:

    • application maintainers are responsible for shipping and updating their dependencies, and may be less competent at doing timely security updates than distro security teams
    • more disk space is used by applications potentially bringing their own copies of the same dependencies

    🤔

    • argon@lemmy.today
      link
      fedilink
      arrow-up
      16
      ·
      edit-2
      4 hours ago

      Another upside is the easy permission management.

      You can revoke network access from your password manager to reduce attack surface; you can revoke camera access from your chat app to prevent accidentaly enabling it; You can restrict an app’s file system access to prevent unwanted changes; etc.

      It’s not yet fit to protect from malicious apps, but it still finds some use.

  • Churbleyimyam@lemm.ee
    link
    fedilink
    arrow-up
    4
    ·
    4 hours ago

    If your distro provides everything you need then I would avoid flatpak. Getting apps to speak to each other is a pain, updates use more data, backups and restores take much longer, they don’t perform as well and config files are not necessarily where you expect them to be.

    I have Debian Stable on an older laptop and only install apps as flatpaks if they are not available otherwise. I also have a very new laptop with Fedora on it (because it needs a newer kernel) and have had to install more flatpaks just to make things work properly, because they include their dependencies, codecs etc which are missing in Fedora. Appimages seem to do this too and I find them preferable to flatpak because they integrate more predictably with my system. Apps are slower to launch though and have to be manually updated.

    Like you, I’d prefer to just have a package manager and a single source of software and plan to go back to Debian when my newer machine is supported by it.

  • cmgvd3lw@discuss.tchncs.de
    link
    fedilink
    arrow-up
    26
    arrow-down
    2
    ·
    6 hours ago

    I might be an exception here, but I really like flatpaks. I like their sandboxed nature and using Flatseal, you can cherry pick the permissions you want to give to a flatpak application. Don’t want to give n/w access, boom done, like that. And finally if anything goes wrong, delete the app data and you are fresh to go. Also from a security standpoint, you can grand or deny access to specific directories and most apps don’t have root access.

  • jokeyrhyme@lemmy.ml
    link
    fedilink
    English
    arrow-up
    11
    ·
    5 hours ago

    Can I ignore flatpak indefinitely?

    Sure, at least until software you want to use is flatpak only, e.g. Bottles

    • Shareni@programming.dev
      link
      fedilink
      arrow-up
      6
      ·
      edit-2
      5 hours ago

      Or use a stable distro, need a package newer than 2 years, and don’t want spend a day compiling dependencies of dependencies.

  • hollyberries@programming.dev
    link
    fedilink
    arrow-up
    19
    ·
    7 hours ago

    Is it because developers are often using dependencies that are ahead of release versions?

    That has been my experience recently. I had the same mindset as you until a critical piece of software I use shat the bed on Arch (LiveCaptions) that affected my being able to watch training videos for work.

    Because it was time critical and I didn’t feel like possibly breaking other things for one package, I grabbed the flatpak. It came with its own nvidia driver package (mine was newer) and it worked out of the box without having to mess with anything and that was enough to change my hardline view on that.

    Now it’s just another tool to use in an emergency when important things randomly break.

  • That’s what I do. But then I mostly use Arch or Arch based distros (e.g. EndeavourOS). So I have access to AUR. If something isn’t on AUR (very rare, but can happen), I just create the package for it and publish to AUR. I do use some AlmaLinux machines as server. I don’t really need many programs outside of the standard repos there since I use them mostly for hosting Docker images. But if I do need to install something like that, I’ve some self-written LURE install scripts.

  • Sickday@kbin.earth
    link
    fedilink
    arrow-up
    26
    ·
    7 hours ago

    I don’t develop distributed applications, but Im not understanding how it simplifies dependency management. Isn’t it just shifting the work into the app bundle? Stuff still has to be updated or replaced all the time, right?

    That’s correct. This simplifies the dependency management system because not every distribution ships with every version of every package, so when software requires a version of a package that the distro dosesn’t ship with or have in its repositories, the end user has to either build the package from source, or find some other way to run their software. Flatpaks developers will define the versions of dependencies that are required for an application to run and that exact version is pulled in when the flatpak is installed. This makes the issue of every distro not having every version of every package moot.

    Don’t maintainers have to release new bundles if they contain dependencies with vulnerabilities?

    They don’t have to, no. But they absolutely should.

    Is it because developers are often using dependencies that are ahead of release versions?

    Sometimes, yes. Or the software is using a dependency that is so old that it’s no longer included in a distro’s package repositories.

    Also, how is it so much better than images for your applications on Docker Hub?

    I would say they’re suited to different purposes.

    Docker shines when availability is a concern and replication is desired. It’s fantastic for running a swarm of applications spread across multiple machines automatically managing their lifecycles based on load. In general though, I wouldn’t use Docker containers to run graphical applications. Most images are not suited for this by default, and would require you install a bunch of additional packages before you could consider running any graphical apps. Solutions to run graphical applications in Docker do exist (see x11docker), but it doesn’t really seem like a common practice.

    Flatpaks are designed to integrate into an existing desktops that already have a graphical environment running. Some flatpaks include the packages required for hardware acceleration (Steam, OBS) which can eliminate the need for those packages to be available via your distro’s package manager.

    What this means is that a distro like Alpine Linux that doesn’t have an nvidia package in its repos can still run Steam because the Steam flatpak includes the nvidia driver if you have an nvidia GPU installed.

    Never say never, I guess, but nothing about flatpak really appeals to my instincts. I really just want to know if it’s something I should adopt, or if I can continue to blissfully ignore.

    ¯_(ツ)_/¯ It’s a tool. Use it when it’s useful, or don’t.

    • krakenfury@lemmy.sdf.orgOP
      link
      fedilink
      English
      arrow-up
      9
      ·
      edit-2
      6 hours ago

      Thanks for the detailed answer. I think I have a clearer picture of the problems it’s trying to solve and the solutions it’s delivering.

      It also now seems connected to immutable distros I’ve heard about recently. So I guess the idea there is that the OS is just a tiny core set of libraries that never have to change, then the applications have their dependencies bundled, instead of requiring them as system dependencies.

      I’m not convinced it’s something I want as a user, but more importantly not something I need.

      From a development perspective, it seems downright seductive, allowing almost total freedom of opinion.

  • Emma Liv@lemmy.ca
    link
    fedilink
    English
    arrow-up
    11
    arrow-down
    2
    ·
    edit-2
    6 hours ago

    Just as my two cents, as a user - I like flatpaks because I can have up to date versions of certain applications on a more stable Debian base. I also like that application configs all go in one spot (~/.var/app/com.Example.example), and having granular permissions management per application. As for immutable distros, I’d happily use one if I wasn’t already getting all the stability I need from LMDE :)