4 ms·

> No high level, stable, sane (truly forward and backward compatible) and standardized API for developing GUI applications (like core Win32 API - most Windows 9

> No high level, stable, sane (truly forward and backward compatible) and standardized API for developing GUI applications (like core Win32 API - most Windows 95 applications still run fine in Windows 10 - that's 24 years of binary compatibility). Both GTK and Qt (incompatible GTK versions 1, 2, 3, 4 and incompatible Qt versions 4, 5, 6 just for the last decade) don't strive to be backwards compatible. So just install the previous version of those toolkits with the application (or use your package manager which will do that for you). Windows gets around this by installing basically everything in the base install and that causes the OS footprint to be grossly inflated. Where as Apple basically stick their middle finger to backwards compatibility and tell devs they have to update their applications. Personally I think Linux has the right approach here: being new features but allow old libraries to be installed when required.

yyyk 6y ago
Distros like to deprecate the previous version of these toolkits and not include them at all. Installing GTK1 or QT <= 4 is beyond the capacity of ordinary users (not of HN crowd of course).
- laumars 6y ago
  If an application in the repos depends on it, then that version of Qt or GTK will also be available in the repos. What's more likely to happen is: - either that application is either dropped from the repos for being unmaintained (if it's using a library that old then there's likely other issues with it) - or some other helpful sole would fork the project and update it to run on a newer version framework This is also very distribution specific. For example ArchLinux still supports Qt 3 applications and libraries in the community repos however I wouldn't expect the same from CentOS (though admittedly I've also not checked).
  - yyyk 6y ago
    Well, our scenario is that the app is not updated, so that's kinda assumed. What usually happens is that distros drop apps due to old library version, and if the user needs it, than the user has to build all the deps, and most users can't do it. I didn't know Arch had older versions - most distros are very eager to drop, since supporting (or even compiling) these huge frameworks past EOL becomes harder and harder.
    - laumars 6y ago
      That’s the problem though, your scenario is making a boat load of assumptions to stand up a theoretical point. Assumptions that the user is running a specific distro, that they then want a specific application and that application has been unmaintained for more than 10 years. This isn’t a common scenario regular Linux folk are going to find themselves in. Plus the situation wouldn’t be any better on Windows (good luck finding the installer for software that has been abandoned 10 years ago from safe places online) nor macOS (Apple do breaking changes more frequently more than any other platform) either. And that’s without factoring in any security concerns that running software as old as that might introduce. So regardless of the platform, if it’s consumer software (ie not industrial applications or other such specialist edge case), you’d recommend the user switches to a newer and maintained alternative.
      - yyyk 6y ago
        "your scenario is making a boat load of assumptions to stand up a theoretical point" Well, that's the scenario the original post made, not mine. From my experience, this can happen albeit rarely - especially with closed source software. "specific distro" == The most popular Linux distros don't include old frameworks. "they then want a specific application and that application has been unmaintained for more than 10 years" This (for example) eventually describes pretty much 99% of games released natively for Linux, unless one goes with Steam which tries to keep stuff working (I dunno whether GoG or itch also do it). For really old software, Windows is the best bet. Even if Windows itself doesn't work (it usually does), wine might.
swiley 6y ago
TK is pretty stable and high level and allows for scripting on top of that. Plus it runs on nearly anything not just GNU/Linux.
mhd 6y ago
Note that even with Windows you often had to install some standard libraries, like MSVCR.DLL or the DirectX version du jour (and I think some VB runtimes, too). Most often redistributed with the software, so done by the installer. Although, to be fair, it might very well be the case that for a given old Linux binary, your distribution won't* have the old runtimes available. Good luck if you've got a commercial pre-press helper application that requires Qt 1.x. Other than availability, what's the big backwards compatibility killer for Linux? a.out vs. ELF? (I remember someone creating their own distribution due to the ELF/glibc shift, back in neolithic times)
sz4kerto 6y ago
Try and run an app relying on Qt4 on the most recent Ubuntu. It's a total PITA. You'd need to compile Qt4 yourself. (Not joking.)
- AsyncAwait 6y ago
  Last time I used Ubuntu, there were PPAs for this, but Qt 4 is outdated and does not even support HDPI, coming from a Mac user it is rich, because macOS software tends to support at most 2 releases of macOS at any given time.
- laumars 6y ago
  Ubuntu isn't the desktop Linux out there. There are others and some of them have a more extensive array of software available and/or a larger collection of legacy libraries in their official repositories.

yyyk 6y ago

Distros like to deprecate the previous version of these toolkits and not include them at all. Installing GTK1 or QT <= 4 is beyond the capacity of ordinary users (not of HN crowd of course).

laumars 6y ago
If an application in the repos depends on it, then that version of Qt or GTK will also be available in the repos. What's more likely to happen is: - either that application is either dropped from the repos for being unmaintained (if it's using a library that old then there's likely other issues with it) - or some other helpful sole would fork the project and update it to run on a newer version framework This is also very distribution specific. For example ArchLinux still supports Qt 3 applications and libraries in the community repos however I wouldn't expect the same from CentOS (though admittedly I've also not checked).
- yyyk 6y ago
  Well, our scenario is that the app is not updated, so that's kinda assumed. What usually happens is that distros drop apps due to old library version, and if the user needs it, than the user has to build all the deps, and most users can't do it. I didn't know Arch had older versions - most distros are very eager to drop, since supporting (or even compiling) these huge frameworks past EOL becomes harder and harder.
  - laumars 6y ago
    That’s the problem though, your scenario is making a boat load of assumptions to stand up a theoretical point. Assumptions that the user is running a specific distro, that they then want a specific application and that application has been unmaintained for more than 10 years. This isn’t a common scenario regular Linux folk are going to find themselves in. Plus the situation wouldn’t be any better on Windows (good luck finding the installer for software that has been abandoned 10 years ago from safe places online) nor macOS (Apple do breaking changes more frequently more than any other platform) either. And that’s without factoring in any security concerns that running software as old as that might introduce. So regardless of the platform, if it’s consumer software (ie not industrial applications or other such specialist edge case), you’d recommend the user switches to a newer and maintained alternative.
    - yyyk 6y ago
      "your scenario is making a boat load of assumptions to stand up a theoretical point" Well, that's the scenario the original post made, not mine. From my experience, this can happen albeit rarely - especially with closed source software. "specific distro" == The most popular Linux distros don't include old frameworks. "they then want a specific application and that application has been unmaintained for more than 10 years" This (for example) eventually describes pretty much 99% of games released natively for Linux, unless one goes with Steam which tries to keep stuff working (I dunno whether GoG or itch also do it). For really old software, Windows is the best bet. Even if Windows itself doesn't work (it usually does), wine might.

swiley 6y ago

TK is pretty stable and high level and allows for scripting on top of that. Plus it runs on nearly anything not just GNU/Linux.

mhd 6y ago

Note that even with Windows you often had to install some standard libraries, like MSVCR.DLL or the DirectX version du jour (and I think some VB runtimes, too). Most often redistributed with the software, so done by the installer. Although, to be fair, it might very well be the case that for a given old Linux binary, your distribution won't* have the old runtimes available. Good luck if you've got a commercial pre-press helper application that requires Qt 1.x. Other than availability, what's the big backwards compatibility killer for Linux? a.out vs. ELF? (I remember someone creating their own distribution due to the ELF/glibc shift, back in neolithic times)

sz4kerto 6y ago

Try and run an app relying on Qt4 on the most recent Ubuntu. It's a total PITA. You'd need to compile Qt4 yourself. (Not joking.)

AsyncAwait 6y ago
Last time I used Ubuntu, there were PPAs for this, but Qt 4 is outdated and does not even support HDPI, coming from a Mac user it is rich, because macOS software tends to support at most 2 releases of macOS at any given time.
laumars 6y ago
Ubuntu isn't the desktop Linux out there. There are others and some of them have a more extensive array of software available and/or a larger collection of legacy libraries in their official repositories.