6 ms·

I don't know, as a software author myself I don't like the "modern" way of thinking. I like to write an application once, and then be able to update the depende

I don't know, as a software author myself I don't like the "modern" way of thinking. I like to write an application once, and then be able to update the dependencies and it will still work later, because the dependencies use a stable and sensible interface. I remember writing a couple of apps in the early GTK 2 days, in PyGtk, and they would still run with the very latest GTK 2 version. Due to pythons dynamic nature, I could even get them to run on older GTK versions (when I needed to run on CentOS) by providing polyfills for the one or two missing methods. I get that compatibility shifts the maintenance burden to the library developers but that complexity has to go somewhere, and I'd prefer it centralized.

jcelerier 6y ago
> I like to write an application once, and then be able to update the dependencies and it will still work later, because the dependencies use a stable and sensible interface. as a software user I really hate using an app and having its GUI randomly change even if the app wasn't updated, just because the linux distro changed some lib underneath
- AshamedCaptain 6y ago
  Why do you want updates if not for that. The reason one updates the distribution is to get new features or fixes. It would be a friggin disaster if only this program got the fixes, but not that program, so now they can't agree on the clipboard format, for example.
  - Silhouette 6y ago
    A lot of users don't want updates. They just want their software to work and do whatever they're using it for. As a practical matter, software that is network-accessible or deals with data from outside sources may well need a security patch from time to time. Those updates are good for almost everyone, but by their nature, they should also be transparent to users. It's a different story when you're talking about changing functionality that is visible to the user. Almost everyone hates it when UI elements like menus or toolbars or dialog layouts or shortcut keys get changed from what they're used to, particularly if there is no apparent reason for the change.
    - AshamedCaptain 6y ago
      > As a practical matter, software that is network-accessible or deals with data from outside sources may well need a security patch from time to time. This is as good argument as any for allowing the dependencies to be updated without updating the main software.
    - konjin 6y ago
      > A lot of users don't want updates. They just want their software to work and do whatever they're using it for. >As a practical matter, software that is network-accessible or deals with data from outside sources may well need a security patch from time to time. Those updates are good for almost everyone, but by their nature, they should also be transparent to users. That's a problem of the system you're using. I use Debian stable for my servers because you can only allow security patches: https://wiki.debian.org/UnattendedUpgrades https://wiki.debian.org/UnattendedUpgrades
      - Silhouette 6y ago
        My business servers typically run Debian Stable for exactly this reason. Most platforms, sadly, are not as reliable in this respect as Debian's. In particular, big consumer platforms like Windows, iOS and Android have all been horrendous when it comes to conflating essential updates for things like security patches or catastrophic data loss bugs with arbitrary updates that change behaviour and move UIs around.
    - atoav 6y ago
      > A lot of users don't want updates. They just want their software to work and do whatever they're using it for. True. But these updates often are what keeps the software working, as software doesn't usually live in complete isolation from the rest of the system. Not having to rely on the system dependecies helps in decoupling and being able to update in a more controlled fashion. If you have to fear with every update that something is taken away from you, then maybe you are just getting your software from the wrong people?
      - bregma 6y ago
  - mannykannot 6y ago
    > Why do you want updates if not for that? For security patches - that is by far the most important issue, followed by (in order) non-security bug fixes and finally non-breaking enhancements. What is definitely not wanted are regressions, which, in my book, includes cryptic changes to the way one does a task, even if it is still possible. And the first of these is, of course, a strong argument against bundling, while the last of these is the thing that most motivates bundling. It is unfortunate that this is being presented in an us-versus-them way, when cooperation for the common good is needed.
- captainmuon 6y ago
  Yeah but isn't one point of updating to get UI improvements? If you install a new theme, I expect the UI of apps to change. I recall there were updates that allowed you to drag a window from the titlebar, add overlay scrollbars, get a macOS-like menu and so on. (I might be showing my age here but I recall how excited everybody was when Windows 95, 98, 2000, XP came out, just because they looked fresher. You didn't need to force updates on people, people were excited to pay $200 to run the same apps on a fancier OS. I wonder when that changed.)
konjin 6y ago
It's kind of astonishing to me that I can run software written 30 years ago in C without changing anything, yet I can't expect a node project written last week with the exact same functionality to work today without a huge test suite.
- daniellarusso 6y ago
  Progress!
