4 ms·

>I can write software today that will work without modification even on versions of windows from 15 years ago without recompilation On the other hand if my Win

>I can write software today that will work without modification even on versions of windows from 15 years ago without recompilation On the other hand if my Windows app is complete in and of itself, but depends on a library which requires security updates, I will have to continuously release and distribute updates to it for the next 15 years (or however long it remains useful) even though the app itself is not changing. I'm currently working on a Windows plugin for an app, which requires linking to a ~20MB library, and also another library which in turn links to that same ~20MB library, but using an incompatible linker. The plugin is also for an application that uses that ~20MB library, distributed separately, and in turn many users install a standalone version of that library to use alongside the program. That's 4 copies of the library just for one application on Windows, and this library is common and most likely also distributed with many other apps on most users PCs. All of them will need separate updates.

AnIdiotOnTheNet 6y ago
> On the other hand if my Windows app is complete in and of itself, but depends on a library which requires security updates, I will have to continuously release and distribute updates to it for the next 15 years (or however long it remains useful) even though the app itself is not changing. Only if that library is not part of the base Windows platform, which already supplies a whole lot of things you'd typically need, cryptographic functions among them. So yeah, if you depend on things that aren't part of the base platform it is your responsibility to update them. Or, and this is equally imporntant, not update them if doing so breaks your application. If you only depend on the platform then you don't really need to worry about it except in the rare case of an ABI break. 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. > I'm currently working on a Windows plugin for an app, which requires linking to a ~20MB library, and also another library which in turn links to that same ~20MB library, but using an incompatible linker. The plugin is also for an application that uses that ~20MB library, distributed separately, and in turn many users install a standalone version of that library to use alongside the program. That's 4 copies of the library just for one application on Windows, and this library is common and most likely also distributed with many other apps on most users PCs. All of them will need separate updates. I'm curious what this library could be. At that size and level of commonness, I can only imagine that it is Qt or GTK, or some other "portable" platform layer.
- ubercow13 6y ago
  >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.

AnIdiotOnTheNet 6y ago

> On the other hand if my Windows app is complete in and of itself, but depends on a library which requires security updates, I will have to continuously release and distribute updates to it for the next 15 years (or however long it remains useful) even though the app itself is not changing. Only if that library is not part of the base Windows platform, which already supplies a whole lot of things you'd typically need, cryptographic functions among them. So yeah, if you depend on things that aren't part of the base platform it is your responsibility to update them. Or, and this is equally imporntant, not update them if doing so breaks your application. If you only depend on the platform then you don't really need to worry about it except in the rare case of an ABI break. 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. > I'm currently working on a Windows plugin for an app, which requires linking to a ~20MB library, and also another library which in turn links to that same ~20MB library, but using an incompatible linker. The plugin is also for an application that uses that ~20MB library, distributed separately, and in turn many users install a standalone version of that library to use alongside the program. That's 4 copies of the library just for one application on Windows, and this library is common and most likely also distributed with many other apps on most users PCs. All of them will need separate updates. I'm curious what this library could be. At that size and level of commonness, I can only imagine that it is Qt or GTK, or some other "portable" platform layer.

ubercow13 6y ago
>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.