Linux Mint drops Ubuntu Snap packages • Hacker News Board

Re: Linux Mint drops Ubuntu Snap packages

#61

Post by red_admiral » Wed, Jul 08, 2020, 5:58 PM UTC

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…

I wonder how hard it would be, in theory, to write an open-source "cracked" version of snap that lets you do these things.

Re: Linux Mint drops Ubuntu Snap packages

#62

Post by _jal » Wed, Jul 08, 2020, 5:58 PM UTC

ncr100 wrote: post #26

solarkraft wrote: post #20

Earlier quoted context omitted.

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

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

Yep. One of many reasons they're banned in our shop.

Even for client software it is bad - an app quitting out from under me because it wants to update is functionally equivalent to a crashing bug - but they're offering daemons this way, which is just insane.

Who doesn't want all their containers randomly restarting because someone up the distro chain decided when your machine needed to upgrade?

https://snapcraft.io/lxd

Re: Linux Mint drops Ubuntu Snap packages

#63

Post by kd913 » Wed, Jul 08, 2020, 5:58 PM UTC

commoner wrote: post #41

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…

There is no downside to Flatpak's support for multiple repositories and ability to self-host repositories. GNOME Software and KDE Discover both set Flathub as the default repository, which serves as the primary software source, and users can optionally add more repositories if they choose to do so. Users who don't want additional repositories can simply stay with Flathub without having to do anything. The Snap server…

>There is no downside to Flatpak's support for multiple repositories and ability to self-host repositories.

There are always tradeoffs. I would argue there are advantages for having a trusted party vetting my software repos. It's why I even use Ubuntu because I trust Canonical to make some sane decisions when vetting their repositories.

You give multiple repository support and suddenly users have to one find a way to add another repo, and second there is no way of removing software from those repositories if they do end up malicious.

Which is why I brought up the webupd8 java instance having root access to thousands of machines.

>users can optionally add more repositories if they choose to do so.

Ubuntu is the version of Linux designed to be used by your grandmother. They want to make it as easy as possible for users to install trusted/safe software from both proprietary/free vendors.

It's kind of telling that Mozilla/Microsoft/Spotify/Jetbrains released software as a snap long before it is even possible on flatpak but nevermind that. I don't think you can even get VSCode, Spotify or Intellij on Flatpak.

Re: Linux Mint drops Ubuntu Snap packages

#64

Post by nullc » Wed, Jul 08, 2020, 5:58 PM UTC

To call Ubuntu snap a security disaster would be a tremendous understatement.

Re: Linux Mint drops Ubuntu Snap packages

#65

Post by knowhy » Wed, Jul 08, 2020, 5:59 PM UTC

jefft255 wrote: post #23

I wonder if it is finally time for me to give Arch a try. It's a shame that all my lab's machines run Ubuntu; although I find it solid, this sort of controlling behavior by Canonical seems against the spirit of FOSS.

You should do that. I did so in 2012 and I have never looked back. Besides that ArchLinux just works better the ArchLinux community understood that a good documentation is way more important than a flashy gui.

Re: Linux Mint drops Ubuntu Snap packages

#66

Post by ocdtrekkie » Wed, Jul 08, 2020, 5:59 PM UTC

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…

> Canonical already spent a large amount of investment opensourcing launchpad and nobody other than them operate it.

I posit that this doesn't matter.

Presumably Ubuntu's infrastructure should be open source so that it can be inspected if necessary, for security reasons. It shouldn't matter if nobody else is actually hosting an alternative copy... it is still important that their copy be open source.

Re: Linux Mint drops Ubuntu Snap packages

#67

Post by commoner » Wed, Jul 08, 2020, 6:00 PM UTC

kd913 wrote: post #63

commoner wrote: post #41

Earlier quoted context omitted.

There is no downside to Flatpak's support for multiple repositories and ability to self-host repositories. GNOME Software and KDE Discover both set Flathub as the default repository, which serves as the primary software source, and users can optionally add more repositories if they choose to do so. Users who don't want additional repositories can simply stay with Flathub without having to do anything. The Snap server…

>There is no downside to Flatpak's support for multiple repositories and ability to self-host repositories. There are always tradeoffs. I would argue there are advantages for having a trusted party vetting my software repos. It's why I even use Ubuntu because I trust Canonical to make some sane decisions when vetting their repositories. You give multiple repository support and suddenly users have to one find a way to…

> You give multiple repository support and suddenly users have to one find a way to add another repo, and second there is no way of removing software from those repositories if they do end up malicious.

> Ubuntu is the version of Linux designed to be used by your grandmother. They want to make it as easy as possible for users to install trusted/safe software from both proprietary/free vendors.

By default, GNOME Software and KDE Discover only use the Flathub repository. Your grandmother won't be adding other repositories to the Flatpak client. Users who don't add any extra repositories will use Flathub, which is a trusted source of software that runs on an open source server.

> It's kind of telling that Mozilla/Microsoft/Spotify/Jetbrains released software as a snap long before it is even possible on flatpak but nevermind that. I don't think you can even get VSCode, Spotify or Intellij on Flatpak.

https://www.flathub.org/apps/details/com.visualstudio.code

https://www.flathub.org/apps/details/com.spotify.Client

https://www.flathub.org/apps/details/com.jetbrains.IntelliJ-...

Re: Linux Mint drops Ubuntu Snap packages

#68

Post by zentiggr » Wed, Jul 08, 2020, 6:01 PM UTC

superkuh wrote: post #32

solarkraft wrote: post #20

Earlier quoted context omitted.

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.

I don't run any APT based distribution right now but I understand the issues... I think the biggest problem I see is Canonical developing what looks like a very useful tool but holding it proprietary.

If Canonical provided the snap creation and hosting tools to the community I imagine it would be judged on its technical merits.

As it is, I see more and more reports that Canonical is trying to gain more and more control and that's exactly what I don't like to see.

Would have tried Ubuntu but they've poisoned that well. I'll have to recalculate.

Re: Linux Mint drops Ubuntu Snap packages

#69

Post by 6AA4FD » Wed, Jul 08, 2020, 6:01 PM UTC

superkuh wrote: post #28

aphexairlines wrote: post #10

This seems like a problem: > Snap packages are effectively black-boxes; they cannot be reproduced independently as the packaging data is controlled by the package maker alone. One of the nice properties of debian packages is the ability to `apt-get source` and build it locally. Would be a shame to lose that. Maybe Nix and Guix can provide the best of both worlds here: self-contained software but reproducible builds t…

Any distro where you have to write a little haskell-ish 30 line script to set up an environment just to be able to start compiling (or even running!) things is not going to be widely popular for desktop use.

`nix-shell -p ghc` does it for me.

Re: Linux Mint drops Ubuntu Snap packages

#70

Post by tyree731 » Wed, Jul 08, 2020, 6:02 PM UTC

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?

If all you're doing is taking an internal repository and hosting it externally, then it takes no time. But if you make sure licenses are being used correctly throughout the code, audit to make sure no internal secrets accidentally made their way into the internal repository (this happens as much in closed source as it does in open source), and you try to remove any problematic code, commit messages or references from the code, it takes time.