Linux Mint Introduces Its Own Take On the Chromium Web Browser (zdnet.com) 33
Mint's programmers, led by lead developer, Clement "Clem" Lefebvre, have built their own take on Google's open-source Chromium web browser. ZDNet reports: Some of you may be saying, "Wait, haven't they offered Chromium for years? Well, yes, and no. For years, Mint used Ubuntu's Chromium build. But then Canonical, Ubuntu's parent company, moved from releasing Chromium as an APT-compatible DEB package to a Snap. The Ubuntu Snap software packing system, along with its rivals Flatpak and AppImage, is a new, container-oriented way of installing Linux applications. The older way of installing Linux apps, such as DEB and RPM package management systems for the Debian and Red Hat Linux families, incorporate the source code and hard-coded paths for each program.
While tried and true, these traditional packages are troublesome for developers. They require programmers to hand-craft Linux programs to work with each specific distro and its various releases. They must ensure that each program has access to specific libraries' versions. That's a lot of work and painful programming, which led to the process being given the name: Dependency hell. Snap avoids this problem by incorporating the application and its libraries into a single package. It's then installed and mounted on a SquashFS virtual file system. When you run a Snap, you're running it inside a secured container of its own. For Chromium, in particular, Canonical felt using Snaps was the best way to handle this program. [...]
Lefebvre wrote, "The Chromium browser is now available in the official repositories for both Linux Mint and LMDE. If you've been waiting for this I'd like to thank you for your patience." Part of the reason was, well, Canonical was right. Building Chromium from source code is one really slow process. He explained, "To guarantee reactivity and timely updates we had to automate the process of detecting, packaging and compiling new versions of Chromium. This is an application which can require more than 6 hours per build on a fast computer. We allocated a new build server with high specifications (Ryzen 9 3900, 128GB RAM, NMVe) and reduced the time it took to build Chromium to a little more than an hour." That's a lot of power! Still, for those who love it, up-to-date builds of Chromium are now available for Mint users.
While tried and true, these traditional packages are troublesome for developers. They require programmers to hand-craft Linux programs to work with each specific distro and its various releases. They must ensure that each program has access to specific libraries' versions. That's a lot of work and painful programming, which led to the process being given the name: Dependency hell. Snap avoids this problem by incorporating the application and its libraries into a single package. It's then installed and mounted on a SquashFS virtual file system. When you run a Snap, you're running it inside a secured container of its own. For Chromium, in particular, Canonical felt using Snaps was the best way to handle this program. [...]
Lefebvre wrote, "The Chromium browser is now available in the official repositories for both Linux Mint and LMDE. If you've been waiting for this I'd like to thank you for your patience." Part of the reason was, well, Canonical was right. Building Chromium from source code is one really slow process. He explained, "To guarantee reactivity and timely updates we had to automate the process of detecting, packaging and compiling new versions of Chromium. This is an application which can require more than 6 hours per build on a fast computer. We allocated a new build server with high specifications (Ryzen 9 3900, 128GB RAM, NMVe) and reduced the time it took to build Chromium to a little more than an hour." That's a lot of power! Still, for those who love it, up-to-date builds of Chromium are now available for Mint users.
poor lazy dee-veh-lupperz (Score:1)
Re: (Score:3)
Re: (Score:2)
Due to this snap stupidity, I had to create my own script to replace "df" (which I generally use instead of fdisk -l for a quick overview of storage space):
With it being so easy to create "magic" file systems in Linux, I can't see why they don't make one single mounted file system that hosts all the snaps as subdirectories instead of polluting the pool of mount points.
Re: (Score:2)
Re: (Score:2)
Due to this snap stupidity, I had to create my own script to replace "df" (which I generally use instead of fdisk -l for a quick overview of storage space):
With it being so easy to create "magic" file systems in Linux, I can't see why they don't make one single mounted file system that hosts all the snaps as subdirectories instead of polluting the pool of mount points.
How about: df --si "$@" | egrep -v "/snap|tmpfs|udev"|sort -h -k 2
But snaps are so fetch! (Score:1)
Re: (Score:2)
They require the programmer to comply with standards and take a traditional Unix style approach, rather than a Windows style "
Re: (Score:2)
Mine is still on Xubuntu because (sigh) I need MS Teams and VMware View for work.
Re: (Score:2)
Re: poor lazy dee-veh-lupperz (Score:2)
Source code? (Score:3)
Only if you install a source rpm, which most people don't do.
Re: (Score:1)
Only if you install a source rpm, which most people don't do.
The point is that it is available for installation, should the user want to, and that is corresponds precisely to the executable package when (re)compiled.
Whether most people decide to install it or not is immaterial. That it is available for those who wish to do so, is the point.
Went out of my way to install Chromium deb via apt (Score:3)
The first thing I did when I installed Ubuntu 20.04 was to try to figure out a way to install Chromium without resorting to a snap. I mean if I type 'apt install chromium' that means I want it installed as a normal debian package, not a snap. After all that's what I mean by typing that command! Fortunately I can get it from Debian upstream without any problems.
I understand the appeal of snaps and flatpaks, and they come in handy for some things. But I have never found the integration (using Mate Desktop here) to work that well. And the isolation becomes bothersome. I realize that of all applications, a browser probably is the biggest security risk, and thus any kind of containerization is probably a good thing, but I just prefer it to update with apt like every other system package. Only occasionally do I get things in snaps or flatpaks, such as when a version of a program I need now requires more recent versions than found in my long-term support distro. For example QGIS on CentOS 7.
Re:Went out of my way to install Chromium deb via (Score:4, Informative)
You're not the only one. Instructions here:
https://askubuntu.com/question... [askubuntu.com]
Ya know... source tarballs are not easy, but (Score:2)
They made it VERY clear when devs were using bleeding edge, not ready for prime time stuff.
snaps, flatpacks etc are as, TFA says, to make things easier for the devs. Not the owners/users of the systems.
Re: Ya know... source tarballs are not easy, but (Score:2)
Classic case of the tail wagging the dog. Making life easier should always be a secondary consideration
Re: (Score:2)
ya think?
Good For Them, Though Still In a Container? (Score:3)
Why use a container for every application? There is a point for scaling up instances of an application, but, in practical experience running multiple containers with each hosting a service eats resources. A desktop PC with a P5 + 16 GB RAM + SSD is now starved with five containers plus the stuff running on the host OS. Maybe the cause is part Win 10 + Docker, but, use a container when it makes sense, or does it make sense for a web browser?
I have not looked at Chromium, and have only used Google's Chrome when needed because someone else made their webpage/app work only on Chrome. +25M lines of code for Chromium!? Is Chromium its own OS hosted in an application? I went down that hole after reading this paragraph from the article, 6 hours to build?
"To guarantee reactivity and timely updates we had to automate the process of detecting, packaging and compiling new versions of Chromium. This is an application which can require more than 6 hours per build on a fast computer. We allocated a new build server with high specifications (Ryzen 9 3900, 128GB RAM, NMVe) and reduced the time it took to build Chromium to a little more than an hour."
Re: (Score:2)
Yes, the web is just an OS for running javascript.
Troublesome for developers? (Score:2)
While tried and true, these traditional packages are troublesome for developers
In the past, programs were written to be helpful to users. Now they are written to be easier to develop for developers, at the cost of user's convenience.
Browser Security - Snaps may be good (Score:2)
containers (Score:1)
Re: (Score:2)
Marty! You need to think with containers!
Learn from the WhatWG and Electron: Each tool must come with its own libraries, OSv*and* VM.
And be sure to store each single bit in a separate AVX512 register. As a UTF-8 string in a variant data type with metadata. Expressed in XML!
DLL hell? (Score:2)
I haven't really kept up with the installation discussions, but: who remembers "DLL hell" on Windows, when every program came packaged with it's specific dependencies? You wound up with zillions of copies of the same library - in various versions - hanging around your system, and often multiple copies loaded into memory. Sure, it was easier for individual developers to deliver their applications, but it was not so great for the system owners.
Aren't Snaps doing the same thing? Why are we not going to regret
Re: (Score:2)
Re: DLL hell? (Score:2)
Only 20 years or so...
Re: (Score:2)
That depends largely on what build environments the application developers use. Some apps don't have problems, others are a nightmare. Snaps don't really fix that problem. It's just another part of the "build environment" issue that adds even more complexity and unpredictability, and ultimately becomes the end user's problem whether they like it or not.
"DLL Hell" is a thing all OSes have to deal with in one way or another. As usual, the Linux attitude towards this is, "it's just not a problem because we
Dependency hell = clueless. (Score:2)
That's why package managers can install multiple versions of the same library in parallel .
The problem has been solved or more than a decade!
Of course prinitive systems and clueless maintainers and idiot developers who think Linux is just another Windows would never know that, nor know to care.
Containers have nothing to do with the ideas of Unix. They are the exact opposite. And merely bad Windows ideas in disguise. They are only solutions to problems stemming from other bad ideas that should not exist in t
Is this about chromium or snaps? (Score:4, Funny)
Reads like an attempt to make snaps sound good. But sure lets just completely undo the library (er I mean dll) system, I mean we should have a copy of every library compiled once for each program, err I mean app (don't want to confuse those millennials). We have plenty of hdd (er I mean ssd) space for all of that now, right?
Re: (Score:2)
Not defending Snap because I don't know enough about that implementation, but generally speaking self-contained and isolated apps are a good thing.
Shared DLLs made a lot of sense when memory and storage were limited. Now we can trade a little of those for easier management and better security.
Being self contained means no dumping files all over the filesystem during install, plus easy uninstall and easy updating. Also fixed DLL Hell and related issues. You can easily run multiple versions side-by-side, or i
snaps just suck (Score:4, Informative)
When Ubuntu packaged chromium as a snap that's when we started to move away from Ubuntu. While I understand the appeal from a developer perspective they're a poor substitute for the real thing. The use of snaps is a classic example of cost shifting in a manner which costs significantly more, snaps load more slowly, use more memory and have lower performance. This penalty is paid by every user and the build savings are incurred by only a few. Snaps create security problems as the developer can include unpatched or backdoored code, they increase the size of downloads with very few advantages in return. We currently use a secure linux desktop at work however that is changing to centos and snaps were one of the drivers for this change. Basically centos sucks less in this instance. I would have liked to use debian however the ease of integration of freeipa on centos8 was another driver. For example a snap can use a compromised encryption library when the main instance is functional.
Is my Mint Chrome the only one locking up? (Score:2)
I run a bog-standard Linux Mint 18 workstation, got the long-term distro some years back, it's been just fine. But lately, one desktop lockup after another. I SSH in an kill processes, including all of Chromium, but it rarely unlocks; I generally reboot.
It happened more and more often, finally daily, and I nailed it down to Chrome - and not even some special web page with odd javascript, or anything, it would lock up in Gmail. So would "Vivaldi" a project using a Chromium base. I've simply switched t