4 ms·

Is there any explanation for why backwards compatibility breaking changes are so common in the Linux world despite the fact that linux itself does such a good j

Is there any explanation for why backwards compatibility breaking changes are so common in the Linux world despite the fact that linux itself does such a good job avoiding it?

Macha 6y ago
Are they really especially common in the Linux world? UX: Windows 7 -> Windows 8 -> Windows 10 had some pretty drastic changes, even if a big part of Windows 10 was a climbdown. Have you followed the skeumorphic -> flat -> 3d again or Gingerbread to Holo to Material Design guidelines? Dev facing: How have your migrations to WKWebView, notarised builds, M1, the Mac App Store, away from kexts, etc. been? Did you get onboard for WinRT and UWP? You could argue in the Windows case you didn't _have_ to follow these trends, but you also didn't have to on Linux. Pidgin still works much the same as it did a decade ago. Thunderbird is still here and fundamentally the same as when I started using it as a literal child. You can still install MATE and XFCE and have pretty much the same workflow for desktop linux you had 20 years ago on Gnome 1, except with much much better chance of arbitrary hardware/software X working. In the Apple case, you have to follow their guidelines in a much sooner period.
stelonix 6y ago
As code ages, people lose interest in maintaining. When you begin coding an application, you're usually adding features and that's fun, but as time passes and the software reaches its goal, you're left with finding and fixing bugs. That's no fun. Microsoft manages to do so because there's a money incentive for its employees, while free software has no such equivalent. That's why we see things like completely dropping X and writing Wayland from scratch: it's more fun and quicker for developer. Sucks to be us on the receiving end, though. I believe until this kind of thinking shifts, there's not gonna be mass adoption of GNU/Linux systems. People expect software to work and keep working 10 years down the road. The current state of the FOSS ecosystem is full of bitrot and rewrites, with zero incentive for developers to maintain code. Beats the hell out of me why there isn't a distro that allows you to give money to patrons of the packages you use. It's a real no-brainer.
grawprog 6y ago
I could be wrong about this, but I think it mostly just comes down to the maintainers of libraries and software packages. If you've got a less used or less known software package and an upstream library dev makes a breaking change, you've got a choice, stick with the old version or update your code to work with the new version. As time passes, new projects are started on the new version, the new version gets picked up by distro maintainers, old version is slowly phased out as more devs use the newer version. Eventually, maintaining old version and new version in package repos is too much effort to be worth it, old version gets removed, any software stuck on the old version is now broken on that distro without a bunch of workarounds. And essentially, this is happening all the time with most libraries and such.
saizaku 6y ago
I'd say the most likely reason would be the modularity of the user land. Namely it makes the adoption of such backwards incompatible changes much easier. Anyone can make some new piece of software to do something in a new way(ex. init systems). And there will be people who want to use it and don't want to use it. Most of the time distors (and forks) will arise that do it the new way and people who want that will pick those distros. This is really common in the init-systems vs systemd debate.
formerly_proven 6y ago
Might be a GNU ploy, but the more likely explanation is that compatibility requires extra work and effort. Just think about how often libpng broke compatibility. Some libraries are so bad about this (like libpng) that even rolling release distros like Arch have to package multiple versions. No one is willing to put in the effort on Linux to make deployment of software easier. And from the PoV of the distros there is nothing to fix anyway. Windows has invented and largely fixed the DLL hell. Linux only managed to copy the problem. It’s great that the kernel is taking it so seriously, but everything else doesn’t care and constantly breaks compat.
- PaulDavisThe1st 6y ago
  Linux has not copied the DLL hell problem. If you think that, you don't understand what DLL hell was. I assume that by deployment of software, you mean "someone other a distro maintainer building and packaging software". That's no harder on Linux than it is on Windows or macOS (*) , it's just that Linux users have the additional option to get software from their distro too. macOS: you put everything your app needs into ... well, a folder (with some required filenames and organization) windows: you put everything your app needs into ... a folder (with some required filenames and organization) linux: you put everything you app needs into ... a folder. Full integration into "the desktop" needs a few additional steps, easily carried out by an install process. What is missing on Linux is a nice, clean, commonplace way for users to actually carry out the installation process for 3rd party (ISV) software that isn't packaged using the distro packaging system. (*) other than issues with certain, ahem, toolkits that make it hard or impossible to statically link against them (and note: these are typically cross-platform toolkits, ironically).

