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) by Freeman on Thursday July 09 2020, @06:33PM (24 children)
That sounds like a good reason to avoid Ubuntu or any derivative. Linux Mint is taking the better path here. Still, makes me glad the only version of Linux I've been using recently is MXLinux.
I have to admit that Snap sounded interesting, but doing something like is mentioned here, is not acceptable.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 5, Insightful) by epitaxial on Thursday July 09 2020, @07:06PM (13 children)
I remember when Linux folks used to mention DLL hell and feel superior. Now you can't even compile something outside of one specific developers machine. So instead of cleaning up the mess and fixing why that happens they just put everything in a container. You trust the container security to keep bad things from happening to your machine. Sure I'll take this gigabyte of code and libraries from some random internet person and run it. You find a piece of software you need. It needs some random obscure libraries. One of those libraries needs some more libraries and the one repo where its hosted is down. You're knee deep in library bullshit at this point.
(Score: 5, Insightful) by Anonymous Coward on Thursday July 09 2020, @07:53PM (2 children)
They've basically reinvented statically-compiled executables, but badly.
(Score: 4, Funny) by DannyB on Thursday July 09 2020, @08:35PM (1 child)
You could be referring to AppImage.
I've also heard a POV which said that Docker is static linking for millennials.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 1) by organgtool on Friday July 10 2020, @09:00PM
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.
(Score: 2, Touché) by Anonymous Coward on Thursday July 09 2020, @09:18PM
Good luck fixing it. Every previous attempt made the monstrosity even more monstrous.
(Score: 2, Insightful) by Anonymous Coward on Thursday July 09 2020, @09:50PM
This was never not so. I remember Linux dependency hell going all the way back to kernel 0.98
Yep people use different build environments. The bigger the application the more proprietary the build environments tend to get. Every team has a different approach to code development and optimization.
Even GNU doesn't use config tools universally.
(Score: 4, Interesting) by hendrikboom on Thursday July 09 2020, @10:16PM (5 children)
There's guix, which claims to be able to handle multiple versions of the same package to handle depedency hell. Every package gets its own set of (shared) versions of packages it depends on.
(Score: 2) by Marand on Saturday July 11 2020, @02:10PM (4 children)
There's also Nix, which did it first and gave Guix the idea. Guix just copied the it, but using GNU-approved Guile Scheme for the package description and configuration language instead of a custom language like Nix uses. This would be a great thing, since you can use a nice, fully-featured, and powerful language instead of someone's in-house custom PL. But unfortunately they also went full GNU, which means odds are it will be less useful than Nix for use on a real system due to having fewer packages (14k for Guix, 60k for Nix) and no access to things like non-free firmware. So you're back to dealing with Nix and its weird not-quite-Haskell language.
Guix is a great idea but in the real world, if you want an actually useful system, you should never go full GNU.
(Score: 2) by Subsentient on Saturday July 11 2020, @02:46PM (1 child)
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 2) by Marand on Saturday July 11 2020, @03:38PM
:D
That was what I was going for but I decided not to go with a direct quote. Glad it didn't get missed despite that.
(Score: 0) by Anonymous Coward on Saturday July 11 2020, @05:34PM
i installed guix and it didn't work out of the box. end of test.
(Score: 2) by hendrikboom on Monday July 13 2020, @04:51PM
I suppose it would still be possible for a distro to use guix but choose to have guix access its own guix-compatible repositories.
(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?
(Score: 3, Interesting) by Anonymous Coward on Thursday July 09 2020, @07:43PM (7 children)
so you can still use Mint even if you reject Ubuntu. They keep it maintained against the day Ubuntu turns evil or disappears.
(Score: 3, Insightful) by Anonymous Coward on Thursday July 09 2020, @07:56PM (2 children)
There's an ever increasing concensus that Mint should drop their standard distro based on Ubuntu and concentrate all their efforts on LMDE only. I happen to be part of that concensus. LMDE 4 is my daily driver and I couldn't be happier.
(Score: 1, Funny) by Anonymous Coward on Thursday July 09 2020, @11:23PM (1 child)
...if an LMDE tracking Debian testing existed, I'd marry it and bear it's huge-headed children.
(Score: 2) by Runaway1956 on Friday July 10 2020, @03:44PM
The huge heads are a result of the systemd mutation. Just so you know.
(Score: 2) by SDRefugee on Thursday July 09 2020, @08:05PM (3 children)
And even if (when) Ubuntu truly jumps the shark, Mint also tracks Debian with their LMDE version. Mint definitely looks to be the way to go... Not to mention
I think it looks nicer than Ubuntu (using the Cinnamon DE)
America should be proud of Edward Snowden, the hero, whether they know it or not..
(Score: 2) by hendrikboom on Thursday July 09 2020, @10:16PM (2 children)
Is systemd optional in mint?
(Score: 2) by Common Joe on Friday July 10 2020, @03:26AM
Not to my knowledge, but, if you like Cinnamon (which is a big thing in Mint), you can install Cinnamon in Devuan. In version 2, it's one of the options you have when installing Devuan. Devuan just came out with version 3 and I assume Cinnamon is in version 3, but I haven't checked it out yet.
(Score: 0) by Anonymous Coward on Friday July 10 2020, @01:11PM
It's optional in Debian too. However, Debian allows all its other components to place hard dependencies on systemd components, thereby making it de-facto compulsory.
But happily, the elogind package from AntiX ships with an API-compatible libsystemd.so, thereby allowing pretty much anything from Debian (even Wayland) to run smoothly without systemd. But by then it's called AntiX.
(Score: 3, Interesting) by driverless on Friday July 10 2020, @10:35AM (1 child)
OTOH it's not "Ubuntu turning evil", they're trying to fix a genuine problem related to out-of-date libs in LTS versions. Their solution seems OK until you look in a bit more detail and realise it results in unepected behaviour for some users. Hopefully they'll realise this is a problem and address it. But in any case it's not the "evil corporation slips in unwanted malware" that the summary makes it out to be.
(Score: 0) by Anonymous Coward on Saturday July 11 2020, @05:38PM
they're slipping in vendor lockin and unacceptable access restriction though and that's not OK.