4 ms·

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

by orev 5y ago

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.”

colechristensen 5y ago
Both things are true and equally annoying.
deleted 5y ago
[deleted]
magila 5y ago
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).
- _0w8t 5y ago
  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.
  - Dagger2 5y ago
    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.
    - _0w8t 5y ago
      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.
      - Dagger2 5y ago
        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.
- orev 5y ago
  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.
jsiaajdsdaa 5y ago
I guess we can agree that there is a cultural inertia that instantly biases someone against something based on perceptions of time XD
Retric 5y ago
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.
jolux 5y ago
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.
- wildfire 5y ago
  What other things we use daily are "draft standards"?
  - Volundr 5y ago
    E-mail (RFC-821), HTTP (RFC-7540), IPv4 (RFC 791), etc. Pretty much the entire internet.
- dahfizz 5y ago
  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.
  - jolux 5y ago
    Not if it’s written by a good programmer.
- NtGuy25 5y ago
  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!"

by orev 5y ago

colechristensen 5y ago

Both things are true and equally annoying.

deleted 5y ago

[deleted]

magila 5y ago

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).

_0w8t 5y ago
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.
- Dagger2 5y ago
  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.
  - _0w8t 5y ago
    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.
    - Dagger2 5y ago
      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.
orev 5y ago
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.

jsiaajdsdaa 5y ago

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

Retric 5y ago

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.

jolux 5y ago

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.

wildfire 5y ago
What other things we use daily are "draft standards"?
- Volundr 5y ago
  E-mail (RFC-821), HTTP (RFC-7540), IPv4 (RFC 791), etc. Pretty much the entire internet.
dahfizz 5y ago
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.
- jolux 5y ago
  Not if it’s written by a good programmer.
NtGuy25 5y ago
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!"