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

191–200 of 538 posts

Re: Linux Mint drops Ubuntu Snap packages

#191

Post by rlpb »

pdonis wrote: post #141
rlpb wrote: 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…

> audit, hold, pin

Originally you said audit, hold, modify.

You can audit snaps just as you can audit third party apt repositories. Either the publisher ships the source such that you can rebuild, or they don't.

You can hold snaps using this method: https://forum.snapcraft.io/t/disabling-automatic-refresh-for...

You can modify snaps just as you can modify what you get from a third party apt repository. Either the publisher ships the source such that you can modify and rebuild, or they don't.

Re: Linux Mint drops Ubuntu Snap packages

#192

Post by old-gregg »

sgillen wrote: post #181
driverdan wrote: post #170

Earlier quoted context omitted.

> If desktop Linux is ever going to be mainstream there needs to be an easy to use "app store" Why? Desktop computers worked just fine for 35 or so years before app stores showed up. It's completely unnecessary.

Yes but I believe that most causal non techy users just wont put up with it or at least would much prefer a GUI.

With gadgets similar to iPhones and iPads I think we'd be better off designating general purpose computers for professional use, and not having to worry about hypothetical "grandpas" installing malware while checking the weather, especially on Linux.

Re: Linux Mint drops Ubuntu Snap packages

#193

Post by simosx »

_nodg wrote: post #135