Is there any explanation for why backwards compatibility breaking changes are so common in the Linux world despite the fact that linux itself does such a good job avoiding it?

Macha 6y ago

Are they really especially common in the Linux world? UX: Windows 7 -> Windows 8 -> Windows 10 had some pretty drastic changes, even if a big part of Windows 10 was a climbdown. Have you followed the skeumorphic -> flat -> 3d again or Gingerbread to Holo to Material Design guidelines? Dev facing: How have your migrations to WKWebView, notarised builds, M1, the Mac App Store, away from kexts, etc. been? Did you get onboard for WinRT and UWP? You could argue in the Windows case you didn't _have_ to follow these trends, but you also didn't have to on Linux. Pidgin still works much the same as it did a decade ago. Thunderbird is still here and fundamentally the same as when I started using it as a literal child. You can still install MATE and XFCE and have pretty much the same workflow for desktop linux you had 20 years ago on Gnome 1, except with much much better chance of arbitrary hardware/software X working. In the Apple case, you have to follow their guidelines in a much sooner period.

stelonix 6y ago

As code ages, people lose interest in maintaining. When you begin coding an application, you're usually adding features and that's fun, but as time passes and the software reaches its goal, you're left with finding and fixing bugs. That's no fun. Microsoft manages to do so because there's a money incentive for its employees, while free software has no such equivalent. That's why we see things like completely dropping X and writing Wayland from scratch: it's more fun and quicker for developer. Sucks to be us on the receiving end, though. I believe until this kind of thinking shifts, there's not gonna be mass adoption of GNU/Linux systems. People expect software to work and keep working 10 years down the road. The current state of the FOSS ecosystem is full of bitrot and rewrites, with zero incentive for developers to maintain code. Beats the hell out of me why there isn't a distro that allows you to give money to patrons of the packages you use. It's a real no-brainer.

grawprog 6y ago

I could be wrong about this, but I think it mostly just comes down to the maintainers of libraries and software packages. If you've got a less used or less known software package and an upstream library dev makes a breaking change, you've got a choice, stick with the old version or update your code to work with the new version. As time passes, new projects are started on the new version, the new version gets picked up by distro maintainers, old version is slowly phased out as more devs use the newer version. Eventually, maintaining old version and new version in package repos is too much effort to be worth it, old version gets removed, any software stuck on the old version is now broken on that distro without a bunch of workarounds. And essentially, this is happening all the time with most libraries and such.

saizaku 6y ago

I'd say the most likely reason would be the modularity of the user land. Namely it makes the adoption of such backwards incompatible changes much easier. Anyone can make some new piece of software to do something in a new way(ex. init systems). And there will be people who want to use it and don't want to use it. Most of the time distors (and forks) will arise that do it the new way and people who want that will pick those distros. This is really common in the init-systems vs systemd debate.

formerly_proven 6y ago

Might be a GNU ploy, but the more likely explanation is that compatibility requires extra work and effort. Just think about how often libpng broke compatibility. Some libraries are so bad about this (like libpng) that even rolling release distros like Arch have to package multiple versions. No one is willing to put in the effort on Linux to make deployment of software easier. And from the PoV of the distros there is nothing to fix anyway. Windows has invented and largely fixed the DLL hell. Linux only managed to copy the problem. It’s great that the kernel is taking it so seriously, but everything else doesn’t care and constantly breaks compat.

PaulDavisThe1st 6y ago
Linux has not copied the DLL hell problem. If you think that, you don't understand what DLL hell was. I assume that by deployment of software, you mean "someone other a distro maintainer building and packaging software". That's no harder on Linux than it is on Windows or macOS (*) , it's just that Linux users have the additional option to get software from their distro too. macOS: you put everything your app needs into ... well, a folder (with some required filenames and organization) windows: you put everything your app needs into ... a folder (with some required filenames and organization) linux: you put everything you app needs into ... a folder. Full integration into "the desktop" needs a few additional steps, easily carried out by an install process. What is missing on Linux is a nice, clean, commonplace way for users to actually carry out the installation process for 3rd party (ISV) software that isn't packaged using the distro packaging system. (*) other than issues with certain, ahem, toolkits that make it hard or impossible to statically link against them (and note: these are typically cross-platform toolkits, ironically).