> and we honor those commitments.

Ah, so when the inevitable "bug" appears, and we all learn that you've completely failed to honor anything, what will be your "commitment" then? An apology and a few free months?

Time to start pushing for a self hosted git service again.

> Many will cheer for any case that hurts Meta

Absolutely. Particularly where they've been found to be guilty.

> but we should be aware that these cases are one of the key reasons why companies are backtracking from features like end-to-end encryption

Why _social media_ companies are backtracking. I'm extremely nonplussed by this outcome.

> concerns that allowing teens

Yes, because that's what we all had in mind when considering the victims and perpetrators of these crimes.

in spectrum.c

> Address bits for pixel (x, y):
> * 010 Y7 Y6 Y2 Y1 Y0 | Y5 Y4 Y3 X7 X6 X5 X4 X3

Which is wrong. It's x4-x0. Comment does not match the code below.

> static inline uint16_t zx_pixel_addr(int y, int col) {

It computes a pixel address with 0x4000 added to it only to always subtract 0x4000 from it later. The ZX apparently has ROM at 0x0000..0x3fff necessitating the shift in general but not in this case in particular.

This and the other inline function next to it for attributes are only ever used once.

> During the
> * 192 display scanlines, the ULA fetches screen data for 128 T-states per
> * line.

Yep.. but..

> Instead of a 69,888-byte lookup table

How does that follow? The description completely forgets to mention that it's 192 scan lines + 64+56 border lines * 224 T-States.

I'm bored. This is a pretty muddy implementation. It reminds me of the way children play with Duplo blocks.

> The growing deployment of DNS Security (DNSSEC) and IPv6 has increased response sizes and therefore the use of TCP.

Yes, but doesn't IPv6 also increase the "maximum safe UDP packet size" from 512 bytes to 1280?

> Existing deployments of DNSSEC [RFC4033] have shown that truncation at the 512-byte boundary is now commonplace. For example, a Non-Existent Domain (NXDOMAIN) (RCODE == 3) response from a DNSSEC-signed zone using NextSECure 3 (NSEC3) [RFC5155] is almost invariably larger than 512 bytes.

This has been a flagged issue in DNSSEC since it was originally considered. This was a massive oversight on their part and was only added because DNSSEC originally made it quite easy to probe entire DNS trees and expose obscured RRs.

> The MTU most commonly found in the core of the Internet is around 1500 bytes, and even that limit is routinely exceeded by DNSSEC-signed responses.

> Stub resolver implementations (e.g., an operating system's DNS resolution library) MUST support TCP since to do otherwise would limit the interoperability between their own clients and upstream servers.

Fair enough but are network clients actually meant to use DNSSEC? Isn't this just an issue for authoritative and recursive DNSSEC resolvers to and down the roots?

> by profit-driven utilitarianism.

That's generous. To me it's just felonious corruption possibly bordering on treason.

> and it makes money

It doesn't make money. Which is why these rent seeking entities attach themselves to the federal and state budgets with onerous contracts that they will defend to the death. If they had to actually compete for private business they would be out of money by end of year.

> of the society we want to build

This isn't directionless either. The people doing this have a vision for your society and they're willing to do almost anything to secure that.

> That’s the world the tech industry is building.

Which is why I find monopoly law enforcement so important. "Too big to fail" has become the norm and it seems to me is a required ingredient in order to achieve these outcomes.