wahern

> Exploitability over the internet is unlikely, most ISP routers drop packets with ipoptions fields.

That doesn't track. Apple iPhones are a major user of MPTCP and they report the majority of requests supporting MPTCP, IIRC 70+%.

Okay, but like with the banking myth there was no law or official government policy that specifically prohibited black ownership. And the only legally enforceable impediment after the 14th Amendment were racial covenants on private property (drawn up by property owners themselves by private agreement), which became void in 1948 after SCOTUS said it was unconstitutional for courts to enforce racial covenants.

Notwithstanding that they were examples of extra-legal discrimination (in the sense of not being direct legal prohibitions), racial covenants and red lining also didn't just effect black Americans, though nationwide they were disproportionately impacted. I only point that out because most people would say it was incongruous to claim Jews or Polish or Asians were legally prohibited from owning land in many areas.

I think it's an important distinction because there are vestiges of redlining that persist today. First time homeowner mortgage subsidies, the first major stepping stone for building wealth for most people, effectively exclude many kinds of multiunit housing, such as condos and, IIRC until recently, attached housing like duplexes. This disproportionately impacts prospective urban black homeowners, and quite deliberately. Likewise, IIUC prefabbed homes or similar are excluded, which disproportionately impacts poor rural whites and blacks alike. There are legitimate concerns behind those restrictions, such as developer and rental fraud, just as nominally there were legitimate concerns behind redlining, namely sustainability of property valuations. Though in all these cases it's obvious the reason they persist(ed) as-is is for largely discriminatory reasons, as the legitimate substance of the concerns could be addressed. At the same time, we wouldn't say they legally prohibit ownership; if you're wealthy enough they're no impediment at all, just like redlining and covenants were no impediment if you were wealthy enough (racial covenants could be overcome by just buying up all the adjacent property so there was no other property owner to enforce the covenant; the government couldn't by itself enforce such covenants, only adjoining property owner "beneficiaries").

Perhaps counterintuitively, black letter property law was one of the legal areas most resilient to both racial and sex discrimination. The 1800s saw some regression, but that didn't last long, often because courts themselves couldn't tolerate the illogic. People criticize it, but property is indeed sacrosanct to American legal and political culture, and it was very difficult to carve out exceptions that permitted blacks and women to be excluded without threatening the underlying principles of the system that secured owners' rights. That's why prejudiced treatment tended to come in the form of private, regulatory, or extra-legal discrimination, which arguably persists today in the form of restrictive zoning and related development policies which not coincidentally are impediments to free & clear property ownership, just enough to be tolerable to the well-off while disproportionately impacting the real targets.

That particular syntax has far too many caveats to be safely employed, IMO. It would be better to use variably-modified types (VMTs), which currently is more-or-less[1] a pointer to a VLA:

  int foo(int (*bar)[10])

In particular, sizeof(*bar) and (in C2y) countof(*bar) will do the correct thing. But you need to dereference bar almost every to use it properly, and unfortunately sizeof(bar) instead of sizeof(*bar) will compile cleanly, though countof(bar) is guaranteed to fail.

The dilemma is C's array to pointer decaying semantics. C2y will try to roll that back somewhat (a[i] will no longer be identical to i[a] via the a[i] == a + i == i + a transitive relation), but there's only so much you can do in that regard, especially for array passing, without new syntax or silently breaking alot of valid, proper, carefully written C code. There's too much that can fall through the cracks by relying on non-standard compiler heuristics to substitute for proper typing.

[1] Strictly speaking a VLA can only be created as automatic storage objects, but a VMT can type dynamically allocated (malloc'd) memory. But the syntax looks like a pointer to a VLA because it originates from the need to pass actual VLAs as parameters.

> Those language features are not examples of dependent types, though...

Ironically C is the only language in that list with a dependent type. It's not _Generic, of course, but variable-length arrays (VLAs), which neither C++, Rust, nor Zig have.

50 years would be 1976. Perhaps you're confusing it with the myth about women being legally prohibited from opening bank accounts. (1972 was when sex discrimination by businesses was outlawed at the Federal level, though there was never a law that prohibited a women from having a bank account, not directly, and not indirectly since the 1800s. Some banks discriminated against married women, but unless they lived in a one-bank town there were others that were happy to have their business.)

Goroutines and lexical closures create a dilemma for embedded targets. Go was designed around the notion that using goroutines (threading, basically) should be effortless and employed without hesititation. Lexical closures is a critical aspect of that, and by extension GC. Both goroutines and lexical closures require dynamic allocation, at least when combined with some other Go design decisions (e.g. seamless recursion, dynamic method invocation, etc).

Go does a great job of making these impose minimal cost, both technically and cognitively, on typical platforms, from server (including many "embedded" server environments) to desktop to smartphone. That's why it has such a sophisticated yet largely transparent user space threading layer. But it's very difficult and usually impractical for Go to target extremely resource constrained environments without exposing and crippling it's core abstractions. Some people are willing to contort Go to fit that space, but perhaps that's because their vision of what makes Go, Go, differs from the creators' and core maintainers' understanding of Go.

You didn't need a centralized regulatory agency to enforce a law. Even federal laws, if they're written so, can be prosecuted by individual states or even individual persons. Some aspects of antitrust law already work this way.

Doing so can prevent regulatory capture and shelter enforcement from the vicissitudes of politics. It also doesn't require maintaining a government workforce. OTOH, you have to be careful what you ask for. Unless a law is very narrowly tailored then ubiquitous enforcement can have it's own problems, e.g. CEQA.

GMail has a 25-30% share of the client market.

Is it impractical to never send a message through Google? Probably, depending on the circles you communicate in. But that's not the same thing as saying it's impractical to avoid Google for most of your messages, and certainly not the same as saying you can't avoid GMail for anything.

There was a discussion about this on NPR recently. According to the guest, the underlying phenomenon (which goes back a long way) is avoiding long-As, an aversion to sounding like snooty Boston Brahmans. It strongly correlates with political and socio-cultural affiliation, and with words that people are self-conscious about or otherwise are deemed to be more likely to signal affiliation. Iran is specifically discussed.

Before the advent of the modern carceral approach that's not unlike what we had. You got flogged 3 times or stood in the stocks for a day. Though at least there was process--the sentence was imposed by a judge, not a cop. The benefit there was you weren't disappeared for days or months on end, completely destroying your life.