3 ms·

>By contrast, breaking user space ABI on Linux is tradition, and there isn't really any such thing as a stable and consistent set of libraries you can depend on

>By contrast, breaking user space ABI on Linux is tradition, and there isn't really any such thing as a stable and consistent set of libraries you can depend on as a platform because of the ludicrous level of fragmentation. This is true but for apps where source code is available, it doesn't seem like that much of an impediment to keeping things working. I use various tools that haven't been updated for many years but have been easy to keep working as Linux userspace has changed. For closed-source things indeed it's different. >I'm curious what this library could be. The example was ffmpeg. You're right that there probably aren't that many examples of common libraries of that size. But Qt is a good example and why shouldn't it be reasonable to use it and not have a burden placed on me to provide security updates? If I am writing an app and want to use something like libcurl, I would prefer not to have the onus placed on me to monitor and distribute libcurl security updates for the rest of my life, especially if this is just a hobby project. Suddenly I am taking on the role and responsibility akin to a whole Linux distribution, and all because I wanted to write some silly little app. And even if I am that responsible, I as a user have to count on all the developers of apps I'm using to be just as responsible themselves. I mostly have no way to know whether they are, unlike the situation for example as a Debian user where they have a known track record and I can have some level of confidence.

AnIdiotOnTheNet 6y ago
> This is true but for apps where source code is available, it doesn't seem like that much of an impediment to keeping things working. I use various tools that haven't been updated for many years but have been easy to keep working as Linux userspace has changed. For closed-source things indeed it's different. Closed source or unmaintained. Setting up build environments is such a chore with a high probability of conflict that people often use docker containers for it. On top of that, compiling unmaintained older software yourself often requires enough knowledge to dig into the code and correctly fix the errors that have been introduced by API changes. Personally, I find it easier to try and get old binaries working instead. Besides, closed source software not only exists, but also describes some of the most popular professional tools in existence. > The example was ffmpeg. You're right that there probably aren't that many examples of common libraries of that size. But Qt is a good example and why shouldn't it be reasonable to use it and not have a burden placed on me to provide security updates? Windows provides both its own media and GUI layers. I don't see why Windows should be expected to maintain any alternatives people choose to use. > If I am writing an app and want to use something like libcurl, I would prefer not to have the onus placed on me to monitor and distribute libcurl security updates for the rest of my life, especially if this is just a hobby project. Suddenly I am taking on the role and responsibility akin to a whole Linux distribution, and all because I wanted to write some silly little app. Your choices as a developer have consequences! Windows has its own APIs for this. If you don't want the burden of maintaining a non-platform dependency then don't use one. If it is "just a hobby project" and you don't want to update your dependencies then just don't. The alternative is being beholden to third party volunteers to keep your software both available and working.
- ubercow13 6y ago
  >Windows provides both its own media and GUI layers Yes and using the Windows APIs in any meaningful way requires the user to install a ffmpeg-based backend for it anyway (LAVFilters) as it is insufficient in and of itself. And even this leads to problems often enough that media players seem to bundle their own version of LAVFilters anyway (defeating the purpose of using the API...at this point why not just use ffmpeg directly?) and forego using the globally installed ones. Unless the system APIs can cover every use case that a software could need a library for, and do it just as well as the commonly used standard, I think the fact that there are some Windows APIs for some of these things is kind of beside the point. This dependency problem will still rear its head at some point.

AnIdiotOnTheNet 6y ago

> This is true but for apps where source code is available, it doesn't seem like that much of an impediment to keeping things working. I use various tools that haven't been updated for many years but have been easy to keep working as Linux userspace has changed. For closed-source things indeed it's different. Closed source or unmaintained. Setting up build environments is such a chore with a high probability of conflict that people often use docker containers for it. On top of that, compiling unmaintained older software yourself often requires enough knowledge to dig into the code and correctly fix the errors that have been introduced by API changes. Personally, I find it easier to try and get old binaries working instead. Besides, closed source software not only exists, but also describes some of the most popular professional tools in existence. > The example was ffmpeg. You're right that there probably aren't that many examples of common libraries of that size. But Qt is a good example and why shouldn't it be reasonable to use it and not have a burden placed on me to provide security updates? Windows provides both its own media and GUI layers. I don't see why Windows should be expected to maintain any alternatives people choose to use. > If I am writing an app and want to use something like libcurl, I would prefer not to have the onus placed on me to monitor and distribute libcurl security updates for the rest of my life, especially if this is just a hobby project. Suddenly I am taking on the role and responsibility akin to a whole Linux distribution, and all because I wanted to write some silly little app. Your choices as a developer have consequences! Windows has its own APIs for this. If you don't want the burden of maintaining a non-platform dependency then don't use one. If it is "just a hobby project" and you don't want to update your dependencies then just don't. The alternative is being beholden to third party volunteers to keep your software both available and working.

ubercow13 6y ago
>Windows provides both its own media and GUI layers Yes and using the Windows APIs in any meaningful way requires the user to install a ffmpeg-based backend for it anyway (LAVFilters) as it is insufficient in and of itself. And even this leads to problems often enough that media players seem to bundle their own version of LAVFilters anyway (defeating the purpose of using the API...at this point why not just use ffmpeg directly?) and forego using the globally installed ones. Unless the system APIs can cover every use case that a software could need a library for, and do it just as well as the commonly used standard, I think the fact that there are some Windows APIs for some of these things is kind of beside the point. This dependency problem will still rear its head at some point.