Search
62 results for “AthanSpod”
-
Tapped into #EDDN (#EliteDangerous Data Network) yesterday with like 3 lines of code and got an endless data spill in return.
That is rather impressive: https://eddn.edcd.io/
Not that I have any particular use for this but I understand the work that went into the companion apps for Elite a lot better now.
o7 @AthanSpod 👏
-
Finally getting around to upgrading my home server from Debian bookworm (12/oldstable) to trixie (13/stable).
`apt upgrade --without-new-pkgs` went smoothly enough, just a few config files with local tweaks.
Currently wishing I had FTTP for the `apt full-upgrade` downloads. I'm "languishing on only 80Mbps FTTC".
I expect to have some issues to sort out once this bit is done, and I still need to re-activate/update my third-party repositories....
-
Finally getting around to upgrading my home server from Debian bookworm (12/oldstable) to trixie (13/stable).
`apt upgrade --without-new-pkgs` went smoothly enough, just a few config files with local tweaks.
Currently wishing I had FTTP for the `apt full-upgrade` downloads. I'm "languishing on only 80Mbps FTTC".
I expect to have some issues to sort out once this bit is done, and I still need to re-activate/update my third-party repositories....
-
Finally getting around to upgrading my home server from Debian bookworm (12/oldstable) to trixie (13/stable).
`apt upgrade --without-new-pkgs` went smoothly enough, just a few config files with local tweaks.
Currently wishing I had FTTP for the `apt full-upgrade` downloads. I'm "languishing on only 80Mbps FTTC".
I expect to have some issues to sort out once this bit is done, and I still need to re-activate/update my third-party repositories....
-
Finally getting around to upgrading my home server from Debian bookworm (12/oldstable) to trixie (13/stable).
`apt upgrade --without-new-pkgs` went smoothly enough, just a few config files with local tweaks.
Currently wishing I had FTTP for the `apt full-upgrade` downloads. I'm "languishing on only 80Mbps FTTC".
I expect to have some issues to sort out once this bit is done, and I still need to re-activate/update my third-party repositories....
-
Firstly, I am aware that sizing of women's clothing is at *least* this bad.
I've had two pairs of Keen "Men's Hiking Shoes", specifically their "Targhee" brand.
I bought the first pair in person, so fitted the size in person. Those claim "EU 44, US 10.5, UK 9.5, CM 28.5"
When those wore out I ordered a pair of the third version of that shoe in the same UK 9.5 size. After a week it was clear they were too big. My big toes were getting bruised.
So, I ordered a pair of UK 9 (and eventually gave the 9.5s away, as it seemed too much hassle to sort out a return, especially with having worn them a week of active use).
Those size 9 claim "EU 43, US 10, UK 9, CM 28", so shorter ? I've measured the internal length, toe-tip to heel, in both, and they both seem to be more or less just 28cm.
Now the sizing that Keen currently declares says of UK 9: US 10, EU 43, UK 9, CM 27", which seems like it would definitely be too small for me, right?
The chart is at https://cdn.shopify.com/s/files/1/0788/6815/2663/files/NEW_KEEN_SIZE_CHART.pdf?v=1763031527 , and as you can see, if I want "something 28cm long internally" I might need either the UK 10 ("CM 27.8") *or* the UK 10.5 or even 11 (CM 28.2 and 28.6).
How difficult is it to just have *consistent* sizing ? I already know their idea of UK 9.5 can sometimes be UK 9, or vice versa, so how can I trust the sizing at all, other than finding somewhere to buy in person ?
-
Firstly, I am aware that sizing of women's clothing is at *least* this bad.
I've had two pairs of Keen "Men's Hiking Shoes", specifically their "Targhee" brand.
I bought the first pair in person, so fitted the size in person. Those claim "EU 44, US 10.5, UK 9.5, CM 28.5"
When those wore out I ordered a pair of the third version of that shoe in the same UK 9.5 size. After a week it was clear they were too big. My big toes were getting bruised.
So, I ordered a pair of UK 9 (and eventually gave the 9.5s away, as it seemed too much hassle to sort out a return, especially with having worn them a week of active use).
Those size 9 claim "EU 43, US 10, UK 9, CM 28", so shorter ? I've measured the internal length, toe-tip to heel, in both, and they both seem to be more or less just 28cm.
Now the sizing that Keen currently declares says of UK 9: US 10, EU 43, UK 9, CM 27", which seems like it would definitely be too small for me, right?
The chart is at https://cdn.shopify.com/s/files/1/0788/6815/2663/files/NEW_KEEN_SIZE_CHART.pdf?v=1763031527 , and as you can see, if I want "something 28cm long internally" I might need either the UK 10 ("CM 27.8") *or* the UK 10.5 or even 11 (CM 28.2 and 28.6).
How difficult is it to just have *consistent* sizing ? I already know their idea of UK 9.5 can sometimes be UK 9, or vice versa, so how can I trust the sizing at all, other than finding somewhere to buy in person ?
-
Firstly, I am aware that sizing of women's clothing is at *least* this bad.
I've had two pairs of Keen "Men's Hiking Shoes", specifically their "Targhee" brand.
I bought the first pair in person, so fitted the size in person. Those claim "EU 44, US 10.5, UK 9.5, CM 28.5"
When those wore out I ordered a pair of the third version of that shoe in the same UK 9.5 size. After a week it was clear they were too big. My big toes were getting bruised.
So, I ordered a pair of UK 9 (and eventually gave the 9.5s away, as it seemed too much hassle to sort out a return, especially with having worn them a week of active use).
Those size 9 claim "EU 43, US 10, UK 9, CM 28", so shorter ? I've measured the internal length, toe-tip to heel, in both, and they both seem to be more or less just 28cm.
Now the sizing that Keen currently declares says of UK 9: US 10, EU 43, UK 9, CM 27", which seems like it would definitely be too small for me, right?
The chart is at https://cdn.shopify.com/s/files/1/0788/6815/2663/files/NEW_KEEN_SIZE_CHART.pdf?v=1763031527 , and as you can see, if I want "something 28cm long internally" I might need either the UK 10 ("CM 27.8") *or* the UK 10.5 or even 11 (CM 28.2 and 28.6).
How difficult is it to just have *consistent* sizing ? I already know their idea of UK 9.5 can sometimes be UK 9, or vice versa, so how can I trust the sizing at all, other than finding somewhere to buy in person ?
-
Firstly, I am aware that sizing of women's clothing is at *least* this bad.
I've had two pairs of Keen "Men's Hiking Shoes", specifically their "Targhee" brand.
I bought the first pair in person, so fitted the size in person. Those claim "EU 44, US 10.5, UK 9.5, CM 28.5"
When those wore out I ordered a pair of the third version of that shoe in the same UK 9.5 size. After a week it was clear they were too big. My big toes were getting bruised.
So, I ordered a pair of UK 9 (and eventually gave the 9.5s away, as it seemed too much hassle to sort out a return, especially with having worn them a week of active use).
Those size 9 claim "EU 43, US 10, UK 9, CM 28", so shorter ? I've measured the internal length, toe-tip to heel, in both, and they both seem to be more or less just 28cm.
Now the sizing that Keen currently declares says of UK 9: US 10, EU 43, UK 9, CM 27", which seems like it would definitely be too small for me, right?
The chart is at https://cdn.shopify.com/s/files/1/0788/6815/2663/files/NEW_KEEN_SIZE_CHART.pdf?v=1763031527 , and as you can see, if I want "something 28cm long internally" I might need either the UK 10 ("CM 27.8") *or* the UK 10.5 or even 11 (CM 28.2 and 28.6).
How difficult is it to just have *consistent* sizing ? I already know their idea of UK 9.5 can sometimes be UK 9, or vice versa, so how can I trust the sizing at all, other than finding somewhere to buy in person ?
-
Firstly, I am aware that sizing of women's clothing is at *least* this bad.
I've had two pairs of Keen "Men's Hiking Shoes", specifically their "Targhee" brand.
I bought the first pair in person, so fitted the size in person. Those claim "EU 44, US 10.5, UK 9.5, CM 28.5"
When those wore out I ordered a pair of the third version of that shoe in the same UK 9.5 size. After a week it was clear they were too big. My big toes were getting bruised.
So, I ordered a pair of UK 9 (and eventually gave the 9.5s away, as it seemed too much hassle to sort out a return, especially with having worn them a week of active use).
Those size 9 claim "EU 43, US 10, UK 9, CM 28", so shorter ? I've measured the internal length, toe-tip to heel, in both, and they both seem to be more or less just 28cm.
Now the sizing that Keen currently declares says of UK 9: US 10, EU 43, UK 9, CM 27", which seems like it would definitely be too small for me, right?
The chart is at https://cdn.shopify.com/s/files/1/0788/6815/2663/files/NEW_KEEN_SIZE_CHART.pdf?v=1763031527 , and as you can see, if I want "something 28cm long internally" I might need either the UK 10 ("CM 27.8") *or* the UK 10.5 or even 11 (CM 28.2 and 28.6).
How difficult is it to just have *consistent* sizing ? I already know their idea of UK 9.5 can sometimes be UK 9, or vice versa, so how can I trust the sizing at all, other than finding somewhere to buy in person ?
-
FWIW I just used https://calculator-apps.com/networking-calculators/mtu-mss-calculator to calculate 'proper' MTU/MSS values for my ip(6)tables rules.
Being paranoid about TCP Timestamps and SACK that's 1420 and 1440. I've set those and will need to remember to check if I see any weird issues....
-
FWIW I just used https://calculator-apps.com/networking-calculators/mtu-mss-calculator to calculate 'proper' MTU/MSS values for my ip(6)tables rules.
Being paranoid about TCP Timestamps and SACK that's 1420 and 1440. I've set those and will need to remember to check if I see any weird issues....
-
FWIW I just used https://calculator-apps.com/networking-calculators/mtu-mss-calculator to calculate 'proper' MTU/MSS values for my ip(6)tables rules.
Being paranoid about TCP Timestamps and SACK that's 1420 and 1440. I've set those and will need to remember to check if I see any weird issues....
-
FWIW I just used https://calculator-apps.com/networking-calculators/mtu-mss-calculator to calculate 'proper' MTU/MSS values for my ip(6)tables rules.
Being paranoid about TCP Timestamps and SACK that's 1420 and 1440. I've set those and will need to remember to check if I see any weird issues....
-
FWIW I just used https://calculator-apps.com/networking-calculators/mtu-mss-calculator to calculate 'proper' MTU/MSS values for my ip(6)tables rules.
Being paranoid about TCP Timestamps and SACK that's 1420 and 1440. I've set those and will need to remember to check if I see any weird issues....
-
Well, now I feel stupid. I finally figured out why, since upgrading to Debian 13/trixie, there are some websites I couldn't connect to, but only over IPv6, they work fine on their IPv4 address.
Fucking MTU.
I'd for a long time had an IPv4 iptables rule to force the MSS (maximum segment size) on outbound packets to `1400`. But I never put in an equivalent for IPv6.
I use 'jumbo packets' on the LAN between desktop and server, which means an MTU of 4088 (for that pair of NICs). So anything forwarded out was using an MSS of 4088 as well.
The issue only showed up for *some* sites, and only for IPv6, and only on 13/trixie because:
1. 13/trixie uses openssl 3.x, not the older version, which has slightly different cipher suites etc in the default config.
2. IPv6 addressing makes packets that little bit bigger.
3. I've only ever observed the issue with MS Azure/Edge hosts.What was happening was that the first part of the "Server Hello" after a "Change Cipher Spec, Client Hello" from my end was being lost, as the TCP level packet was too large and fragmented... but the first fragment was too large for my PPP link.
So, added an ip6tables rule to do the set-mss thing as well, and now it works.
-
Well, now I feel stupid. I finally figured out why, since upgrading to Debian 13/trixie, there are some websites I couldn't connect to, but only over IPv6, they work fine on their IPv4 address.
Fucking MTU.
I'd for a long time had an IPv4 iptables rule to force the MSS (maximum segment size) on outbound packets to `1400`. But I never put in an equivalent for IPv6.
I use 'jumbo packets' on the LAN between desktop and server, which means an MTU of 4088 (for that pair of NICs). So anything forwarded out was using an MSS of 4088 as well.
The issue only showed up for *some* sites, and only for IPv6, and only on 13/trixie because:
1. 13/trixie uses openssl 3.x, not the older version, which has slightly different cipher suites etc in the default config.
2. IPv6 addressing makes packets that little bit bigger.
3. I've only ever observed the issue with MS Azure/Edge hosts.What was happening was that the first part of the "Server Hello" after a "Change Cipher Spec, Client Hello" from my end was being lost, as the TCP level packet was too large and fragmented... but the first fragment was too large for my PPP link.
So, added an ip6tables rule to do the set-mss thing as well, and now it works.
-
Well, now I feel stupid. I finally figured out why, since upgrading to Debian 13/trixie, there are some websites I couldn't connect to, but only over IPv6, they work fine on their IPv4 address.
Fucking MTU.
I'd for a long time had an IPv4 iptables rule to force the MSS (maximum segment size) on outbound packets to `1400`. But I never put in an equivalent for IPv6.
I use 'jumbo packets' on the LAN between desktop and server, which means an MTU of 4088 (for that pair of NICs). So anything forwarded out was using an MSS of 4088 as well.
The issue only showed up for *some* sites, and only for IPv6, and only on 13/trixie because:
1. 13/trixie uses openssl 3.x, not the older version, which has slightly different cipher suites etc in the default config.
2. IPv6 addressing makes packets that little bit bigger.
3. I've only ever observed the issue with MS Azure/Edge hosts.What was happening was that the first part of the "Server Hello" after a "Change Cipher Spec, Client Hello" from my end was being lost, as the TCP level packet was too large and fragmented... but the first fragment was too large for my PPP link.
So, added an ip6tables rule to do the set-mss thing as well, and now it works.
-
Well, now I feel stupid. I finally figured out why, since upgrading to Debian 13/trixie, there are some websites I couldn't connect to, but only over IPv6, they work fine on their IPv4 address.
Fucking MTU.
I'd for a long time had an IPv4 iptables rule to force the MSS (maximum segment size) on outbound packets to `1400`. But I never put in an equivalent for IPv6.
I use 'jumbo packets' on the LAN between desktop and server, which means an MTU of 4088 (for that pair of NICs). So anything forwarded out was using an MSS of 4088 as well.
The issue only showed up for *some* sites, and only for IPv6, and only on 13/trixie because:
1. 13/trixie uses openssl 3.x, not the older version, which has slightly different cipher suites etc in the default config.
2. IPv6 addressing makes packets that little bit bigger.
3. I've only ever observed the issue with MS Azure/Edge hosts.What was happening was that the first part of the "Server Hello" after a "Change Cipher Spec, Client Hello" from my end was being lost, as the TCP level packet was too large and fragmented... but the first fragment was too large for my PPP link.
So, added an ip6tables rule to do the set-mss thing as well, and now it works.
-
Well, now I feel stupid. I finally figured out why, since upgrading to Debian 13/trixie, there are some websites I couldn't connect to, but only over IPv6, they work fine on their IPv4 address.
Fucking MTU.
I'd for a long time had an IPv4 iptables rule to force the MSS (maximum segment size) on outbound packets to `1400`. But I never put in an equivalent for IPv6.
I use 'jumbo packets' on the LAN between desktop and server, which means an MTU of 4088 (for that pair of NICs). So anything forwarded out was using an MSS of 4088 as well.
The issue only showed up for *some* sites, and only for IPv6, and only on 13/trixie because:
1. 13/trixie uses openssl 3.x, not the older version, which has slightly different cipher suites etc in the default config.
2. IPv6 addressing makes packets that little bit bigger.
3. I've only ever observed the issue with MS Azure/Edge hosts.What was happening was that the first part of the "Server Hello" after a "Change Cipher Spec, Client Hello" from my end was being lost, as the TCP level packet was too large and fragmented... but the first fragment was too large for my PPP link.
So, added an ip6tables rule to do the set-mss thing as well, and now it works.
-
About fucking time... Android finally doing proper DHCPv6. When this is live on my phone I can turn off SLAAC, and not have Windows insist on using it (yes, there's meant to be ways to stop Windows from using SLAAC, so it only uses DHCPv6, but I never saw any of them work). *I* don't want 'random' addresses, I want predictable ones for firewalling and ACLs: https://android-developers.googleblog.com/2025/09/simplifying-advanced-networking-with.html?m=1
-
About fucking time... Android finally doing proper DHCPv6. When this is live on my phone I can turn off SLAAC, and not have Windows insist on using it (yes, there's meant to be ways to stop Windows from using SLAAC, so it only uses DHCPv6, but I never saw any of them work). *I* don't want 'random' addresses, I want predictable ones for firewalling and ACLs: https://android-developers.googleblog.com/2025/09/simplifying-advanced-networking-with.html?m=1
-
About fucking time... Android finally doing proper DHCPv6. When this is live on my phone I can turn off SLAAC, and not have Windows insist on using it (yes, there's meant to be ways to stop Windows from using SLAAC, so it only uses DHCPv6, but I never saw any of them work). *I* don't want 'random' addresses, I want predictable ones for firewalling and ACLs: https://android-developers.googleblog.com/2025/09/simplifying-advanced-networking-with.html?m=1
-
About fucking time... Android finally doing proper DHCPv6. When this is live on my phone I can turn off SLAAC, and not have Windows insist on using it (yes, there's meant to be ways to stop Windows from using SLAAC, so it only uses DHCPv6, but I never saw any of them work). *I* don't want 'random' addresses, I want predictable ones for firewalling and ACLs: https://android-developers.googleblog.com/2025/09/simplifying-advanced-networking-with.html?m=1
-
About fucking time... Android finally doing proper DHCPv6. When this is live on my phone I can turn off SLAAC, and not have Windows insist on using it (yes, there's meant to be ways to stop Windows from using SLAAC, so it only uses DHCPv6, but I never saw any of them work). *I* don't want 'random' addresses, I want predictable ones for firewalling and ACLs: https://android-developers.googleblog.com/2025/09/simplifying-advanced-networking-with.html?m=1
-
For some reason a LOT of Microsoft-tagged (whois) IPs are **very** interested in the query "IN ANY fysh.org".
I'm seeing *thousands* of TCP connections to the name server at once, all for that same query.
I'm still going through the list of IPs from about 30 minutes ago, but so far whois is mostly saying "Microsoft", sometimes with a "cloud" tag. There's one bunch of Google in there too, but for all I know they're just because the MSFT ones are causing a lot of:
named[2218860]: Accepting TCP connection failed: quota reached
So, are Microsoft cloud IPs known to do something like this, perhaps some web scraper gone wrong? Or is someone leveraging Azure for some sort of DoS attack ? It's not *incredibly* effective if so, no immediate sign of other issues with fysh.org services, but I've not gotten to checking that in detail yet.
-
For some reason a LOT of Microsoft-tagged (whois) IPs are **very** interested in the query "IN ANY fysh.org".
I'm seeing *thousands* of TCP connections to the name server at once, all for that same query.
I'm still going through the list of IPs from about 30 minutes ago, but so far whois is mostly saying "Microsoft", sometimes with a "cloud" tag. There's one bunch of Google in there too, but for all I know they're just because the MSFT ones are causing a lot of:
named[2218860]: Accepting TCP connection failed: quota reached
So, are Microsoft cloud IPs known to do something like this, perhaps some web scraper gone wrong? Or is someone leveraging Azure for some sort of DoS attack ? It's not *incredibly* effective if so, no immediate sign of other issues with fysh.org services, but I've not gotten to checking that in detail yet.
-
For some reason a LOT of Microsoft-tagged (whois) IPs are **very** interested in the query "IN ANY fysh.org".
I'm seeing *thousands* of TCP connections to the name server at once, all for that same query.
I'm still going through the list of IPs from about 30 minutes ago, but so far whois is mostly saying "Microsoft", sometimes with a "cloud" tag. There's one bunch of Google in there too, but for all I know they're just because the MSFT ones are causing a lot of:
named[2218860]: Accepting TCP connection failed: quota reached
So, are Microsoft cloud IPs known to do something like this, perhaps some web scraper gone wrong? Or is someone leveraging Azure for some sort of DoS attack ? It's not *incredibly* effective if so, no immediate sign of other issues with fysh.org services, but I've not gotten to checking that in detail yet.
-
For some reason a LOT of Microsoft-tagged (whois) IPs are **very** interested in the query "IN ANY fysh.org".
I'm seeing *thousands* of TCP connections to the name server at once, all for that same query.
I'm still going through the list of IPs from about 30 minutes ago, but so far whois is mostly saying "Microsoft", sometimes with a "cloud" tag. There's one bunch of Google in there too, but for all I know they're just because the MSFT ones are causing a lot of:
named[2218860]: Accepting TCP connection failed: quota reached
So, are Microsoft cloud IPs known to do something like this, perhaps some web scraper gone wrong? Or is someone leveraging Azure for some sort of DoS attack ? It's not *incredibly* effective if so, no immediate sign of other issues with fysh.org services, but I've not gotten to checking that in detail yet.
-
And that's another trip to the Specsavers in Andover done, until I go pick up the new glasses in ~2 weeks.
Once more the staff were lovely, professional and both offered good information and answered any questions I had.
My bank account is wincing, as I've refreshed all *three* pairs; "intermediate vision" for computer work (most of my day), normal varifocals, and another varifocal pair with a polaroid tint for if it's sunny.