Running nyx just shows some of the circuits (guard, middle, exit) but I seem to have no way of associating those circuits with fetchmail’s traffic. Anyone know how to track which exit node is used for various sessions?

In nyx, on the first page, press e and enable STREAM events. These have the following form:

[stream id] [status] [circuit id] [hostname/ip]:[port] ...

Find the correct stream based on hostname/ip, then you can cross-reference the [circuit id] with the items on the Connections page.

It's the Schmidtstedter Knoten in Erfurt.

This element is never generated as a candidate in the picker, probably a quirk of this specific site. I just looked at the DOM and saw this related element next to the dark mode button.

Edit i2psnark.upbw.max in i2psnark.config (this can be in a number of locations based on install type and platform - just search for it).

Or you can remove the maxlength and size attributes from the text input, it will save just fine.

https://linux-tc-notes.sourceforge.net/tc/doc/cls_u32.txt:

The base operation of the u32 filter is actually very simple. It extracts a bit field from a 32 bit word in the packet, and if it is equal to a value supplied by you it has a match. The 32 bit word must lie at a 32 bit boundary.

Try removing all the superfluous default routes.

The ecology supports it then. S. variegatus would have been found near pine.

It is T. porrifolius

Have you tried running tcpdump / wireshark on another device in the network when this happened?

I'm not on NixOS, but I have a decent working knowledge of Tor.

Not quite clear on what you're trying to do, are you trying to run a relay, or just connecting to the Tor network and pointing your browser to the socks proxy?

Arti (the official Tor implementation in Rust) is not a complete replacement for the Tor C implementation yet. Hidden service support is disabled by default (due to the lack of a security feature that could allow guard discovery attacks), and bridges don't work either. If you don't understand Tor very well stick with the old router.

I occasionally experience the same thing. When this happens, it appears the jwt token is not sent with the initial request (thus appearing to be logged out), but it is sent with api requests on the same page (unread_count, list, etc.), so the cookie is not lost (document.cookie also shows it). Sometimes refreshing again fixes it, but I haven't yet found a good workaround. I'll experiment a bit next time it happens.

The bot missed the remaining 7 pages and the result of the benchmark:

"Overall it comes down to what workloads you are engaged in whether you may notice any performance difference when upgrading your Linux kernel (or otherwise being patched for Inception on your given OS) on an AMD Zen desktop or server. For the most part users are unlikely to notice anything drastic, aside from some sizable database performance hits in a few cases. It's unfortunate seeing some of these regressions due to the Inception mitigation but ultimately is unlikely to really change the competitive standing of AMD's latest wares on Linux. Most of the prior AMD CPU security mitigations have also not resulted in any performance degradation, so this Inception mitigation difference is a bit rare. It also was announced on the same day as Intel Downfall where there was again a sizable hit to Intel CPU performance."