Live data from Hacker News

Linux Mint drops Ubuntu Snap packages

lwn.net

231–240 of 538 posts

Re: Linux Mint drops Ubuntu Snap packages

#231
post #112

Earlier quoted context omitted.

You can watch the discussions from Popey, Martin Wimpress etc... It's pretty clear from their perspective that they built the tech from users/devs first approach. Do you really think Canonical is looking for money over here? If so do please precisely explain in the short-term how exactly you think they are gonna achieve that. Do you think they are suddenly going to be able to dominate the entire 100% Linux desktop so…

The FOSS community opposes Snap because its server is closed source and forces vendor lock-in to Canonical, among other reasons. This is fairly simple to understand and not "disingenuous".

> The FOSS community opposes Snap because its server is closed source

If this was true FOSS projects wouldn't be publishing things on the snap store (they are, and they publish on google play, winget, and other closed app stores).

No one can claim they speak for whatever you think "the FOSS community" is, let alone what it opposes or supports.

Re: Linux Mint drops Ubuntu Snap packages

#232
My only brief experience with Snap packages was installing golang (on Ubuntu). I was just dabbling, and the snap package seemed to be a lot more recent than the apt version, so I went for it.

A week or so later, I guess the snap package auto-updated itself, because my go installation broke with an error about how the go tool version no longer matches the currently running version of go.

That pretty much ruined Snap in my mind, particularly for system software.

Re: Linux Mint drops Ubuntu Snap packages

#233
post #90

Earlier quoted context omitted.

> Namely that it would be expensive to open source it with little benefit in return. Would you describe exactly what will be expensive in releasing the source code to software that was developed in house? Does it have lots of dependencies on proprietary software? If so, why? > Namely they want one location to find software, and one location to serve software. And this, is the killer. This is exactly what the people a…

> Does it have lots of dependencies on proprietary software? Not so much proprietary software (those dependencies would be owned by Canonical and therefore released in the same lot) but I understand there is considerable dependency on deployment machinery. Documentation for that machinery will need to be split out into private (contains secrets, references to customers, etc) and public (consumable by someone looking…

> The world has moved to that.

The world has also moved to casually clicking links to "install" arbitrary apps (which in turn call stacks of arbitrary libraries and frameworks the dev probably found by casually clicking links).

You could give Debian and Ubuntu another decade to work on their packaging infrastructure and they still wouldn't reach parity with what we get through the web with the current browser security model.

Re: Linux Mint drops Ubuntu Snap packages

#234

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…

I think it's because they extract compressed rootfs tar each time to be mounted in LXC container. Even with a beefy computer, it takes considerable time.

Re: Linux Mint drops Ubuntu Snap packages

#235

This seems like a problem: > Snap packages are effectively black-boxes; they cannot be reproduced independently as the packaging data is controlled by the package maker alone. One of the nice properties of debian packages is the ability to `apt-get source` and build it locally. Would be a shame to lose that. Maybe Nix and Guix can provide the best of both worlds here: self-contained software but reproducible builds t…

Any distro where you have to write a little haskell-ish 30 line script to set up an environment just to be able to start compiling (or even running!) things is not going to be widely popular for desktop use.

It's definitely going to take some work. I have set up my first NixOS install, and the functionality is very impressive, but usability-wise it is a mess.

I think Nix/Guix is going to be the bridge to the post-POSIX world where we can move away from the trend of a globally visible filesystem and into much stronger container-based approach. But it can't be in its current form; the Nix language and Guix's Guile/Scheme are too difficult and not declarative enough.

Re: Linux Mint drops Ubuntu Snap packages

#236

It's interesting in that I quite like the idea of snap packages, just not their implementation. I recently purged snaps from my Ubuntu Mate machines after a few years of use because of the realization of only using two: 1. The micro terminal editor. 2. Chromium, because it was forced. Well, #1 was packaged for 20.04 so I didn't need it any longer. That left Chromium. For that single package, I had to tolerate my syst…

~/snap is really just wholly unacceptable, how did that even become a thing? Do the people who develop this software never use their own systems?

I have no nice words about the person who thought that folder is acceptable to use. Seriously, what the fuck even?

Re: Linux Mint drops Ubuntu Snap packages

#237

Earlier quoted context omitted.

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.

Still it's an improvement over the current situation. Using snap IMHO only makes sense with closed-source or Open-source software that you don't want to self-compile but at the same time there is only a package available for a different distribution. So a typical installation procedure might be to forcibly install it with dpkg while ignoring the dependencies which cannot be resolved automatically. (Or worse, convert rpm to deb and then install it...) Of course the source is still downloadable, on the other hand, reproducible builds are anyway far from standard. I would prefer snap any time over other more crude installation methods if compiling is not viable.

Re: Linux Mint drops Ubuntu Snap packages

#238
post #184

Earlier quoted context omitted.

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

Same. I'm running Linux as my primary desktop and server operating system for ~16 years, and I don't really care if it's becoming more mainstream on desktops anymore. It's already working perfectly fine for my needs, so I don't even want it to change much.

But it should at least continue to grow on the same rate as Windows and Mac. Losing market share is gonna be disastrous, as it would mean less software supported, and companies give less time to ensure quality of software supported.

Re: Linux Mint drops Ubuntu Snap packages

#239
post #198

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

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

I assume then that you don't speak German?

Re: Linux Mint drops Ubuntu Snap packages

#240
post #111
post #3

Canonical's decision to abuse the power of apt packages to make it some "universal installer" is kinda gross. I get the thought but I would consider is surprising that, say, installing python-* actually installed pip and ran pip install. This is totally going to break Gnome Software's UI since it has plugins for snap, flatpack, apt, dnf, pacman, etc.. and making it so that Chromium from apt is doing a run-round with…

> Canonical's decision to abuse the power of apt packages to make it some "universal installer" is kinda gross. This is a mischaracterization. "chromium-browser" is a transitional package that installs the chromium snap for one reason: it is to provide an upgrade path for users of Chromium in previous Ubuntu releases to the latest Ubuntu release without breaking Chromium. I use an example of where Debian does the sam…

> it is to provide an upgrade path for users of Chromium in previous Ubuntu releases to the latest Ubuntu release without breaking Chromium.

Are you seriously, unironically claiming this?

You broke a massive amount of native plugins. The snap auto-update mechanism fucks up Chromium's data each time because Chromium gets no warning that it suddenly can't write to the disk. Its launch time is also way worse. On top of all that, Chromium just vomits all over syslog due to incomplete/bad confinement. You even made the damn switch when a massive CVE was found in Chromium, delaying a critical security update for a week due to the switch.

What a massive load of bullshit.

Post reply on HN