Hi, Can someone tell me if the following errors were because of a network hiccup (there was no visual indication from F41 that the wifi network had disconnected and reconnected) or whether it was because of some other reason? Running the command dnf check-upgrade again indicated there was nothing to do.
Docker CE Stable - x86_64 ???% | 0.0 B/s | 0.0 B | 00m00s
Curl error (6): Could not resolve hostname for
https://download.docker.com/linux/fedora/41/x86_64/stable/repodata/repomd.xm... [Could not resolve host: download.docker.com] - https://d
Curl error (6): Could not resolve hostname for
https://download.docker.com/linux/fedora/41/x86_64/stable/repodata/repomd.xm... [Could not resolve host: download.docker.com] - https://d
Curl error (6): Could not resolve hostname for
https://download.docker.com/linux/fedora/41/x86_64/stable/repodata/repomd.xm... [Could not resolve host: download.docker.com] - https://d
Curl error (6): Could not resolve hostname for
https://download.docker.com/linux/fedora/41/x86_64/stable/repodata/repomd.xm... [Could not resolve host: download.docker.com] - https://d
Librepo error: Cannot download repomd.xml: Cannot download
repodata/repomd.xml: All mirrors were tried Copr repo for neurofedora-extra owned by @neurofedora ???% | 0.0 B/s | 0.0 B | 00m00s
Curl error (6): Could not resolve hostname for
https://download.copr.fedorainfracloud.org/results/@neurofedora/neurofedora-... [Could not resol
Curl error (6): Could not resolve hostname for
https://download.copr.fedorainfracloud.org/results/@neurofedora/neurofedora-... [Could not resol
Curl error (6): Could not resolve hostname for
https://download.copr.fedorainfracloud.org/results/@neurofedora/neurofedora-... [Could not resol
Curl error (6): Could not resolve hostname for
https://download.copr.fedorainfracloud.org/results/@neurofedora/neurofedora-... [Could not resol
Librepo error: Cannot download repomd.xml: Cannot download
repodata/repomd.xml: All mirrors were tried RPM Sphere - Noarch ???% | 0.0 B/s | 0.0 B | 00m00s
Curl error (6): Could not resolve hostname for
https://github.com/rpmsphere/noarch/raw/master/repodata/repomd.xml [Could not resolve host: github.com] - https://github.com/rpmsphere/
Curl error (6): Could not resolve hostname for
https://github.com/rpmsphere/noarch/raw/master/repodata/repomd.xml [Could not resolve host: github.com] - https://github.com/rpmsphere/
Curl error (6): Could not resolve hostname for
https://github.com/rpmsphere/noarch/raw/master/repodata/repomd.xml [Could not resolve host: github.com] - https://github.com/rpmsphere/
Curl error (6): Could not resolve hostname for
https://github.com/rpmsphere/noarch/raw/master/repodata/repomd.xml [Could not resolve host: github.com] - https://github.com/rpmsphere/
Librepo error: Cannot download repomd.xml: Cannot download
repodata/repomd.xml: All mirrors were tried google-chrome ???% | 0.0 B/s | 0.0 B | 00m00s
Curl error (6): Could not resolve hostname for
https://dl.google.com/linux/chrome/rpm/stable/x86_64/repodata/repomd.xml [Could not resolve host: dl.google.com] - https://dl.google.co
Curl error (6): Could not resolve hostname for
https://dl.google.com/linux/chrome/rpm/stable/x86_64/repodata/repomd.xml [Could not resolve host: dl.google.com] - https://dl.google.co
Curl error (6): Could not resolve hostname for
https://dl.google.com/linux/chrome/rpm/stable/x86_64/repodata/repomd.xml [Could not resolve host: dl.google.com] - https://dl.google.co
Curl error (6): Could not resolve hostname for
https://dl.google.com/linux/chrome/rpm/stable/x86_64/repodata/repomd.xml [Could not resolve host: dl.google.com] - https://dl.google.co
Librepo error: Cannot download repomd.xml: Cannot download
repodata/repomd.xml: All mirrors were tried RPM Sphere - Basearch ???% | 0.0 B/s | 0.0 B | 00m00s
Curl error (6): Could not resolve hostname for
https://github.com/rpmsphere/x86_64/raw/master/repodata/repomd.xml [Could not resolve host: github.com] - https://github.com/rpmsphere/
Curl error (6): Could not resolve hostname for
https://github.com/rpmsphere/x86_64/raw/master/repodata/repomd.xml [Could not resolve host: github.com] - https://github.com/rpmsphere/
Curl error (6): Could not resolve hostname for
https://github.com/rpmsphere/x86_64/raw/master/repodata/repomd.xml [Could not resolve host: github.com] - https://github.com/rpmsphere/
Curl error (6): Could not resolve hostname for
https://github.com/rpmsphere/x86_64/raw/master/repodata/repomd.xml [Could not resolve host: github.com] - https://github.com/rpmsphere/
Librepo error: Cannot download repomd.xml: Cannot download
repodata/repomd.xml: All mirrors were tried Fedora 41 - x86_64 - Updates ???% | 0.0 B/s | 0.0 B | 00m00s
Curl error (6): Could not resolve hostname for
https://mirrors.fedoraproject.org/metalink?repo=updates-released-f41&arc... [Could not resolve host: mirrors.fedoraproject.org] -
Curl error (6): Could not resolve hostname for
https://mirrors.fedoraproject.org/metalink?repo=updates-released-f41&arc... [Could not resolve host: mirrors.fedoraproject.org] -
Curl error (6): Could not resolve hostname for
https://mirrors.fedoraproject.org/metalink?repo=updates-released-f41&arc... [Could not resolve host: mirrors.fedoraproject.org] -
Curl error (6): Could not resolve hostname for
https://mirrors.fedoraproject.org/metalink?repo=updates-released-f41&arc... [Could not resolve host: mirrors.fedoraproject.org] -
Curl error (6): Could not resolve hostname for
https://mirrors.fedoraproject.org/metalink?repo=updates-released-f41&arc... [Could not resolve host: mirrors.fedoraproject.org] -
Curl error (6): Could not resolve hostname for
https://mirrors.fedoraproject.org/metalink?repo=updates-released-f41&arc... [Could not resolve host: mirrors.fedoraproject.org] -
Curl error (6): Could not resolve hostname for
https://mirrors.fedoraproject.org/metalink?repo=updates-released-f41&arc... [Could not resolve host: mirrors.fedoraproject.org] -
Curl error (6): Could not resolve hostname for
https://mirrors.fedoraproject.org/metalink?repo=updates-released-f41&arc... [Could not resolve host: mirrors.fedoraproject.org] -
Curl error (6): Could not resolve hostname for
https://mirrors.fedoraproject.org/metalink?repo=updates-released-f41&arc... [Could not resolve host: mirrors.fedoraproject.org] -
Curl error (6): Could not resolve hostname for
https://mirrors.fedoraproject.org/metalink?repo=updates-released-f41&arc... [Could not resolve host: mirrors.fedoraproject.org] -
Curl error (6): Could not resolve hostname for
https://mirrors.fedoraproject.org/metalink?repo=updates-released-f41&arc... [Could not resolve host: mirrors.fedoraproject.org] -
Curl error (6): Could not resolve hostname for
https://mirrors.fedoraproject.org/metalink?repo=updates-released-f41&arc... [Could not resolve host: mirrors.fedoraproject.org] -
Librepo error: Cannot prepare internal mirrorlist: Curl error (6):
Could not resolve hostname for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f41&arc... [Co Failed to download metadata (metalink: "https://mirrors.fedoraproject.org/metalink?repo=updates-released-f41&arc...") for repository "updates" Librepo error: Cannot prepare internal mirrorlist: Curl error (6): Could not resolve hostname for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f41&arc... [Could not resolve host: mirrors.fedoraproject.org]
regards, Steve
On 22/11/24 13:55, Jonathan Billings wrote:
On Nov 21, 2024, at 16:06, Stephen Morris steve.morris.au@gmail.com wrote:
Can someone tell me if the following errors were because of a network hiccup (there was no visual indication from F41 that the wifi network had disconnected and reconnected) or whether it was because of some other reason? Running the command dnf check-upgrade again indicated there was nothing to do.
Docker CE Stable - x86_64 ???% | 0.0 B/s | 0.0 B | 00m00s
Curl error (6): Could not resolve hostname for
https://download.docker.com/linux/fedora/41/x86_64/stable/repodata/repomd.xm... [Could not resolve host: download.docker.com] - https://d [ SNIP]
My hunch is that it couldn’t resolve the host name for the repo.
But seriously, was there something about these errors or other effects that made you think it was something other than DNS being broken?
I would have thought that if my wifi connection had been temporarily disconnected, hence the data couldn't be retrieved, I would have gotten popups from fedora around the disconnect/reconnect. I would have also thought that if it was a broken DNS the reissuing the dnf check-upgrade would have repeated the messages. With the reissuing of the command not producing any messages about refreshing the repositories in question and saying there were updates to put on, it had refreshed the repositories even though it got the error, and there were actually no updates?
regards, Steve
-- Jonathan Billings
Jonathan Billings:
But seriously, was there something about these errors or other effects that made you think it was something other than DNS being broken?
Stephen Morris:
I would have thought that if my wifi connection had been temporarily disconnected, hence the data couldn't be retrieved, I would have gotten popups from fedora around the disconnect/reconnect.
You could get unable to resolve hostnames due to a networking problem with your system, your router, your ISP, the route to the host, the host itself...
But the messages showing that various different domain names couldn't be resolved virtually discounts its being the end host (unless they all happened to be on the same server, but I seriously doubt that).
There's every chance you struck a moment while your ISP was fiddling with things, or something failed there.
I would have also thought that if it was a broken DNS the reissuing the dnf check-upgrade would have repeated the messages.
I don't see anything regarding that in your log (you mentioned it, but didn't show any logs).
With the reissuing of the command not producing any messages about refreshing the repositories in question and saying there were updates to put on, it had refreshed the repositories even though it got the error, and there were actually no updates?
We can only guess that cached results were used.
Unfortunately you haven't shown us anything else to diagnose the problem. Such as using the dig tool on those and other addresses. The output of ifconfig, or other commands, showing the network parameters. Was there a gateway, a DNS server, did you get a real IP address? Nor did you tell us whether anything else was working at the same time (web browsing, etc).
On 23/11/24 16:36, Tim wrote:
Jonathan Billings:
But seriously, was there something about these errors or other effects that made you think it was something other than DNS being broken?
Stephen Morris:
I would have thought that if my wifi connection had been temporarily disconnected, hence the data couldn't be retrieved, I would have gotten popups from fedora around the disconnect/reconnect.
You could get unable to resolve hostnames due to a networking problem with your system, your router, your ISP, the route to the host, the host itself...
But the messages showing that various different domain names couldn't be resolved virtually discounts its being the end host (unless they all happened to be on the same server, but I seriously doubt that).
There's every chance you struck a moment while your ISP was fiddling with things, or something failed there.
I would have also thought that if it was a broken DNS the reissuing the dnf check-upgrade would have repeated the messages.
I don't see anything regarding that in your log (you mentioned it, but didn't show any logs).
With the reissuing of the command not producing any messages about refreshing the repositories in question and saying there were updates to put on, it had refreshed the repositories even though it got the error, and there were actually no updates?
We can only guess that cached results were used.
Unfortunately you haven't shown us anything else to diagnose the problem. Such as using the dig tool on those and other addresses. The output of ifconfig, or other commands, showing the network parameters. Was there a gateway, a DNS server, did you get a real IP address? Nor did you tell us whether anything else was working at the same time (web browsing, etc).
In the past when I have lost internet access because my wifi disconnected from the router and reconnected, I get a popup message from Fedora that the wifi disconnected followed immediately by a popup message saying it had reconnected. That didn't happen in this case. If there was upstream interference preventing the refreshing of the indicated repositories then I would have expected the reissue of the command to refresh those repositories which it didn't, unless dnf had marked them as refreshed even though they weren't. I also thought I didn't need to show the messages "Updating and loading repositories" and "Repositories loaded" with nothing in between to show that the messages are produced even if there is nothing to do. I'll know better next time. By default Fedora is configured to get DNS servers from DHCP, which I haven't changed, and DHCP is configured in my router to get those addresses from my ISP, with my router as the gateway. It is possible my router/modem were playing up, as afterwards I was having issues with maintaining internet connections in Windows while playing a steam game, which restarting the modem and router rectified. But if the repositories in question were not actually refreshed as the error messages were indicating, why did a reissue of the command not refresh them, had DNF invalidly marked them as refreshed when they actually weren't, or were the error messages bogus, or did DNF retry after producing the messages and not told us it had successfully refreshed the repositories?
regards, Steve
On Sun, 2024-11-24 at 10:21 +1100, Stephen Morris wrote:
In the past when I have lost internet access because my wifi disconnected from the router and reconnected, I get a popup message from Fedora that the wifi disconnected followed immediately by a popup message saying it had reconnected. That didn't happen in this case.
If you lose connection to your WiFi router, your computer will try and reconnect, and can give you notifications about it.
If your computer didn't lose connection, but the router stopped routing, or something in front of it did, you won't get disconnection notices from the computer (because the "connection" between it and the router never changed). You may get offline notices from software that cannot connect to a server, and you may get reconnection notices from them, too.
In the past when I have lost internet access because my wifi disconnected from the router and reconnected, I get a popup message from Fedora that the wifi disconnected followed immediately by a popup message saying it had reconnected. That didn't happen in this case.
More info is certainly better. If you have *working* stuff in the middle of non-working things, it gives more info about where the fault may lay.
It is possible my router/modem were playing up, as afterwards I was having issues with maintaining internet connections in Windows while playing a steam game, which restarting the modem and router rectified.
That's a very significant bit of information.
Things do glitch, routers are no exception. A reboot is sometimes necessary. Also, they can get software updates over the net which can make them sluggish until its all over and done with (either self- updating, or pushed updates on ISP-supplied routers).
It's important to note that a router has a finite number of connections it can manage, and processing power available for its tiny operating system. If you have some software that's gone mad making hundreds of connections, and not dropping them, the router can stop working. If it gets bombarded by a flurry of external activity it can get overwhelmed. If you have dozens of things on your network, PCs, laptops, phones, tablets, WiFi controlled light fightings, etc., you can exceed its capacity to handle that (or handle that well). I've had routers that struggle to operate its in-built web server based configuration controller.
There's also outside interference. Cluttered WiFi broadcasts by your neighbours on the same channel can bog things down. And I had an ADSL router get continously knocked off by the switch mode power supply connected to a portable hard drive. Every couple of seconds the radiated hash would kill the routers attempts to communicate. It was so bad it didn't matter where in the house it was plugged in, the computer didn't even have to be connected to the network. The moment the drive was plugged in, even if the computer was off, its radiated hash got into the house earth wiring, which transmitted it to the phone cable going around the house.
But if the repositories in question were not actually refreshed as the error messages were indicating, why did a reissue of the command not refresh them, had DNF invalidly marked them as refreshed when they actually weren't, or were the error messages bogus, or did DNF retry after producing the messages and not told us it had successfully refreshed the repositories?
I'll have to let someone else answer that specifically, but in general:
On the net lots of things used cached data (browsers, domain name lookups, lots more). The next time you attempt to access the same data it will/can
* Look at its cached data, see if it's still supposed to be valid (according to meta data expiry dates and its own settings about cache expiry), and use it. * Reach out to the remote end and see if its expired and should be refreshed. It may still do this, even if its already cached data is considered still in date. * Try or not try to refresh it. * Use the cached data if that's fine, use the cached data if it's unable to refresh it and isn't too stale (according to various metadata), or abort if it considers it's too stale.
Going on past experience, if I have done a "dnf update", then did another one within a certain time period no attempt was made to see if data needed refreshing. That time period could be longer than you'd expect it.
Some people get into a bad habit of doing a "clean all" before updating, which increases the workload and traffic of the repo servers. There are more nuanced controls for cleaning *some* of the local data, but it shouldn't be necessary, it should be automatic. And if your local data is being continually mangled, you have other problems you should be solving.
On 24/11/24 15:11, Tim wrote:
Going on past experience, if I have done a "dnf update", then did another one within a certain time period no attempt was made to see if data needed refreshing. That time period could be longer than you'd expect it.
I've been in the situation where running a dnf check-upgrade has refreshed the two Fedora Updates repositories and then issued dnf upgrade immediately after and had it refresh the two updates repositories again. I've been told from this mail list that for the Updates repositories that is normal as they are being updated all the time.
regards, Steve
On 24 Nov 2024, at 21:54, Stephen Morris steve.morris.au@gmail.com wrote:
I've been in the situation where running a dnf check-upgrade has refreshed the two Fedora Updates repositories and then issued dnf upgrade immediately after and had it refresh the two updates repositories again. I've been told from this mail list that for the Updates repositories that is normal as they are being updated all the time.
Did you do both dnf commands with sudo?
If dnf check-update was not run under sudo then the metadata is saved somewhere is you user’s $HOME. Then when you run sudo dnf update it will not have access to the user’s copy of the meta data.
Barry
On Sun, 24 Nov 2024 at 23:13, Barry barry@barrys-emacs.org wrote:
On 24 Nov 2024, at 21:54, Stephen Morris steve.morris.au@gmail.com
wrote:
I've been in the situation where running a dnf check-upgrade has
refreshed the two Fedora Updates repositories and then issued dnf upgrade immediately after and had it refresh the two updates repositories again. I've been told from this mail list that for the Updates repositories that is normal as they are being updated all the time.
Did you do both dnf commands with sudo?
If dnf check-update was not run under sudo then the metadata is saved somewhere is you user’s $HOME. Then when you run sudo dnf update it will not have access to the user’s copy of the meta data.
And, just for the record because I still had the Vagrant box running:
[vagrant@localhost ~]$ id uid=1000(vagrant) gid=1000(vagrant) groups=1000(vagrant) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [vagrant@localhost ~]$ dnf check-upgrade > /dev/null 2>&1 [vagrant@localhost ~]$ find . -mmin -1 . ./.local/state/dnf5.log ./.cache ./.cache/libdnf5 ./.cache/libdnf5/updates-e19adde8fd271134 ./.cache/libdnf5/updates-e19adde8fd271134/repodata ./.cache/libdnf5/updates-e19adde8fd271134/repodata/repomd.xml ./.cache/libdnf5/updates-e19adde8fd271134/repodata/010f603e88da3adf72fbdc14876833963399f814ce1795698cffa6d529bf9cc8-primary.xml.zck ./.cache/libdnf5/updates-e19adde8fd271134/repodata/c885cb31c9bc9b0f810cbffcefca8d74d49ae5b34e7a5d89fa64b618379e123b-comps-Everything.x86_64.xml.zst ./.cache/libdnf5/updates-e19adde8fd271134/repodata/493151ccb8d844a2243c7940877cfe990b00784d3d1b51a45048f9d24652be0f-updateinfo.xml.zck ./.cache/libdnf5/updates-e19adde8fd271134/solv ./.cache/libdnf5/updates-e19adde8fd271134/solv/updates-updateinfo.solvx ./.cache/libdnf5/updates-e19adde8fd271134/solv/updates-group.solvx ./.cache/libdnf5/updates-e19adde8fd271134/solv/updates.solv ./.cache/libdnf5/fedora-7efbab3c1dbcd0d4 ./.cache/libdnf5/fedora-7efbab3c1dbcd0d4/repodata ./.cache/libdnf5/fedora-7efbab3c1dbcd0d4/repodata/repomd.xml ./.cache/libdnf5/fedora-7efbab3c1dbcd0d4/repodata/3973367e3877b70900ae12d5074f025c99015ab5bc829d2cfbf6fa5d7a0cd0e2-primary.xml.zck ./.cache/libdnf5/fedora-7efbab3c1dbcd0d4/repodata/e0139f84a99188422fc0b0ce898b3eea06ee4b9702158c5a24adc70047c5a760-comps-Everything.x86_64.xml.gz ./.cache/libdnf5/fedora-7efbab3c1dbcd0d4/solv ./.cache/libdnf5/fedora-7efbab3c1dbcd0d4/solv/fedora-group.solvx ./.cache/libdnf5/fedora-7efbab3c1dbcd0d4/solv/fedora.solv ./.cache/libdnf5/fedora-cisco-openh264-1e5e9f1be3093a1f ./.cache/libdnf5/fedora-cisco-openh264-1e5e9f1be3093a1f/repodata ./.cache/libdnf5/fedora-cisco-openh264-1e5e9f1be3093a1f/repodata/repomd.xml ./.cache/libdnf5/fedora-cisco-openh264-1e5e9f1be3093a1f/repodata/a15963f895f0869850dc7805b79794c1913c9492d24214d2712a21ae3c97f578-primary.xml.gz ./.cache/libdnf5/fedora-cisco-openh264-1e5e9f1be3093a1f/repodata/3d50825fb25440abc9579f078205d6ba3590b1d146187af8179eb43214c8b40e-comps-Temporary.x86_64.xml.gz ./.cache/libdnf5/fedora-cisco-openh264-1e5e9f1be3093a1f/solv ./.cache/libdnf5/fedora-cisco-openh264-1e5e9f1be3093a1f/solv/fedora-cisco-openh264-group.solvx ./.cache/libdnf5/fedora-cisco-openh264-1e5e9f1be3093a1f/solv/fedora-cisco-openh264.solv
The root-owned cache files are in /var/cache/libdnf5/ from man 8 dnf5
FILES Cache Files /var/cache/libdnf5/
On 25/11/24 10:13, Barry wrote:
On 24 Nov 2024, at 21:54, Stephen Morrissteve.morris.au@gmail.com wrote:
I've been in the situation where running a dnf check-upgrade has refreshed the two Fedora Updates repositories and then issued dnf upgrade immediately after and had it refresh the two updates repositories again. I've been told from this mail list that for the Updates repositories that is normal as they are being updated all the time.
Did you do both dnf commands with sudo?
If dnf check-update was not run under sudo then the metadata is saved somewhere is you user’s $HOME. Then when you run sudo dnf update it will not have access to the user’s copy of the meta data.
Yes, I believe they were both issued under sudo, but I'll double check that next time.
regards, Steve
Barry
On 25/11/24 10:30, Will McDonald wrote:
And, just for the record because I still had the Vagrant box running:
[vagrant@localhost ~]$ id uid=1000(vagrant) gid=1000(vagrant) groups=1000(vagrant) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [vagrant@localhost ~]$ dnf check-upgrade > /dev/null 2>&1 [vagrant@localhost ~]$ find . -mmin -1 . ./.local/state/dnf5.log ./.cache ./.cache/libdnf5
Thanks Will, I wasn't aware that dnf did things that way. I'm only encountering these situations now because I've only just started using the check-upgrade command with dnf.
regards, Steve
On Sun, Nov 24, 2024 at 12:12 AM Tim via users < users@lists.fedoraproject.org> wrote:
On Sun, 2024-11-24 at 10:21 +1100, Stephen Morris wrote:
It is possible my router/modem were playing up, as afterwards I was having issues with maintaining internet connections in Windows while playing a steam game, which restarting the modem and router rectified.
That's a very significant bit of information.
Things do glitch, routers are no exception. A reboot is sometimes necessary. Also, they can get software updates over the net which can make them sluggish until its all over and done with (either self- updating, or pushed updates on ISP-supplied routers).
It's important to note that a router has a finite number of connections it can manage, and processing power available for its tiny operating system. If you have some software that's gone mad making hundreds of connections, and not dropping them, the router can stop working.
I use NoScript, which provides a list of mostly 3rd party sites used by a site I visit. These lists have been growing over time, it is not unusual to have dozens of external sites requested by a site I visit.
Tim:
It's important to note that a router has a finite number of connections it can manage, and processing power available for its tiny operating system. If you have some software that's gone mad making hundreds of connections, and not dropping them, the router can stop working.
George N. White III:
I use NoScript, which provides a list of mostly 3rd party sites used by a site I visit. These lists have been growing over time, it is not unusual to have dozens of external sites requested by a site I visit.
Likewise. It's ridiculous the conglomeration of crap scripts people add to web pages, often because they can't actually create code themselves. It's a security risk for both sides, because any of those scripts could change at any moment. And when you're in a country with slow internet it really drags things down (having a 50 Mb/s local connection means very little when nearly everything goes through much slower overseas links).
The other thing I'd noticed back when I had a very dynamic IP (on an ISP with incredibly short lease time, so that you could disconnect and reconnect and get a new IP to try and duck some traffic problems), was that if you acquired the IP from someone who'd been torrenting, or filesharing, that you'd get bombarded with gazillion connection requests for a very long time. That really upset my ADSL modem.
On 27 Nov 2024, at 01:36, Tim via users users@lists.fedoraproject.org wrote:
It's ridiculous the conglomeration of crap scripts people add to web pages, often because they can't actually create code themselves.
It is also often tracker scripts from data-brokers. If you watch the inspection tools network panel in your browser you get to see what is being loaded. Also notice that accesses never stop for some pages as tracking of dwell time is done.
Barry
-
Barry -
George N. White III -
Jonathan Billings -
Stephen Morris -
Tim -
Will McDonald