SoylentNews is people
SoylentNews
Linux reviews notes that
The popular Linux Mint operating system has decided to purge the snap package manager from its repositories and forbid installation of it. The motivation for this drastic move is that the upstream Ubuntu Linux distribution Linux Mint is based on will stealthily install snapd and use that to install Chromium from the Canonical-controlled SnapCraft instead of installing a regular Chromium package like most users expect.
The Linux Mint blog has this to say about Ubuntu's use of snap to use their chromium package to subvert apt:
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 installs itself without asking you.
Is Ubuntu turning evil?
(Score: 2, Insightful) by Anonymous Coward on Friday July 10 2020, @10:30PM (1 child)
When on Earth was this?
I've been using Linux for decades, and I remember a mess worse than "DLL Hell" dating back to the mid-90s. Often, if you wanted a binary, if you weren't running a specific distro (and then, often only a specific version), any binary you obtained would be useless. Your only option would be to recompile, assuming that you could get the code, and the library, and possibly the source code for the library (and any other dependencies), and get compatible versions, and (cherry on top!) the whole thing worked without compiler error or producing an executable that promptly crashed.
The repos managed to help with this to some extent, but only if the software you wanted was in the repo, making them a "soft walled garden" long before Apple or Google came up with them. I don't think most Linux fans realize that this is the case, since they recoil from walled gardens (as they should). And keep in mind, I like Linux a great deal, and it frustrates me that this is the case, when it didn't need to be and it shouldn't be. They marvel at the simplicity of the repo, and don't realize what really makes it tick and what its implications are. I don't even think the initial distros were made with this in mind, either, but that's the end result, essentially accidentally bringing them to a relatively large audience in a palatable form, since you didn't have to recompile if the distro already compiled it for you. But if the program wasn't in there, or - horror of horrors! - was proprietary, you were in for suffering.
Since that time the distros seem to have gone out of their way to crap on Linus' attempts at making binary backwards compatibility a reliable thing, and have more than made up with it with library incompatibility by the ton.
Ultimately containers are the best way to get around the library and distro mess. The people who are scratching their heads and wondering why people want containers likely include the ones that precipitated these ridiculous conditions in the first place.
(Score: 0) by Anonymous Coward on Saturday July 11 2020, @12:20AM
Distros that make packaging easy tend to have many packages. Arch is a good example - the PKGBUILD file is just a shell script that sets a few variables and supplies the build and package functions (CRUX has even simpler Pkgfiles, but no dependency management). BSDs have fewer packages and a higher barrier to entry - Makefile-based ports with a complicated set of procedures to properly build and sign.
Somehow Gentoo ebuilds are strange and over-complicated, but they have a huge repo? Elitist ricer overcompensation?