Live data from Hacker News

Linux Mint drops Ubuntu Snap packages

lwn.net

151–160 of 538 posts

Re: Linux Mint drops Ubuntu Snap packages

#151
post #36
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.

You are not required to publish source packages, most of the third party repos I use either don't have them or they are surprisingly useless because I don't have the build environment they were executed in.

Re: Linux Mint drops Ubuntu Snap packages

#152
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…

>snapd not open-source.

Red herring. The Linux Mint teams' main complaints have to do with issues around the way snap wrests control from the user.

>I will remind people that the most popular PPA to this day is a Java PPA being run by some 3rd party that doesn't offer Java. That PPA has root access to thousands of machines.

Imagine strawman-ing this hard.

Re: Linux Mint drops Ubuntu Snap packages

#153
post #94

Earlier quoted context omitted.

> but from the User perspective it seems like FlatPaks[1] are much better and address the issues that this article raises This is interesting, because the last few days I was actually working on packaging an application of mine as a snap/flatpak. From my PoV, they both have their fair share of issues. Snaps enforce a sandbox, which I think is actually a good idea, because the desktop security model is somewhat broken…

As a user I don't like neither Snaps (that for sure as this is Cannonical only) nor FlatPaks (as they seem conceptually a "80% solution" which combines the problems of package systems with the problems of self-contianed apps, but don't improve on anything). For me the only acceptable solution besides proper .debs are AppImages. AppImage doesn't try to "replace" the package management for desktop apps like the former…

I tend to agree with you, but I really like updating all my software with one click/command.

So out of curiosity:

My application is already self contained and statically linked, so no AppImage needed, but it behaves like one, you can just run download and run it everywhere. And so what you're describing will be for sure an option for those who like it (in fact currently it's the only option in alpha).

How would you like to get updates for something like this? Visit the website yourself occasionally to check for updates? Have the application notify you a new version is available? Have an integrated updater so the binary can update itself?

Re: Linux Mint drops Ubuntu Snap packages

#154
post #36

Earlier quoted context omitted.

>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.

Sure because Snap is designed to be able to distribute closed source applications. Part of the reason Snap and Flatpak exist is that distributing binaries on Linux is an enormous pain.

So allow viewing sources for the open source packages. If sources aren't available, then the user can easily opt not to install the binary.

Re: Linux Mint drops Ubuntu Snap packages

#155
post #72

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 might like Linux Mint or Pop OS, both of which are re-spins of Ubuntu without snaps. Or for that matter, regular old Debian probably has 99% of what you need.

Adding a vote for regular old Debian. My strategy is to run Debian testing, and then 6 months or so after it's promoted to stable, switch back to the new testing branch. This way I get a reasonably stable experience (Debian's view of "testing" is at least as stable as many other distros' view of "stable"), avoid the large churn in testing right after a new stable series is released, and still get to use all the newest stuff.

The only thing to watch for is testing isn't covered by the Debian security team, so you need to pay attention to security advisories and make a call to keep or uninstall if a package you use has a security issue, as testing often doesn't get security fixes until a week or so after stable does.

Re: Linux Mint drops Ubuntu Snap packages

#156
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…

From an IT perspective:

I can set up an internal APT mirror for my users, servers, test systems, etc., but I can't set up an internal snap mirror as far as I can tell. This means that despite having an internal repo that I can whitelist, some package installations will now arbitrarily require internet access. I can no longer install chromium on a system without access to the internet, and package installation will fail as a result.

I'd rather have an older version than a snap version, personally, but better would be two packages which Provides: the same chromium-browser, chromium and chromium-snap.

The most irritating thing here is that they're using a package distribution system which handles dependencies and updates flawlessly, and has for decades, and using it to install things using a package system which does not solve those problems, and instead ships multiple copies of multiple libraries and applications, which run slower, ignoring any settings I have in APT.

So far, it's a maintenance nightmare, and I loathe it.

Re: Linux Mint drops Ubuntu Snap packages

