I am currently using Linux Mint (after a long stint of using MX Linux) after learning it handles Nvidia graphics cards flawlessly, which I am grateful for. Whatever grief I have given Ubuntu in the past, I take it back because when they make something work, it is solid.

Anyways, like most distros these days, Flatpaks show up alongside native packages in the package manager / app store. I used to have a bias towards getting the natively packed version, but these days, I am choosing Flatpaks, precisely because I know they will be the latest version.

This includes Blender, Cura, Prusaslicer, and just now QBittorrent. I know this is probably dumb, but I choose the version based on which has the nicer icon.

all 23 comments

sorted by: hot top controversial new old
[–] 1 point 3 years ago* (last edited 3 years ago)

i avoided flatpacks before.
but now that i tried out silverblue and had to rely heavily on them,
i have to admit that flatpacks are not nearly as bad as i thought.

the only issues i encountered are with steam (might not start propperly on first launch)
and with ides(terminal starts inside the sandbox)

other than that it works great.

  • source
  • [+] 1 point 3 years ago* (last edited 2 years ago)
    [–] 1 point 3 years ago (1 child)

    I accept that I'm in the minority on these things, but I value simplicity really highly, and I mean "simple" as a very specific concept that's different from "easy". It can be harder to resolve library dependencies on a system where everything is installed using the native package manager and common file systems, but nothing is as "simple" as ELF binaries linking to .so files. Nested directories branching off of / is "simpler" than containers.

    Do I have any practical reason for preferring things this way? Not really. There are some ancillary benefits that come from the fact that I'm old and I already know how to do more or less anything I need to do on a Unix system, and if you tell me I need to use flatseal or whatever, I'd rather just use users and groups and tools that have been fine for me for 25 years. But that's not really why I like things this way. I have no issue with embracing change when it otherwise appeals to me --I happily try new languages and tools and technology stacks all the time. What it really is is that it appeals to the part of my brain that just wants to have a nice orderly universe that fits into a smaller set of conceptual boxes. I have a conceptual box for how my OS runs software, and filling that box with lots of other smaller little different boxes for flatpack and pyenv and whatever feels worse to me.

    If they solved practical problems that I needed help solving, that would be fine. I have no problem adopting something new that improves my life and then complaining about all the ways I wish they'd done it better. But this just isn't really a problem I have ever really needed much help with. I've used many Unix systems and Linux distributions as my full-time daily use systems since about 1998, and I've never really had to spend much effort on dependency resolution. I've never been hacked because I gave some software permissions it wouldn't have had in a sandbox. I don't think those problems aren't real, and if solving them for other people is a positive, then go nuts. I'm just saying that for me, they're not upsides I really want to pay anything for, and the complexity costs are higher than whatever that threshold is for me.

  • source
  • hideshow 2 child comments
  • [–] [S] 1 point 3 years ago

    Your knowledge of Unix systems is incredibly powerful, and I highly respect that. You are in control of your system, which is the ultimate goal of personal computing. It is even more powerful that your mental models are reflected in your system. That is super cool, I hope to get their some day.

    I am also very happy you enjoy trying out new technologies, and don't have the grumpy jadedness of just using what you always use.

    For me I thoroughly enjoy learning new skills that unlocks the power of all my many computers, and put them to use. Computing should be fun and empowering, and too often people deprive themselves of fun.

  • source
  • parent
  • [–] 0 points 3 years ago (1 child)

    I use Flatpaks for everything I can. I like how Flatpak keeps apps in a container isolated from my system. Also, Flatpaks contains every lib in every version I need for my installed apps, which means It does not rely on my system libs, and I like It, cause my system libs is to make my system works only.

    Flatpaks are just the future of packaging

  • source
  • hideshow 2 child comments
  • [–] [S] 0 points 3 years ago (1 child)

    Great explanation and rationale for using Flatpaks! I hope others with questions see this.

    I understand how people may be annoyed by the redundancy of every app packaging their own lib, but I swear those are measured in kilobytes, and people tend to be so obsessively minimalist it is a non-issue. Then again, minimalist are probably compiling their software.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 0 points 3 years ago (1 child)

    I disagree. The other day I wanted to install some audio app that came in flatpak install format (I'll check and add the name later). The app was less than 30MB in size, but the installation included 300MB of a previous version of org.freedesktop!

  • source
  • parent
  • hideshow 2 child comments
  • [–] [S] 1 point 3 years ago

    I think that is one time download of a library so the app can run. Also, any other app that needs it.

    It seems to me that the biggest complaint people have with flatpaks are the space it takes.

    I wonder if the blow up in GBs was an early buggy behavior?

  • source
  • parent
  • [–] 0 points 3 years ago (1 child)

    No, because I don't have a very powerful computer

    Even if I did, I would still prefer to have native applications because it would be more permissive

  • source
  • hideshow 2 child comments
  • [–] [S] 0 points 3 years ago (1 child)

    I am totally ignorant, do flatpaks use a lot more processing?

  • source
  • parent
  • hideshow 2 child comments
  • [+] -1 points 3 years ago* (last edited 9 months ago) (1 child)
  • [–] [S] 0 points 3 years ago (1 child)

    I am glad that the startup times have improved, that bodes well for future startup times. Using up more storage really is what makes it suck for everyone. I thought that it was more efficient, since I see a lot of .platform, and I assumed those are libraries shared across flatpak apps that use those dependencies.

    I am almost sure AppImage has the same problem? I don't know, people do rated that better though.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 0 points 3 years ago (1 child)

    This is exactly what flatpaks were meant to do. Simplify the program deployment across all distros

  • source
  • hideshow 2 child comments
  • [–] 0 points 3 years ago (2 children)

    100%. I just wrote a long post surmising this somewhere, but I'm switching my 5 year old Arch install to something like Debian Stable/Testing because I use almost entirely Flatpaks for my user applications (I would do 100% of them if every app I used had a Flatpak), and it's really just a much better idea to run bleeding edge on only the stuff you care about instead of an entire system.

  • source
  • hideshow 4 child comments
  • [+] -1 points 3 years ago* (last edited 9 months ago)
    [–] -2 points 3 years ago (1 child)

    I don't like flatpak or snap or any of them. System libraries exist for good reason, just because your computer is stupid fast and you have enough disk for the library of Congress a couple times over doesn't mean you should run a veritable copy of your whole operating system for each program. IMO it's lazy.

    Sandboxing is a different thing though, if that's the purpose then it's doing it right.

  • source
  • hideshow 2 child comments
  • [–] 2 points 3 years ago* (1 child)

    I have a ton of flatpaks which means packages are shared between them, so no it’s not lazy or a copy of the whole system. It makes a ton of sense for stability.

    Updates are diff’s so downloading and updating is fast. Not entire packages.

    Making every package work with only a certain version of a dependency and hoping it is stable doesn’t make a lot of sense.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 0 points 3 years ago

    You've just moved the packaging problem from distributions to app developers.

    The reason you have issues is historically app developers weren't interested in packaging their application so distributions would figure it out.

    If app developers want to package deb, rpm, etc.. packages it would also solve the problem.

  • source
  • parent