2 more bits of info:

1- In Brazil (for example) there are non-explicitly metered (contractually speaking) home internet connections. I'm not sure how the heuristic works in these cases. It would be bad, of couse, if it does not work. Nowadays, when passing the limit, they slow down the connection (a lot) until the end of the month; but the internet providers are trying to charge in the future.

2- In Brazil (for example) there are still slow home internet connections (1Mbps, 2Mbps). I think the heuristic avoid downloading updates while internet is in use. Again, it would be bad user experience if it does not work.

2016-10-29 22:26 GMT-02:00 Adam Williamson <adamwill@fedoraproject.org>:
Hi folks!

I kinda hate kicking off discussions like this without having a solid
solution to propose or being able to promise to work on one, but this
really seems important. Unfortunately I can't claim I'm gonna have time
to do any concrete work on it, though I'd really *like* to. But I
thought it would be worthwhile to kick around still; perhaps someone
else will be inspired.

I just read Hedayat's review of Fedora 25 Beta:
https://hedayatvk.wordpress.com/2016/10/30/fedora-25-beta
and this really jumped out at me:

"And, if you care about your internet usage, make sure that you disable
both dnf makecache timer, and stop PackageKit from downloading updates
automatically. I don’t allow a new Fedora installation to access
internet before doing these, as it might just eat a considerable amount
of data."

There's two things I think are somewhat unfortunate here:

1) Both dnf and GNOME Software / PackageKit default to performing
fairly data-hungry transactions in the background, out of the box,
without telling you about it. GNOME's is particularly bad, as it will
happily download available updates in the background, which can be
gigabytes worth of data. DNF only updates its metadata caches (on a
systemd timer), but even that could be behaviour that users in certain
circumstances really really do not want.

2) There is no particularly obvious or visible mechanism for a 'typical
user' (or, if you prefer, many of the target 'personas' for our
flavors) to configure this behaviour...and you have to figure out two
completely *different* configuration mechanisms in order to shut off
both.

I think this is kind of poor behaviour on our part and we should make
it better. Do I have a specific concrete proposal? No. But I do have
some vague ideas.

* We could have some kind of configuration interface appear on install
/ first boot. This would require integration with anaconda and/or
initial-setup and gnome-initial-setup.

* We could invert the defaults and have the apps ask the user if they
want to enable data-hungry background operations on first interaction:
the first time you use dnf (without -y) it could say 'hey, do you want
to turn on background cache refreshes?' Similarly, the first time you
run GNOME Software or click on an update notification, it could say
'hey, do you want to turn on background update downloads'?

* We could at least make both of them respect one single config setting
for 'do data hungry background operations' (this is kinda one small
part of the bigger issue that is 'dnf and PK-based stuff don't share
any configuration aside from repo definitions').

Anyone have thoughts on this? Any DNF or Software devs want to say I'm
totally wrong and an idiot? Anyone inspired to do something more
concrete than a mailing list post? :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
desktop mailing list -- desktop@lists.fedoraproject.org
To unsubscribe send an email to desktop-leave@lists.fedoraproject.org