How does it stack up against traditional package management and others like AUR and Nix?

  • Montagge@lemmy.zip
    link
    fedilink
    arrow-up
    0
    ·
    8 months ago

    I use it but I hate how much space it uses and I hate when I update flatpaks I have no idea how much is going to download.

  • Shareni@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    8 months ago

    How does it stack up against traditional package management and others like AUR and Nix?

    I only used AUR for a few packages (<5 at a time). It’s to be avoided and only used if the other options are a massive pain (unless it’s an official package).

    Then I left Arch and eventually landed on MX. During that time Nix with home-manager has slowly replaced flatpak, and I don’t even have it installed anymore. Nix is better in every way, except for ease of use.

    Flatpak has great gui integration (for gui tools). You can click through everything, and the updates are unified. It usually works perfectly fine if you just need to install a few programs.

    With nix, there’s a lot more setup, but there are many benefits. You end up with a list of packages, and that’s really useful because you can take a fresh install, install nix and home manager, and then run a single line to reinstall everything. You can rollback updates, pin specific versions, install packages from a repo (if it has a flake.nix with outputs), and also configure them. I’m using the unstable branch, and it’s giving me bleeding edge packages on Debian. And there’s no risk of outdated system libraries, like with flatpak, because it provides everything.

    • Guenther_Amanita@feddit.de
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      That all sounds great, thanks!
      Do you have any tips for an “easy” start, where everything is already pre-configured?

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

        Nope, and that’s the worst part of nix. I’m actually planning on writing a short startup guide, but I need to solve a few more issues first.

        But, this should help you out until then:

        The home.nix should be automatically generated, and that’s where you put all of your packages. I left a few as an example.

        NixGL is needed to use openGL (nixGL lutris for example). It works in most cases, but I couldn’t get alacritty or kitty to work. There are some ways to have packages automatically use it, but I still haven’t tried them out.

        Flake allows you to select the correct nix repo (stable/unstable), appropriate home-manager version, and add outside packages like nixgl. It’s technically not necessary, but I wouldn’t go without it. Here I’m using the unstable repository, check the relevant docs if you want to go with releases instead.

        The equivalent of apt update && apt upgrade is nix flake update && home-manager switch --impure. I like cd-ing into the nix dotfile directory (all of the files are in there and symlinked to ~/.config/ locations), but you can also use command line arguments to point to the flake.

        nix flake update updates the package definitions to what’s in the repo

        home-manager switch install them, and also updates any configs it’s managing. The --impure is only needed if you’re using nixgl (bad build commands depend on system time).

        nix-collect-garbage to force a clean up of unused packages

        https://search.nixos.org/packages makes searching for packages a lot easier

        https://mynixos.com/search?q=home-manager+ same, but for finding options to configure packages through home-manager

        Comment if you need help

        update: removed nixGL from flake and home, installed it through nix-channel in order to not use --impure during home-manager switch

        • Guenther_Amanita@feddit.de
          link
          fedilink
          arrow-up
          0
          ·
          edit-2
          8 months ago

          Thanks! I saved the comment for later.

          What advantage do you see in Nix compared to Distrobox?
          I personally enjoy DB because of its simplicity.
          I just open BoxBuddy, create a new container from the dropdown-list, and then just start using my Debian or Arch container on top of Fedora Atomic for example.

          The two main benefits I see in Nix are the reproducibility and the big repo. But in case of the repository size, Debian and Arch (+ AUR) are extremely big aswell.
          Are there any other big benefits, that I can’t get with Distrobox, but with Nix?
          Just as a small side note, I’m no power user and tend to use my PC more like a casual guy.

          • Shareni@programming.dev
            link
            fedilink
            arrow-up
            0
            ·
            edit-2
            8 months ago

            I haven’t used distrobox, so take this with a grain of salt:

            • reproducibility: if you copy my nix files, the flake.lock will ensure you have the exact same results as me

            • declarative package management: you make a list of packages and the declarative nature forces you to keep it up to date at all times, that’s how you install/remove them. On arch you need to -Syu the package and remember to add it to an installation script (I never did). This also allows for easier maintenance because you don’t need to go through random dependencies to find an unused package you’ve installed (~100 packages on the list == almost 2000 packages installed). If there’s a distrobox version of a Dockerfile, you can do the same but it will most likely have the same disadvantages.

            • home-manager allows you to configure packages (usually not worth it though)

            • no need to export packages, when you install them they’re immediately available in your main distro

            • combine these and you have an extremely simple setup to distrohop, or work on multiple devices. You can also for example break off certain packages in a separate module, and only install them on a certain machine.

            • I’m guessing updates are easier, and if it breaks something, you can easily rollback to a previous generation. It will not only revert to the exact same packages you used previously, but it will also revert any package configs it controls. And on top of that it lets you pin a package to a specific version, and upgrade everything else.

            • cross-platform: you can take your list and install the same packages on win/mac natively. They don’t need to run linux in a vm like a container would

            • less storage used?

            • temporary package installs. For example I only needed arandr for 30 seconds to set up a new monitor, so I just nix shell nixpkgs#arandr and it created a shell with that package. When I was done I just closed the terminal, and didn’t need to think about it anymore. The package was completely removed the next time I ran nix-collect-garbage.

            • you need a package that’s in no repository, but it has a flake with all of the compilation dependencies? You just cd into the repo, nix develop, and you’ve got a temporary environment with everything you need to start following the compilation instructions

            But in case of the repository size, Debian and Arch (+ AUR) are extremely big aswell.

            Arch has a lot of packages, but there are some that I had to install through aur which I don’t like. Nixpkgs have so far had everything I needed, except for nixgl (although I couldn’t get a few of them to work). Also, you can chose between “stable” and unstable repos. Arch doesn’t have a frozen version with updates every ~6 weeks, and no other release based distro comes even close in either quantity or freshness.

            That’s what I can think of for a casual user. There are a lot more benefits for professionals to be honest, and I wouldn’t suggest nix at all if home-manager didn’t massively simplify the whole process. Getting to those few simple files from above was a massive pain, and it’s made even worse by the official nix guide suggesting outdated methods, and most of the support threads being for nixos. With them, you can get going in like 10 minutes even if you don’t know anything.

            • Guenther_Amanita@feddit.de
              link
              fedilink
              arrow-up
              0
              ·
              8 months ago

              Thanks for your great explanation!
              How up-to-date are the packages, compared to Flatpaks?

              IIRC, I used Nix a while ago to install a program, which was supposedly hard to build for Linux and crashed all the time as Flatpak. Sadly, the Nix version was almost a year old and also not great.

              But I think I’ll take a look into it again. I began using terminal apps a lot more and also became a huge fan of image based distros, and I think Nix packages have similar benefits as immutable distros.

  • Ryan@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    8 months ago

    I definitely prefer it over Snaps or appimages. Straight-forward to update, and Flatseal provides a nice GUI to control permissions (if needed). Themes may not work properly, but whatever, not a big deal for me.

    The distro’s repo is always my go-to. If it’s not available there, then flatpak, and I’ll use appimage under duress. If that doesn’t work, I’ll figure out a different solution.

  • Captain Aggravated@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    0
    ·
    8 months ago

    Some of the under-the-hood implementation of Flatpak irritates me, like why the hell are we installing software in /var? Using it with the terminal is a pain because of the org.something.SomeThing shit it does, and I think Flatpak gives you all the drawbacks of app sandboxing with none of the benefits. It likes to not see the whole file structure; for instance I found the Flatpak version of Steam to be unusable because it wouldn’t see anywhere I wanted to put my games library. That needs to be fixed.

    That said, I think it’s the better of the three all-distro package managers, it’s got a central repository and package manager unlike Appimage so it’s a place to publish and get stuff, and it’s not tied to Canonical so it’s obviously better than Snap.

      • Captain Aggravated@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        0
        ·
        8 months ago

        Installing a separate program to make the first program work the way it should in the first place, and opening bugs in repos, is abolutely 100% things end users are willing to do.

        • Pantherina@feddit.de
          link
          fedilink
          arrow-up
          0
          ·
          8 months ago

          KDE has flatpak settings included, GNOME is doing their thing with unix philosophy and all. Flatseal works fine.

          As I said, you should not need to edit those settings, maybe you need to, and if it generally makes sense (for example GNUmeric only has documents access, nothing else) this needs to be fixed.

          Will not happen often for common apps

            • Pantherina@feddit.de
              link
              fedilink
              arrow-up
              0
              ·
              8 months ago

              The state of flatpak permissions currently is like that. They can never read each others storage, much like on Android with /storage/emulated/0/Android/data. So it you keep stuff stored inside these apps its safe.

              Until they can use portals, many have permissions to read/write everything

  • kingmongoose7877@lemmy.ml
    link
    fedilink
    English
    arrow-up
    0
    ·
    8 months ago

    My totally unscientific opinion (with a double-your-money-back guarantee!):

    I’m not crazy about either Flatpak or Snap for that matter as there’s so much backend baggage for both as well as certain hurdles regarding privileges and access to the file system (somebody please correct me if I’m wrong or working with dated information.)

    My other completely prejudiced, unfounded bias against Flatpak is that it appears to have been adopted by RedHat as “the one true way,” and what with IBM’s/RedHat’s behaviour anti-FOSS behaviour lately, plus I’ve almost always have been an apt user, I find it a pill hard to swallow.

    Me, say what you will about the security issues and its other flaws, but I like AppImage.

    • Pantherina@feddit.de
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      8 months ago

      Flatpaks follow the concept “losen the sandbox as much as needed to make apps work”. This sucks, in constrast to android, but its needed.

      So you shouldnt need to edit anything via Flatseal/KDEs settings, if you want to make apps work.

      Flatpak is default on OpenSuse too, even more as they use Flathub instead of the Fedora Flatpaks repo. RHEL is just trying to get some money and stop people from using their work, as they need to make money.

      Honestly it should be normalized that people on FOSS do weird things to make money. Fedora is RHEL upstream, so RHEL is not stealing any code, just take what Fedora does and wait a bit until its stable.

      Appimages are completely flawed and as an apt user you should not like to use them, at all. This post of min may give some infos, I will update it soon.

      • kingmongoose7877@lemmy.ml
        link
        fedilink
        English
        arrow-up
        0
        ·
        8 months ago

        And speaking of completely flawed, your link doesn’t work.

        Anyway, thanks for berating informing me about AppImage but it’s the closest thing on Linux to app bundles which IM<HO is the sanest way to package applications.

          • kingmongoose7877@lemmy.ml
            link
            fedilink
            English
            arrow-up
            0
            ·
            8 months ago

            Thats a lemmy problem

            Hmmm…my link in the previous post works. More proof of why Linux has never really taken off with the non-spectrum general public. I guess just following format ([words](https://your.lousy.link)) or – god forbid – you select a word, click the link button and paste just isn’t esoteric enough…?

            In any case, I see that you edited your post to cover your tracks fix Lemmy’s error.

            • Pantherina@feddit.de
              link
              fedilink
              arrow-up
              0
              ·
              8 months ago

              The error is that I dont use https as every browser defaults to that, but lemmy links it internally. I fixed it. Stop annoying me, my comment was constructive and trying to help, so whatever this is stop it.

  • Lemmchen@feddit.de
    link
    fedilink
    arrow-up
    0
    ·
    8 months ago

    Does anyone know how they handle spoofed malware? I can never figure out whether I can trust the packages from flathub. I always have to check the official website of the particular software first.

  • Jesus_666@feddit.de
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    8 months ago

    On the one hand I like the basic idea, on the other hand I think that some fundamental problems aren’t fully solved yet. There big use case are passkeys and direct password manager integration – neither mesh well with the idea of software that isn’t allowed to talk to most of the system.

    I’m certain that this will be resolved at some point but for now I don’t think Flatpak and its brethren are quite there yet.

    • Pantherina@feddit.de
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      passkeys

      Dont know, may already work? Keyword adaption

      direct password manager integration

      Not sure what that means, but probably native messaging, a biig missing portal.

      Flatpak has an Inter-process-communication permission, so software could absolutely be opt-in allowed to talk, while keeping security for the rest. Apps cant see each others ~/.var/app/org.app.name/ storage though, never.

  • ZephrC@lemm.ee
    link
    fedilink
    arrow-up
    0
    ·
    8 months ago

    I still prefer traditional packages, but I get why devs of complicated graphical apps with lots of dependencies hate them. As for Flatpak specifically, I’m not super impressed. It’s just going to get more annoying over time having more old versions of all their libraries and more and more apps that aren’t updating to the latest version so they eat up a ton of drive space and give constant notices to harass the devs, but out of all the major distro agnostic options they suck the least and they’re getting better the fastest, which is why I think they’ve pretty much won at this point. I’m not currently using them, but it’s pretty much inevitable that I’ll have to at some point, and overall that’s probably more good than bad. I think AppImages could have been better if the lead dev wasn’t a walking, talking collection of weird hills to die on, but I’m afraid that ship has already sailed.

    • Pantherina@feddit.de
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      I mean if the apps are not maintained, they wouldnt work well as distro packages too, would they?

      • ZephrC@lemm.ee
        link
        fedilink
        arrow-up
        0
        ·
        8 months ago

        Not really. It’s actually pretty common for simpler, unmaintained apps to get small changes in each distro made by the distro maintainers to stay compatible with their current library versions. There’s nobody doing that on Flathub.

        • Pantherina@feddit.de
          link
          fedilink
          arrow-up
          0
          ·
          8 months ago

          Probably, but I guess thats the lack of “it has to be updated”. Just as distro maintainers do, flatpak maintainers or contributors can do as well, as its often pretty easy.

          • ZephrC@lemm.ee
            link
            fedilink
            arrow-up
            0
            ·
            8 months ago

            Sure, they can, and yeah it is pretty easy, but people have lives. They move on. A distro always has someone checking to make sure things aren’t broken. On Flathub it won’t even break. It’ll just waste drive space and start giving users annoying error messages, and there if the maintainer isn’t interested in maintaining it anymore the only option for doing anything about it is to fork the whole project, and who’s going to do that for something that isn’t even really broken?

            • Pantherina@feddit.de
              link
              fedilink
              arrow-up
              0
              ·
              8 months ago

              you dont need to fork a project to update its manifest on github flathub. I think the packaging is very easy and accessible, in comparison to maintaining some Debian repo package etc. Also there are way more officially supported apps on Flathub, so I dont think the lack of pressure to upgrade an app is such a big problem.

              But for sure, Onionshare was one of them, and different parts of the community took care of it.

              • ZephrC@lemm.ee
                link
                fedilink
                arrow-up
                0
                ·
                8 months ago

                How exactly do you update the github of a flathub package with no one actively maintaining it? Not sarcastic. That is an actual question.

                And I’m not worried about big officially supported apps. A better example of the kind of thing I’m talking about is older open source games. Flatpak could be great for games. No distro out there is maintaining a current version of every open source game that has ever been released, but Flathub can, and it could be great. Unfortunately anything that’s not being actively maintained is rapidly going to become a 200MB download that whines about security every time you update your flatpaks, even if it doesn’t connect to the internet at all. Even if it’s possible for any random person to update it, who will?

                Of course, this doesn’t just have to be about games. There are lots of open source programs out there that just kind of get completed and abandoned. And that’s not even bringing up all the closed source software on flathub that definitely won’t be updated eventually. These aren’t unsolvable problems, of course, but I don’t even think anybody working on flatpak even cares.

                • Pantherina@feddit.de
                  link
                  fedilink
                  arrow-up
                  0
                  ·
                  8 months ago

                  I dont know who manages “who can maintain”, if its only a single person thats bad of course. Good point that should be addressed to the flathub people. There should always be administrative access to some form of elected bunch of people that can then merge PRs or make new people admins.

                  True about the EOL runtime error messages, I mean they are important but should be possible to mute per app, especially when its offline. This will then just consume more disk space, which is probably fine.

      • scratchandgame@lemmy.ml
        link
        fedilink
        Tiếng Việt
        arrow-up
        0
        ·
        8 months ago

        Why it is unfounded?? The sandbox is still a lie (flatseal is impractical security since it makes you become a security researcher overnight), apps are not properly filesystem-unveiled. But a new level of complexity.

        • Pantherina@feddit.de
          link
          fedilink
          arrow-up
          0
          ·
          8 months ago

          Could you explain “filesystem-unveiled”?

          Apps are not updated to support portals for “compatibility” or just lack of maintenance. Flatpak needs to follow their approach if they want to have many apps being supported.

          Desktop Linux doesnt have the marketshare to dictate that all apps need to adopt portals. In the meantime, flathub.org has a rating system and verified checks, this is simply not well shown in KDE Discover and not sure about GNOME software.

          • scratchandgame@lemmy.ml
            link
            fedilink
            Tiếng Việt
            arrow-up
            0
            ·
            edit-2
            8 months ago

            Could you explain “filesystem-unveiled”?

            Means its filesystem access is restricted.

            For example, chromium on OpenBSD use the unveil(2) system call to restrict itself to /tmp and $HOME/Downloads .

            Many popular flatpak applications have filesystem=host. This is equal to restrict all filesystem access and then unveil the whole filesystem.

            Apps are not updated to support portals for “compatibility” or just lack of maintenance. Flatpak needs to follow their approach if they want to have many apps being supported.

            Desktop Linux doesnt have the marketshare to dictate that all apps need to adopt portals. In the meantime, flathub.org has a rating system and verified checks, this is simply not well shown in KDE Discover and not sure about GNOME software.

            If they can’t even enforce portals, flatpak is a new level of complexity.

            So I said it is trash.

            • Pantherina@feddit.de
              link
              fedilink
              arrow-up
              0
              ·
              8 months ago

              Good that Chromium does that, but this means if it doesnt use portals many things will be broken.

              The host access is not actually everything

              These directories are blacklisted: /lib, /lib32, /lib64, /bin, /sbin, /usr, /boot, /root, /tmp, /etc, /app, /run, /proc, /sys, /dev, /var

              Exceptions from the blacklist: /run/media These directories are mounted under /var/run/host: /etc, /usr

              Portals need a change in the app code that is not huge but differs from other packaging formats on any distro and OS. So it sucks that its so slow but that has a reason.

              • scratchandgame@lemmy.ml
                link
                fedilink
                Tiếng Việt
                arrow-up
                0
                ·
                8 months ago

                The host access is not actually everything

                Not as restrictive as chromium’s unveil.

                For home it even restrict to the downloads folder, not accessing the whole home directory.

                • Pantherina@feddit.de
                  link
                  fedilink
                  arrow-up
                  0
                  ·
                  8 months ago

                  Yes that only works for browsers and would completely break image viewers, document editors etc

  • OsrsNeedsF2P@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    8 months ago

    People need to realize that before Flatpak, distributing a small-time Linux app was a nightmare. Appimages were your best option if you wanted to avoid distro specific builds, PPAs and AUR, etc. Ever since packaging 2009scape on Flathub I haven’t looked back. It auto updates. People can find it from software centers. It works on all distros. It connects straight to upstream’s CICD. It even forced us to adopt XDG compliance so we could sandbox it better.

    Yes, Flatpak has downsides like the download size (on disk it doesn’t matter because it gets compressed and the runtimes are shared, same as literally any other package manager). But overall, I hugely welcome it over the options we had before. Much love to the Flatpak and Flathub devs!

  • atzanteol@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    8 months ago

    I’m a bit “eh” on flatpak. The only benefit I see is that it’s sometimes more up-to-date than what I can get from an LTS package repository. As a heavy CLI user they force me to find and click icons which is irritating (yeah - I know about flatpak run something.I.always.forget but that’s even worse somehow).

    I’ve hit occasional issues with applications being too locked-down. Like with Darktable only being able to see things in $HOME/Pictures. But I keep my photography work in a different location so it can’t see it. I had to jump through some odd hoops to fix that. Not a problem of flatpak itself per se but something you can expect when dealing with package makers.

    I fall back on flatpak if the version available through the standard package manager is too out-of-date for my liking. Other than that I can’t be bothered.

    EDIT: Okay - for people who think they’re being “helpful” by telling me that “aliases are a thing” just stop. I’m not going to workaround a broken system. I’m going to use another one that isn’t broken (or less broken).

    • ZephrC@lemm.ee
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      If you’re going to use flatpak from the command line you’re definitely going to need to start aliasing those flatpak run commands. It’s still annoying, but at least that way it’s only annoying once.

      • atzanteol@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        0
        ·
        8 months ago

        No. I’ll use snaps before I start maintaining a bunch of aliases that I shouldn’t have to. It’s a flaw in flatpak.

        • Pantherina@feddit.de
          link
          fedilink
          arrow-up
          0
          ·
          8 months ago

          No snaps are insecure on other distros that Ubuntu, as they are only isolated using apparmor. Also they are nonfree by design, just no.

          • atzanteol@sh.itjust.works
            link
            fedilink
            English
            arrow-up
            0
            ·
            8 months ago

            They’re not insecure. No more so than when I install a package via apt. No more so than when I download some code and compile it. This is propaganda.

                • Pantherina@feddit.de
                  link
                  fedilink
                  arrow-up
                  0
                  ·
                  8 months ago

                  You have the option to add the verified subset only, and you can always check permissions before starting an installed app, and it will not start before.

    • Pantherina@feddit.de
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      8 months ago

      Try this aliasing script I made

      No idea if it still works lol, but should tbh. I think its even pretty well done.

      1. Lists your installed flatpak apps
      2. Searches for already added aliases
      3. Convert the appname to be the last part, remove - _ and make uppercase letters lowercase
      4. Alias to bash, fish, zsh

      Only thing missing is handling duplicate apps I think.

  • daniyeg@lemmy.ml
    link
    fedilink
    English
    arrow-up
    0
    ·
    8 months ago

    purely as an end user i hate how much it downloads with each update and how much it uses the disk space although that’s much less of an issue. i know it’s solving a real problem and relieving a lot of the headaches of developers maintaing packages for each distro’s specific package standard, but it’s simply not the software distribution solution for people without at least well enough internet.

    i wouldn’t use any distro with flatpaks as its main way of delivering software and i would in almost all cases always choose alternatives even if it’s outdated. i don’t necessarily hate flatpak itself but for me i don’t want to spend money on extra data cap and wait 30 minutes for a small update for my game launcher to finish.

    the appimage of one of the applications i was interested in was 3 times less than the average flatpak update so redownloading the appimage every time would be better. if i installed more packages yeah the math would be better but it’s still wasted data per update no matter how small it actually is. i found out after a while of using flatpak that i wouldn’t just update and was stuck with outdated software anyway.

    • Bitrot@lemmy.sdf.org
      link
      fedilink
      English
      arrow-up
      0
      ·
      8 months ago

      Flatpak updates should generally download changed data, it does a poor job of showing how much this will be in advance though.

  • rotopenguin@infosec.pub
    link
    fedilink
    English
    arrow-up
    0
    ·
    8 months ago

    My main problem with Flatpak is that it hands temporary /var/run/1000 file links to programs instead of real filenames. That would almost be bearable, if Flatpak also took responsibility for keeping those links from breaking sometime after your next reboot.

    If I say “here is a path that an app is allowed to use”, flatpak should just allow an open() in there to work. It should not lie about the name of files in there. An app should be able to open a file there, remember that name, and count on being able to access it again in the future.

    Other than that, Flatpaks are the bees knees. I love finding something I want to do, finding a solution in the flatpak store, and click-click I’m already doing shit. Finding Windows software is absolute garbage next to this.

    • Pantherina@feddit.de
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      8 months ago

      Thats basically persistent portals. Would be possible if Distro portals had a button to give the app permanent (static) permission to that dir.

      Would indeed be useful and not hard to implement. In the portal window just add a button “permanent” which does

      flatpak override --filesystem=$PWD org.app.name
      

      Want to open a discussion or Feature request for your desktops portal?

    • Pantherina@feddit.de
      link
      fedilink
      arrow-up
      0
      ·
      8 months ago

      Flatpak is a project trying to fix many things at once

      • make apps that work on every distro
      • thus have apps officially supported by the devs, unlike distro packages mostly
      • sandbox apps with an android-like permission system with a rating system
      • use modern standards like delta-downloads, deduplication and BTRFS compression to save storage space
      • make everything nice and user friendly