Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux Mint drops Ubuntu Snap packages

lwn.net

Post reply on HN
Print view View original

31–40 of 538 posts

Re: Linux Mint drops Ubuntu Snap packages

#31

Post by ncr100 »

entropicdrifter wrote: post #22
ncr100 wrote: post #15

Earlier quoted context omitted.

Is there no way to sandbox these packages - "have you cake and eat it too?" I'm a noob to modern Linux. Edit: Are snaps images? ...like containers? Edit 2: answer: > mounted dynamically by the host operating system, together with declarative metadata that is interpreted by the snap system to set up an appropriately shaped secure sandbox or container for that application

If you need this kind of packaging but want to retain freedom, just use an alternative solution like flatpak, which sandboxes from the get-go and lets you control what parts of your system the application can access

Neat - "permissions that are defined by the maintainer of the Flatpak and can be controlled (added or removed) by users on their system" - https://en.wikipedia.org/wiki/Flatpak

I'm wondering now if Wikipedia would be appropriate to host a linux sandboxed app packaging comparison chart in the form of https://linuxhint.com/snap_vs_flatpak_vs_appimage/ - and it would be extensible ...since Wikipedia.

Re: Linux Mint drops Ubuntu Snap packages

#32

Post by superkuh »

solarkraft wrote: post #20
ncr100 wrote: post #15

Earlier quoted context omitted.

Is there no way to sandbox these packages - "have you cake and eat it too?" I'm a noob to modern Linux. Edit: Are snaps images? ...like containers? Edit 2: answer: > mounted dynamically by the host operating system, together with declarative metadata that is interpreted by the snap system to set up an appropriately shaped secure sandbox or container for that application

The main (and better supported) competitor is Flatpak, which at least doesn't have the terrible marketing.

All containerization is just the fever to the sickness that is the futureshock from extremely fast rate of development of major libs like c++$year, glibc (no matter what they say about having stable endpoints), and the like. You can't run a program written today on the system repo libraries from 5 years ago.

Containers try to mitigate this problem but like a fever they often end up making things worse.

Re: Linux Mint drops Ubuntu Snap packages

#33

Post by stonogo »

kd913 wrote: post #12

The reason for why the backend for the snap store hasn't been opensourced has been explained multiple times. Namely that it would be expensive to open source it with little benefit in return. Canonical already spent a large amount of investment opensourcing launchpad and nobody other than them operate it. Mainly because the majority of the costs are for operating an instance which most other distros aren't willing to…

None of these arguments are convincing.

> Namely that it would be expensive to open source it with little benefit in return.

I don't think that's the real reason; I think it's that Canonical wants to maintain control. Their dream of being the App Store of linux isn't working out.

> Canonical already spent a large amount of investment opensourcing launchpad

If their development practices make open-source development expensive, that's Canonical's problem, not anyone else's. Nobody else uses Launchpad because Launchpad is not a compelling platform. It's still tied to bazaar, which frankly lost the version-control wars. Treating git as a second-class citizen is not how to engender contributors.

> Snap store specifically from what I gather is a bunch of operational machinery that doesn't make sense without also operating launchpad.

Another example of having to choose: did Canonical engineer themselves into a corner, causing all of Launchpad to become technical debt from under which Snap cannot escape? Or was it a deliberate business decision to try to maintain control of the store? An affirmative conclusion in either case doesn't look good for Snap.

> Namely they want one location to find software, and one location to serve software. If users have to use the command line to add a external repo that has unfetted access, then that defeats any usability gains.

Users pretty clearly do not want this. Many people use Ubuntu expressly because of the PPA system; I'd argue that it directly caused Fedora's COPR system to exist because of the user demand. There's no mandate that PPA installation require command-line configuration; it would be trivial to create a bespoke per-PPA using e.g. Vala. Synaptic already allows configuration of PPAs via GUI. It's total non-issue.

> That and the whole aspects of malware/trust goes out the window.

They're already out the window. Snap packages are not reviewed for content and anyone can just cram software into it from random GitHub repositories. Wouldn't it be nice if it were possible to set up a 'curated' Snap store with strong promises of software quality and review? We can't, because it's apparently too hard to run. Another drag on Snap.

I'll not bother to respond to the whataboutism regarding PPAs. Literally the only difference between "a giant PPA that Canonical hosts" and the Snap store is that anyone can upload to the Snap store.

None of the problems Snap store purports to solve are compelling, so these explanations don't really further the cause.

Re: Linux Mint drops Ubuntu Snap packages

#34

Post by gavinray »

rocky1138 wrote: post #19
ColanR wrote: post #5

I've been putting off my next OS reinstallation, but I think I'll be moving away from Ubuntu and over to Mint this time.

Pop!_OS is another choice to consider. Apparently they are sticking with Ubuntu but are stripping the Snap stuff before pushing any updates.

Seconding Pop!_OS, utterly fantastic distro.

Based on Ubuntu but with a bunch of manual patches + tweaks and driver support additions (particularly Nvidia). Really solid stock UI, and it even comes with a tiling WM built in.

https://github.com/pop-os/shell

Re: Linux Mint drops Ubuntu Snap packages

#35

Post by agentx3r »

kd913 wrote: post #12

The reason for why the backend for the snap store hasn't been opensourced has been explained multiple times. Namely that it would be expensive to open source it with little benefit in return. Canonical already spent a large amount of investment opensourcing launchpad and nobody other than them operate it. Mainly because the majority of the costs are for operating an instance which most other distros aren't willing to…

Disclaimer, I like the snap packaging format, and I'm not familiar with the history of launchpad.

Operationally:

- I can trivially host and control my own apt repository, either as a mirror of some upstream repository, or with bespoke packages.

- I can't do the same with snaps.

