Hacker News Reader

Comment by orev | Hacker News Reader

There is a lot of cultural inertia that instantly biases against anything old and stable in developer circles.

It's super annoying, tbh. A subset of developers only seem comfortable with technology invented in the past 18-24 months, regardless of how untested and unstable it is.

“What's this? It was written 2 years ago? It must be old and useless. I’m going to require my app to use the latest version and I don’t care what kind of headaches it makes for the people who actually need to make sure it’s up an running when users try to use it.”

View on HN

Sure, that's annoying too, but I don't see how it's relevant to the topic at hand. IPv6 isn't some shiny new tech, the original RFC just turned 26. It's also not just a superficial re-write of some existing tool, it fixes a real problem which clearly needs to be addressed (no pun intended).

I wish v6 just tried to fix things. The problem with v6 was that it also tried to do thing in a right way and broke too much compatibility. And then it turned out what was right in 1995 was no longer so for the last 10 years.

It mostly only broke the things it had to break. v4 isn't forwards compatible to longer address lengths, so the lack of compatibility isn't the fault of any aspect of v6's design.

v6 128-bit address was an attempt to simplify the routing. The was fear that with big routing tables that v4 stated to require 25 years ago the performance would collapse. In practice it never became an issue. Yet with smaller address space, like with just 48 bits, connecting from v6 to v4 address would be possible with much less complex nat.

That was part of it, but there was also a desire to be very sure we had enough address space to avoid needing to go through this again. SEND and privacy extensions also make use of the 128-bit address to add some security.

It's already possible to connect from v6 to v4, and using 48-bit addresses wouldn't make doing so any easier. 48 bits would also be way too small; there'd be no point in going to this amount of effort to update IP only to then have to do it a second time straight afterwards.

I agree my response isn’t directly relevant, I’m just tired of seeing the same tropes over and over again about how Ops people’s only motivation is to drag their feet on everything just because they’re old and out of date. They actually have good reasons for having processes that appear to slow things down, for good reason.

Both things are true and equally annoying.

I guess we can agree that there is a cultural inertia that instantly biases someone against something based on perceptions of time XD

How odd, I find the opposite with most developers having close to zero tolerance for buggy tools.

Trying to keep jumping to the new hotness is simply a survival strategy.

One developer's "old and stable" is another developer's "filled with vulnerabilities that nobody will ever find let alone bother to fix because everyone assumes it's old and stable."

IPv6 has been a draft standard since 1998. Get a better argument.

What other things we use daily are "draft standards"?

E-mail (RFC-821), HTTP (RFC-7540), IPv4 (RFC 791), etc. Pretty much the entire internet.

A brand new project being written from scratch is way more likely to have bugs and likely to be abandoned as quickly as it started.

Not if it’s written by a good programmer.

Had this issue with a coworker who uses a decade old version of Linux and refuses to install anything other than base packages cus it's "Stable". Well I made an in house tool, and it's not stable, since his glibc had a bug that's been fixed for a decade that made it so pthreads would break. Everytime I tried telling him it's his system before someone else found the bugfix, he would go "YOU JUST DON'T KNOW HOW TO WRITE MULTITHREADED CODE! MAKE IT SINGLETHREADED AND FIND THE BUG!"

Reply on news.ycombinator.com