Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)O
Posts
0
Comments
71
Joined
3 yr. ago

  • This also explains why VPN is a possible workaround to this issue.

    Your VPN will encapsulate any packets that your phone will send out inside a new packet (its contents encrypted), and this new packet is the one actually being sent out to the internet. What TTL does this new packet have? You guessed it, 64. From the ISP's perspective, this packet is no different than any other packets sent directly from your phone.

    BUT, not all phones will pass tethered packets to the VPN client -- they directly send those out to the internet. Mine does this! In this case, TTL-based tracking will still work. And some phones seem to have other methods to inform the ISP that the data is tethered, in which case the VPN workaround may possibly fail.

  • Not sure if it's still the case today, but back then cellular ISPs could tell you are tethering by looking at the TTL (time to live) value of your packets.

    Basically, a packet starts with a TTL of 64 usually. After each hop (e.g. from your phone to the ISP's devices) the TTL is decremented, becoming 63, then 62, and so on. The main purpose of TTL is to prevent packets from lingering in the network forever, by dropping the packet if its TTL reaches zero. Most packets reach their destinations within 20 hops anyway, so a TTL of 64 is plenty enough.

    Back to the topic. What happens when the ISP receives a packet with a TTL value less than expected, like 61 instead of 62? It realizes that your packet must have gone through an additional hop, for example when it hopped from your laptop onto your phone, hence the data must be tethered.

  • If I remember right, the syncing issue was particularly egregious when you run windowed X11 programs on Wayland. So it could be that you got lucky.

  • It's the explicit sync protocol.

    The TL;DR is basically: everyone else has supported implicit sync for ages, but Nvidia doesn't. So now everyone is designing an explicit sync Wayland protocol to accommodate for this issue.

  • You need to enable DRM KMS on Nvidia.

  • Mine is simply default KDE. The only visible thing I've changed is the wallpaper -- changes to my desktop mostly concentrate on the "invisible" ones like shortcut keys or setting changes or scripting.

  • It's just a notable milestone. For as long as I can remember Linux marketshare never went above the 3.something% mark.

  • Desktop? I settled on Arch and Fedora.

    Server? Debian. Although technically I never distrohopped on servers, been using Debian since the beginning of time.

  • It's not a fork of wlroots. wlroots is a library to assist developers in creating Wayland compositors.

  • This is probably family dependent. My family is similar to OP's, we usually text if we want to have casual conversations. Voice calls are limited to serious topics only... unless I text them "hey, let's have a call" or something like that first.

  • IPv4 version: Think of your public IP:Port as the office building, your internal IP:Port as the floor number, and reverse proxy as the reception on that floor.

    (Your public IP:Port is routed to your internal IP:Port by the NAT on your router. The router knows which public port relates to which internal IP:Port due to the port forwarding rules you setup.)

    IPv6 version: Think of your public IP:Port as the office, and the reverse proxy as the reception.

    The following will be common to both IP protocols.

    The port is usually 80 or 443, because reverse proxy is used for HTTP(S) connections, and by default those connections use the aforementioned ports.

    When someone connects to your IP:Port, they ask the reverse proxy "hey, can you bring me to Mr. https://my-awesome-plex.xyz/ ?" and the reverse proxy will act as a middleman between that someone and the actual server that is serving that domain name.

    The reverse proxy, as a middleman, forwards your requests to the server, and the server's response is forwarded back to you by the reverse proxy too.

    And just to make things complete... Why do we use reverse proxies?

    1. To hide the identity of the actual server. This is easy to understand - you are only ever talking to the proxy, never the actual server. It's just that your messages are continually forwarded to the actual server.
    2. To save IP addresses. (One public address can serve multiple websites, if the actual servers are given only private IP addresses.)
    3. To load balance. The reverse proxy can direct one to another server if the first server is overloaded. This requires a website to be served by more than one server though, and selfhosters like us never really need it.
    4. To prevent attacks. If the reverse proxy realises that someone has been making too many connections to https://my-awesome-nas.com/, the reverse proxy can reject subsequent connections. This is how Cloudflare works.
    5. Caching. If the middleman remembers that the server responded "what is the answer to everything" with "42", then the next time someone asks the same question again, the middleman will simply reply with the same response. This takes off the workload on the server.