41–50 of 175 posts
Earlier quoted context omitted.
I don't understand, isn't the original complaint here that everything needs support eventually?
Everything should not need support. The fact that most everything needs support is a symptom of how crazy the software industry is.
This matches my experience. Obviously it's impossible to generalize without making mistakes, but I started to notice that projects that loudly talk about their use of SemVer often break compatibility. In other words, it seems like they think SemVer is a way to liberate them in breaking APIs because now they have a way to tell the world about it explicitly, and so nothing can go wrong.
Ecosystems that have adopted SemVer massively do not value backward compatibility (npm comes to mind), and their package managers often have to provide solvers for complex dependencies; users can get to a corner where they must upgrade something but they can't because it depends on something else that bumped the major version and now the interfacing code has to be rewritten.
Go is an ecosystem that values backward compatibility a lot. They are using SemVer as well now but on the other hand they say that modules shouldn't really bump major version that often, if at all (which in turns makes me question whether adopting SemVer has been a good idea, or a compromise that they had to take to concede something to the community subset that was pushing for a more standard package management solution).
I think Qt is a project that uses SemVer (before it was named so!) in the right way. They break major version every 8-10 years, and they struggle a lot to make sure not to do that often. In C++, it's not even easy because of include files and ABI, but they manage to keep the ABI stable across all minor version upgrades, so that you can upgrade a minor of Qt without even recompiling your software using it.
Earlier quoted context omitted.
No, you misunderstand. You need new libraries to make your new hardware work. You can't use versions of driver libraries like Mesa that are older than your hardware, and Mesa has a ton of dependencies like libstdc++ and LLVM so you can't use old versions of those either. This is a major problem for Flatpak.
I don't see why that's any bigger problem than anything else, flatpak includes mesa as part of the SDK: https://docs.flatpak.org/en/latest/available-runtimes.html#f... If there ends up being a problem with libstdc++ and LLVM, it's not hard to statically link those, if it's not being done already.
Yes, the freedesktop runtimes ship extensions with newer versions of Mesa and its dependencies. This doesn't entirely solve the problem. For one thing, libstdc++ before GCC 5 did not maintain a backwards-compatible ABI, so if the app was compiled too long ago it won't work with a new libstdc++. Steam is now working around this problem by using dlmopen() namespaces to load different version of libstdc++ into the same process. Flatpak is not there yet.
For another, NVidia drivers complicate this even more. The NVidia client-side library must exactly match the version of the loaded kernel module which Flatpak can't control. So NVidia drivers are broken out into yet another runtime extension, and it can't package these drivers due to licensing issues so it will dynamically download NVidia drivers to generate an extension on the fly. NVidia drivers also depend on libstdc++ by the way, another reason why static linking doesn't magically solve the problem.
On top of all this is just the massive complexity and maintenance burden of keeping all this working. All these runtimes with all their extensions, somebody has to keep updating these, and when a runtime is deprecated all of the software that was built for it is defunct. All of this can be solved just by keeping libraries backwards compatible and building for native Linux, not Flatpak or anything else.
Earlier quoted context omitted.
I don't see why that's any bigger problem than anything else, flatpak includes mesa as part of the SDK: https://docs.flatpak.org/en/latest/available-runtimes.html#f... If there ends up being a problem with libstdc++ and LLVM, it's not hard to statically link those, if it's not being done already.
It is nowhere near as simple as you make it out to be. Yes, the freedesktop runtimes ship extensions with newer versions of Mesa and its dependencies. This doesn't entirely solve the problem. For one thing, libstdc++ before GCC 5 did not maintain a backwards-compatible ABI, so if the app was compiled too long ago it won't work with a new libstdc++. Steam is now working around this problem by using dlmopen() namespace…
I hope you can see that "keep libraries backwards compatible forever" is not really a good option either and is probably orders of magnitude more work than just doing all the things you said. In some situations, it is also impossible: if there are bugs in the API contract then it has to be broken eventually.
Earlier quoted context omitted.
This is a flaw in Linux Desktops' choice of application management paradigms, which insists that everything be tightly coupled and managed. It is entirely possible and reasonable to have a stable set of base system libraries everyone can depend on and otherwise applications must bring their own.
It's not just possible and reasonable. It's how literally every other platform works. It's also how the Linux Standard Base worked. It was intended to be a stable well-defined backwards-compatible set of libraries common across distributions. Of course the LSB had its share of problems but they had the right idea to bring stability to Linux as a platform for binary apps.
Earlier quoted context omitted.
For personal use, here's the same thing again. Say a Linux user wants to play a game. The stable old version of their distro doesn't play well with the libs/drivers needed to play the game. So the user must install a newer, less tested, distro. But the goal was not to be "on the bleeding edge" for its own sake; it's playing the game, and there's no other (easy) way.
This is a flaw in Linux Desktops' choice of application management paradigms, which insists that everything be tightly coupled and managed. It is entirely possible and reasonable to have a stable set of base system libraries everyone can depend on and otherwise applications must bring their own.
Might be possible soon, now that building Linux with clang is supported.
Earlier quoted context omitted.
How badly do you really need that feature? Why did no one need it a couple of years ago?
Because sometimes "stable" software has bugs. A true story about one of my websites: It runs on Debian Stable, because I like stability and at the time, Debian was the OS I was most familiar with. It also does a lot of image manipulation, for which it uses ImageMagick. In March of 2018, I discover a bug in ImageMagick: if you perform various hue/saturation modulations, sometimes pixels just turn "black" for no reason…
https://imagemagick.org/script/install-source.php
I used to have a similar version-freshness issue with ffmpeg on Ubuntu, for a video-encoding system I was running. Turns out that building ffmpeg isn't actually that hard. :) Later, I switched to using Nix as a layer over the distro; then I could just build ffmpeg once on my build system, and push the "closure" (the app & all its dependencies) to the other nodes in my encoding farm.
The most unstable software that I experienced was the original Mac. I'm sure that it cost me a non-trivial drop in my GPA.
Earlier quoted context omitted.
It is nowhere near as simple as you make it out to be. Yes, the freedesktop runtimes ship extensions with newer versions of Mesa and its dependencies. This doesn't entirely solve the problem. For one thing, libstdc++ before GCC 5 did not maintain a backwards-compatible ABI, so if the app was compiled too long ago it won't work with a new libstdc++. Steam is now working around this problem by using dlmopen() namespace…
I'm still not sure I understand, it sounds like a solution exists and both Steam and Flatpak are working towards it. I don't see why nvidia can't also do the same things. I hope you can see that "keep libraries backwards compatible forever" is not really a good option either and is probably orders of magnitude more work than just doing all the things you said. In some situations, it is also impossible: if there are b…
> I hope you can see that "keep libraries backwards compatible forever" is not really a good option
??? Why would I be able to see that? You've given zero explanation or evidence for why that would be the case. I see a whole lot of people in this thread in addition to the article explaining why backwards compatibility is good. Nobody is giving valid reasons as to why it's bad.
Microsoft has managed to keep the whole Win32 API compatible "forever". GUI apps built for Windows 95 still work out of the box on Windows 10. Backwards compatibility is a major part of why they are still the dominant platform: businesses actually care about this. They use ancient proprietary software that is critical to their business whose source code has long been lost to the sands of time. A platform that breaks their software is no platform at all.
> probably orders of magnitude more work than just doing all the things you said.
Really? How hard is it to not break things?
It's sometimes more work to add new features or support new hardware without breaking the ABI but clearly it's feasible. glibc 2.1 was released in 1999 and the maintainers decided at that point that they would preserve backwards compatibility forever. We're now at 22 years without a major ABI break. There have been some hiccups of course (the memcpy() fiasco) but they've been fixed.
The GCC team have decided to follow in their footsteps. Since version 5 they've decided they're not going to break the libstdc++ ABI anymore. The culture of backwards compatibility is finally growing on the Linux desktop. This is a far better solution than Flatpak.