Linux Mint pushes out its own Chromium build to help users avoid Canonical's Snap Store
- Reference: 1604338212
- News link: https://www.theregister.co.uk/2020/11/02/linux_mint_chromium_build/
- Source link:
"The Chromium browser is now available for both Linux Mint and LMDE," [1]said Mint maintainer Clement Lefebvre, noting that the build process for the application and new package is a lengthy one "which can require more than six hours per build on a fast computer."
[2]
Linux Mint now has its own Chromium build
The team has allocated a new build server which brings the time down to just over an hour, and has automated the detection of a new version of Chromium and rebuilding the package. Chromium is also packaged for Debian but "was rarely up to date," said Lefebvre.
[3]
'Official build for Linux Mint'
The big deal here is that Canonical [4]said in October 2019 that Chromium, the open-source browser which shares code with Google Chrome, would transition to be packaged solely as a snap, meaning a package designed for the Snap Store, managed by Canonical.
The company said at the time that "maintaining a single release of Chromium is a significant time investment for the Ubuntu Desktop," especially as Google rolls out a new version every six weeks, with security releases in between.
'This was bigger than GNOME and bigger than just this case.' GNOME Foundation exec director talks patent trolls and much, much more [5]READ MORE
Linux Mint is based on Ubuntu (though there is also a Debian version, LMDE, and an Xfce variant, featuring the lightweight Xfce desktop). Snaps have advantages over traditional .deb packages, being somewhat isolated and enabling one package to target multiple distros.
The Mint team, though, were not happy that Canonical controls the distribution of snaps, and were also [6]miffed that Ubuntu used a dummy Chromium package which was "acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store."
[7]
The official Google Chrome is also available as a .deb package but is not open source and comes with baggage of its own
Google does offer its Chrome browser as a .deb package, but Chrome is not open source, making Chromium a more attractive proposition for Linux users.
The new Mint-built Chromium shows that the team is serious about enabling its users to manage without the Snap store, though as a user commented, the problem could recur with other packages. "Can I very politely bring up the other SNAP cornering? FWUPD requires SNAP," said a user, referring to an open-source tool for managing firmware updates.
The notion of building applications into containerised packages is not going away. "The effort that is going into having application developers be able to target a single runtime or that works across distributions, I think is absolutely fantastic, and it's something that's been missing for many many years on Linux systems," said Gnome Foundation executive director Neil McGovern, [8]speaking to The Register recently, though he expressed similar misgivings to those of Lefebvre, saying: "I do have a concern that the Snap Store is entirely gated by Canonical."
Lefebvre also introduced a prototype IPTV player called Hypnotix, which is in early Alpha, a new Favourites feature in the file browser and file selection dialog – reminiscent of a similar Quick Access feature in Windows Explorer. ®
Get our [9]Tech Resources
[1] https://blog.linuxmint.com/?p=3978
[2] https://regmedia.co.uk/2020/11/02/mint-chromium.jpg
[3] https://regmedia.co.uk/2020/11/02/chromium.png
[4] https://snapcraft.io/blog/chromium-in-ubuntu-deb-to-snap-transition
[5] https://www.theregister.com/2020/10/23/this_was_bigger_then_gnome/
[6] https://www.theregister.com/2020/06/02/linux_mint_team_snap/
[7] https://regmedia.co.uk/2020/11/02/chrome-linux.png
[8] https://www.theregister.com/2020/10/23/this_was_bigger_then_gnome/
[9] https://whitepapers.theregister.com/
Re: I guess, but why?
This is about Chromium, not Chrome
Snaps R Us
I tried to enjoy Ubuntu 20.04, I really did, but Snaps are an awful experience as an end user, so I tried Fedora and am now happy.
I suspect I'm not the only one.
Re: Snaps R Us
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.
Re: Snaps R Us
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.
@Paul Kinsler - Re: Snaps R Us
Think long term. Who is benefiting and how. Look at systemd for an example.
No.
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.
Re: No.
It’s simply the pursuit of money - Canonical, IBM (Red Hat), etc. This is why the commons can’t have nice things when somebody can make a quid by obfuscation and complication...
They missed the obvious.
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.
Re: They missed the obvious.
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.
Re: They missed the obvious.
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!
Re: They missed the obvious.
"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 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.