perennialmind

If you want to sell real estate while still retaining rights to visit a grave sited thereupon, the legal instrument is called an "easement". Sometimes the access grant is associated with ownership of another property (e.g. shared driveway), but it can just as easily be just to a sentimental goldfish aficionado.

My point was meant purely as an intellectual exercise, not a critique of engineering choices made in the face of adverse practical realities. My apologies if it came across otherwise.

With the luxury of hindsight, allowing an admixture of 32-bit and 64-bit addresses strikes me as an obviously clean solution to the one real problem IPv6 solves. But in 1992, that was a complete non-starter.

The hopes were for a converged software stack, but the candidates were all parallel protocols competing with IPv4. A full transition would end with the extinction of IPv4. Upgrading IPv4, quite apart from the brass tacks of the wire format, would have entailed variable-length addresses and even the idea of starting a new protocol with 64-bit addresses with an upgrade path was considered far too scary at the time. That was only one of a slew of non-technical requirements imposed from above for future proofing, NIH paranoia, vague security promises and politics in general.

A decade later, when IPv6 had real-world deployments was far to late for 6to4 to save the day: entirely because a swath of non-6to4 addresses existed and needed to be reachable. Given no strategic gain apparent for upgrading the commercial core, aligning financial interests by upgrading past the edge instead would absolutely have made sense. Unfortunately the hard parts the engineers anticipated in the early 90s were not the ones that held IPv6 back.

In summary, I agree: 6to4 could have been great!

I only read up on CLNP based on a fascination with counterfactuals. I will say there is a fair bit to IS-IS and ES-IS that's directly relevant to the original articles points on the circuits-to-bus-to-circuits physical evolution. There was no blanket assumption that the underlying layer look like Ethernet. The subnet equivalent was at a higher level and the assumptions were that there would be an actual network of links to manage.

The fact that IS-IS survived as a relevant IP routing protocol says a lot on its own.

CLNP had existing implementations and was fundamentally sound. On its technical merits, RFC1347 TCP and UDP with Bigger Addresses (TUBA) wins hands-down. But it took too long for the ISO to agree to a hand-off (the IETF wanted to be able _fork_ it, which seems nuts to me) and the IAB required ownership.

But aside from that, I actually do think we could have baked address extensions into the existing packet format's option fields and had a gradual upgrade that relied on that awful bodge that was (and is) NAT. And had a successful transition wherein it died a well-deserved death by now. :-)

IPv4 was designed with extension headers: it boggles my mind that simply using the headers to extend the address was never seriously considered. It was proposed: https://www.rfc-editor.org/rfc/rfc1365.html

It still would have been a ton of work, but we could have just had what IPv6 claimed to be: IPv4 with bigger addresses. Except after the upgrade, there'd be no parallel system. And all of DJB's points apply: https://cr.yp.to/djbdns/ipv6mess.html

IPv4 will be with us for a long, long time. My point is that we're stuck with the combination in some form or another and it didn't have to be that way.

Embedding the address extension using the extension mechanism built into IPv4 would have allowed for a true upgrade and a single IP address space. Two nodes with eight-byte IP addresses would exchange packets without any rewriting. That's an address-space expansion, not just a weird way to do NAT. With perfect foresight, I have no doubt the IETF could have embraced NAT as a transition technology quickly obsoleted by broad adoption.

There's no viable alternative to dual stack with NAT now. We're stuck with it.

But when IPv6 was standardized, a pure upgrade to IPv4 was still feasible. IPv4 allows for extensions headers and middleboxes hadn't yet imposed protocol ossification. If instead of the encapsulation the article supposes, the upgrade embraced translation, we could have had an IPv4+ with NAT fallback. A node on a network behind a IPv4+ router would send out a packet with the RFC1918 interior address encoded as the address extension. Either the server (which would have a proper IPV4 address) responds without the extension header, at which point the IPv4+ router at the edge has to do NAT-style connection tracking, or the response packet can be forwarded as-is.

