this post was submitted on 02 Oct 2023
833 points (95.7% liked)

linuxmemes

21183 readers
1288 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
    poopsmith
    zephyr
    rtxn
    833
    Remember kids: Canonical is not your friend. (i.imgur.com)
    submitted 1 year ago by [email protected] to c/linuxmemes
    149 comments fedilink hide all child comments
     
    you are viewing a single comment's thread
    view the rest of the comments
    [–] [email protected] 20 points 1 year ago (2 children)

    It’s slow, forced by Canonical, and starts a pointless format war with Flatpack.

    [–] yaaaaayPancakes 4 points 1 year ago (3 children)

    Flatpack isn't without its own quirks and flaws. There is no One True Way. Being open-source, there shouldn't be one.

    It is definitely slow though, mostly on first run.

    [–] ChunkMcHorkle 7 points 1 year ago

    Being open-source

    Yeah, that. That's exactly the problem. To quote @Puzzle_Sluts_4Ever above, who put it much better than I could:

    . . . the main issues boil down to concerns over some parts of the Snap ecosystem being closed source, Canonical’s ongoing efforts to try to get some of the Red Hat “premium linux” money, and arguments that other solutions (e.g. flatpaks and appimages) are “just as good, if not better”. And it doesn’t help that Canonical/Ubuntu is increasingly pushing snap as “the only solution” for some applications.

    When you speak of no single One True Way and things being completely open source, Canonical/Ubuntu have already left the chat.

    [–] iopq 4 points 1 year ago (2 children)

    There should be one way for sandboxed shit, since the alternative of package managers already exists

    We don't need snap, app image, flatpak all to compete. We need shit that just works

    [–] yaaaaayPancakes 4 points 1 year ago

    There's a bunch of different package managers too. It all just kinda works.

    [–] [email protected] 3 points 1 year ago

    Gotta be honest, as a dev I tried to make a Flatpack of my app and gave up. Making a snap was much easier. Of course, I also offer it as a .deb, .rpm, Pacman package, etc. too

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

    I still don't even know what problem snap and flatpak were intended to solve. Just apt or dnf installing from the command line, or even using the distro provided store app, has always been sufficient for me.

    [–] doktorseven 6 points 1 year ago* (last edited 1 year ago)

    Modern Linux distros tend to have configuration and dependency issues where certain packages if installed the "Linux Way" doesn't completely work as desired at times depending on the distro or even a desktop spin (which might have different default libraries installed than the "main" one). Flatpak is a single configuration meant to work one single way across all distributions and has become more of a standard, usable way for Linux applications to just work.

    Use Flatpak. Easy to install and easy to tweak from flatseal or similar GUI Flatpak permission tweakers if you want more flexibility at the possible cost of security.

    [–] jj4211 6 points 1 year ago

    The idea is that the application may want libraries asynchronously of the distribution cadence. Worse, multiple applications may have different cadence and you want to use both (some app breaks with gnome 45 and so it needs gnome 44, and another app requires gnome 46).

    Or some pick forks of projects that neglected to change the shared object name or version, so you have two multimedia applications depending on the same exact library name and version, but expecting totally different symbols, or different 'configure' options to have been specified when they built the shared library.

    So we have this nifty mount namespace to make believe the 'filesystem' is whatever a specific application needs, and for that to be scoped to just one.

    There's also an argument about security isolation, but I find that one to be unfulfilled as the applications basically are on the honor system with regards to how much access it requests of the system compared to a 'normal' application. So an application can opt into some protection so it can't accidentally be abused, but if the application wants to deliberately misbehave it's perfectly allowed to do so.