10
anti-snap stance is anti-consumer (lemdro.id)
submitted 2 years ago* (last edited 2 years ago) by to c/linux@lemmy.ml
58 comments fedilink hide all child comments
 

The title is a quote from Mastodon. I’ve always seen dislike towards snap so I was taken back when I saw this stance. The person who wrote this was referring to Tuxedo Laptops.

What are your thoughts on this?

EDIT:

Here’s the original comment: https://mastodon.social/@popey/112591863166141029

EDIT 2:

Some clarification for those accusing me of not following the thread or being disingenuous.

Didn't bother to follow the thread?

https://mastodon.social/@popey/112593520847827981

I posted my question here before this particular response from the OP. I asked the question on Lemmy out of interest and wanting to get a wider perspective. I also engaged with the OP on the thread so that I can get their perspective on their stance.

you are viewing a single comment's thread
view the rest of the comments
[–] 1 point 2 years ago (1 child)

Probably along the lines of 'its bloated and too many dependencies'.

Though most flatpaks use a common base, any modifications on top of that sometimes need to be stored modified (now having 2 or more copies of one dependency)

To anyone that's not a Linux nerd the app looks about the same size as on all other OS's, but on Linux it makes it a lot larger than just bare bones installing it via package manager

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

    But on the other hand, it works on all distros.

    I think the pros outweigh the cons here, no?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 2 years ago*

    Not for everyone, no. For me, each supposed pro has a corresponding con or is just a no-op:

    1. Only one package for all distros: Despite what people think, this does not lower the amount of work for the program's creator, who was never required to create any sort of binary package at all. Furthermore, it means that fewer people are checking the package for faults—that's part of what distro maintainers do, y'know.

    2. No external dependencies: Not only does this cause disk bloat, but it means that if the flatpak is no longer updated, the dependencies packaged inside it may not be either . . . which is one of the issues that dynamic linking was supposed to avoid in the first place. Might as well just go old-school and statically link the binary.

    3. Installations at user rather than system level: Only of value if I don't have admin authority, and I don't have to deal with a single system where that's the case, so this is a no-op.

    4. Supposedly more rapid updates: I'm running Gentoo, not Debian fossil :cough: oldstable. If I really want to, I can have my package manager install direct pulls from source control for many packages. New changes every day—beat that, flatpak. Plus, unless there's been a substantial change to a package's build method, I can bump actual releases myself just by copying and renaming a small file, then running a couple of commands.

    5. Sandboxing: As far as I'm concerned, the amount of security added by sandboxing and the amount of security added by the additional scrutiny from the distro maintainers is probably about even (especially since the sandbox, as a non-trivial piece of software, will inevitably contain bugs). And I can can throw firejail on top if I'm worried about something specific (or run it in a VM if I'm really nervous). I can understand why this might be attractive to some people, but for me the weight is very low.

    .

    So I'm left with avoiding bloat and bugs in flatpak's system integration vs. a little bit of security gained by additional sandboxing (which I don't think I really need, because I'm only mid-level paranoid). Thus, I'm not interested in complexifying my update process by incorporating flatpak into my system. Others' needs may be different.

  • permalink
  • fedilink
  • source
  • parent