On 6/21/21 4:52 PM, Chris Murphy wrote:
> PackageKit and dnf keep separate metadata in /var/cache and they
> update periodically. PackageKit seems to do this on login, but I've
> also noticed it trigger an update when I switch networks. And dnf is
> on a timer. Either of them can use a lot of cpu, it just depends on
> how much updating they need.
Well, this raises the question of just whether packagekit is something
everyone needs in the first place. I manage my systems with dnf and
have never once opened the Gnome software manager thingie. Googling
around, I find:
https://blogs.gnome.org/hughsie/2019/02/14/packagekit-is-dead-long-live-well-something-else/
What's the benefit of letting packagekit chew up CPU here, even if I
implement the limits Chris suggests?
Many of the younger linux users I encounter came to linux from Windows because
a mission critical application requires linux. Some have only used the command line
after Google told them to run "sudo <some_application_giving_access_denied>" resulting
in a badly broken system with some user files owned by root or data saved in root's
home directory. Ask for a directory listing and you get a file manager image. For this
group, dnf is not an option. The Gnome software manager has the added advantages
that it a) forces a reboot and b) offers flatpak versions of major applications. Because
I work with this class of users, I try to stick with Gnome's GUI software manager, but
I'm not always patient enough to let it grind away for long periods.
Before I retired my work included running afternoon practicals for 2-week workshops.
Earlier workshops used systems set up in advance, but users struggled to get the
software working when they returned to their home labs. The first two afternoons were
devoted to linux command-line basics and applying those to install and configure the
software on user's laptops. Unfortunately, such workshops can only reach a small number
of users. There are online courses with similar content, but dropout rates are high, probably
related to users struggling with the command-line. For in-person workshops we handled some
problematic procedures using one-on-one instruction, then having the first learners become
teachers for the remaining students. I think there is work underway to develop remote
learning environments that have provisions for teaching assistant office hours and breakouts
into small groups.