As part of the ongoing work to reduce authentication fatigue, the elementary OS team are going over everything with a fine-tooth comb to ensure asking for admin / root permission makes sense.
One idea they came up with, which appears to be integrated into elementary OS 5.1.5 'Hera', is the removal of needing to enter the admin password when you're doing updates with the AppCenter. The question is why? As they explained, you already gave your full permission to install the applications originally and that they "provide clear expectations around curated versus non-curated apps" so they felt it didn't make sense to authenticate again just to do updates.
I like the idea and hope it doesn't somehow backfire. Authentication fatigue can be a very real thing. It's the same as the cookie banners a lot of websites have because of all their external stuff loading in, I imagine clicking them away without even looking is now what the majority do because it's constantly there.
Another really nice change is how images are copied in their file manager. Copying an image in Files and then pasting into a program like an image editor, will now actually paste the image in (if possible) and not a file path. That's quite a handy accessibility update and one I love the sound of. On top of that their file manager will also now show a file info overlay while in the list view which is a nice tweak.
elementary OS has the kind of attention to the finer details that I wished every Linux distribution had.
If you're interested in what else the crew have been up to, check out their latest update post. For more info on elementary OS check the official site. They go for a pay what you want method for downloading their ISO, you can support them with as much or as little as you like (even zero), it's certainly a different way to support a Linux distribution but it appears to work well for them.
Article taken from GamingOnLinux.com.
wvstolzing Jun 6, 2020
Quoting: scaineI paste this into /etc/sudoers on every single install I do.
# Allows certain command to run without a password
scaine ALL=(root) NOPASSWD: /usr/bin/apt update
scaine ALL=(root) NOPASSWD: /usr/bin/apt dist-upgrade
scaine ALL=(root) NOPASSWD: /usr/bin/apt auto-remove
scaine ALL=(root) NOPASSWD: /usr/bin/purge-old-kernels
Although since I've moved to Mint, I find the GUI for updates is pretty good, so I don't do my command-line maintenance anywhere near as much.
I do the same. It's also possible to group the listed binaries under command aliases, which — IMHO — makes the sudoers file a little tidier; e.g.
Cmnd_Alias SOFTWARE = /usr/bin/dnf upgrade, /usr/bin/rpm
Cmnd_Alias SOMETHINGELSE = /usr/bin/somethingelse& then, for the actual permissions:
%wheel ALL=(ALL) NOPASSWD: SOFTWARE, SOMETHINGELSE
Quoting: randylIt's just a hunch and opinion based on the goals immutable images are supposed to accomplish. I believe the idea is to improve core OS stability, reliability, and upgrade management while keeping customization to container based environments in userland. It should offer more consistent and focused OS development and maintenance. I don't think the traditional approach will go away, but rather mainstream distros will move to something like this. The idea behind this tech makes a lot of sense to me, but I also think it has a long way to go before it's mature and ready for mass consumption.I agree with you again @randyl ;)
The new ideas behind Silverblue, and more specifically behind the ostree and flatpak techs, are really interesting. At its core, it comes from git's tech: one sha = one specific commit, and you can transparently switch between commits any time you want.
The result, with ostree, is that it is very difficult to break your system (like a standard repo upgrade could do.. nvidia drivers anyone?
). You upgrade your system in the background, reboot, if it works, you're good, if it doesn't work, you simply get back to your previous "commit" with just one command line, and you fixed your problem. Just need to wait for a fix upstream. Think of these "commits" as snapshots.As for Flatpak, the interesting part is that Flatpak packages still shares packages together. And if one is depending on a package at version 1.1, and the other is depending on version 1.2, the packages are simply pointing to different "commits". So, compared to a more regular upgrade system, you can't have the upgrade of one package breaking the upgrade of a second package because the new version of one of the dependencies is actually incompatible with the second package for whatever reason.
And, also, Flatpak packages are jailed, which procures a bit more security overall.
As @randyl said, all these techs are still quite young compared to traditional package systems, but they are really interesting. I don't use Silverblue, but I do use Flatpak a lot ;)
Last edited by Creak on 6 June 2020 at 5:37 pm UTC
Patreon
PayPal
See more from me