6 ms·

With 100% more snaps? No thanks.

by bfrog 3y ago

Gordonjcp 3y ago
What exactly is wrong with snaps?
- binarymax 3y ago
  It’s not possible to freeze a working configuration with snaps as they always auto-update. This is problematic for deploying software that has known working dependency versions. Edit: I didn’t know about the new updates to snap and pinning. Thanks for the info!
  - Gordonjcp 3y ago
    Yes you can, you just specify the channel you want to pin it to.
  - asddubs 3y ago
    lunar lobster introduces the option to put snaps on hold
- smoldesu 3y ago
  Oh boy... - As a user: Snaps are annoying and don't work like a native app. It creates a new folder in my home directory, has little very consistency with other apps (even other packages of the same app), and feels generally unsuited for desktop use. If I'm going to use any of these godawful statically-linked-runtime package managers, it won't be the proprietary one. - As an admin: Snaps are alright. If you just need to insta-configure something and are extremely lazy, it's a faustian deal pre-installed on every Ubuntu machine. As loathe as I am to admit it, most snaps are a cinch to install compared to native packaging or even Flatpak.
  - Gordonjcp 3y ago
    So basically their problem is "New Thing Scary, Grug No Like"?
- blendergeek 3y ago
  The snap client only supports the Canonical Snap Store. There is not even an "advanced configuration" to add your own. I do not want a single point of failure in the Linux ecosystem. Canonical does.
- MattPalmer1086 3y ago
  Slow, proprietary, auto update, sandboxed (which causes integration problems with other things). Solves a problem for Canonical and makes everyone else's life harder.
  - throw10920 3y ago
    Sandboxing is a necessary evil - the Linux security model for applications installed on your computer is atrocious. The two main options we have to fix it are either a fine-grained capabilities model, or a coarse-grained sandboxing model - and the latter is an order of magnitude less work to implement. However, Snaps do an impressively poor job of implementing a sandbox.
    - CoastalCoder 3y ago
      > Sandboxing is a necessary evil Can you elaborate on the "necessary" part? I'm able to accomplish my computing goals without snaps.
      - throw10920 3y ago
        "Necessary" because Linux's security mitigations are unacceptably insecure for the 21st century. As it stands, I have to completely trust applications before I run them, and there's literally no reason for that to be the case - sandboxing is a straightforward mechanism, not a tricky problem like Traveling Salesman.
    - MattPalmer1086 3y ago
      Simply not necessary for normal applications running on my local desktop. And yes, I do work in security.
      - throw10920 3y ago
        I don't care if you work in security - the fact is that I have to completely trust every application that I want to run on Linux, which is unacceptably bad, and "Simply not necessary for normal applications running on my local desktop" is factually false (unless you're using some "gotcha" convoluted definition of "normal"). A sanely-designed OS will provide either capabilities or sandboxing - the tech has been around for decades, and they're more needed than ever in the 21st century with its abundance of malware.
- nicolaslem 3y ago
  Snap has been around for 8 years and during this time it got zero traction outside of Ubuntu. Canonical is known for axing their own projects eventually when they fail to get traction, so it seems pretty safe to assume that the writing is on the wall for snap.
  - lockhouse 3y ago
    In Canonical’s defense, it seems like every time they try to do something innovative, Red Hat copies the idea and implements it slightly better. Upstart -> systemd Unity -> Gnome 3 Shell Mir -> Wayland Snaps -> flatpak I’m not saying Red Hat is wrong to do this, that’s the nature of healthy competition and we all benefit from this.
    - doubled112 3y ago
      Weren't Wayland and flatpak first? And GNOME 3 as well? Unity was a reaction to GNOME 3's big changes. Either way, I agree that competition is better.
      - selivanovp 3y ago
        No. Snap started as a project and got useful before flatpak. Wayland technically was before Mir, but existed as blueprints and ideas back then. Shuttleworth tried to influence its design for his vision of linux desktop, but got rejected, so Mir was created. Mir became useful way before first implementations of Wayland, but Shuttleworth idea to expand Mir and Ubuntu to phones resulted in feature creep, lack of funding and eventually to project failure. Gnome shell was also released after Unity. Both were influenced by MacOS LaF. The problem with Unity was that it was based on gnome 2 and compiz, that was a good compositor back in the days, but a dead end as a technology, as compositor should’ve been implemented on a lower level and be an integral part of DE. Shuttleworth started Mir and new Unity based on that, but both sank and Ubuntu had to revert to gnome-shell that became useful and more performant than earlier versions.
      - lockhouse 3y ago
        You’re right on all counts. My memory failed me on the order of those. Thanks for setting me straight!
