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: 4, Informative) by pTamok on Thursday July 09 2020, @07:01PM (7 children)
If people want a different choice to Snaps and Flatpaks, there is also the lesser known Appimage [wikipedia.org].
(Score: 3, Informative) by fustakrakich on Thursday July 09 2020, @09:39PM (5 children)
Heh, I remember when Mac programs came that way, all self contained. It was back in the System 7 days. Sure beats the hell out of scattering bits and pieces all over your drive during "installation"
La politica e i criminali sono la stessa cosa..
(Score: 4, Insightful) by fyngyrz on Thursday July 09 2020, @10:50PM (4 children)
They still come that way. Basically it's a package with subfolders containing the various bits and pieces. From the developer POV, you can stuff all the relevant stuff in there to make sure that bitrot and OS mutation don't break your stuff nearly as much. It's a great system.
It differs from a Snap, though, in that you can actually edit and modify the application contents with the appropriate permissions, so if you get stuck with something really borken (RocketChat-snap, I'm looking at you), you might actually have a chance to address it. Snaps are utterly toxic. I despise them.
--
I'm trying to give up sexual innuendo.
But it's hard.
So hard.
(Score: 4, Interesting) by TheReaperD on Friday July 10 2020, @12:10AM
Did Ubuntu go full fellatio to the copyright cartels and allow completely unreadable, uneditable binaries be installed on their systems? And, if so, in the case of Chrome, made it the only install option to the point of backdooring it when you tried to install it with apt-get? I haven't used Ubuntu in a while so I'm actually curious if I need to avoid it in the future.
Ad eundum quo nemo ante iit
(Score: 3, Funny) by VLM on Friday July 10 2020, @01:04PM (2 children)
I miss the old days when the groupthink was dynamic linking made your apps better and more secure, not the opposite like now.
Someday I think we'll reach the other extreme where /bin/ls is a symlink to a sandboxed static linked docker image, and when yet another security bug is fixed in strcpy you'll have to essentially download and reinstall the entire box instead of one library.
(Score: 2) by fyngyrz on Friday July 10 2020, @05:57PM (1 child)
The problem is, it rarely did, unless you were incompetent in the first place.
It meant you were using other people's code, OPC that despite the accessibility (sometimes) for others to look it over and verify it, rarely actually was looked over, and even if it was, it wasn't done carefully or completely or even well. And like most OPC (and final applications and OS implementations, frankly) out in the wild, was rarely documented well or even at all.
Code that you usually had to wait for bugfixes for; bugfixes that often never arrived.
Code that wasn't written to do exactly what you wanted, nor just what you wanted, and so contained anything from a little to enormous amounts of cruft, some of which might be peripherally involved with, and subtly affecting, the functionality, the security, and the fit of the overall project. And which, consequently, you could not document completely even if you wanted to, because it ends up being incomprehensible in its multi-layered dependence upon random stuff you never even get to see, much less have the good fortune to encounter detailed documentation for, or come with test suites to solidly validate.
Code that carried with it various legal hurdles and roadblocks as to what you could, and could not, do with it.
Code that might, or might not, be portable across platforms.
Code that might, or might not, use a development environment that you actually have set up.
Code that would break when bitrot and/or mutation set in on the dynamically linked, but now dynamically different, binary.
Code that turned out to have been 16-bit when you needed 32- or 64-bit.
Code that didn't take into account big- and/or little-endianness.
Code that brought in dependencies on framework after framework in an ever-deepening heap of unknown, eventually unknowable, weaknesses, vulnerabilities, as well as outright bugs and/or memory stomping and/or memory leaks.
Sure, if you can't take time to write what you need, you can always lean on the wide world of "maybe it'll do", but if you can, and you're willing to put in the work, a lot of that — even most of it — can be avoided.
The only real exception — for large systems, anyway — is the host OS. For small systems, you can write the whole shooting match.
Well, some of us can, anyway. :)
--
Months of development work saves hours of up-front design.
(Score: 2) by VLM on Saturday July 11 2020, @02:32PM
I hear what you're saying that code is rarely perfect, but it rapidly turns into a race between an individual or small team vs perhaps the entire gnu-libc effort, and usually the glibc people won.
Now I'd agree that for some obscure glue library with only two users in the real world, yeah you can almost certainly do better than they did even with the usual NIH problems.
(Score: 0) by Anonymous Coward on Saturday July 11 2020, @05:41PM
appimage is gay. if i wanted to download executables from all over the internet and not have them properly integrated, i could run windows.