I usually go with Ubuntu on cloud platforms because it’s one of the defaults.
Any suggestions on what’s a good alternative distributor go with that is widely supported and easily available on the variety of cloud platforms?
Linux Mint drops Ubuntu Snap packages
91–100 of 538 posts
Re: Linux Mint drops Ubuntu Snap packages
#92Installed ubuntu 18.04, purged snapd. It was back after `do-release-upgrade` to 20.04
I think it's reasonable that the installer for a new LTS release would go with the default package-management scheme.
Especially if the people authoring the do-release-upgrade scripts weren't aware of this being a hot-button issue.
Re: Linux Mint drops Ubuntu Snap packages
#93I'm unclear why ubuntu needs the chromium package in apt. Seems like they should just stop publishing apt packages for chromium, only publish in snap, and steer users into using snap for installs and not apt. Seems less confusing and wins or loses on its merit.
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.
Re: Linux Mint drops Ubuntu Snap packages
#94From 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).
> 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. If your application cannot run as a sandboxed app, you need to be granted special permissions by canonical after manual review (my app needs this), where they also discuss if they can make a new permission in a safe way for your usecase that everyone can use afterwards.
On one hand this sucks because I need to ask canonical for permission to publish something, and there's no certainty that I will get these permissions as a nobody for a new app nobody ever heard of before. On the other hand, I think I like that they're doing something about the desktop security model.
The next problem is, if this is denied, how do I ship updates? Provide a self updater? Easy to write, but if everyone does that, we can just go full windows and abandon package managers. Tell people to just curl | bash? That's not more secure than a potentially shady snap.
But I do have to praise canonical for being very helpful in IRC and the forums for helping me debug issues and file bugs against snap stuff.
Now flatpak on the other hand, just feels kinda weird to me.
It sandboxes things, but every application can pretty much grant itself access to everything. This is a completely different philosophy, but if you rely on everyone tightly sandboxing their applications without granting themselves permissions for sandbox escape, I think something like landlock[0] (when it lands) or pledge is much more suited for this, and baked into the application.
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.
(Community-)Support for building flatpaks? Pretty much non-existant.
So yeah, the entire linux upstream-packaging situation is still quite depressing honestly. And with the time and energy I have invested into this by now, I could have written a simple but sufficient self-updater about 10 times over.
[0]: https://landlock.io/
Re: Linux Mint drops Ubuntu Snap packages
#95I've been putting off my next OS reinstallation, but I think I'll be moving away from Ubuntu and over to Mint this time.
Pop!_OS is another choice to consider. Apparently they are sticking with Ubuntu but are stripping the Snap stuff before pushing any updates.
Any reason to use Pop!_OS over Mint, or vice versa?
Re: Linux Mint drops Ubuntu Snap packages
#96Earlier quoted context omitted.
There is no downside to Flatpak's support for multiple repositories and ability to self-host repositories. GNOME Software and KDE Discover both set Flathub as the default repository, which serves as the primary software source, and users can optionally add more repositories if they choose to do so. Users who don't want additional repositories can simply stay with Flathub without having to do anything. The Snap server…
>There is no downside to Flatpak's support for multiple repositories and ability to self-host repositories. There are always tradeoffs. I would argue there are advantages for having a trusted party vetting my software repos. It's why I even use Ubuntu because I trust Canonical to make some sane decisions when vetting their repositories. You give multiple repository support and suddenly users have to one find a way to…
Your first argument is an argument against using Linux at all.
Re: Linux Mint drops Ubuntu Snap packages
#97Earlier quoted context omitted.
>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? Im not too sure as I don't work for Canonical. However, from an external perspective having worked with bzr and launchpad, I wouldn't be surprised if there is a bunch of aspects there that would make opensourcing a nightmare. Th…
> However, from an external perspective having worked with bzr and launchpad, I wouldn't be surprised if there is a bunch of aspects there that would make opensourcing a nightmare. If Canonical, as a Linux company, is not willing to spend the effort to open source their software, then Snap can continue to be rejected by Linux distributions. Canonical's most obvious reason for keeping the Snap server closed source is…
You haven't really at all explained any justifiable reason for Canonical to open source it. You still haven't argued at all the resource aspects which are I think the primary motivator here.
Canonical has done this experiment precisely in the past, and we see the results of nobody operating their own launchpad instance. Nobody contributing back. That experience probably trumps all of this goodwill and opinions from the community.
Canonical is more importantly getting users, publishers and numbers behind them. A discussion I remember reading was that every snap has 10x more installs than the corresponding flatpak. That and they have 1st party support from major publishers like Google, Microsoft, Amazon, Spotify, Mozilla, Jetbrains, KDE etc....
Those aspects are more important for usability for the average user.
Re: Linux Mint drops Ubuntu Snap packages
#98Earlier quoted context omitted.
> just use an alternative solution like flatpak Saying " just use an alternative" seems overly dismissive of the complications that entails. IIUC, the only options for that are (a) abandon Ubuntu, or (b) actively circumvent Ubuntu's software distribution infrastructure, reminiscent of dealing with Windows 10 forced updates. IMHO this somewhat erodes Ubuntu's value proposition.
I have a laptop that I'm planning on rebuilding from a failed NTFS/Win10 system to Linux something. Now I know it's not going to be Ubuntu or anything else derived from Canonical.
> Now I know it's not going to be Ubuntu or anything else derived from Canonical.
Why avoid Ubuntu derivates like Mint or Pop!_OS, though?
They're doing the heavy lifting of fighting Canonical on this issue. Maybe using one of those distros instead of vanilla Ubuntu actually strengthens the pressure that Canonical feels on this topic.
Re: Linux Mint drops Ubuntu Snap packages
#99I've been kind of disappointed by Snap. It seemed like it was a way to always have the latest version of software you care about available, but in practice, nobody updates their Snaps. I used it to get a newer version of Go, and while it is more recent than what comes with Ubuntu, it's still not the latest version. Apparently Some Guy updates it on a volunteer basis when he remembers, so it's nearly useless. Even if…
> Some Guy updates it on a volunteer basis when he remembers Blame repo culture. In saner worlds there is no requirement for a middle man between developer and user, so users get the software when the developer releases it to them. For various reasons (only a few of which are technical), Linux has settled on this middelmen-everywhere way of doing things, and because it is FOSS all those middlemen are also volunteers…
It's not brain damage its a reaction to people being capable developers but crap at system engineering.
I really don't want 187 system vulnerabilities from 12 apps which use different versions of different outdated libraries.
Re: Linux Mint drops Ubuntu Snap packages
#100This 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…
This doesn't have to be true. It's perfectly possible to produce a reproducible-build snap, and many Free Software snaps are reproducible from source. It's established convention to do it this way.
The capability is necessary because snaps can also ship proprietary software (eg. Spotify, Skype, etc). So one wouldn't expect this to be a property of (binary) snaps, just as it isn't for binary debs. apt/deb comes with "source package building tooling" (dpkg-source, dpkg-buildpackage, policy around debian/rules, etc) and so do snaps (snapcraft).