- DanielBMarkham 6y ago
  What amazes me more is that there are people actively arguing that this is a good thing. You see developers spend huge amounts of time chasing down obscure dependency issues and begging on forums for help with how library X works with version Y on platform Z, yet many of these same folks will come online and tell you that this is a great thing. It's like many of us (and I include myself in this observation) are unable to step outside our own work and see how we actually spend our time. We become so obsessed on the goal that we lose track of how many new obstacles we put in our own way year-after-year.
  - mattgreenrocks 6y ago
    I’m half convinced that developers self-inflict incidental complexity to justify their job at some level. And also because they have a poor technical aesthetic and don’t know that it can be better.
    - jokethrowaway 6y ago
      I caught myself thinking this as well. TBH, I feel the same about most professions, politicians in primis. But if I have to think rationally "Never attribute to malice that which is adequately explained by stupidity"
      - konjin 6y ago
        Why?
pornel 6y ago
The alternative is asking dependencies to never ever make any breaking changes anywhere. This is not sustainable long term. It forces library authors to grow APIs purely additively, which eventually makes them overcomplicated and full of traps that can't be fixed, e.g. look at X11 and its recurring drama of screensaver lock security. Library authors have to eventually clean stuff up. Ossified applications have to eventually update. Semver just adds a way to coordinate it.
- xorcist 6y ago
  This argument is sensible, but given that applications outlive both hardware and operating systems, the alternative is users keeping whole operating systems around forever without updating them. The Linux kernel is one opposite example. They are pretty hard line about never breaking userspace APIs. It is overcomplicated and full of traps though. For most end users it's still worth it. The reason you took X11 as an example is because it's still around, all modernized APIs that leveraged broken backwards compatibility are long gone by now.
- slaymaker1907 6y ago
  There is a solution to the additive API problem, but C and C++ do not allow it. The solution is to create separate modules like x11/v1, x11/v2, etc. which live in the same distribution. It is therefore permitted for module A to use x11/v1, module B to use x11/v2, and module C to use both A and B (you may need to also provide a shim between common types like a to_v1 function). In this setup x11_v2 probably exposes many of the same bindings as v1, but that is ok since it is low effort to wrap a function or to re-export a private module with the common bindings. This doesn't work in C/C++ due to how the C ABI works. There needs to be an easy way to say that even though A and B both have a foo function they are not the same foo and a way for module C to use both versions of foo by renaming one of them in its source. This is the greatest sin of the C ABI in my opinion, not even the lack of overloads.
  - captainmuon 6y ago
    I think if you use dynamic linking, it is in principle possible for module A to use v1 internally, and for module C to use v2, and neither to know about the other. But you can't use global objects, and you can't share objects from the internal libraries between modules. And the dynamic linker on Linux at least tries to reuse symbols, so it doesn't work by default. This was a big problem in the Gtk2 / Gtk3 transition, where you could not use both in the same process. I think there is a flag to prevent symbol reuse, though.

jcelerier 6y ago

> I like to write an application once, and then be able to update the dependencies and it will still work later, because the dependencies use a stable and sensible interface. as a software user I really hate using an app and having its GUI randomly change even if the app wasn't updated, just because the linux distro changed some lib underneath

AshamedCaptain 6y ago
Why do you want updates if not for that. The reason one updates the distribution is to get new features or fixes. It would be a friggin disaster if only this program got the fixes, but not that program, so now they can't agree on the clipboard format, for example.
- Silhouette 6y ago
  A lot of users don't want updates. They just want their software to work and do whatever they're using it for. As a practical matter, software that is network-accessible or deals with data from outside sources may well need a security patch from time to time. Those updates are good for almost everyone, but by their nature, they should also be transparent to users. It's a different story when you're talking about changing functionality that is visible to the user. Almost everyone hates it when UI elements like menus or toolbars or dialog layouts or shortcut keys get changed from what they're used to, particularly if there is no apparent reason for the change.
  - AshamedCaptain 6y ago
    > As a practical matter, software that is network-accessible or deals with data from outside sources may well need a security patch from time to time. This is as good argument as any for allowing the dependencies to be updated without updating the main software.
  - konjin 6y ago
    > A lot of users don't want updates. They just want their software to work and do whatever they're using it for. >As a practical matter, software that is network-accessible or deals with data from outside sources may well need a security patch from time to time. Those updates are good for almost everyone, but by their nature, they should also be transparent to users. That's a problem of the system you're using. I use Debian stable for my servers because you can only allow security patches: https://wiki.debian.org/UnattendedUpgrades https://wiki.debian.org/UnattendedUpgrades
    - Silhouette 6y ago
      My business servers typically run Debian Stable for exactly this reason. Most platforms, sadly, are not as reliable in this respect as Debian's. In particular, big consumer platforms like Windows, iOS and Android have all been horrendous when it comes to conflating essential updates for things like security patches or catastrophic data loss bugs with arbitrary updates that change behaviour and move UIs around.
  - atoav 6y ago
    > A lot of users don't want updates. They just want their software to work and do whatever they're using it for. True. But these updates often are what keeps the software working, as software doesn't usually live in complete isolation from the rest of the system. Not having to rely on the system dependecies helps in decoupling and being able to update in a more controlled fashion. If you have to fear with every update that something is taken away from you, then maybe you are just getting your software from the wrong people?
    - bregma 6y ago
