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

361–370 of 538 posts

Re: Linux Mint drops Ubuntu Snap packages

#361

Post by coronadisaster »

coronadisaster wrote: post #337
emerongi wrote: post #220

Snaps are super laggy. GNOME calculator on Ubuntu runs in a snap and it is baffling that whoever made the decision to package it in a snap by default was OK with the fact that it takes 2 seconds to launch a basic calculator on a 2017 laptop (edit: re-tested, it took 5 seconds). To top it off, a couple months ago my calculator disappeared. For some reason I have been having problems with snap applications disappearing…

not sure if it is only snaps... my galculator takes a couple seconds to open and it isn't a snap... maybe gnome is the issue

why the down vote? I don't even use *buntu... Not that I like snaps, but it just got a lot slower lately

Re: Linux Mint drops Ubuntu Snap packages

#362

Post by mixmastamyk »

philliphaydon wrote: post #354
mixmastamyk wrote: post #348

Earlier quoted context omitted.

Not anymore. I found a chromium PPA, and while not perfect, it doesn't do any of the irritating things listed above.

I just went to chrome.Google.com and downloaded it and installed it. shrug

Google is even less trustworthy than Canonical. I only use chromium for a few tests in incognito mode.

Firefox FTW.

Re: Linux Mint drops Ubuntu Snap packages

#363

Post by MR4D »

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…

Your link just convinced me to switch from Ubuntu. Thank you!

Re: Linux Mint drops Ubuntu Snap packages

#364

Post by cyphar »

petre wrote: post #188
still_grokking wrote: post #161

Earlier quoted context omitted.

That's easy. It should be officially in Debian. ;-) Stuff like AppImage, static binaries, Docker & Co are for me at least a kind of "last resort". Even I'm using Docker a lot[1] to try things out I first look for an AppImage in those cases. But when I decide that some app should become part of my system I will look for a proper package. One source to rule them all… [1] Docker is a big problem on it's own. But as I ca…

Debian has a lot of rules, some of which prevent statically linked binaries, like Go programs, from being packaged and shipped with it. A notable example is lxd. Appimages are great but there's no sandboxing or updates. But hey, we used to downlad debs and install them by hand on Debian 1.3, before apt was a thing. Maybe appimages could be signed and distributed in a similar fashion.

Go programs are not (generally speaking) statically linked, unless you're explicitly doing CGO_ENABLED=0, -tags 'netgo' and the whole variety of other tricks needed to coax static binaries out of the compiler. Try running "ldd" or "file" on your Go binaries -- most of the time they'll be dynamic objects and linked to glibc, especially if you're just doing a stock "go build".

In addition, Debian definitely does package Go programs -- they've packaged some of mine and they have possibly the most ambitious way of solving the great vendor/ issue (which most other distributions have ignored).

The likely issue with LXD is that they require specific versions of various system libraries that they package in their source code bundles (including a fork of sqlite3!). I packaged LXD for openSUSE[1]. It wasn't really fun, but it is fairly doable if you have a flexible enough view on "good packaging practices" (and I imagine Debian packagers didn't feel like going through all the necessary workarounds -- which includes patching the ELF binary in the openSUSE case). And note that LXD isn't even a static binary -- I tried to compile it statically to get around a whole range of issues and it was a nightmare.

[1]: https://build.opensuse.org/package/show/Virtualization:conta...

Re: Linux Mint drops Ubuntu Snap packages

#365

Post by Izkata »

petre wrote: post #188
still_grokking wrote: post #161

Earlier quoted context omitted.

That's easy. It should be officially in Debian. ;-) Stuff like AppImage, static binaries, Docker & Co are for me at least a kind of "last resort". Even I'm using Docker a lot[1] to try things out I first look for an AppImage in those cases. But when I decide that some app should become part of my system I will look for a proper package. One source to rule them all… [1] Docker is a big problem on it's own. But as I ca…

Debian has a lot of rules, some of which prevent statically linked binaries, like Go programs, from being packaged and shipped with it. A notable example is lxd. Appimages are great but there's no sandboxing or updates. But hey, we used to downlad debs and install them by hand on Debian 1.3, before apt was a thing. Maybe appimages could be signed and distributed in a similar fashion.

> Appimages are great but there's no sandboxing or updates.

I know nothing about AppImages, but up above someone said they do have updates: https://news.ycombinator.com/item?id=23773878

Re: Linux Mint drops Ubuntu Snap packages

#366

Post by roryokane »

I think the LWN article misunderstands what Ken VanDine meant by “pressure” in the following quote:

