8 ms·

Meanwhile a Windows application compiled 25 years ago still runs today. A Windows application compiled 30 years ago runs with a very small compatibility shim yo

Meanwhile a Windows application compiled 25 years ago still runs today. A Windows application compiled 30 years ago runs with a very small compatibility shim you can ship with it as a DLL.

arp242 3y ago
> a Windows application compiled 25 years ago still runs today *Usually, not always. A GTK 2 application compiled 25 years ago usually still runs today, too. Just because GTK 3 is available doesn't mean GTK 2 stopped existing.
- bandrami 3y ago
  A GTK 2 application compiled 25 years ago was before the Big Glibc Switch that caused us so many headaches in the early 00's, so no, it won't.
  - arp242 3y ago
    My xv copy has a mtime of Aug 4 1998 (pre-compiled binary from the RPM on the website). It runs on my current Void Linux system. Not GTK, but that's a detail: point is it runs, and is 25 years old. I've also run old Opera copies from the 90s, although that's longer ago and I'm not sure if that still works.
asoneth 3y ago
Having discussed this issue with friends at Microsoft, they apparently spend astronomical amounts of time, money, and effort to maintain backwards compatibility while still adding new capabilities, functionality, and toolkits. They know that this is a key reason many organizations rely on Windows. I have no specific insight into decision-making in open source organizations, but given that the resources they're working with are several orders of magnitude less it's not surprising to me that they sometimes end up having to choose between stability and new functionality. (While I personally prefer projects towards one end of that spectrum, I'm happy that different projects have different values for other people.)
- bandrami 3y ago
  Linus is also kind of obsessive about this at the kernel level. I wish more of the userland shared that priority (cough cough)
  - tuna74 3y ago
    Yeah, the driver ABI in Linux is totally stable. Cgroups as well!
- coldpie 3y ago
  A big part of it is the ecosystem is mostly/almost entirely open-source, so in theory you can update all your applications to use the new API. So breaking changes are not as big a deal in that world, as they are on Windows where you definitely do not have that option due do the primacy of closed-source software. I think this view is short-sighted, though. If there are 100 users of a given library, then it takes 100x more effort to update all the applications than for the 1 library developer to avoid making breaking changes.

Meanwhile a Windows application compiled 25 years ago still runs today. A Windows application compiled 30 years ago runs with a very small compatibility shim you can ship with it as a DLL.

arp242 3y ago

> a Windows application compiled 25 years ago still runs today *Usually, not always. A GTK 2 application compiled 25 years ago usually still runs today, too. Just because GTK 3 is available doesn't mean GTK 2 stopped existing.

bandrami 3y ago
A GTK 2 application compiled 25 years ago was before the Big Glibc Switch that caused us so many headaches in the early 00's, so no, it won't.
- arp242 3y ago
  My xv copy has a mtime of Aug 4 1998 (pre-compiled binary from the RPM on the website). It runs on my current Void Linux system. Not GTK, but that's a detail: point is it runs, and is 25 years old. I've also run old Opera copies from the 90s, although that's longer ago and I'm not sure if that still works.

asoneth 3y ago

Having discussed this issue with friends at Microsoft, they apparently spend astronomical amounts of time, money, and effort to maintain backwards compatibility while still adding new capabilities, functionality, and toolkits. They know that this is a key reason many organizations rely on Windows. I have no specific insight into decision-making in open source organizations, but given that the resources they're working with are several orders of magnitude less it's not surprising to me that they sometimes end up having to choose between stability and new functionality. (While I personally prefer projects towards one end of that spectrum, I'm happy that different projects have different values for other people.)

bandrami 3y ago
Linus is also kind of obsessive about this at the kernel level. I wish more of the userland shared that priority (cough cough)
- tuna74 3y ago
  Yeah, the driver ABI in Linux is totally stable. Cgroups as well!
coldpie 3y ago
A big part of it is the ecosystem is mostly/almost entirely open-source, so in theory you can update all your applications to use the new API. So breaking changes are not as big a deal in that world, as they are on Windows where you definitely do not have that option due do the primacy of closed-source software. I think this view is short-sighted, though. If there are 100 users of a given library, then it takes 100x more effort to update all the applications than for the 1 library developer to avoid making breaking changes.