Is Linux better for backward compatibility than Windows?

estimator7292 2 days ago | parent | next [-]

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 2 days ago | parent [-]

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

▲

scratcheee 2 days ago | parent [-]

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 a day ago | parent [-]

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 a day ago \| parent [-]
		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.

▲

arp242 2 days ago | parent | prev [-]

Depends; you should be able to still run binaries from the 90s, but if it's dynamically linked and doesn't ship with the libraries finding compatible libraries might be a pain and it won't run out the box. If you have the source code, then it should usually compile with minimal or no changes unless it depends on very old libraries that have seen incompatible changes (which is often the case). One of the nicer things about Windows is that it's a much more comprehensive "batteries included" system.

▲

rstuart4133 9 hours ago | parent | next [-]

To put this in some perspective, I used Debian's debootstrap to install Debian Woody (2002 vintage) on a Linux 5 (I think?) kernel. It all worked as expected. I suspect the XWindows protocol is fairly backward, and you could recompile everything with the gcc Woody shipped. I guess that says a thing or two about Debian maintaining backward compatibility with older package formats too.

It's not a stunt I try to pull with Windows.

▲

M95D a day ago | parent | prev [-]

No, it won't compile. Not even kernel v4.8 can be compiled with gcc v11+.

	▲	arp242 20 hours ago \| parent [-]
		I don't know what the issue with Linux is, but most projects should compile. I've compiled many old projects. You do need to tweak some flags at times because defaults change.