> By shipping such a key application as a snap it will continue to keep pressure on to ensure we keep improving the experience while also reducing our maintenance burden for the LTS and future releases of Ubuntu.

The article takes the quote to mean that “Canonical … is using [Snap] to apply pressure where it wants to see change” and implies that Canonical is trying to pressure distros like Linux Mint to support Snap. But I think VanDine meant only that using Snap in a high-profile package puts pressure on Canonical to make Snap easier to use in Ubuntu.

That’s a less controversial goal than the one implied by the article. Of course, whether Canonical’s actions are truly motivated by that goal is a separate discussion topic.

Re: Linux Mint drops Ubuntu Snap packages

#367

Post by rlpb »

Daishiman wrote: post #190
simion314 wrote: post #160

Earlier quoted context omitted.

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…

The differences are the following: * Nonfree software is generally demarcated as such. There is nonfree software that has available source (in the case of some codecs), other that comes as blobs. * The Chromium package is open source, and in most distros comes as binary built from the toolchain set up by the package maintainers. In all free software distros if you don't want to download the binary, you can download t…

> * Nonfree software is generally demarcated as such. There is nonfree software that has available source (in the case of some codecs), other that comes as blobs.

This is the same in apt as it is in the Snap Store. Compare https://snapcraft.io/chromium to https://snapcraft.io/spotify for example: the license field is clearly presented there.

> * The Chromium package is open source, and in most distros comes as binary built from the toolchain set up by the package maintainers. In all free software distros if you don't want to download the binary, you can download the source and build locally with the provided build scripts (in the case of most APT packages in Debian/ubuntu).

Also true for the Chromium snap (see next item for details).

> * Serving Chromium binaries with Snap removes the option of downloading, inspecting, and running the build chain locally

This is outright false. The Snap Store page for Chromium is available here: https://snapcraft.io/chromium. It links to the source, which is the git repository here: https://code.launchpad.net/~chromium-team/chromium-browser/+.... You can use these source together with snapcraft (which is Free Software, licensed under GPL-3.0) to download, inspect and run the build chain locally, including with any modifications that you want to make. You'll get a snap package as output, which you are free to distribute and other users can install it using the snap CLI.

> * Serving a different version of Chromium, or replacing the stock version with a different variety, cannot be done without creating a new Snap repository.

Partly false. You can ship a different version of Chromium in the Snap Store under a different name. This is an automated process, rather like creating a PPA. As long as you aren't misleading anyone and you follow the terms of the relevant licenses[1], nobody will stop you.

> * Because there is no open source Snap repository software, Mint is unable to set up an alternative repo that could work around some of the objections they have with Ubuntu.

Partly correct. One generally cited reason for this is that the same criticism was leveled at Launchpad which was opened in response - but nobody is running an alternative production of Launchpad anywhere so Canonical doesn't want to waste that sort of effort again. Another is that store fragmentation is bad. I'm just stating the other side's position here. Please don't shoot the messenger.

[1] Chromium's licenses are listed as: Apache-2.0 AND BSD-3-Clause AND LGPL-2.0 AND LGPL-2.1 AND MIT AND MS-PL AND (GPL-2.0+ OR LGPL-2.1+ OR MPL-1.1)

Re: Linux Mint drops Ubuntu Snap packages

#368

Post by peterwwillis »

pjfin123 wrote: post #84

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…

This was done 19 years ago. It was called Lindows. It came with a fancy GUI and custom packaged applications using a private app repository. Wal-Mart sold PCs pre-installed with it. I bought one.

Needless to say, that was not enough for Linux to go mainstream.

Re: Linux Mint drops Ubuntu Snap packages

#370

Post by enobrev »

emerongi wrote: post #220

Snaps are super laggy. GNOME calculator on Ubuntu runs in a snap and it is baffling that whoever made the decision to package it in a snap by default was OK with the fact that it takes 2 seconds to launch a basic calculator on a 2017 laptop (edit: re-tested, it took 5 seconds). To top it off, a couple months ago my calculator disappeared. For some reason I have been having problems with snap applications disappearing…

This move made me 100% opposed to snap. Don't beta test on my daily-drivers as a default.

The calculator should -always- load in a couple ms. It's one of the simplest tools on the shelf! If a calculator snap can't load immediately then I have no interest in a single other snap app. Waiting more than a second is a nightmare, and I've definitely waited 5+ seconds at times. That's about how long it takes my system to boot. As far as I'm concerned it's a complete failure and I couldn't possibly trust it on any desktop or server that I manage.

Post reply on HN