- mannykannot 6y ago
  > Why do you want updates if not for that? For security patches - that is by far the most important issue, followed by (in order) non-security bug fixes and finally non-breaking enhancements. What is definitely not wanted are regressions, which, in my book, includes cryptic changes to the way one does a task, even if it is still possible. And the first of these is, of course, a strong argument against bundling, while the last of these is the thing that most motivates bundling. It is unfortunate that this is being presented in an us-versus-them way, when cooperation for the common good is needed.
captainmuon 6y ago
Yeah but isn't one point of updating to get UI improvements? If you install a new theme, I expect the UI of apps to change. I recall there were updates that allowed you to drag a window from the titlebar, add overlay scrollbars, get a macOS-like menu and so on. (I might be showing my age here but I recall how excited everybody was when Windows 95, 98, 2000, XP came out, just because they looked fresher. You didn't need to force updates on people, people were excited to pay $200 to run the same apps on a fancier OS. I wonder when that changed.)

konjin 6y ago

It's kind of astonishing to me that I can run software written 30 years ago in C without changing anything, yet I can't expect a node project written last week with the exact same functionality to work today without a huge test suite.

daniellarusso 6y ago
Progress!
DanielBMarkham 6y ago
What amazes me more is that there are people actively arguing that this is a good thing. You see developers spend huge amounts of time chasing down obscure dependency issues and begging on forums for help with how library X works with version Y on platform Z, yet many of these same folks will come online and tell you that this is a great thing. It's like many of us (and I include myself in this observation) are unable to step outside our own work and see how we actually spend our time. We become so obsessed on the goal that we lose track of how many new obstacles we put in our own way year-after-year.
- mattgreenrocks 6y ago
  I’m half convinced that developers self-inflict incidental complexity to justify their job at some level. And also because they have a poor technical aesthetic and don’t know that it can be better.
  - jokethrowaway 6y ago
    I caught myself thinking this as well. TBH, I feel the same about most professions, politicians in primis. But if I have to think rationally "Never attribute to malice that which is adequately explained by stupidity"
    - konjin 6y ago
      Why?

pornel 6y ago

The alternative is asking dependencies to never ever make any breaking changes anywhere. This is not sustainable long term. It forces library authors to grow APIs purely additively, which eventually makes them overcomplicated and full of traps that can't be fixed, e.g. look at X11 and its recurring drama of screensaver lock security. Library authors have to eventually clean stuff up. Ossified applications have to eventually update. Semver just adds a way to coordinate it.

xorcist 6y ago
This argument is sensible, but given that applications outlive both hardware and operating systems, the alternative is users keeping whole operating systems around forever without updating them. The Linux kernel is one opposite example. They are pretty hard line about never breaking userspace APIs. It is overcomplicated and full of traps though. For most end users it's still worth it. The reason you took X11 as an example is because it's still around, all modernized APIs that leveraged broken backwards compatibility are long gone by now.
slaymaker1907 6y ago
There is a solution to the additive API problem, but C and C++ do not allow it. The solution is to create separate modules like x11/v1, x11/v2, etc. which live in the same distribution. It is therefore permitted for module A to use x11/v1, module B to use x11/v2, and module C to use both A and B (you may need to also provide a shim between common types like a to_v1 function). In this setup x11_v2 probably exposes many of the same bindings as v1, but that is ok since it is low effort to wrap a function or to re-export a private module with the common bindings. This doesn't work in C/C++ due to how the C ABI works. There needs to be an easy way to say that even though A and B both have a foo function they are not the same foo and a way for module C to use both versions of foo by renaming one of them in its source. This is the greatest sin of the C ABI in my opinion, not even the lack of overloads.
- captainmuon 6y ago
  I think if you use dynamic linking, it is in principle possible for module A to use v1 internally, and for module C to use v2, and neither to know about the other. But you can't use global objects, and you can't share objects from the internal libraries between modules. And the dynamic linker on Linux at least tries to reuse symbols, so it doesn't work by default. This was a big problem in the Gtk2 / Gtk3 transition, where you could not use both in the same process. I think there is a flag to prevent symbol reuse, though.