zekica

There is no separate per-process address space on 8080 or Z80, for that you need an MMU/protected mode.

Cryptography is every download you ever do in a browser, bitlocker or equivalent encrypted disk access. Add to that gzip or brotli compression (common in HTTP). Hardware decoders for newer video codecs (such as AV1) are not that common (less than 50% of devices) so most youtube watch time on desktops/laptops is software decoding. It's a lot more than 1%.

rEFInd is great! I wish they just updated the default theme to something nicer.

That's one of the original design requirements for wireguard. Unless a packet is signed with the correct key, it won't respond at all.

Starlink is in a better position as their satellites are in a low earth orbit - 30 times closer than geostationary. It correlates to 1000 times (30dB) stronger signal on both sides.

Yes, but it doesn't have to be. Have you looked into Dave Taht's crusade against buffers?

Honest question: why do we need to optimize for <10kbps? It's really impressive what they are able to achieve at 6kbps, but LTE already supports >32kbps and there we have AMR-WB or Opus (Opus even has in-band FEC at these bitrates so packet loss is not that catastrophic). Maybe it's useful in satellite direct-to-phone use-cases?

Never? Google will probably reduce their SWE more and more assuming we get exponentially better at LLMs or something better comes along, but it won't ever be fully replaced.

Not really, they updated to 5.6.x but used code from the git tag, not from the tarball, and only in their snapshot (not stable) version. The git repository never contained <i>build-to-host.m4</i>, so the injected build step was never executed and not backdoored library was produced.

Mostly true, but IPC is not the only thing influencing power consumption - process node also plays a significant part, so Apple will be ahead as long as they use the newest nodes at TSMC.

Apple's IPC mostly comes from their 8-wide instruction decoder that isn't possible in x86_64 because of variable instruction lengths.

> but that raises the question of why Red Hat are writing a new driver

Nvidia's driver cannot be included in the upstream linux as it doesn't follow kernel coding style and code organization, but more importantly it is tightly coupled to a single version of their GSP firmware - they have to be updated at the same time.

udp[8] = 1 filters only handshake packets. Without it, data packets would also be sent to the userspace daemon.

I'm not sure if initial handshakes can be replayed, but since WireGuard ignores unknown clients, it might be possible.

I don't miss it, DisplayPort is a really good replacement.

64:ff9b::/96 is allocated for NAT64 - and most US mobile carriers use this as most Android and iOS phones use IPv6 only APNs with DNS64 and 464XLAT.

The difference is that OpenWrt has the entire source code available, and unlike those franken-distros, it is built as vanilla linux + a set of patches. As long as there is enough interest, anyone can rebase these patches on top of a newer mailine kernel. For example some Ubnt XW boards recently got an update to 23.05 after being stuck on 19.07.

> so they're far from the only group guilty of benefitting from openwrt without contributing

This is certainly true. SoC vendors often base their SDK on a fixed version of OpenWrt and then add proprietary patches on top. Then sell the SoC + SDK to a device vendor that adds additional proprietary patches and sells the device.

The issue with this is that the only way to fix security issues is to back-port them to the exact kernel version the SoC used as a base, and after a year or two, they completely drop support and you're left with a device that has known security vulnerabilities you can do nothing about.

How many old routers are still in use that are used as part of a botnet?

As a small contributor to OpenWrt, I don't like the whole: release one version of their proprietary fork of OpenWrt and then just do security fixes on top of that.

If they really want to focus on hardware and base everything on top of OpenWrt, it would be easier for them to upstream as much as possible and let the community handle updates. Even donating would be less expensive. It would be somewhat of a win-win situation IMO.

Won't tail call optimization mostly mitigate this?

IMHO, nuclear is not delivering only because of new compliance requirements and nimbysm.

No, AMD doesn't have E-Cores right now, but even when they do it won't ever crash: they have Zen4 as their P-Core and Zen4c as their E-Core. Both support exactly the same extensions.

I bought MT7921K on a PCIe card for two older PCs and they work fine, AX210 is better but Mediatek is not bad - between two of them on 6GHz they managed >1Gbps and didn't lock up at all even after 200GB.

Just had to use at least Linux 6.1 or newer and had to set regulator domain manually... Compiling upstream mt76 enabled even more stability and also enabled AP+STA operation.

90W is peak power consumption for these. They idle at about 8-9W measured at the wall socket or $22-25/year.

If the network already supports NAT64 I would use CLAT running on the system. That way you don't need LD_PRELOAD.

You can have an AP accepting multiple different WPA2-PSK and/or WPA3-SAE passphrases, and since on WPA2 PMK depends on the password, and on WPA3 PMK is different for each client, you can put them in different VLANs or have per PMK MAC mapping if they share the same VLAN.

Great explanation but went right away with NAT, port forwarding and no mention of proper routing setup and no mention of IPv6.

You can use Mozilla's offline translate extension - it doesn't support many languages but it works.

It is actually star pound star pound 4 6 3 6 pound star pound star. 4636 represents INFO.

IMO, better options are box86/box64 or FEX.

It was last time I was looking.

RIPE-738 (European RIR's address allocation and assignment policy) says that home users should get at least /56.