Live data from Hacker News

Linux Mint drops Ubuntu Snap packages

lwn.net

351–360 of 538 posts

Re: Linux Mint drops Ubuntu Snap packages

#351
post #206
post #185

Earlier quoted context omitted.

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

There is no apt package with chromium, but there is an apt package name 'chromium-browser'.

https://packages.ubuntu.com/focal/chromium-browser

In previous versions of ubuntu, that package would install chromium, as one would expect.

In recent versions of ubuntu, this package is a stub that installs snapd, and then snapd installs chromium.

There is a substantial difference between those two things. Users that try to install chromium through an open package management system are being pushed to Canonical's proprietary store.

Re: Linux Mint drops Ubuntu Snap packages

#352
post #191
post #141

Earlier quoted context omitted.

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

[deleted]

Re: Linux Mint drops Ubuntu Snap packages

#353
post #191
post #141

Earlier quoted context omitted.

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

> Originally you said audit, hold, modify

I didn't; the post you were originally responding to (the GP of my original post, which is the GP of this one) did. I am not the person who made that post.

You appear to be saying that you can audit, hold, modify, pin software in third-party repositories. That means you agree with what I was saying in the GP to this post, that you have just as much ability to do all these things with third-party repo software as you do with software distributed using snaps.

Re: Linux Mint drops Ubuntu Snap packages

#354

Earlier quoted context omitted.

Just install chrome without snaps?!? Works fine?!?

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

Re: Linux Mint drops Ubuntu Snap packages

#355
post #253
post #206

Earlier quoted context omitted.

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

Oh. If there is no Chromium apt package, isn't the following from TFA (lwn) misleading? > The problem was the decision to change the Ubuntu chromium-browser APT package itself upstream in Ubuntu. Previously, that package would simply install Chromium directly. With the change, it would instead install the Snap package-management tools first and then install the Snap equivalent of the Chromium package — without making…

There is a Chromium package in the Ubuntu apt repositories, which installs Chromium through snap.

I just use the Chrome apt repository from Google which seems simpler all around.

Re: Linux Mint drops Ubuntu Snap packages

#356

Earlier quoted context omitted.

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

My personal theory by now is that that person/team is sick of being forced to work on a stillborn project, and is trying to create as many pain points as possible to get the project killed already. I see no other reason by now. In that case, hats off to him.

Re: Linux Mint drops Ubuntu Snap packages

#357
post #234

Earlier quoted context omitted.

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.

What is weird to me is that apparently there has not been someone in a position of power in this project that would go "Wait guys, this is not good. Any other ideas? How can we improve?" No, just roll on with it. There was a period of time, around 2010-2015 when I really felt that computers were fast. SSDs were getting more affordable and that was a huge improvement, every action was immediately responsive. In 2020,…

Somebody somewhere is probably running a calculator as an electron app that takes 10 seconds to open.

Re: Linux Mint drops Ubuntu Snap packages

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

From an IT perspective: I can set up an internal APT mirror for my users, servers, test systems, etc., but I can't set up an internal snap mirror as far as I can tell. This means that despite having an internal repo that I can whitelist, some package installations will now arbitrarily require internet access. I can no longer install chromium on a system without access to the internet, and package installation will fa…

There is a big user issue on top of the philosophical and maintenance issues - snaps are SLOOOOOOW. I've only experienced them with two applications, and both took forever to startup compared to the apt-get installed versions I quickly replaced them with.

OK, "forever" is hyperbole - it was probably about 5 seconds. But it was enough of an annoyance for me to figure out how to install a deb packaged version. And every user having to wait an extra 5 seconds every time they open an app aggregates to a lot more time than Canonical saves maintaining packages.

That doesn't sit right with me, so my next OS upgrade will be Mint or pure Debian. I've been with Ubuntu since Dapper Drake, and I'd like to thank Canonical for making great distros all that time. But I'm not going to follow you down the snap-only path, time for me to move on.

Re: Linux Mint drops Ubuntu Snap packages

#359

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.

That "little haskell-ish 30 line script" gives you a stable and reproducible system that other distros can never provide. If I can spare myself from doing a clean re-install of my system every few releases just by writing a few lines of configuration, it's absolutely worth it. It also helps that I can reuse that configuration for any of my computers too, because I don't have to spend time installing and configuring software for each new computer I use.

BTW most people don't need to write a full-fledged "script" to get their system up and running. All they need to specify are some configuration variables that specifies the sort of things you'd need to specify anyways if you're going to setup a new system, like which packages should be installed. With NixOS, you write those things on a file instead of typing it on the command line.

Re: Linux Mint drops Ubuntu Snap packages

#360
post #345
post #326

Earlier quoted context omitted.

> "snap vs flatpak vs appimages once again shows the fragmentation within the linux desktop ecosystem." A common misconception about the FOSS ecosystem is that many similar projects is "wasted effort". In reality, diversity is what allows for progress and flexibility. Otherwise you end up with a single package manager which nobody can change AKA mono-culture. > " Microsoft is going to eat Linux Desktop. WSL to run yo…

> A common misconception about the FOSS ecosystem is that many similar projects is "wasted effort". From a developers and users perspecive, it is a wasted effort. Users still keep wasting time 'choosing' a distro. There's 1 form of Windows and macOS to choose and support. For a software vendor, you need to 'define support'. I can support all Windows and macOS users, but I can only target a certain amount of Linux use…

> "From a developers and users perspective, it is a wasted effort."

My point is that, the perceived "wasted effort" is actually learning and re-thinking the desktop. Many novel approaches to simpler OS's and package managers have risen, due to the diversity of the FOSS ecosystem.

Just like Darwinian evolution, many projects spawn into existence, only the fittest survive. The projects/distro's that don't survive were not a waste, they serve to prove which ideas work/don't work. Making all projects better off.

> "Just look at the tons of distro configurations that a software vendor needs to test for"

True there's many distros, but there's no reason to support them all, only the biggest. It's similar to translating books into other languages, you would translate a book to [1] Dumi, as it's the least used language on Earth.

Most Vendors only support the top OS's which are probably Windows, MacOS and Ubuntu.

> "Perhaps the reason the Linux desktop has failed is because of the lack of a standard desktop or common SDKs other than the Linux kernel itself."

This is a real point, and is something snap, flatpack etc. are trying to fix. Maybe one day a Linux desktop will unify on a standard...

[1] https://www.daytranslations.com/blog/rare-languages-spoken/#....

Post reply on HN