3 ms·

Generally no, and that's a feature, not a bug. The main problem you run into is dynamically linked dependencies. If a program depends on some particular behavio

Generally no, and that's a feature, not a bug. The main problem you run into is dynamically linked dependencies. If a program depends on some particular behavior in a particular version of a library that has been updated, it won't work on a modern system with modern libraries. You can work around it in most cases, but it's not particularly easy or straightforward. Old programs with statically linked dependencies might work, but you run into issues where the GUI framework is broken or incompatible or your window manager doesn't like it. Lots of little random stuff like that. Windows is best in class at backwards compatability, though whether that's a good thing is up for debate.

AlienRobot 1y ago
Why wouldn't that be a good thing? I don't want my apps breaking just because the OS updated.
- scratcheee 1y ago
  Not disputing the obvious advantages, but since you asked: Being forced to maintain compatibility for all previously written apis (and quite a large array of private details or undocumented features that applications ended up depending on) means windows is quite restricted in how it can develop. As a random example, any developers who have written significant cross platform software will be able to attest that the file system on windows is painfully slow compared to other platforms (MS actually had to add a virtual file system to git at one point after they transitioned to it because they have a massive repo that would struggle on any OS, but choked especially badly on Windows). The main cause (at least according to one windows dev blog post I remember reading) is that windows added apis to make it easy to react to filesystem changes. That’s an obviously useful feature, but in retrospect was a major error, so much depends on the filesystem that giving anything the ability to delay fs interaction really hurts everything. But now lots of software is built on that feature, so they’re stuck with it. On the other hand, I believe the Linux kernel has very strict compatibility requirements, they just don’t extend to the rest of the OS, so it’s not like there’s a strict rule on how it’s all handled. Linux has the obvious advantage that almost all the software will have source code available, meaning the cost of recompiling most of your apps for each update with adjusted apis is much smaller. And for old software that you need, there’s always VMs.
  - BlackLotus89 1y ago
    Kind of a bad example. Firstly because you are comparing windows with the Linux kernel. The Linux kernel has excellent backwards compatibility. Every feature introduced will be kept if removing it could break a userland application. Linus is very adamant about "not breaking userspace" The main problem with backwards compatibility (imho) is glibc. You could always ship your software with all dynamic lobs that you need, but glibc does make it hard because it likes to move awkward and break things.
    - mid-kid 1y ago
      Glibc is one of the few userspace libraries with backwards compatibility in the form of symbol versioning. Any program compiled for glibc 2.1 (1999!) and later, using the publically exposed parts of the ABI, will run on modern glibc. The trouble is usually with other dynamically linked libraries not being available anymore on modern distributions.

AlienRobot 1y ago

Why wouldn't that be a good thing? I don't want my apps breaking just because the OS updated.

scratcheee 1y ago
Not disputing the obvious advantages, but since you asked: Being forced to maintain compatibility for all previously written apis (and quite a large array of private details or undocumented features that applications ended up depending on) means windows is quite restricted in how it can develop. As a random example, any developers who have written significant cross platform software will be able to attest that the file system on windows is painfully slow compared to other platforms (MS actually had to add a virtual file system to git at one point after they transitioned to it because they have a massive repo that would struggle on any OS, but choked especially badly on Windows). The main cause (at least according to one windows dev blog post I remember reading) is that windows added apis to make it easy to react to filesystem changes. That’s an obviously useful feature, but in retrospect was a major error, so much depends on the filesystem that giving anything the ability to delay fs interaction really hurts everything. But now lots of software is built on that feature, so they’re stuck with it. On the other hand, I believe the Linux kernel has very strict compatibility requirements, they just don’t extend to the rest of the OS, so it’s not like there’s a strict rule on how it’s all handled. Linux has the obvious advantage that almost all the software will have source code available, meaning the cost of recompiling most of your apps for each update with adjusted apis is much smaller. And for old software that you need, there’s always VMs.
- BlackLotus89 1y ago
  Kind of a bad example. Firstly because you are comparing windows with the Linux kernel. The Linux kernel has excellent backwards compatibility. Every feature introduced will be kept if removing it could break a userland application. Linus is very adamant about "not breaking userspace" The main problem with backwards compatibility (imho) is glibc. You could always ship your software with all dynamic lobs that you need, but glibc does make it hard because it likes to move awkward and break things.
  - mid-kid 1y ago
    Glibc is one of the few userspace libraries with backwards compatibility in the form of symbol versioning. Any program compiled for glibc 2.1 (1999!) and later, using the publically exposed parts of the ABI, will run on modern glibc. The trouble is usually with other dynamically linked libraries not being available anymore on modern distributions.