#157
I haven't used Snap much, but I would like to add this: The Ubuntu Software Center (and debian packaging in general) is not gen-pop friendly. There are library packages, support packages, metapackages, and when you search, the results are shaky, non-existent, or overwhelmed by results no end-user would be interested in installing standalone.

There is also the issue of dependencies, and there is some elegance in the design philosophy of "package everything for a program and install it standalone" vs. having shared libraries.

So I see the benefit in an app-store. Someone below said "snap is horrible" because it's lock in. It isn't! Ubuntu hasn't taken away apt.

But simple, easy package distribution to nontechnical users, for the benefit of stability and ease of use, is a noble one.

Re: Linux Mint drops Ubuntu Snap packages

#158
post #127

If desktop Linux is ever going to be mainstream there needs to be an easy to use "app store" where users can use a GUI to install apps which need to be sandboxed like on a mobile phone with defined permissions. Snapcraft is way ahead of Flatpak on this and the current Ubuntu setup works well. On Ubuntu you can go to the Ubuntu software app (gui) search for software and it blends apt results with snap results. This re…

> If desktop Linux is ever going to be mainstream there needs to be an easy to use "app store" where users can use a GUI to install apps which need to be sandboxed like on a mobile phone with defined permissions. Curious... do you think that the world has moved on from the "download from website and run installer" model? Obviously that has serious drawbacks from a security perspective, but up until less than a decade…

>For the most part, the only people who really care about "the year of the Linux desktop" are people trying to build a business around desktop Linux

As another long time Linux guy, I have a feeling most of those obsessed with Linux becoming a mainstream desktop platform are Mac or Windows users.

Re: Linux Mint drops Ubuntu Snap packages

#159
post #141
post #131

Earlier quoted context omitted.

> Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them... I think it should be noted that this generally applies to the addition of "third party apt repositories" in general, use of which is the problem that snaps fix[1] Some snaps are built from Free Software and reproducible sources, as are some third party apt repositories. In other words, if this criticism bothers…

> if this criticism bothers you, then you should never install from any third party apt repositories ever. This does not follow at all. Third-party apt repositories work just like Ubuntu's apt repositories; you have just as much ability to audit, hold, pin, etc. in both cases. If there is a difference in reliability (software from third-party repos is more likely to break your system--and, btw, software from Canonica…

Third-party apt repositories are a security nightmare: you are giving a third party unrestricted semi-silent root access to your computer. I can trust my distro provider with this, but it should be strongly discouraged for third-parties. Instead, installing PPAs to get updated builds of standard packages seems considered “normal”. At least, this doesn’t hold true for snaps.

Re: Linux Mint drops Ubuntu Snap packages

#160

Earlier quoted context omitted.

>As long as you can audit the source and build chain what's the problem? As long as Linux Mint developers are not doing that how it helps you? you don't trust Canonical binaries but you trust the deb binaries, you could be honest and claim that you don't like snap but you still trust the deb binaries.

The point isn't that the devs are the ones doing the auditing, even though pretty much everything that lives in DEB and RPM repos has maintainers which do. The point is that you can audit without having to depend on a third party. Nobody's claiming audits are free or that they're assumed. The point is that you have the option to choose to trust as much or as little of the build chain, from the compiler to the target…

let me clear some things up and tell me if I am wrong, link me to the correction and I will apologize.

- Mint uses Ubuntu repositories

- Canonical pushes the changes they want into this repos, this changes are probably done by scripts that build source code on Canonical servers.

- the Ubuntu repos also contain binary blobs

- when a Mint user does an update he gets the binary directly from Canonical servers, there is no Mint dev or Mint script that does any check to see if for example the evil Canonical modified the NVIDIA driver and added even more evil in it then already is

Now explain to me if all the above is true why would someone that does not trust Canonical would use Mint? There is no safety checks to prevent evil Canonical people do evil things.

My conclusion is if you don't trust Canonical don't use Mint. Maybe Mint is working on addressing this and soon we will see an PR campaign that announces they are finally able to self host but until then I would stop the hypocrisy about not trusting Canonical. (Btw there are many smaller distros that can host their own repos, not sure why Mint is not doing it)

Post reply on HN