Live data from Hacker News

Linux Mint drops Ubuntu Snap packages

lwn.net

281–290 of 538 posts

Re: Linux Mint drops Ubuntu Snap packages

#281
post #93
post #71

Earlier quoted context omitted.

On latest LTS (Ubuntu 20.04 LTS) the apt version is simply a transitional package. It installs the snap for you. It says so on the description directly next to the name: "Transitional package - chromium-browser -> chromium snap" There only for people upgrading, so they are not suddenly surprised seeing their browser gone.

Just seems like an unintended consequences confusing situation. I think a pretty rational policy would to _never_ have an apt package install a snap package. Moving to snap is a breaking change, effectively, so you have to bite the bullet at some point. Mixing your distribution systems with references to each other seems like a recipe for confusion and anger. And it looks like they got the expected outcome.

Then people get stuck on old insecure versions of chromium. Or it simply disappears. Do you really think that doesn't create confusion and anger?

Re: Linux Mint drops Ubuntu Snap packages

#282
post #94

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…

> Then there is this weird thing where flatpaks force a runtime on you. My application is a statically linked go binary. But flatpaks pretty much want to force me to add an entire freedesktop suite as a dependency, as you simply cannot choose no runtime.

That's a weird criticism to have of Flatpak. The FreeDesktop dependency is the base set of libraries all flatpaks have access to. You don't have to use it. In fact Freedesktop is a great idea, to provide a base framework applications can use that goes further than just libc. If we want Linux on the desktop, we need a common desktop framework interface.

It would be like being unhappy a static go binary on Windows COULD access all of the win32 libraries.

Also, Flatpak currently is best suited to GUI apps. If your go binary is a GUI app using either GTK or KDE, these will need the freedesktop facilities (such as D-Bus) to actually run properly.

Re: Linux Mint drops Ubuntu Snap packages

#283

Earlier quoted context omitted.

AppImages do have an update mechanism: https://docs.appimage.org/packaging-guide/optional/updates.h...

AppImage seems like the best replacement then. I've loathed Snap since it first appeared on my horizon and I installed LibreOffice with it and that snap image showed up in my mounted drives forever. I was a big fan of Canonical/Ubuntu for years and switching to Debian has not been without pain points but at least I have more control of my computer. Pop! OS and Linux Mint seem like good Linux desktop alternatives to U…

> Linux Mint seem like good Linux desktop alternatives to Ubuntu at this point if you don't want to use Debian.

Mint also has Debian based distro.

Re: Linux Mint drops Ubuntu Snap packages

#284
post #169

Earlier quoted context omitted.

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

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

> Canonical only installed the chromium snap because they did not have the resources to support a deb version instead

So Canonical has the resources to make an entire DE, an init system, a mobile OS, a new display server (all of which were dumped on the roadside), and then going all in on a brand new sandboxing/package management system developed from scratch, but merely compiling a web browser officially supported by google and used by nearly every single one of their users is too much work?

Re: Linux Mint drops Ubuntu Snap packages

#285
post #257

Just today I switched from Ubuntu to Pop_OS (I hate that name). Unity was giving me some trouble as it's starting to conflict with all the newer stuff so I had to make a decision. I dislike Gnome Shell. It's clean and fast but the GUI is "locked" to the main monitor and I can't even switch windows without looking at it. But I love how the distro is made focusing on a good user experience. To give you an example, the…

https://support.system76.com/articles/desktop-environment/ I don't use Pop!_OS, but I recommend Plasma.

I know Plasma, I can't stand the inconsistency and the ugliness.

Re: Linux Mint drops Ubuntu Snap packages

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

Is "I just give you a tgz with small folder of files, one of which is a binary; I managed to make it run just about everywhere" worse than AppImage (notably, for a GUI app)?

Re: Linux Mint drops Ubuntu Snap packages

#287
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).

I feel like both Snappy and FlatPak are inferior to AppImage, which IMO is much easier to use (it's a self-contained executable) and doesn't rely on any fancy management daemons or what have you.

Like, in terms of user experience it's about as close to the Windows-style "download this .exe and run it" approach as one could get, though it'd be interesting to see a macOS-style "put this .app in your ~/Applications" approach as well (which should be doable with a daemon watching such a folder and generating e.g. menu entries and such, as an optional component or perhaps a feature of the desktop environment itself).

Re: Linux Mint drops Ubuntu Snap packages

#288
post #286

Earlier quoted context omitted.

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…

Is "I just give you a tgz with small folder of files, one of which is a binary; I managed to make it run just about everywhere" worse than AppImage (notably, for a GUI app)?

That's basically what an AppImage is, except that an AppImage goes one step further and slaps that tarball onto an executable that opens its embedded tarball and runs whatever's inside.

Re: Linux Mint drops Ubuntu Snap packages

#289

Earlier quoted context omitted.

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)

On the sandboxing front, it works great with Firejail: https://firejail.wordpress.com/documentation-2/appimage-supp...

Re: Linux Mint drops Ubuntu Snap packages

#290
post #153

Earlier quoted context omitted.

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

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

I've seen all three approaches with AppImage'd software.

There are also package managers specifically for AppImage'd software, though it doesn't look like any of 'em are particularly mature.

Post reply on HN