riobard

There's a asymmetry here that "-R" works both for reverse static and dynamic (using SOCKS protocol) forwarding, but "-D" is required for dynamic forwarding which "-L" cannot do.

Why is that?

Are you sure? I thought it's just AES without any authentication.

That's exactly the issue. I'm just pointing out that it's a fantasy to hope for simple numbering of max supported speeds will simplify the current USB mess.

It will not.

Consumers would expect plugging a 20Gbps device into a 40Gbps port should result in 20Gbps negotiated speed. In reality it will mostly likely end up at 10Gbps (or less) because of the mess.

mark the speed on the USB ports, removing ambiguities

Unfortunately it's not true.

Quiz: what happens when a device capable of 20Gbps is plugged into a port marked as 40Gbps?

by the time batteries wear out, most people are going to want a new a phone.

Not true. In recent years smartphones do not advance much, and would be perfectly fine to keep working if not for the dying battery.

At the very least we'd need to see some data that shows that most people replace batteries when it is possible to do so.

The degree of "possible" varies greatly depending on the available expertise and spare parts. Right now in EU it's cost prohibitive for both coz the special labor required is expensive and almost no official spare parts for consumers. So of coz this will be no data to support your claim.

How do you achieve that on macOS then? With PF?

why is jack retasking a thing…

> The macOS version uses deep packet inspection to do this more reliably. That's not an option here.

I thought it would be easier to do DPI on Linux than macOS. No???

It just proved the author knows nothing about either technology.

Seamless WiFi roaming is mostly a client decision. The best you can do on AP is to:

a) optimize signal strength for coverage (stronger signals aren't always better in multi-AP deployment);

b) provide hints via 802.11k/v/r to help clients make, hopefully, better decisions;

c) forcefully drop and disassociate clients when signal is weak enough.

But if the client has bad WiFi implementation, there's nothing much you could do.

OpenWRT currently supports 802.11k/v/r, but optimizing coverage by adjusting signal strength and channels is left for experienced users to deal with manually. There is the are where some commercial offerings will do, but the result greatly varies. AFAIK there's no ideal system anyway coz physics is hard.

I used to think that the scenes of the TV series “Person of Interest” were exaggerated for storytelling purposes. Maybe not and it was accurate prescience.

China has several teams working on FEL and several experimenting light sources, the latest being built in Shenzhen https://www.iasf.ac.cn/

"(sftp) packetizes the data and waits for responses, effectively re-implementing the TCP window inside a TCP stream."

why is it designed this way? what problems it's supposed to solve?

I hate the original Mac Pro case so much!!! The metal box is so heavy and the edges of the aluminum top handle is so sharp that you definitely need a pair of heavy-duty gloves to move it around.

OK, can we have 7GHz and 8GHz for Wi-Fi please?

China has already reserved the entire 6GHz for cellular and vehicles.

What do these devices do that can't be accomplished by an OpenWrt One + an external AP for less money and fully FOSS?

Nice UI (as the company is best known for https://ui.com)

The assumed mentality of “being flexible” is the very reason WireGuard was created to fight against in the first place, otherwise why bother? IPSec is already standardized and with wide-spread hardware implementation (both FPGA and ASIC) and flexible.

Those pesky WD bridges usually support USB Bulk Storage only but not UASP, resulting in worse performance and higher CPU usage.

Also HDD power management is often complicated by the bridge chip sometimes intervening.

Not recommended for long-term use.

Yeah but those are pretty dated. I was under the impression those old Ampere servers are not efficient compared to modern EPYC anymore. So I’m wondering what their current generation of arm64 servers look like :p

What ARM64 machines are you using and what are they used for? Last year you were announcing Gen 12 servers on AMD EPYC (https://blog.cloudflare.com/gen-12-servers/), but IIRC there weren’t any mentions of ARM64. But now it seems you’re running ARM64 in full production.

Thank you very much for the clarification! :)

Thanks! The Cloudflare blog article explained GSO pretty well: application must send a contiguous data buffer with a fixed segment size (except for the tail of the buffer) for GSO to split into smaller packets. But how does GRO work on the receiving side?

For example GSO might split a 3.5KB data buffer into 4 UDP datagrams: U1, U2, U3, and U4, with U1/U2/U3 being 1KB and U4 being 512B. When U1~4 arrives on the receiving host, how does GRO deal with the different permutations of orderingof the four packets (assuming no loss) and pass them to the QUIC layer? Like if U1/U2/U3/U4 come in the original sending order GRO can batch nicely. But what if they come in the order U1/U4/U3/U2? How does GRO deal with the fact that U4 is shorter?

What mail clients do you recommend that make mailing list UI/UX tolerable?

Can someone explain how UDP GSO/GRO works in detail? Since UDP packets can arrive out-or-order, how does a single large QUIC packet be split into multiple smaller UDP packets without any header sequence number, and how does the receiving side know the order of the UDP packets to merge?

Unfortunately ads and tracking go hand in hand: without tracking, targeted ads are much less effective. If everything else stays the same, you'll just get more, bigger, and flashing ads to compensate for the inefficiency, like what you see today on smaller sites without sophisticated user data.

I'd certainly hope ISP follow your reasoning. BTW that was why I put my WireGuard server on port 443, hoping it would avoid the tragic QoS…

The paper is somewhat title-bait: most of the data flow and privacy concerns (section 3) isn't caused by eSIM but by MVNO and business practices which applies to physical SIM as well. Additionally, it's expecting too much from _travel_ SIM cards (physical or embedded) where the primary consumer concern is cost.

Never had a single problem with it (but increased latency because of weird routings around the world).

UDP (which WireGuard uses to encapsulate your data) traffic is often de-prioritized. You won't notice it when the network load is low, but it will seriously degrade experience during high load periods.

Apple’s pricing structure is: X SE < X < X Air < X Pro.