I guess, but why?
Chrome anything as turned into one serious resource hog with VERY limited blocking abilities.
So why would anyone want this? Besides being stupid.
The Linux Mint team has arranged to provide its own Chromium package to users who were previously pointed towards Canonical's Snap Store if they wanted to get the popular browser. "The Chromium browser is now available for both Linux Mint and LMDE," said Mint maintainer Clement Lefebvre, noting that the build process for the …
Actually, I'm a projectionist, and your 5 pound wouldn't buy a large popcorn and a Diet Coke.
If you actually read what you quoted, you'd see that Google TAKE Chromium and use it to make Chrome. That does not mean they're the same thing. Mac OS X uses BSD as a starting point, but that doesn't make it the same as OpenBSD, does it?
Snaps are an awful experience as an end user
The problem seems to be that there's an extremely poorly documented set of magic incantations that are necessary if the default installation doesn't align with your use case (connecting "interfaces") and the scope of the incantations grows ever wider as the need to give supposedly-isolated packages access to system resources becomes more apparent.
Plus, of course, we have the Unix approach of letting a thousand flowers bloom, which means it will be some time before the various flavours of containerisation converge on a common set of well-known principles.
I think snaps are fine - and perhaps even rather helpful - if you have to run off-piste software programs that are very picky about which library versions they deign to compile/work with; especially if you have two or more such programs, and they happen to disagree about Qt, or java, or some such thing. But I don't see how chromium fits that category, so forcing all "standard" chromium use into a snap is not, in my opinion, either necessary or polite.
I'm puzzled. I've had Chromium for ages on Linux Mint, via the Software Manager GUI. It's not the snap version. I use it just for a particular logged in Google service. I use Waterfox with uMatrix and Classic Theme Restorer, Classic Repository and Cookie Swap plug-ins for everyday use.
I also get regular updates of Chromium and Waterfox and Firefox via the Update Manager.
It does seem that with Snap, systemd, Wayland and other projects that certain members of the Linux community are making a grab at emulating Microsoft and becoming the gatekeeper and controller of the Linux ecosystem.
A certain authoritarian streak is becoming apparent in the attitudes of Canonical, Red Hat and Gnome amongst others in that choice is being restricted and a path laid down that users must follow. Now I don't know if this is due to an overweening sense of superiority, plain unadulterated arrogance or simply the pursuit of money but whatever it is it does not sit well with me.
I started using Linux in 1997, trying to get away from the smothering sensation I felt when I was forced to use Microsoft's offerings. Yes, I had to use them at work but at home I was glad to get away from the dirigiste attitude of MS and set up a system that suited the way I wanted to work and not be forced to toe the MS line.
Now it seems as if certain companies want to take control of my boxes and tell me how things will be. Luckily I have no need to use their products nor do I wish to. Instead this being Linux I do have a choice but what worries me is for how long.
We need to be on our toes and stop the 90s coming back to haunt us.
Of course we can, intellectual commons is unlimited in area. When the businessmen, architecture astronauts* and other control freaks have pissed in the pool (again) we, regretfully, move on. It's extra effort of course, but the option is always there.
* Yeah them, you know who.
Hmm, maybe Joel's follow up article would have been a better choice.
The first article:
I tried to coin a term for the kind of people who invented Hailstorm: architecture astronauts. “That’s one sure tip-off to the fact that you’re being assaulted by an Architecture Astronaut: the incredible amount of bombast; the heroic, utopian grandiloquence; the boastfulness; the complete lack of reality. And people buy it! The business press goes wild!”
Mr. Spolsky illuminated Boris Johnson 11 years before the latter got in !
Snap and Flatpak exist to fix a long standing issue of compatibility when application developers want to ship code independently of a distribution (which should be most/all developers). What is scary is that distro developers seem to have forgotten what Shared Object files are for and are insisting on creating stable ABIs for long-term compatibility by abusing the kernel namespacing features as part of the solution for both Snap and Flatpak.
All Canonical, Red Hat and other prominent players really have to do, is huddle together to make one unified base system with common binaries and a focus on full ABI/API compatibility, just like FreeBSD, Solaris, macOS and Windows all have. There is no reason that can't include old and new major versions of key libraries (GTK+, GTK2, GTK3, Qt2, Qt3, Qt4, X11, glibc) and no reason why one can't include the very newest versions of simple command line tools. Maintaining one common base makes long term maintenance trivial.
Instead, Flatpak and Snap developers seem hellbent on making independent ABIs for peeople to target, independent of the distribution and then applying sandboxes to the result. This means configuration choices aren't globally respected and everything ends up a mess when it comes to shared plugins (e.g. gstreamer, mesa etc.). It also means backwards compatibility is a mess to maintain. For example: gtk-gnutella still uses GTK+ (as in GTK 1.2). What's worse, shipping GTK1 with every damn app or shipping one copy? It's still unmaintained and insecure either way, so why does it matter? Just ship it in the base system, it won't break ABI if nobody is touching it!
On Windows, people duplicate Qt and other open source libraries when they ship software. This does suck because it creates a maintenance headache for system administrators when developers neglect to keep their frameworks up to date. However, the core Windows runtimes are all centralised. To ensure backwards compatibility, WinSxS acts as a means of allowing new and old DLL versions to co-exist, while the latest version will be loaded in by default, unless a specific application needs a legacy version for any given reason. In general, this approach means no containers, no namespacing and up to 25 years of application binary backwards compatibility.
Unlike with Microsoft Windows, the Linux community can actually afford to fix the backwards compatibility gap right now. All they have to do is stop making tons of separate distributions and make one solid base system to work from. A base which includes all the old libraries that aren't maintained any more.
As an end user I don't want applications distributed "independently of a distribution". I want them integrated into my distribution's package management, and using the system wide libraries that are updated properly. Bundling apps as "snaps" or "flatpaks" is the kind of brain-dead crap that exists in the Windows world, where applications bundle third party DLLs that then go unpatched for security or stability issues.
Indeed. One man's browser is another's poison. It would be good if every Linux distro GUI installation had a 'choose your browser' question from the top six available (with I'll install my own option). Save having Linux Mint and RapberryPi foundation as two examples struggling to make Chromium sensibly usable when there are very fine alternatives available. Death to the default browser!
The latest version of Linux Mint 20 comes with Firefox pre-loaded and with the Canadian English language pack installed by default. Setting the spell checking to English UK doesn't work despite it having that language installed too. Tried uninstalling Firefox to do a clean re-install but it made Cinnamon unstable and it kept crashing.
I ended up reformatting the hard drive and reinstalling Linux Mint 20 again yesterday and I'm back to square one with Firefox ignoring the spell checking language and using Canadian again.
I don't claim to understand the ins and outs of snap vs other strategies, but something is definitely screwed up in Linux Mint 20 regarding Firefox.
"where applications bundle third party DLLs that then go unpatched for security or stability issues."
Yes, this! Once you start compiling ion static libraries, everyone has to play ball when a vuln shows up in one of those multiple copies and they all need patching instead of just the one dynamically linked library.
Admittedly I'm probably spoiled by FreeBSD and it's ports/packages systems and a unified kernel/userland which rarely have the dependency hell the Linuxes used to suffer from, and still do in some respects.
I don't want them distributed independently either. Except when I do, because the distro's package is broken, obsolete or some similar reason. Various development frameworks and minor applications have fallen foul of this over the years. In one memorable case I now run the Windows version of a little utility under WINE because it relies on (IIRC) a no-longer-shipped Qt version and has never been updated. The Windows version ships with all the necessary old DLLs or whatever and more or less just works.
That said, web browsers are hardly edge-case, seldom-used niche applications.
Part of the time the package demands as a minimum version x.y.z of some library when it's quite possible an older one would suffice. I've seen this a few times where some application wouldn't build because of such a dependency and then discovered a pre-built version that worked fine.
It seems that in the rush to devise proprietary nostrums an existing approach has been forgotten: install the application in /opt where it can sit with its own collection of libraries.
As I said, I am worried how things will turn out with Linux if things go on as they are.
I have been thinking about BSD. Having tried them in the past I have been wary of switching as I have not found the experience all that I might wish. One candidate that has caught my eye is Dragonfly BSD. Now my server wrangling days are over, thank goodness, I don't need a server OS and as far as I can see Dragonfly is more desktop oriented so it may suit me.
But, changing all my systems over to a BSD one is not something I look forward to and for the moment I will stick to PCLinuxOS which is, thankfully, a thriving distro with an attitude and methods that suit the way I think,
It's nice to have a plan B though so I might try out Dragonfly in VM and see how it goes.
I tried that and found it a world of paper cuts. At least for my use cases. A shame, but there it is.
What are your plans for when the x.org abandonware has bitrotted beyond use? After all, Wayland is explicitly Linux only.
I am pretty sure that by the time x.org has left us, Wayland will be replaced with something different anyway. Hopefully it will be less Linux-centric.
That said, I know FreeBSD has Wayland and even its own compositor (called Hikari). So I don't think Wayland is particularly non-portable.
Myself, I think XWayland ontop of Wayland is fairly nice. For me a network aware display system is a requirement so thankfully this exists for now. Once Wayland matures it might even get this kind of stuff built in to its protocol.
Moving to a Wayland + XWayland model seems to have a couple of nice advantages: you get the networking for the apps that can do that, and the X part doesn't have to concern itself with actually driving displays, which is the part that has been described "abandonware".
That model clearly leaves the option open for _other_ network-aware protocols to slot in beside XWayland at the same time. I used to have a soft-spot for Display Postscript, and might even still have the manual somewhere. Or perhaps QNX Photon, or Plan9's 9P?