Years ago, I stumbled upon the "idea" was already debated in other fields long before programming. Lumpers and Splitters.

https://en.wikipedia.org/wiki/Lumpers_and_splitters

I wrote a while back, Most of the executives I have met really have no clue. They just go with what is being promoted in the space because it offers a safety net. Look, we are "not behind the curve!". We are innovating along with the rest of the industry.

https://news.ycombinator.com/item?id=46670190

network effects. I just can not bring my team to use fossil. They have to share code with others. Other departments. And everyone (99%+) uses git. It just feels like a disservice to force them to use fossil. It is a catch-22.

It is similar to so many other things in the tech space. Trying to get fellow developers to use functional style idioms. Trying to enforce immutability. It is like something big (like a facebook or google project) has to force the community to get on board.

I've come up with a set of rules that describe our reactions to technologies:

1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works.

2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it.

3. Anything invented after you're thirty-five is against the natural order of things.

He said he was worried but he had backups upon backups. I saw him restore a bunch of websites once, using cpanel, and I thought it is an amazing little bit of software with all of the click a button to setup many different things (like WAF). A real time saver and provides some guidance if you are not a unix-internet guru.

https://www.vaultofculture.com/vault/nst/2023/02/13/zorkmaps

Something about it reminds me of force directed graphs, where you only care about the nodes and edges (the rooms and connections).

ipv6 was standardized in 1995 6to4 was standardized in 2001

6to4 is not used in any meaningful way today.

What was missing was ipv6 should have had 6to4 (but better) in it, in 1995.

Now, I could go on about what is wrong with 6to4, but every new topic is just another surface area for ipv6 proponents to launch another question (I sometimes suspect in bad faith).

It does not address the network level identity and reachability. There is no default, globally routable mapping where owning a ipv4 automatically gives you an equivalent identity in ipv6 that others can reach without translation infrastructure. The transition mechanisms are not uniform or canonical, and that increases complexity.

6to4 was an attempt at that kind of embedding and I do not think it succeeded?

The original specification of ipv6 did not directly address a translation mechanism? It seemed to rely on, well, everyone will go dual stack and we will shut down the old ipv4 stack. I think it should have addressed that in the beginning and provided the one canonical way of doing it, perhaps with guides on timelines to get the ISP and backbone providers to get on board.

I think part of the problem is not so much a technical one, as a coordination issue. Who are you more likely to get on board? ISP and backbone providers. What is the path forward? Here is the recommended path forward, kind of thing.

But it does not follow that address design is irrelevant. The structure of the address space directly determines whether translation can be stateless and alogrithmic.

In a hypothetical ipv42 design that preserves a deterministic embedding relationship between old and new addresses, translation at the edges could be largely stateless and mechanically reversible, to reduce coordiation overhead between operators and it makes reachability more predictable.

In our world ipv6, the transition seems to require a mix of dual stack, nat64, dns64, tunneling aproaches. The mapping between ipv4 and ipv6 is not uniformly deterministic across all deployment contexts.

Also, there is just a human factor. The mental gymnastics that go on. The perception of what is the way forward? With ipv6, it feels like everyone has to go get their ipv6 stack in order. With a hypothetical ipv42, where the ISPs and backbone providers can throw in the translation layers, it feels like, to me, they would have gotten on board much more quickly. Yeah, I know, it is just a feeling.

But in an ipv42 type setup, you would have determnistic embedding so that every ipv4 address is represented inside the larger address space. This would allow translation at network boundaries and let old systems continue to operate unchanged. Then the routers and systems would be upgraded incrementally. I think that is why it would have been upgraded more quickly.

Address exhaustion, Routing table scalability, restore end to end routability, autoconfiguration, header simplification, mulitcast + anycast, security standardization.

Whereas, I think a lot of those things could have been solved in other ways, or more slowly. I would have preferred a ipv4.2 64 style because it would have prioritized

Address exhaustion, keeping backward operational compatibility, fewer changes to institutional knowledge, and still had incremental rollout (that I think would have occurred much more quickly than ipv6).

Words mean nothing. They can be interpreted how ever they need to be interpreted by those in power.

https://en.wikipedia.org/wiki/ECHELON

Comments URL: https://news.ycombinator.com/item?id=47957494

Points: 79

# Comments: 19

From the places I have worked, I would say the reason there is so much bad code at big companies is nobody really cares. It is just a job. You could bust your butt and clean up a code base, or fix a 10 year old bug that has been costing the company a half a million dollars a year, and it will not increase your salary in the slightest (Well, maybe a kudos and a pat on the back but that is not guaranteed).

Office Space had it right in the scene where Peter is being interviewed by the two bobs.