So launchpad and snap store isn't quite apples-to-apples. It would help of course if a snap store could be statically hosted or re-implemented, but the full API is quite complex.

Re: Linux Mint drops Ubuntu Snap packages

#36

Post by curt15 »

psanford wrote: post #7

From the linked announcement: https://blog.linuxmint.com/?p=3906 > Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. You’ve as much empowerment with this as if you were using proprietary software, i.e. none. This is in effect similar to a commercial proprietary solution, but with two major differences: It runs as root, and it…

>You can’t audit them, hold them, modify them or even point snap to a different store.

In particular, it's easy to inspect the sources for apt packages using "apt-get source". Snap seems to have no equivalent command.

Re: Linux Mint drops Ubuntu Snap packages

#37

Post by michaelmrose »

ncr100 wrote: post #15
psanford wrote: post #7

From the linked announcement: https://blog.linuxmint.com/?p=3906 > Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. You’ve as much empowerment with this as if you were using proprietary software, i.e. none. This is in effect similar to a commercial proprietary solution, but with two major differences: It runs as root, and it…

Is there no way to sandbox these packages - "have you cake and eat it too?" I'm a noob to modern Linux. Edit: Are snaps images? ...like containers? Edit 2: answer: > mounted dynamically by the host operating system, together with declarative metadata that is interpreted by the snap system to set up an appropriately shaped secure sandbox or container for that application

Sandboxing addresses AN issue but does not address any of the issues discussed in this article.

Also sandboxing and running apps under reduced permissions makes a lot of sense but should be seen as a tool to increase security not an answer outright as poorly used any tool can be less effective or even harmful.

Historically locking down increasingly effectively often leads to impeding things the user actually wants to do which leads to apps asking for and granting permissions with the net effect of training users click yes to enable whatever the app wants to do.

It ends up being not just a technical challenge but a psychological one as well and its less easily resolved once you start having to deal with real users.

Re: Linux Mint drops Ubuntu Snap packages

#38

Post by entropicdrifter »

nawgszy wrote: post #30
ncr100 wrote: post #26

Earlier quoted context omitted.

Thank you - :) Reading about the cons of Snap now - "auto-updates cannot be turned off" - https://en.wikipedia.org/wiki/Snap_(package_manager)

Just what we all want on our production hosts.

Especially when they're being installed covertly through APT

Re: Linux Mint drops Ubuntu Snap packages

#39

Post by fullstop »

rocky1138 wrote: post #19
ColanR wrote: post #5

I've been putting off my next OS reinstallation, but I think I'll be moving away from Ubuntu and over to Mint this time.

Pop!_OS is another choice to consider. Apparently they are sticking with Ubuntu but are stripping the Snap stuff before pushing any updates.

I've been using Pop!_OS on a System76 laptop since February, and like it quite a bit.

I use plasma desktop on all of my other systems, but left this one with the defaults.. so far I really like it, but I have a problem with gnome-shell leaking memory over time, since I tend to not shut down or log out over long periods of time. If I don't restart / log out, /usr/bin/gnome-shell eats up more and more memory (as the gdm user). I let it get up to about 7GB before I updated some firmware and rebooted the laptop.

I mean, I put 32GB of RAM in the thing in an attempt to future-proof it, but this is kind of bonkers.

Re: Linux Mint drops Ubuntu Snap packages

#40

Post by kd913 »

blendergeek wrote: post #21
kd913 wrote: post #12

The reason for why the backend for the snap store hasn't been opensourced has been explained multiple times. Namely that it would be expensive to open source it with little benefit in return. Canonical already spent a large amount of investment opensourcing launchpad and nobody other than them operate it. Mainly because the majority of the costs are for operating an instance which most other distros aren't willing to…

> Namely that it would be expensive to open source it with little benefit in return. Would you describe exactly what will be expensive in releasing the source code to software that was developed in house? Does it have lots of dependencies on proprietary software? If so, why? > Namely they want one location to find software, and one location to serve software. And this, is the killer. This is exactly what the people a…

>Would you describe exactly what will be expensive in releasing the source code to software that was developed in house? Does it have lots of dependencies on proprietary software? If so, why?

Im not too sure as I don't work for Canonical. However, from an external perspective having worked with bzr and launchpad, I wouldn't be surprised if there is a bunch of aspects there that would make opensourcing a nightmare.

Things like potentially giving some mechanism that could enable a user to sign/publish on behalf of Canonical snaps/packages for example. That kind of thing would probably need to be removed. Deep integration between CI/operational infrastructure for things like building images. I can imagine after Canonical's experience of launchpad that they probably did hardcode aspects and it isn't some modular thing you can just spin up on docker.

>And this, is the killer. This is exactly what the people at Linux Mint do not want. This is why F-Droid exists on Android. Yes, free software can be distributed on the snap store or on Google Play, but ultimately these are proprietary platforms controlled by one corporate entity whose interests may not be aligned with those of the community. Users of community Linux distros demand choice in where they obtain software.

Snaps I checked aren't there to replace apt. They don't prevent the install of flatpak, appimages or any alternative. Canonical has no agreement that prevents parties like Mozilla/KDE from only publishing on the snap store.

>Malware has already been successfully pushed to the Snap Store. We now trust software because it came from a store that removes well known malware.

There was one case of a snap bundled with a cryptominer. That was settled within 3 days and addressed to the community in a blog. Since then, it has been deliberately looked for. As someone who has published on the snap store, yes there are some checks present to ensure malicious software isn't being pushed.

>The idea of "trust" here is also antithetical to open-source and software freedom. Rather than trusting software because it has verifiable source code,

It is really easy for me to see exactly what is being run/executed on the snaps that I install. In fact I have built/used snaps successfully without even the snap store all together.

Post reply on HN