Linux Mint Dumps Ubuntu Snap (zdnet.com) 117
An anonymous reader quotes a report from ZDNet: Mint's programmers, led by lead developer, Clement "Clem" Lefebvre, has dropped support for Ubuntu's Snap software packing system. [...] So, what's not to like? Well, a lot, thinks Clem. As he wrote in July 2019, the idea is fine: "When snap was announced it was supposed to be a solution, not a problem. It was supposed to make it possible to run newer apps on top of older libraries and to let third-party editors publish their software easily towards multiple distributions, just like Flatpak and AppImage." But, he said, "What we didn't want it to be was for Canonical to control the distribution of software between distributions and third-party editors, to prevent direct distribution from editors, to make it so software worked better in Ubuntu than anywhere else and to make its store a requirement."
Clem was worried then that Canonical was moving in that direction because: "Ubuntu is planning to replace the Chromium [Google's open-source browser and foundation for Chrome] repository package with an empty package, which installs the Chromium snap. In other words, as you install APT [Debian's program for installing and managing DEB files] updates, Snap becomes a requirement for you to continue to use Chromium and installs itself behind your back. This breaks one of the major worries many people had when Snap was announced and a promise from its developers that it would never replace APT. A self-installing Snap Store which overwrites part of our APT package base is a complete NO-NO. It's something we have to stop and it could mean the end of Chromium updates and access to the snap store in Linux Mint."
Fast forward to now, and that's still the case with Chromium, and Clem has had enough: "In the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store. 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 installs itself without asking you."
Clem was worried then that Canonical was moving in that direction because: "Ubuntu is planning to replace the Chromium [Google's open-source browser and foundation for Chrome] repository package with an empty package, which installs the Chromium snap. In other words, as you install APT [Debian's program for installing and managing DEB files] updates, Snap becomes a requirement for you to continue to use Chromium and installs itself behind your back. This breaks one of the major worries many people had when Snap was announced and a promise from its developers that it would never replace APT. A self-installing Snap Store which overwrites part of our APT package base is a complete NO-NO. It's something we have to stop and it could mean the end of Chromium updates and access to the snap store in Linux Mint."
Fast forward to now, and that's still the case with Chromium, and Clem has had enough: "In the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store. 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 installs itself without asking you."
Fair enough (Score:2)
Re:Fair enough (Score:5, Funny)
I switched to Windows. It's a different hammer, but it feels the same when you repeatedly smack yourself on the head with it.
Re: (Score:2)
Is there an APT repository for Real Chrome?
Re:Fair enough (Score:5, Informative)
https://www.google.com/linuxre... [google.com]
Re:Fair enough (Score:5, Informative)
APT repositories are distro-specific, but since Debian has a Chromium package [debian.org], Mint could use the source package for that as a base for their own Chromium package.
Another option would be to embrace a different cross-distro package format like Flatpack or AppImage. The problem with Snap is that it has a single central repository which is run by Canonical, instead of being able to use multiple repositories that can be added or removed by the end user.
Re:Fair enough (Score:5, Insightful)
I guess it's better in that now there are only three redundant systems instead of a dozen or two, but dammit... is it any wonder that so few developers want to support desktop Linux? The fragmentation continues yet again.
I don't blame Mint. The snap model seems pretty antithetical to everything FOSS represents, having all your packages managed by a corporation, with no alternative method of distribution, and no community oversight.
I guess, it just sort of irritates me that it had to come to this. IMO, fragmentation (and specifically, incompatibilities caused by fragmentation) is a pretty bit problem for Linux, at least in regards to software distribution. These package managers are supposed to help solve this problem, and yet, now the package managers themselves are fragmenting. Am I the only one who thinks this is bonkers?
Re: Fair enough (Score:2)
There's only one distribution method that needs to be supported on Linux: tarballs+Make.
Each distro might have their own specialized approach, but all of these other cross-distro "solutions" are worthless.
Re: (Score:3)
There's only one distribution method that needs to be supported on Linux: tarballs+Make.
No thanks. I've better things to do with my life than sit there watching a terminal spew out a load of crap whilst it takes infinitely longer to compiles software than it took to download it.
Re: (Score:3)
Re: (Score:2)
There's only one distribution method that needs to be supported on Linux: tarballs+Make.
That works fine, till regular patching of all that built from source software becomes necessary. Then it becomes tedious.
Re: (Score:2)
A lot of Linux users seem to actively work towards keeping Linux exclusive to expert users, and/or as a pure open-source-only sanctuary. Or, they may just use Linux in a server-only environment, and so aren't really bothered by the lack of user-facing software (at least, compared to Windows or Mac). So for them, it's not a problem. They don't care if only a few percent of desktops run Linux, since their needs are satisfied.
That's not an illogical stand to take, really. But it definitely runs contrary to
Re: (Score:2)
Static linking? I remember installing WordPerfect 8, it had 2 dependencies, libc5 and xlibs5 and just worked.
The drawback is that if the company doesn't maintain their package, security fixes and such which are often fixed by a library update.
Re: (Score:2)
I've said it before, and I'll say it again. Proprietary software must die. It is always immoral--no excuses.
Re: Fair enough (Score:2)
The problem is mainly for closed source; not much so for open. Distros are usually ok with packaging software for their pkg mgr of choice. Making packages from source isn't that complicated. Vendors can help out quite a bit by following some coding standards (ie: std build scripts, env vars, stds across versions, etc). The distro pkg maintainer can translate that std to their pkg's.
This changes when providers build in pre-compiled binaries, have a complex build/update path, too many micro changes, or kee
Re: Fair enough (Score:2)
You are not the only one.
https://xkcd.com/927/ [xkcd.com]
Re:Fair enough (Score:5, Informative)
but do we have any practical solutions?
Yes, use Firefox.
Re: (Score:2)
I agree, but even then there are still reasons why one would want to install Chromium or any other browser alongside of it. Moreover, this is about a Linux distribution maintainer's perspective, where one wants and needs to offer a comprehensive selection of browsers in its repositories.
Re: (Score:2)
Why use Chromium when you can just install Chrome.deb??
Re: (Score:2)
There is no "Chrome.deb" for anything but x86-64 (or well there is also x86-32 but really old and half-broken by now). And it isn't only about the 32-bit but also about arm, starting with Raspberry Pi and going to a lot of other thing, mostly smartphones and tablets.
Bwa-ha-ha-ha!!! (Score:1)
Sorry, I see fools re-inventing package systems every few years. "Build it yourself", deb, apt, rpm, yum, flatpack, pip, CPAN, ant/maven/gradle, "modular" RPM's. It typically takes 5 years to realize the new system solves no problems that competent use of the old system could provide, and to realize the instability introduced by the new system.
Re: (Score:3, Interesting)
There are new package systems that aren't a repeat of deb/rpm. nix/guix is a new direction that let software that are up to date use shared latest version of libraries, meanwhile older software can share and use older version of libraries all in co-existence. The problem is they are too enthusiast-oriented. Nix is still not dummy-proof enough and ask for a lot of script file / command line fiddling. Guix is worse as it goes the no-binary-blob route and only accept pure open-source stuff in their official r
Re: (Score:2, Insightful)
Well if you want libraries bundled with applications, why not simply statically link them?
I agree, but... (Score:5, Interesting)
If you staticallly link an executable with a full-GPL library, then the whole executable inherits GPL, with its source-code release requirements. Some projects would not like this - although it only applies to the copy that you distribute, not the whole project. However, you can't statically link to both a close source and a GPL library.
Of course, bundling it all together in a snap probably does make the whole snap GPL anyway, but no one wants to think about that.
Re: I agree, but... (Score:2)
Not if you link it during the build on the target machine. Then there's no distribution so the GPL doesn't apply.
Re: I agree, but... (Score:2)
Where have I heard that before?
https://www.theregister.com/20... [theregister.com]
Re: (Score:3)
containers are cancer as well.
Tech developed by people so bad at systems architecture they have no idea how to keep APIs and libraries stable.
Re: (Score:2)
Re: Bwa-ha-ha-ha!!! (Score:2)
Undocumented behavior is pretty much the highest form of an unstable API.
Re: (Score:2)
I hate that goddamn gnome calculator snap that ships with Ubuntu. At work I need to do a quick calculation and type calc and of course it takes 5 seconds to load that stupid container. Meanwhile xcalc loads instantly.
Re: (Score:2)
I've never seen the point of simulating the user interface of a 1990-era pocket calculator. I run
xterm -title calc -geometry 80x10 -e python3 -ic 'from math import *'
This has a negligible startup delay and gives me a command history and line editing, all of python, while not adding unnecessary keystrokes for simple calculations like 123*45/67[enter].
Good (Score:5, Insightful)
Good on Mint making grown-up decisions. It's the best Linux distro I've used: smooth operation, solid, looks nice, and evidently good leadership.
Re:Good (Score:5, Interesting)
If Mint still supported KDE, I wouldn't have switch to Ubuntu. With this news, it seems I need to pick another distro to upgrade from 18.04.
Re: (Score:2)
KDE is point and click only? (Score:2)
As someone who's only used Window Maker, GNOME 2, and now xfce extensively, is it really the case that KDE doesn't have an affordance for minimize / maximize / close functionality via keyboard shortcuts?
Re: (Score:2)
No, it's never been the case. You can bind keyboard hotkeys to do all kinds of things with your windows, I want to say since KDE 2 in fact!
Re: (Score:2)
What do you mean by supported? What is stopping you from installing KDE? Isn't the whole point of Linux you have the ability to customize whatever you want?
Re: (Score:2)
If Mint still supported KDE, I wouldn't have switch to Ubuntu. With this news, it seems I need to pick another distro to upgrade from 18.04.
What Mint release did you get that didn't have KDE a few clicks away? We're talking literally less than 15s of effort here.
Re: (Score:2)
Why? Does either Chromium or Snap have some feature that's critical to you?
Re: (Score:1)
Good first step, anyway. Why not just dump canonical and base Mint directly on Debian? Personally, I don't want to use a distro based on a distro that is based on another distro. It just adds too many level of potential bulls***. Snap was one of several reasons that I dumped Ubuntu and switched to Manjaro last year.
Re: (Score:2)
So... (Score:2)
If I use Firefox, do I even need Chromium installed? Should I uninstall it now, before it goes to Snap? Or is it already snap (running LM 19.3)?
I don't use Chrome, except on the work computer in Windows that came with it. Home computers all use FF, and I guess I could always jump on a Windows machine with Edge if I want to use something that's Chromium-only. So why do I even need Chromium in my Linux machine?
Re:So... And... (Score:3)
and ... if I uninstall Chromium via the Software Manager and it's already a Snap, will it uninstall the whole thing, or just remove the APT link and keep the Snap installed?
Re:So... And... (Score:5, Informative)
Re:Canonical just became Microsoft (Score:5, Interesting)
and its 'You will do it our way or not at all!' attitude.
IMHO, this has been on the cards for sometime. Canonical are doing more of what I call 'fiddling while Rome burns' stuff.
Certainly in the two LUG's I'm a member of, Ubuntu and its dericatives were once the most popular distros. No longer. Mint is where it is at these days.
I've never really liked Ubuntu. They started out with really good aims but they seemed to fall down when they tried to out do RedHat. RHEL/CentOS is not flashy but works very well in the background like any good OS should do.
I use either CentOS (servers) or Mint these days. I'm not alone there.
Another footgun moment from Canonical?
Re: (Score:2)
debian unstable or GTFO
Re: (Score:1)
Snap on Ubuntu is devouring more and more applications, so uninstalling Chromium will not help.
Total garbage. A clean install of Ubuntu MATE 20.04 has *one* snap - the crappy software store. It took me less that a minute to remove this and the entire snap infrastructure.
Re: (Score:2)
So why do I even need Chromium in my Linux machine?
Unless you're a web developer you probably don't.
Linux Mint dumping snap (Score:2)
awesome, I installed Ubuntu 20.04 a few months ago, hated having to go through Snap to install Chromium. Wonder why FF is now my main browser ?
Re: Linux Mint dumping snap (Score:3)
I did the same. Maybe it's a cunning ploy to push people back to Firefox again?
bravo (Score:5, Insightful)
Re: (Score:1)
I don't want duplicates of every single library for every single application.
So don't install literally everything from flatpack / appimage / snaps, only what can't be easily backported to your system's release. Problem solved.
I don't want a separately mounted filesystem for each application that's running, crapping up my "df" output.
Deal with it. It's no worse than having a ton of subdirs mounted VS. having all of /var, /etc, /home, and friends all residing in a huge / partition.
I don't want an unnecessary delay each time I start a program.
Get a toaster made in the last 2 decades and that problem goes away.
Re: (Score:2)
IOW, don't use snap, and don't use docker garbage.
And the more people who refuse to use either, the better.
Re: (Score:2)
and don't use docker garbage.
What do you have against virtualization? What next, I'm sure you're already on the don't use the cloud bandwagon, but I suppose you're just using Docker as a gateway drug to "don't use zen/KVM", then I suppose at some point you will say don't use multitasking and run only one program on any computer at a time and your assertion will be complete.
Or maybe I'm reading you wrong and you simply have no idea what Docker's purpose is.
Re: (Score:1)
and don't use docker garbage.
What do you have against virtualization?
Containerization is not virtualization.
Re: bravo (Score:2)
Maybe the same reason I don't run Internet Explorer on Linux by using a Windows VM. If you can't get the software working natively, then I have zero confidence in your ability to deliver a an up-to-date secure product.
Re: (Score:2)
Is your piece of software to shitty that it can't be built and executed outside the parameters of the lone developer's machine?
Re:bravo (Score:4, Interesting)
Well, docker is pretty garbage. Some useful concepts, but compared to more modern designs (e.g. podman) a relatively poor design. In large part because it had to make due without some kernel features when they started, but now that more capabilities are in the kernel, there are much more sane ways of providing capability more broadly.
That said, the general state of how namespaces and cgroups are used even with better tooling is disheartening. There are good things that can be done (e.g. using cgroups to better schedule, control and restrict individual applications, or using pid namespace to hide unrelated applications from each other, or using mount namespaces to show only a subset of user data to an application rather than the traditional "all apps of a user have equal access"). Should you have to deal with the ideally rare scenario of a necessary, yet fragile/picky application, then giving that application its own "OS" it is good. Though not unique to containers , they has inspired *some* application vendors to be better about keeping data and application separate and further more likely to be 'blind-mated' with different versions of their user data and less often demand that users do manual migration measures. However these last couple of 'good points' have become 'bad' as the ecosystem leans on them as crutches more and more.
The problem is that applications have given up any semblance of proper packaging and maintenance. This means installing a number of applications has a great deal of duplication. Worse, it is much more likely an application stops bothering to update some security critical library and there isn't a convenient way to impose your own better maintenance discipline on such an application. Not to mention that shoddily duct taping a bunch of assorted crap together in a more fragile way is made easy to install and generally runs at first, but more likely to fail than a well-integrated application and much more unlikely to be easily reparable.
I did a survey of several container applications that were actively being used in my business.
If I went to pull the absolute latest of the ones that were from a public container registry, many of them hadn't updated in over a year at all, and of the ones that did update, many of them only bothered to update their own code and didn't update any dependencies, including many security vulnerabilities.
Internally, there was at least this one team that was excited that we allowed docker containers on our 'uselessly old' CentOS7 systems and rolled their container using what was current at the time: Ubuntu 16.10. So here we are in 2020 and we suggested they should update their now 'uselessly old Ubuntu 16.10' and got told 'no, it's just too hard'. After being berated for not providing them non-LTS platforms to run on, it's rich for them to be even worse at keeping up.
One instance of some container application stopped working at all. Upon contact with the software provider, the ultimate answer was 'it's a container, just delete all your user data and it will start right back up!', which was of no solace to the owner of that instance that actually cared about the data, not about how much trouble it would be to reinstall. Basically the container provider ultimately gave up trying to chase through all the myriad of log files they had from so many services they had put in and said they just couldn't figure out what problem it had with the current user data or how to fix it without losing all the data.
Basically, containers have enabled the laziest and most dangerous inclinations of a lot of developers without any enduring mitigation for the risks those inclinations create.
Re: (Score:2)
Wait: user data inside the container?
That's terrible practice, you never keep user data inside a container. The whole point of containers, aside from being isolated and reproducible, is that you can at any time destroy them and create a new one.
Data should have been on external mounts (e.g.: volumes), and the entire container's FS read-only.
This allows having stateless containers in a way (they have in-memory state, but everything else is ephemeral).
Re:bravo (Score:5, Informative)
Re: bravo (Score:2)
If I wanted a separate library ecosystem to separate may apps, I'd install them to different VMs.
Duplication isn't so bad; it's the user experienoe that sucks. Shared settings don't work properly, paths don't match up, things don't integrate properly into the host system, etc. If I'm ok with all that crap, a VM works just as well.
Re: (Score:2)
I like things to be self contained. As well as eliminating any issues with things like DLL versions it makes cleaning up after them so much easier. The additional overhead is pretty minimal, especially on modern systems where SSDs are as fast as RAM from a decade ago.
Obviously you want to have the choice, but I think containers are a valid choice to make.
Re: bravo (Score:2)
If you can't manage version dependencies, I don't want to use your software. You have demonstrated you can't even manage the basics of building software. Why would I trust your code?
Re: (Score:3)
They often also store configs and settings in the ~/snap mounted volume. Their firefox snap, for example, when removed, also non-recevorably removed the bookmarks and other firefox user setting, which were mapped into a ~/snap routed config dir, FOR EVERY USER on the system. Snaps are not just crap, but dangerous.
Lol DLL hell (Score:2)
What were all those Linux people in the 1990s complaining about Windows and "DLL hell" look how the tables have turned.
Re: (Score:2)
Container-based packaging systems don't do what I want need.
The Mate desktop is a package, right? Or maybe atril, the file viewer, can regarded as a package. Whatever.
I've encountered a malfunction. The version of atril that comes in the version of Mate distributed in Ubuntu-Mate 18.04 doesn't always properly render the magazines I look at. Blocks of text show as gibberish characters. There's nothing wrong with the magazine. It displays okay in ghostview. And it also displays okay in Ubuntu-Mate 20.04, whic
You can make apt pull Chromium from Debian (Score:5, Informative)
I dislike Snap, too, but don't want to leave behind the things I like about Ubuntu, so I configured apt to get Chromium packages (including timely updates) from the Debian repo. Here's how. [askubuntu.com]
Re: (Score:3)
Or you can use Google's repo for it. Then you don't have to tell it to ignore everything else in Debian's repo.
Re: (Score:2)
Using Google's repo would require trusting code from a new party, thereby increasing your attack surface. Using Debian's repo does not, because Ubuntu & derivatives already pull most of their packages from Debian.
Google in particular would make some of us uneasy, because Google has both the motivation to quietly slip things on to people's systems, and a track record of doing so [arstechnica.com].
Come to think of it, I don't think Google offers a Chromium repo at all. As far as I know, they only offer Chrome, which is not
Seems some people remember what FOSS is (Score:5, Insightful)
Excellent.
not cool canonical (Score:3)
Re: (Score:2)
LOL how?
Snap is garbage.
Re: (Score:2)
I think that's what he is saying.
I'm all for it (Score:5, Insightful)
"In the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store. 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."
Okay, so if that's true, that's ungood and I say take it the fuck out. Like now.
Rip it out by the roots and if people feel like installing it, then by all means let them. But FFS don't ship an OS with a built-in root-level backdoor.
Re: I'm all for it (Score:2)
It's not a root back-door. You have to escalate to root to use apt first. Apt packages can already do pretty much everything as root.
The HUGE difference is that the apt packages are individually maintained and patched by the distro, but Snaps can include any random version of whatever library the developer used.
Apt is downloading signed binaries from a trusted source. Snap is more akin to downloading tons of code over HTTP and then using sudo to install it.
The whole reason for snap is so that you can use ou
Re: (Score:2)
From the article:
"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 installs itself without asking you."
Sounds fucked up to me, I'd say get rid of it.
Learned what snap was the hard way (Score:5, Informative)
So Canonical isn't building a walled garden. (Score:5, Informative)
It's more like a Ha-ha [wikipedia.org].
Re: (Score:2)
Or a ho-ho or Om, Croffler, or Io (your choice) forbid a he-he
snap is total garbage (Score:5, Interesting)
snap really is trash. It shits all over your FS and fills up the / partition, with no option of putting anything anywhere other than /snap.
Not even /opt/snap.
Or /usr/local/snap
No you actually have to mount something on /snap or bind mount it elsewhere, since symlinking /snap doesn't even work right.
Re:snap is total garbage (Score:5, Interesting)
/dev/loop3 156416 156416 0 100%
/dev/loop2 46080 46080 0 100%
/dev/loop4 56064 56064 0 100%
/dev/loop0 156416 156416 0 100%
I don't even have chromium installed! Trying to remove the snapd libraries makes it want to uninstall everything (like the desktop). You can't avoid this crap.
Re:snap is total garbage (Score:4, Informative)
I managed to remove snapd from Ubuntu MATE 20.04 without any issues, following these instructions:
Find installed snaps: snap list
Remove installed snaps: sudo snap remove
Remove snapd: sudo apt purge snapd
Remove snap directory from home: rm -rf ~/snap
If you receive an error removing snapd then do the following sudo rm -rf /var/cache/snapd then run sudo apt purge snapd
Re: (Score:2)
Re: (Score:2)
I don't have snapd installed, nor chromium, I deleted the ~/snap dir, and
OK, I see. I had to *install* snapd, then I could snap remove chromium, and the other junk, and then purge snapd.
Thank you so much!
deb packages (Score:1)
Snap is evil (Score:1)
oh snap (Score:1)
sometimes an approach collectively by and for the idiots who didn't understand how everyone else had been getting by without it for the past 20 years is actually just as dumb as you would expect
Re:oh snap (Score:5, Insightful)
Exactly this. Just like docker devs who think a 500M binary makes sense. Why? Because they have no idea how to design libraries and stable APIs
Not surprised (Score:2)
Ubuntu became irrelevant when it adopted idiocies such as systemd and netplan, so I am not surprised.
Systemd (Score:3)
Once you accept that systemd is the right way to do anything you're going to eventually think that this is how software should be fed out to the users - by fiat from Central Control. Systemd is bad design; snap is bad design. Both have the same virtue of making life easier for someone other than you. Fuck 'em.
Now if only Ubuntu would dump Snap (Score:2)
The complete snap ecosystem is a disaster. Want to get rid of apparmour? Say goodbye to all of your snaps. Want to install the latest version of something? Good luck finding it first - a reasonable person (e.g. not a snap developer) would expect the channel hierarchy to flow naturally: Edge over Beta over Candidate over Stable in terms of maturity and versioning. Yet often there are newer versions on stable than edge and the edge or beta versions just aren't updated, or removed, so you end up with ancient v
Snap has always been fuuuuucked up (Score:2)
My first interaction with snap is discovering that using snap-installed apps to access anything on an NFS mount is effing impossible, because something called apparmor (WTF is that anyway) keeps it from happening. The workaround for it is to disable snap for any app that you need to actually work on something mounted in your filesystem. Over time, I keep finding more apps that fail that way and require snap to be disabled. I'd turn it off completely if I could.
Re: (Score:2)
I ran into snap problems because my employer doesn't have /home/user they have /home/corp.com/user and that stopped Slack and other shitty snap containers from working.
Re: Snap has always been fuuuuucked up (Score:2)
Snap provides app isolation.
I don't where people ever got the idea you want apps isolated from one another. You want well-defined boundaries, not isolation.
I remember this Git GUI client that couldn't access my SSH key because it was a Snap. That might sound like a security boon except the workaround is the app asks me to load my key into the app. Now I have to trust the app not only with using my key safely, but with storing it safely. I uninstalled the app.
Someone wrote about this 3yrs ago (Score:2)
I'm glad to see distros agree.
https://medium.com/@acam/im-afraid-for-the-future-of-ubuntu-2f41796073b2#.vj8eh3abb
LMDE...it's the way forward (Score:2)
i hope Mint, after 20.04 leaves the ubuntu base and goes full LMDE...
https://www.linuxmint.com/down... [linuxmint.com]
Re: (Score:1)
you troll
Re: (Score:2, Informative)
The servers running the internet are Linux/BSD. Even Azure now offers Linux because otherwise they can't compete with AWS. Phones are end users devices, not infrastructure devices. The failure of Linux phones or IOT devices is irrelevant.
Perhaps you would be better off spending online time over here [fandom.com].
Re: It's like saying "We're not gonna use systemd" (Score:2)
There is almost no value in a universal package manager.
Or, to put it another way, there is already a universal package manager that has worked fine for a generation: tgz+Make.
Re: (Score:2)
Why does it seem like Linux is repeating what happened with Windows? Practically everything these days uses the built-in Windows Installer; different installers really just provide different front ends on the system installer, with the main differences being whether or how much you pay for them, and how well they integrate with your IDE. The days of actual different installers kind of ended after Windows 98. So Linux is regressing to those bad old days when there was no simple way to install/uninstall thing
Re: It's like saying "We're not gonna use systemd (Score:2)
Developers don't like learning things that are more than a decade old. You have to keep re-tooling so they can feel like they're on the cutting edge re-solving all the problems of yesteryear poorly.