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

201–210 of 538 posts

Re: Linux Mint drops Ubuntu Snap packages

#201

Post by simosx »

chimen wrote: post #133

The fact that you have to post on a forum and argue with people why you need permission X for your snap package was enough for me to abort publishing on this platform. I should ask permissions from the users not from the platform publishers on a forum post.

By default you ask your users for these permissions, if you do not want to get them from the Snap Store.

That is, create your snap package and publish it on the Snap Store. Do not request to pre-approve any permissions. Arrange with your users to enable those permissions on demand.

Re: Linux Mint drops Ubuntu Snap packages

#202

Post by arexxbifs »

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…

"Linux on the desktop" is apparently a lot like having sex in a greenhouse: fucking close to Windows.

Re: Linux Mint drops Ubuntu Snap packages

#204

Post by m4rtink »

still_grokking wrote: post #138
lawl wrote: 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…

Appimage has its own issues though: - no update mechanism - no sandboxing and only basic app isolation - no deduplication (Flatpak automatically deduplicates everything it installs on a machine)

Re: Linux Mint drops Ubuntu Snap packages

#205

Post by m4rtink »

dflock wrote: post #175
lawl wrote: post #153

Earlier quoted context omitted.

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

most AppImages seem to auto-update themselves when you run them, which is convenient, until it isn't. I'd want it in an apt repo, really.

That actually sounds pretty dangerous - what is more likely to get compromised and stay that for a long time - a random developpers app image update service or distro infrastructure ?

Re: Linux Mint drops Ubuntu Snap packages

#206

Post by kd913 »

the_af wrote: post #185
kd913 wrote: post #169

Earlier quoted context omitted.

>Red herring. The Linux Mint teams' main complaints have to do with issues around the way snap wrests control from the user. Like Linux Mint is doing the same? There is no control being lost by using Ubuntu versus Mint. I could remove snapd there without people making that decision for me. Worse would be Mint's decision of removing the only FOSS built version of chromium without offering an alternative in place. Cano…

> Like Linux Mint is doing the same? There is no control being lost by using Ubuntu versus Mint. If I understood the issue correctly (and I may very well be mistaken!) the problem Mint has with Canonical is that Ubuntu has "hijacked" (for lack of a better term) some apt packages so that they now actually install snapd and the snap. So you think you're opting out of snap, but when you use apt to install Chromium you e…

There is no apt package with Chromium.

https://ubuntu.com/blog/chromium-in-ubuntu-deb-to-snap-trans...

Canonical couldn't afford the maintenance costs for it. On Ubuntu distributions it's either the snap or you have to create some weird frankendeb aspect by pulling from Debian.

They explained it better than I would.

In other cases, I don't think of a case where apt installs snaps over apt. I think the only priority for the decision choice was based on most recent version. Although this aspect I am slightly unclear.

Re: Linux Mint drops Ubuntu Snap packages

#207

Post by Miraste »

red_admiral wrote: post #56

Snap sounds to me like the latest of many decisions by Canonical that are more like what you'd expect from a commercial vendor than a FOSS one. This is Microsoft-level coercing people into your own ecosystem. I don't doubt for a moment that it makes business sense for Canonical, but I really wonder whether there's a market for this - the huge majority of people who don't care about this kind of thing are on Windows o…

I'm not sure I see how it even makes business sense. Trying to compete with with Apple and Microsoft by eliminating your strengths to focus on your weaknesses isn't a good play. Gnome and Ubuntu are not and will never be as smooth and integrated as MacOS, and that's okay because that's not why people use them. Take away the openness and you have a slower, uglier Mac with a worse app store.

Re: Linux Mint drops Ubuntu Snap packages

#208

Post by CogitoCogito »

glennpratt wrote: post #151
curt15 wrote: 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.

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.

I'm not sure how this is relevant. You're not required to publish source debian package either, yet there is still a nice command to use in case the source package exists.

Re: Linux Mint drops Ubuntu Snap packages

#209

Post by renewiltord »

I like the App Store functionality etc. It's good to have a trusted store and all that. It's just that Snap packaged stuff is slower to open than stuff otherwise. A user on lobste.rs[0] showed what it was like and mine is just as bad

Also by `df` and `mount` are unusable with this stuff.

0: https://lobste.rs/s/aktv9k/problem_ubuntu_20_04_snaps_where_...

Re: Linux Mint drops Ubuntu Snap packages

#210

Post by baldfat »

still_grokking wrote: post #138
lawl wrote: 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…

FlatPack was made to address two things focused on security:

1) Application won't need root privileges

2) Without compromising on the systems security

Post reply on HN