All the pain of upgrading software to a new protocol still applies, with the added headache of variable length addresses (4 bytes, 8 bytes, potentially more). But no ISP has to make the investments or take the risk of the parallel infrastructure. The IPv4 core carries on, with incremental improvements but zero mandatory upgrades.

There was no upside for an ISP to operate a 6to4 relay, so the anycast address was worse than a blackhole route. It would occasionally permit a connection, but mostly just caused timeouts. Without that poison pill, it could have been a nice way to allow for connecting private subnets that otherwise use conflicting RFC1918 subnets. That's what I used it for.

As I recall, 6to4 worked beautifully between 6to4 nodes in the absence of middlebox interference. The fatal flaw was the anycast address for accessing the "real" IPv6 network. The rosy outcome imagined in the article doesn't require a hypothetical IPv4 extension: just the novel idea of leaving the IPv4 core alone and extending the edge - which would have brought the financial incentives into alignment.

Dotnet's GC has a real latency problem. Miguel de Icaza gave a nice talk on why noticeable pauses are inevitable in a stop-the-world tracing GC, proposing Swift's reference-counting GC as the viable alternative [1]. Still, there are recent developments (Satori GC) with the promise to make the worst case far more palatable (e.g. 250ms -> 5ms) [2].

[1] https://www.youtube.com/watch?v=tzt36EGKEZo

[2] https://github.com/dotnet/runtime/discussions/115627#discuss...

With AutoHotKey you can escalate to sending as-if-by-keyboard, for those frustrating scenarios where clipboard paste is ignored.

  SendInput {Raw}%ClipBoard%`

The sentence "a 32-bit CPU register can address up to 4 gigabyte of memory" is sloppy, the sentence "a 32-bit CPU register can address up to 4 GiB of memory" is not.

Oh that's fun. I imagined a distressed elephant walking through the office and pulling down ceiling tiles, the wood floor splintering under the weight. Didn't think about ears. Attitude, mass, height, and building materials: yes. Ears: no.

Same here: it reduces to a logic problem. I can imagine the transformation, the space, the cube, the rotation individually as concepts, but all of it is more memory than visualization and carrying through the shape and orientation of the numbers seems like magic.

Tesla employs the Norman Doors of false advertising. In the lasting tradition of "Free" (not free), Tesla gave us "Autopilot" (requires manual operation at all time) and "Full Self Driving" (requires alert driver at all time).

Lately I've taken to avoiding that fine point. I find it easier to internalize `foo/bar/.`. Using the self-referential dot this way doesn't carry the same semantics, but the effect is the same and it's a pattern that applies to many tools.

rather than consult the manpage yet again. When I want those semantics, I tack on the self-referential dot. `rsync foo/bar/. baz`

Wow. I had a CS professor insist on exactly that style. I couldn't stand it at first, but making accommodations was the whole point. Unfortunately it got me thinking about what I would want. Now I'm the weirdo and I rarely get to write it the way I want. <shrug>

Nit: WSL2 is available on Windows Home, while Hyper-V is reserved for Pro and up.

I don't know why back-to-back SSL proxies were never afforded an officially sanctioned mechanism for explicitly delegating trust. The alternative is this "I know you're lying, but I love you too much to leave you" mentality.

If you're asking package managers to facilitate such a morally compromised relationship, your best bet is to make user intent explicit and circumscribed. One way to signal that intent might be to adopt a trust-on-first-use approach:

  > rustup --detect-mitm
  MITM thumbprint: 567d3e4c...
  > rustup --permit-mitm=567d3e4c...

Not that that would be easy to do, mind you.

I've gone down that rabbit hole, repeatedly. It's just too fascinating. Likewise, I feel obligated to bring up the Voter Satisfaction Efficiency (or index) metric that seems to be favored by the approval/range voting crowd: basically estimating how utilitarian a given voting system can be. There's a fascinating write-up of their modeling results on github, with code (python).

http://electology.github.io/vse-sim/VSE/ https://rangevoting.org/vsi.html

When it comes up in conversation (or I can work it into conversation), I push people to this - it has some great interactive visualizations

https://ncase.me/ballot/