On Wed, 1 Jul 2020 at 07:19, Zbigniew Jędrzejewski-Szmek
> Yeah. I have no doubt that the decision was made carefully back then.
> That said, time has passed, and btrfs has evolved and our use cases
> have evolved too, so a fresh look is good.
> We have
> maybe this could be used to collect some statistics about the fs type
I am going to try and nix this one in the bud right here. DNF counting
is NOT the place to do this.
Starting to collect such information is a slippery slope and the more
you collect the harder it is to remove personal identifiable data. If
this sort of data is going to be collected it needs to be done by a
specific program that does this, which can be audited, which can be
deleted, and which can be 'cleaned' to meet GDPR and other rules. The
DNF counting works because all it does is give a 'better guess' on
what is going on by randomly burping a countme over a week (if countme
is turned on). The data it collects in the end is not absolute but
fuzzy.. it is just supposedly better a better fuzzy than the previous
The other information gathered in that transaction is stuff that
already has a business need to work.. our servers need to know what
architecture, what release and what ip to send data the appropriate
mirrorlist back to.. we also need to keep a log of the transaction to
debug why XYZ proxy decided to send the wrong thing or some other
Mirrormanager does not have a need to know what filesystem you are
using, it does not need to know what exact CPU, memory amount, or a
bunch of other things which would be useful for the project. Even
something like the packages you have installed which is sort of
closely aligned with a business need that other distros do collect, it
does not collect and adding it now would be a headache.
If the project wants this, then someone needs to make a smolt
replacement but with some people who truly understand privacy
programming well enough to not end up with a landmine field.
Stephen J Smoogen.