Live data from Hacker News

Linux Mint drops Ubuntu Snap packages

lwn.net

301–310 of 538 posts

Re: Linux Mint drops Ubuntu Snap packages

#301
post #188

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.

> prevent statically linked binaries, like Go programs

What do you mean? There's debian go packaging team: https://go-team.pages.debian.net/ as well as go packages in stable (for example https://packages.debian.org/buster/influxdb)

Re: Linux Mint drops Ubuntu Snap packages

#302
This snap business is what we get when commercial interests try to warp the concept of FOSS distributions. That's what we get for letting companies such as Canonical and Red Hat control so much of the distribution space (and I mention Red Hat because of systemd, which has made its inroads much more successfully).

And snap is bad not just because you can't patch, or pin, or set up a snap mirror etc. The whole concept is bad.

That

Re: Linux Mint drops Ubuntu Snap packages

#303
Suse has been around just as long as RedHat, put out a great suite of products, went for-profit, and seems to do well in the EU market. They've never generated as much buzz - good or bad - though. Is that just my perspective from being in the American linux bubble? Centos, RHEL, Debian, Ubuntu, Arch even; I hear about those players all the time.

Re: Linux Mint drops Ubuntu Snap packages

#304
post #259

I wonder if it is finally time for me to give Arch a try. It's a shame that all my lab's machines run Ubuntu; although I find it solid, this sort of controlling behavior by Canonical seems against the spirit of FOSS.

I would recommend anyone considering Arch to skip straight to Void. It's "like Arch", but it addresses a number of pain points - specifically, its binary repositories are much larger, and its package manager won't let you break the system with incomplete upgrades like pacman will (on Arch, anything short of a complete system upgrade every time you install any package is not guaranteed not to lead to breakage, whereas…

I want to try Void Linux one day, but a distro that throws away systemd because REASONS is completely anachronistic for me.

Say what you want, systemd is here to stay. Everybody's free to make a distro without it, but I wouldn't consider it for a full time workstation, at all.

Re: Linux Mint drops Ubuntu Snap packages

#305
post #12

The reason for why the backend for the snap store hasn't been opensourced has been explained multiple times. Namely that it would be expensive to open source it with little benefit in return. Canonical already spent a large amount of investment opensourcing launchpad and nobody other than them operate it. Mainly because the majority of the costs are for operating an instance which most other distros aren't willing to…

> Namely that it would be expensive to open source it with little benefit in return.

Ok, so the whole technology is irrelevant and should not be used then.

> Canonical already spent a large amount of investment opensourcing launchpad

Why develop it as non-open-source to begin with?

Re: Linux Mint drops Ubuntu Snap packages

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

> The next problem is ... how do I ship updates? ...why not make a new release and ship that? That's the way package managers work . Developer makes a package. User installs the package. Then when developer fixes some bug and releases a new version the user can install the new version when the user decides it's necessary. The whole point about this is that it's user-centric. That's good.

It’s largely a good thing but it’s unreasonable not to mention the “flood of bug reports about issues that have since been fixed” effect that comes with manual updates.

This has burnt a few projects pretty badly (especially where distros have packaged an old version and never updated it).

Re: Linux Mint drops Ubuntu Snap packages

#307

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…

> Would be a shame to lose that.

So don't lose that. Use Debian (or Devuan), or one of its properly-FOSS derivative distributions.

Re: Linux Mint drops Ubuntu Snap packages

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

For sandboxing the user is supposed to decide if they will give you access to the permissions that you requested. Now in practice most FlatPak apps don't use sandboxing but hopefully that will change and permissions are treated with scrutiny.

Re: Linux Mint drops Ubuntu Snap packages

#309

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…

> One of the nice properties of debian packages is the ability to `apt-get source` and build it locally.

You don't get that for a lot of third party apt repos actually, no deb-src repo.

Re: Linux Mint drops Ubuntu Snap packages

#310
post #76

Earlier quoted context omitted.

I am honestly thinking the same thing. Still a bit hesitant as I mainly use Linux for work.

I would try fedora or centos. They have good stability and documentation. In my admittedly limited experience centos has worked better for me than debian or ubuntu.

I have returned to Linux after a few years on macOS, and tried Fedora 32: it's interesting, but I did not like:

- The hassle you have to do to install "non-free" software.

- It's basically RHEL unstable: plenty of opinionated, bleeding-edge software choices that are either unsupported [1] or very much undocumented, unless you can find some help on the actual RHEL guides.

- COPR (user packages) is worse than Ubuntu's PPA, both of which are much worse than Arch Linux's AUR.

1: Running Docker on Fedora 32 is non trivial because of how firewalld is configured and because Fedora decided to go all in on nftables. Sure, it's the future, but Docker hasn't got the memo yet. Nor the memo about cgroups2.

Post reply on HN