Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 18 submissions in the queue.

Snap Removed from Mint

posted by Fnord666 on Thursday July 09 2020, @06:27PM   Printer-friendly
from the working-behind-your-back dept.

hendrikboom writes:

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?

Original Submission

 
This discussion has been archived. No new comments can be posted.
Snap Removed from Mint | Log In/Create an Account | Top | 96 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 1) by organgtool on Friday July 10 2020, @09:00PM

    by organgtool (6385) on Friday July 10 2020, @09:00PM (#1019228)

    I know this is a joke but since this is a story about Snap and Docker and I see so many comparisons of the two, I think it's worth pointing out a distinction: one of the main advantages of a Docker image is being able to execute multiple instances of a container based on a single image without the need for maintaining a separate set of config files for each instance. For example, most web-based technologies need to connect to a database and therefore need to provide the connect string to the database in one or more config files. If I ran these apps natively, I would have to maintain separate configs on the file system for each web app instance to point to its companion database instance. However, with Docker I can create a stack and call the database "mydb" in the stack and then refer to the database hostname as "mydb" in all of the web app config and each instance of the web app will be able to communicate with its own db instance with absolutely no additional manipulation of the config. This use case doesn't really present itself for most desktop apps which is why people question the need for containerized desktop apps. In any event, the way that Docker is packaged is fairly independent of the advantages it provides. I just thought I'd take your joke way too seriously to make that distinction.