Kaxo

The seccomp-BPF rules seem almost unusably strict. What is this even designed to be used to run?

In chrome at least asm.js is(/was?) handled by the wasm engine anyway. They essentially did that transpiling at load time.

Yeah, doing it with OpenWRT and PBR is definately much simpler than this approach. However by using hard-coded IP addresses you are at risk of breakage if they change in the future.

Also fastly-hosted services are a bit awkard to configure IP ranges to cover whole blocks as they seem to not use normal CIDR-blocks for different customers.

But you use PBR's ntfset functionality to have your dns server automatically update a set whenever an DNS entry is resolved, then set the policy rules based on the set.

In 2018 NTSB issued a report (https://www.ntsb.gov/investigations/AccidentReports/Reports/...) listing 17 incidents where CVR was lost due to the recording not being turned off after the incident.

And it also lists 17 more incidents where something happened in a flight and it took more than 2 hours to land so data from the incident was lost.

I found Mercusys AX6000 (aka mr90x) to be a great choice.

https://openwrt.org/toh/mercusys/mr90x_v1

Anything with the MT7986B chipset is a good choice, they support Wifi6, have a 2.5G ethernet port, have decent amounts of RAM/flash and mostl importantly have a fast enough CPU to do high speed WAN to LAN routing and firewalling.

Not only that, since 2019 Google have required apps published on play store to have 64bit variants, this should not be a problem.

However I suspect that the Xiaomi has to contend with the Chinese app ecosystem which may not be as strictly controlled, so probably has a decent number of legacy 32bit apps floating about.

Non-replacable battery is the no1 cause.

Its amazing that the general public have accepted that as another other than a deliberate ploy to sell more new phones more regularly.

Regulators need to start enforcing repairability if they actually want to tackle e-waste.

To save others having to read through the thread, this appears to be caused by this bug:

https://bugs.chromium.org/p/chromium/issues/detail?id=148880...

Roughly, as you type the omnibox has various heuristics to prevent the order of results shuffling when you type each letter. In this case the search result for "sentry.i" has its position preserved instead of the intended "url-what-you-typed" taking priority over search.

No conspiracy needed here, just over complicated design that comes from trying to munge two different functionalities into one UI element.

I feel the exact opposite. I've recently been experimenting with ipv6 only via NAT64/DNS64 and run into the same problem (with steam trying to connect out to hard-coded ipv4 addresses).

I started to look into CLAT and really didn't want to have to go through the hassle of a whole new virtual interface with routes etc, when one single app can't just pass a couple different args to connect().

I actually had thought about trying to write something exactly like this myself.

I'm glad to learn it already exists.