- tyingq 3y ago
  I don't know how broad this is, but the container based networking doesn't work with many corporate firewalls. So it's irritating if you happen to use your Ubuntu PC to VPN into work.
  - doubled112 3y ago
    I know the VPN where I work forces all traffic through it, which means no traffic is allowed to the container networks. It causes problems on Windows with WSL2 as well.
- severino 3y ago
  They just don't offer the same user experience as deb packages did. Firefox has always been a deb and it was fine. Now, it's a snap, it has issues with external devices like smartcard readers and so, and I remember it telling you to close it before X days so it could update, but closing the browser made no difference (I eventually moved to the Firefox tarball to forget about all those issues so I'm not really sure how you were supposed to solve it). So, for me, it didn't offer any advantages over the deb package, but brought new headaches. Also, I don't really like much this new concept of packing all the application dependencies instead of working with shared libs. And I'm not the one that criticizes Canonical just for seeking its own solutions, in fact, I liked things like Unity and Upstart. But for me, snaps came to solve a non-problem.
- pizza234 3y ago
  For my use case, self-contained application formats (which includes snaps): 1. They don't scale, space-wise; libraries can take very considerable space 2. Permission issues 3. Configuration issues 4. Startup speed issues Compared to a trusted (I stress "trusted") apt repository, for my use case, they have only downsides.
- throw10920 3y ago
  It's worth noting that, in addition to Snaps starting up slower (a common complaint on this thread), they actually cause the OS to boot up slower. Every Snap application adds a small amount of startup time. I think I shaved a third off my total time by removing a bunch of Snaps, which is atrocious, unacceptable, and unjustifiable.
  - Gordonjcp 3y ago
    So every couple of weeks when you boot your PC, it's a few seconds faster now?
    - throw10920 3y ago
      This is a ridiculous assumption. I'll boot my PC multiple times per day because I dual-boot and I'll sometimes need to switch between OSes repeatedly. This is also a ridiculous dismissal. Snaps don't increase your startup time because it's an intrinsic limitation of the technology (e.g. like how internet connectivity necessitates higher power draw), but because they're designed badly. There's no reason for them to act like that, and people are rightly upset at it.
- bheadmaster 3y ago
  Snap server is non-free software. Without reverse engineering the protocol, it is impossible to host your own snap repository.
  - lproven 3y ago
    This is not true. Other companies have and do most their own snap stores.
    - bheadmaster 3y ago
      According to this blogpost from 2020 [0], this AskUbuntu discussion [1], this random german blog [2] and many other search results of "canonical snap backend proprietary software", the snap backend is proprietary software. There is no official information from Canonical available (that I've managed to find), so I think we can reasonably assume all this correlating information is true. According to this Ubuntu documentation [3], the "dedicated snap stores" are just Canonical-hosted snap stores with more granular control, which isn't equal to hosting your own snap store. There is an open-source implementation of snap store [4] which (assuming it works and someone is using it) would fall under "reverse engineering the protocol" part of my post, because the guy who wrote it reverse engineered the protocol [5]. Assuming that it works, this is the only part of my post that is not completely accurate - it is technically possible to host your own snap server without reverse engineering the protocol yourself, but that's only because someone else already did it. But Canonical could change the protocol any time and render this implementation obsolete, as they've done in the past [6]. [0] https://hackaday.com/2020/06/24/whats-the-deal-with-snap-packages/ https://hackaday.com/2020/06/24/whats-the-deal-with-snap-pac... [1] https://askubuntu.com/questions/1383583/is-it-true-that-snap-has-proprietary-server https://askubuntu.com/questions/1383583/is-it-true-that-snap... [2] https://merlijn.sebrechts.be/blog/2020-08-02-why-one-snap-store/ https://merlijn.sebrechts.be/blog/2020-08-02-why-one-snap-st... [3] https://ubuntu.com/core/docs/dedicated-snap-stores https://ubuntu.com/core/docs/dedicated-snap-stores [4] https://github.com/freetocompute/kebe https://github.com/freetocompute/kebe [5] https://forum.snapcraft.io/t/announcing-project-kebe-open-source-snap-store-start/25088 https://forum.snapcraft.io/t/announcing-project-kebe-open-so... [6] https://github.com/noise/snapstore https://github.com/noise/snapstore
odette4 3y ago
[dead]

With 100% more snaps? No thanks.

by bfrog 3y ago

With 100% more snaps? No thanks.

Gordonjcp 3y ago

What exactly is wrong with snaps?

binarymax 3y ago
It’s not possible to freeze a working configuration with snaps as they always auto-update. This is problematic for deploying software that has known working dependency versions. Edit: I didn’t know about the new updates to snap and pinning. Thanks for the info!
- Gordonjcp 3y ago
  Yes you can, you just specify the channel you want to pin it to.
- asddubs 3y ago
  lunar lobster introduces the option to put snaps on hold
smoldesu 3y ago
Oh boy... - As a user: Snaps are annoying and don't work like a native app. It creates a new folder in my home directory, has little very consistency with other apps (even other packages of the same app), and feels generally unsuited for desktop use. If I'm going to use any of these godawful statically-linked-runtime package managers, it won't be the proprietary one. - As an admin: Snaps are alright. If you just need to insta-configure something and are extremely lazy, it's a faustian deal pre-installed on every Ubuntu machine. As loathe as I am to admit it, most snaps are a cinch to install compared to native packaging or even Flatpak.
- Gordonjcp 3y ago
  So basically their problem is "New Thing Scary, Grug No Like"?
blendergeek 3y ago
The snap client only supports the Canonical Snap Store. There is not even an "advanced configuration" to add your own. I do not want a single point of failure in the Linux ecosystem. Canonical does.
MattPalmer1086 3y ago
Slow, proprietary, auto update, sandboxed (which causes integration problems with other things). Solves a problem for Canonical and makes everyone else's life harder.
- throw10920 3y ago
  Sandboxing is a necessary evil - the Linux security model for applications installed on your computer is atrocious. The two main options we have to fix it are either a fine-grained capabilities model, or a coarse-grained sandboxing model - and the latter is an order of magnitude less work to implement. However, Snaps do an impressively poor job of implementing a sandbox.
  - CoastalCoder 3y ago
    > Sandboxing is a necessary evil Can you elaborate on the "necessary" part? I'm able to accomplish my computing goals without snaps.
    - throw10920 3y ago
      "Necessary" because Linux's security mitigations are unacceptably insecure for the 21st century. As it stands, I have to completely trust applications before I run them, and there's literally no reason for that to be the case - sandboxing is a straightforward mechanism, not a tricky problem like Traveling Salesman.
  - MattPalmer1086 3y ago
    Simply not necessary for normal applications running on my local desktop. And yes, I do work in security.
    - throw10920 3y ago
      I don't care if you work in security - the fact is that I have to completely trust every application that I want to run on Linux, which is unacceptably bad, and "Simply not necessary for normal applications running on my local desktop" is factually false (unless you're using some "gotcha" convoluted definition of "normal"). A sanely-designed OS will provide either capabilities or sandboxing - the tech has been around for decades, and they're more needed than ever in the 21st century with its abundance of malware.
nicolaslem 3y ago
Snap has been around for 8 years and during this time it got zero traction outside of Ubuntu. Canonical is known for axing their own projects eventually when they fail to get traction, so it seems pretty safe to assume that the writing is on the wall for snap.
- lockhouse 3y ago
  In Canonical’s defense, it seems like every time they try to do something innovative, Red Hat copies the idea and implements it slightly better. Upstart -> systemd Unity -> Gnome 3 Shell Mir -> Wayland Snaps -> flatpak I’m not saying Red Hat is wrong to do this, that’s the nature of healthy competition and we all benefit from this.
  - doubled112 3y ago
    Weren't Wayland and flatpak first? And GNOME 3 as well? Unity was a reaction to GNOME 3's big changes. Either way, I agree that competition is better.
    - selivanovp 3y ago
      No. Snap started as a project and got useful before flatpak. Wayland technically was before Mir, but existed as blueprints and ideas back then. Shuttleworth tried to influence its design for his vision of linux desktop, but got rejected, so Mir was created. Mir became useful way before first implementations of Wayland, but Shuttleworth idea to expand Mir and Ubuntu to phones resulted in feature creep, lack of funding and eventually to project failure. Gnome shell was also released after Unity. Both were influenced by MacOS LaF. The problem with Unity was that it was based on gnome 2 and compiz, that was a good compositor back in the days, but a dead end as a technology, as compositor should’ve been implemented on a lower level and be an integral part of DE. Shuttleworth started Mir and new Unity based on that, but both sank and Ubuntu had to revert to gnome-shell that became useful and more performant than earlier versions.
    - lockhouse 3y ago
      You’re right on all counts. My memory failed me on the order of those. Thanks for setting me straight!
tyingq 3y ago
I don't know how broad this is, but the container based networking doesn't work with many corporate firewalls. So it's irritating if you happen to use your Ubuntu PC to VPN into work.
- doubled112 3y ago
  I know the VPN where I work forces all traffic through it, which means no traffic is allowed to the container networks. It causes problems on Windows with WSL2 as well.
severino 3y ago
They just don't offer the same user experience as deb packages did. Firefox has always been a deb and it was fine. Now, it's a snap, it has issues with external devices like smartcard readers and so, and I remember it telling you to close it before X days so it could update, but closing the browser made no difference (I eventually moved to the Firefox tarball to forget about all those issues so I'm not really sure how you were supposed to solve it). So, for me, it didn't offer any advantages over the deb package, but brought new headaches. Also, I don't really like much this new concept of packing all the application dependencies instead of working with shared libs. And I'm not the one that criticizes Canonical just for seeking its own solutions, in fact, I liked things like Unity and Upstart. But for me, snaps came to solve a non-problem.
pizza234 3y ago
For my use case, self-contained application formats (which includes snaps): 1. They don't scale, space-wise; libraries can take very considerable space 2. Permission issues 3. Configuration issues 4. Startup speed issues Compared to a trusted (I stress "trusted") apt repository, for my use case, they have only downsides.
throw10920 3y ago
It's worth noting that, in addition to Snaps starting up slower (a common complaint on this thread), they actually cause the OS to boot up slower. Every Snap application adds a small amount of startup time. I think I shaved a third off my total time by removing a bunch of Snaps, which is atrocious, unacceptable, and unjustifiable.
- Gordonjcp 3y ago
  So every couple of weeks when you boot your PC, it's a few seconds faster now?
  - throw10920 3y ago
    This is a ridiculous assumption. I'll boot my PC multiple times per day because I dual-boot and I'll sometimes need to switch between OSes repeatedly. This is also a ridiculous dismissal. Snaps don't increase your startup time because it's an intrinsic limitation of the technology (e.g. like how internet connectivity necessitates higher power draw), but because they're designed badly. There's no reason for them to act like that, and people are rightly upset at it.
bheadmaster 3y ago
Snap server is non-free software. Without reverse engineering the protocol, it is impossible to host your own snap repository.
- lproven 3y ago
  This is not true. Other companies have and do most their own snap stores.
  - bheadmaster 3y ago
    According to this blogpost from 2020 [0], this AskUbuntu discussion [1], this random german blog [2] and many other search results of "canonical snap backend proprietary software", the snap backend is proprietary software. There is no official information from Canonical available (that I've managed to find), so I think we can reasonably assume all this correlating information is true. According to this Ubuntu documentation [3], the "dedicated snap stores" are just Canonical-hosted snap stores with more granular control, which isn't equal to hosting your own snap store. There is an open-source implementation of snap store [4] which (assuming it works and someone is using it) would fall under "reverse engineering the protocol" part of my post, because the guy who wrote it reverse engineered the protocol [5]. Assuming that it works, this is the only part of my post that is not completely accurate - it is technically possible to host your own snap server without reverse engineering the protocol yourself, but that's only because someone else already did it. But Canonical could change the protocol any time and render this implementation obsolete, as they've done in the past [6]. [0] https://hackaday.com/2020/06/24/whats-the-deal-with-snap-packages/ https://hackaday.com/2020/06/24/whats-the-deal-with-snap-pac... [1] https://askubuntu.com/questions/1383583/is-it-true-that-snap-has-proprietary-server https://askubuntu.com/questions/1383583/is-it-true-that-snap... [2] https://merlijn.sebrechts.be/blog/2020-08-02-why-one-snap-store/ https://merlijn.sebrechts.be/blog/2020-08-02-why-one-snap-st... [3] https://ubuntu.com/core/docs/dedicated-snap-stores https://ubuntu.com/core/docs/dedicated-snap-stores [4] https://github.com/freetocompute/kebe https://github.com/freetocompute/kebe [5] https://forum.snapcraft.io/t/announcing-project-kebe-open-source-snap-store-start/25088 https://forum.snapcraft.io/t/announcing-project-kebe-open-so... [6] https://github.com/noise/snapstore https://github.com/noise/snapstore

odette4 3y ago

[dead]