I haven't been impressed with snap as a user. The jetbrains stuff keeps several versions around by default, which eats disk space. I'm sure there's a way to change that, but I haven't cared enough to dig. The other day I ran `apt install chromium-browser` on a brand new install; it chose to install via snap (grr) and then snapd promptly crashed ("Waiting for restart" -- https://forum.snapcraft.io/t/installing-the-chr…

By default, snapd keeps three copies of older versions of a snap package. It does so, so that you can revert easily to a previous version if the latest version does not work. You can disable this feature by setting the appropriate key to `1`.

There is a negative sentiment around snap packages. Even if you are an experienced Linux user, you fall into that negative sentiment and even if an issue is small, it is a deal-breaker for you.

The "chromium" issue has been explained in 2019. Ubuntu 20.04 does not plan to package "chromium" as a deb package (too difficult to maintain properly), therefore there was a need for a backup plan if users were trying to install it.

Re: Linux Mint drops Ubuntu Snap packages

#195

Post by paulcarroty »

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…

> 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 installs itself without asking you.

Short version: Canonical does classic vendor lock-in with his Snap Store. I'm pretty sure 99.9% HN users knows what it means :)

Re: Linux Mint drops Ubuntu Snap packages

#196

Post by inetknght »

lawl wrote: post #94
jonquark wrote: post #25

Earlier quoted context omitted.

I can see why Snap is like it is from Canonial's perspective - but from the User perspective it seems like FlatPaks[1] are much better and address the issues that this article raises [1] https://flathub.org/home (Disclaimer: I'm talking in a personal capacity but the company I work for in my day job now owns Red Hat - I don't work on Linux Operating Systems).

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

> The next problem is ... how do I ship updates?

...why not make a new release and ship that? That's the way package managers work. Developer makes a package. User installs the package. Then when developer fixes some bug and releases a new version the user can install the new version when the user decides it's necessary.

The whole point about this is that it's user-centric. That's good.

Re: Linux Mint drops Ubuntu Snap packages

#197

Post by kd913 »

commoner wrote: post #176
kd913 wrote: post #143

Earlier quoted context omitted.

You haven't even explained how it's vendor lock-in. Canonical has no way designed their approach to ban the use of apt, rpm, deb, flatpak or appimages. They are in no way of a position to dominate the market in the way Google does with Android and it's stupid to even think that is their aim. It should be pretty obvious to you why they aren't exactly going to claim 30% commission on nothing from users who are as cost…

There are degrees to vendor lock-in, and it's not black and white as you portray it to be. Flatpak and apt exhibit minimal lock-in, because they are decentralized and fully open source. Snap, on the other hand, has a closed source server that is controlled solely by Canonical. Since the Snap Store is the only preinstalled app store on Ubuntu, this results in a greater degree of lock-in than Flatpak and apt. The backl…

>There are degrees to vendor lock-in, and it's not black and white as you portray it to be. Flatpak and apt exhibit minimal lock-in, because they are decentralized and fully open source. Snap, on the other hand, has a closed source server that is controlled solely by Canonical. Since the Snap Store is the only preinstalled app store on Ubuntu, this results in a greater degree of lock-in than Flatpak and apt.

You keep repeating yourself. Having a default mechanism for installing software installed on Ubuntu distros that is using Ubuntu based infrastructure does not constitute vendor lock in. Guess what, Ubuntu uses apt rather than yum. That isn't vendor lock in either.

Having a proprietary back end does not constitute vendor lock in.

What you are saying is the equivalent of using spotify is vendor lock in. That or using Firefox. Heck Canonical's model here is practically no different from Firefox with their addon store.

A developer can choose to ignore snap all together and still distribute on Ubuntu. A user can choose to ignore snap all together and still install software on Ubuntu. They will have to face the consequence of not having to use chromium because nobody is willing to maintain it other than Canonical. What is this nonsense that you are spouting.

>The backlash from Linux Mint and other distributions was partly caused by Canonical using Snap for Chromium when the user intended to install it through apt. This sleight of hand is not as extreme as a 30% commission, but it's a step in the wrong direction. The FOSS community is able to reject moves toward vendor lock-in even if the closed source Snap server does not mandate a 30% commission.

Because any move that you or Mint disagrees with is a 'step' in the wrong direction? So be it, I and probably Canonical would rather be wrong.

Snap has 10x the install base for each snap compared to flatpak. It also has more first party software support.

Re: Linux Mint drops Ubuntu Snap packages

#198

Post by toyg »

jonquark wrote: post #25
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 can see why Snap is like it is from Canonial's perspective - but from the User perspective it seems like FlatPaks[1] are much better and address the issues that this article raises [1] https://flathub.org/home (Disclaimer: I'm talking in a personal capacity but the company I work for in my day job now owns Red Hat - I don't work on Linux Operating Systems).

> the company I work for in my day job now owns Red Hat

That's the longest spelling I've ever seen for a three-letter company.

Re: Linux Mint drops Ubuntu Snap packages

#199

Post by simosx »

jwlake wrote: post #52

I'm unclear why ubuntu needs the chromium package in apt. Seems like they should just stop publishing apt packages for chromium, only publish in snap, and steer users into using snap for installs and not apt. Seems less confusing and wins or loses on its merit.

Chromium is very complicated in terms of packaging, and packaging it as a deb package is too tough. Because when a new version appears, you need to do lots of work to get it updated quickly.

For Ubuntu 20.04, it has been explained (in 2019!) that Chromium will be only available as a snap package. To help users transition, the command `sudo apt install chromium-browser` would install the snap package. It is better than "package not found".

It is so simple, but if you are stuck in a negative sentiment on snaps (read this thread), you get crazy.

Re: Linux Mint drops Ubuntu Snap packages

#200

Post by m4rtink »

lawl wrote: post #94
jonquark wrote: post #25

Earlier quoted context omitted.

I can see why Snap is like it is from Canonial's perspective - but from the User perspective it seems like FlatPaks[1] are much better and address the issues that this article raises [1] https://flathub.org/home (Disclaimer: I'm talking in a personal capacity but the company I work for in my day job now owns Red Hat - I don't work on Linux Operating Systems).

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

Flatpaks deduplicate everything - all flatpak apps and all flatpak runtimes installed on a machine agains each other. So if you specify the basic freedesktop.org runtime, it is effectively a no-op as pretty much everyone will have it already installed, due to most of the other runtimes being based on it and most flatpak apps needing a runtime.

As for sandboxing with Flatpal - AFAIK this is all intentional for the time being. The authors have ckearly statet their initial effort targets app dependency isolation and app portability, not security just now. That is much harder to do without severely limitting useful applications in what they can do.

I have encountered incomplete sandboxing systems that strived for security in past and it has not been a good experience.

For example I had the onr and only official Ubuntu Touch tablet, which used a predecessor of the Snap technology. One day I wanted to show my friends a couple photos from a micro SD card. I put it in to the tablet, bit no photo viewing app could show photos from the card.

Why ? Because back then you could only open files from outside of the apps sandbox one by one using a special system controlled dialog. Not really usable for hundreds of photos and forget about a text editor or an IDE.

This is where I like Flatpak - it gives you all the goodies of app separation and portability without all the hassle of a strict but unfinished secure sandbox. You only need to make sure you are getting the software from thrusted sources.

A I think that's something one should be doiny anyway, even with a strct sandbox - if it can't support basic app use cases, who knows what security holes have the authors left in it...

Post reply on HN