I have two main reasons I don't use it.
I prefer a well tested, stable OS that doesn't change when I run daily/weekly updates
I disagree with their update policy about holding back security fixes and new versions of certain packages
Specifically, Mint Updater doesn't display updates for packages they consider "unsafe" to update. The rules file lists these:
dbus||4|| *xorg||4|| acpid||4|| mountall||4|| mesa||4|| systemd||4|| plymouth||4|| upstart||4|| base-files||5|| linux-||5|| linux||5|| grub||5|| grub2|*|5||
As security fixes come out for the Linux kernel, systemd, xorg, etc. they don't get applied. You can turn back on the unsafe packages in the settings, but since they're targeting the less savvy user, most likely they won't know about the policy or the settings to change it.
To be fair, most home users are behind a firewall, so it's not a critical issue, but it's not infeasible that a user could get compromised on a public WiFi network, or as part of an attack against something that is public facing like a web browser.
If they changed this policy, I personally still might not use it, but I would have no issues recommending it to others because of how much work Mint puts into making the OS functional right after install.
I wonder if all Mint apologizers knows how their update classification mechanism work....
I've used to be neutral about this matter but one day I made the mistake of looking at the source code that classifies when an update is safe and what not.
if is_a_mint_package: level = 1 # Level 1 by default else: level = 3 # Level 3 by default rulesFile = open("/usr/lib/linuxmint/mintUpdate/rules","r")
banshee||2|| firefox||2|| thunderbird||2|| *language-pack||2|| flashplugin||2|| wine||2|| pidgin||2|| *libreoffice||2|| chromium-browser||2|| transmission||2|| shotwell||2|| shutter||2|| evince||2|| gnome-calculator||2|| gthumb||2|| dbus||4|| xorg||4|| acpid||4|| mountall||4|| mesa||4|| systemd||4|| plymouth||4|| upstart||4|| base-files||5|| linux-||5|| linux||5|| grub||5|| grub2||5|| virtualbox|5.0.4-dfsg-2|5||This version is built against the LTS Vivid Xorg/MESA stack. Upgrading it removes virtualbox-guest-x11. Reinstalling the package breaks Xorg. bcmwl||3|| ubuntu-drivers-common||4|| *nvidia||4||
There many web browsers/mail clients out there in Ubuntu repo.... Why only Firefox and Thunderbird are prioritized?
>Mint is a good one to start with.
Mint is literally just Ubuntu with even worse security and a developer that doesn't know what they're doing.
If you care about security at all, you shouldn't use Mint.
>“This is the list of packages it will never update, instead of just integrating changes properly with the packages in the ubuntu archive they instead suppress doing (security) updates at all for them.”
>“I would say forcefully keeping a vulnerable kernel browser or xorg in place instead of allowing the provided security updates to be installer makes it a vulnerable system, yes. I personally wouldn't do online banking with it
So a couple of technical reasons why I don't like Mint :
Mint updater : Cool idea, implemented poorly and with no thought to the Ubuntu update process. They use hardcoded regex's to hold back updates, instead of working within the ubuntu update process to file any regressions they find. See this . Also see this OMGUbuntu article about the issue.
Running programs as root without even asking for your permission : See this for what I'm talking about.
Shipping hardcoded configs via /etc/skel : This is so bad on multiple levels, boot up a Linux Mint KDE ISO and do a ls on /etc/skel/.kde and you'll see that they ship pre populated cache's and configs. Primarily this can cause fun issues like your sound card not working because the cache was created on a devs system who had a very very different sound card setup than yours probably.
As for your web dev stuff : It all comes down to what you're comfortable with. Want the latest bleeding edge stuff and can spend a couple of hours configuring your system just the way you want it? Arch's got your back. Want something rolling release but that's decently tested? Debian Sid should do the trick. Want some thing pre configured that works out of the box with regular release cycles? Pick one of Kubuntu/Debian/SUSE/Random Binary distribution. Basically, whatever works for you. At the end of the day what matters is getting your ~~shit~~ stuff done and what fits with your workflow.
Hands down for Linux Mint team to acknowledge and improve their update system.
> Replace update policies with a welcome screen. > >The introduction of system snapshots allows us to >recommend all updates without caution. > >The concept of regression is still important to explain >but the recommendation becomes completely different. > >Rather than to recommend caution (although that will >still be important when troubleshooting a regression), >we can recommend system snapshots. >The core concepts remain the same (stability-regression and >security/bug-fixes), but no longer have to be balanced against >one another. > >The message is much clearer to the user and doesn't lead to misinterpretation: > >- Set up snapshots >- Update everything
Looks like others have been experiencing high CPU utilization with checkapt.py, which seems to be a part of mintupdate:
https://github.com/linuxmint/mintupdate/issues/51
If you can't figure it out, perhaps you could disable automatic checking for updates in mintupdate, and do your updates manually.
When you click that option in the update manager, it starts this systemd weekly timer: https://github.com/linuxmint/mintupdate/blob/master/lib/systemd/system/mintupdate-automation-autoremove.timer
You can see what it's doing here: https://github.com/linuxmint/mintupdate/blob/master/usr/share/linuxmint/mintupdate/automation/autoremove.sh
Basically just this command, plus some safety stuff to stop the update manager from rebooting the system while it's running
/usr/bin/apt-get autoremove --purge -y
Fundamentally, a version update simply means updating your sources list and updating all packages on the system. This is well documented on ubuntu, so there's no need for mint to add more.
Plus, since mint is not server-focused, there's really no demand for properly documented command line tools. If you look into it more, mint's update commands are supported on the command line as rel_upgrade_root.py, but it's clearly not a tool designed for end users to use directly.
I don't see that option on Mint 20 and right click does nothing on the active kernel for me
Chances are it is an option stored in the binary gnome registry key/value store called dconf, accessible via gsettings command line
possibly (I am guessing blind here) under com.linuxmint.updates schema or something
you could try and check key values under there
> gsettings list-recursively com.linuxmint.updates
perhaps under blacklisted-packages key? guessing here
I also suggest/recommend opening an issue on this if there is not one already in https://github.com/linuxmint/mintupdate/issues
> You chose the policy at the beginning and it was pretty clear. They were not blocked. It was a user option.
"I would like no security updates please" is not an option you want to give users. The Ubuntu developers were entirely correct.
And when you have Mint developers defending the fact that Firefox shouldn't be updated on level 1 and 2, that's a really bad look. Of course, that issue was closed as "solved" when it wasn't solved. This is three years ago, not six years.
On the matter of CVEs: It links to this subforum: https://forums.linuxmint.com/viewforum.php?f=143
There are literally two CVEs over the span of two or three years. So few that they don't get their own section. Perhaps a medal for trying, but no.