SIG is hiring for some roles in Sydney: https://careers.sig.com/global-experienced

Pennsylvania has oil and was formerly a British colony: https://en.wikipedia.org/wiki/Pennsylvania_oil_rush

Another option is to build your own. You could buy a small ARM board like a NanoPi R6S (<$100) with 2.5GbE ports and run pfSense on it.

The NanoPi is of Chinese origin, all the way down to the silicon, how do you know the bootloader or the CPU isn't compromised?

If someone told you a cup may contain poison, would your first reaction be to drink it just to be sure?

We have photographic evidence of the NSA intercepting Cisco routers. I'm not sure the country of origin matters if you have a red spot painted on your back.

https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa...

What's being proposed here - as an alternative solution to mass-produced Chinese equipment of unknown trustworthiness - is to purchase different mass-produced Chinese equipment of unknown trustworthiness.

Your example of highly-targeted physical interception by state-level actors is irrelevant here.

You are really bringing your own OS here. The nanopi can run mainline linux and u-boot[0]. If you suspect an Intel ME-style component with ring -3 access, it should show up in the initialization sequence - there are no blobs here. Features like these are not cheap to implement, especially when Chinese vendors are so keen on cutting costs.

Essentially, this means that there is zero risk, unless you are a target, at which point any unintentional hardware bug caused by the aforementioned corner-cutting will become a concern.

[0] https://linux-sunxi.org/Linux_mainlining_effort

https://linux-sunxi.org/U-Boot

https://linux-sunxi.org/H3

How do you guarantee there isn't some logic flashed onto the chip that overrides the bootloader sequence?

btw, I asked about this 5 months ago [0] and got some interesting replies. I ended up purchasing a PCEngines board (just before they went out of business)

[0] https://news.ycombinator.com/item?id=35568984

From what I've seen, networking peripherals you can attach to a Pi via USB, or whatever, can't really compete with networking peripherals in routers that are integrated on SoCs/SoMs.

The suggested NanoPi R6S has two 2.5G ports connected to PCIe and one 1G port built in to the SoC, it doesn't use USB for networking.

I figure people are using them for router things, like using it as a wireless AP and switch, and the hardware available for those use cases usually fall short of what's available on router SoCs.

you mean buy it from China? Guangzhou,GuangDong China. That's great advice.

Or better yet OPNSense.

Are you using Windows’ built-in Powershell? If so, are you allowed to install the newer Powershell Core (based on .NET Core)? The latter has a lot of fixes and improvements compared to the built-in Powershell.

i dont think its called core anymore its just called powershell 7 now

and dotnet core, is just dotnet

i think they dropped the core part from the name as of dotnet 5

WinFsp (FUSE for Windows) has an NFS driver: https://github.com/winfsp/nfs-win

zlib-ng also has adler32 implementations optimized for various architectures: https://github.com/zlib-ng/zlib-ng

Might be interesting to benchmark their implementation too to see how it compares.

The complicated number encoding scheme you mentioned is a hexfloat: C has them too.

Hexfloat can be really useful when you need precise/exact floating-point constants for numerical methods. Without them, you end up having to do more-complicated hacks to preserve exact constant values when code gets compiled, or you have to live with compilers (sometimes) subtly altering constants.

I wish more languages supported hexfloats.

Just to clarify a bit what "C has them" means; the standard library string-to-float parsing function strtof() [1] support this format.

You can also use them as floating-point literals in your code.

[1]: https://linux.die.net/man/3/strtof

Hexfloat is also vastly easier to parse from/to IEEE 752 format than decimal floats.

Thanks, I had never seen that before. But Concise Encoding did complicate them further by accepting commas as decimal separator.

Your idea for the secret to prevent spoofing is interesting and reminiscent of the verification secret in the SCTP packet header: https://en.m.wikipedia.org/wiki/SCTP_packet_structure

It's indeed a common technique, not my original idea. SCTP seems to be from 2000, but good old tcp also already does this with its sequence numbers (albeit 32-bit, so while it can't be relied on fully it does prevent amplification specifically).

I think it’s more like Gandiva or DataFusion (both from the Apache Arrow project).