6 ms·

This shows exactly what i mean (and i did note that Qt is at least better than Gtk here). An application written in 1995 against the Qt1 API will not work on Q

This shows exactly what i mean (and i did note that Qt is at least better than Gtk here). An application written in 1995 against the Qt1 API will not work on Qt5 because both the API and the ABI has been broken. A user who wants to run such an application (not necessarily released in 1995, Qt1 was in use into the very early 2000s, even though Qt2 was already out) is not able to do so. A developer who wants to modify such an application has to become familiar with both Qt1 and Qt5. In contrast an application written in 1995 that uses Win32 will run out of the box in Windows 10 without any changes. A user can run such an application perfectly fine (and personally i have several applications like that that i'm using) and a developer who wants to work with the code will be able to focus on the application itself (since chances are he already learned Win32 at the past if he worked in any other Win32 program). As an example, some time ago Microsoft released the source code of File Manager which dates back to ~1990 - i was able to navigate that code easily and added the ability to filter a window's contents using multiple wildcards. (note that in both cases i am assuming the applications do not do anything stupid that happened to work at the time but doesn't work nowadays) An application may not even be maintained any more. Or it may be maintained but the user(s) might dislike the changes (e.g. i like Paint Shop Pro 7, released in 2000, but i never liked the UI overhaul that PSP8 got and nowadays after Corel bought the software they have severely... well... gimped it :-P - similarly i do not like the changes introduced in Blender 2.8 so i stick with 2.79 and i know a very talented artist who still uses Photoshop 5 - not CS5, plain 5). Those few days are also very optimistic and really depend a lot on the software in question. AFAIK Lazarus, for example, took ages to update form Qt4 to Qt5 (same story, but much worse due to all the breakage Gtk introduced, with Gtk3 which still isn't really usable). And as i wrote above, most of the time, they are a waste of time. Adding support for touch screens and hidpi (not sure what you have in mind with permission requesting, so i ignore that) doesn't require breaking your API nor your ABI. EDIT: BTW, it isn't impossible to have Windows-like backwards compatibility on Linux, here is a screenshot[0] from a toolkit i used to work on at the past showing the same binary working in both 32bit Red Hat from 1997 and 64bit Debian from 2017 - essentially 20 years of backwards binary compatibility (the colors are off because i didn't bother to implement indexed color support). It is just that the toolkit maintainers do not care, but it is perfectly possible to do that if you care. [0] https://i.imgur.com/YxGNB7h.png https://i.imgur.com/YxGNB7h.png

pxc 7y ago
So to some extent this just reflects my prior ‘commitment’ (it doesn't feel like one at this point, because it follows from many, many preferences about what I like to use) to a Linux/free software life, but I just... don't use unmaintained software and the idea of doing so kinda disturbs me. Maybe art stuff is kinda special here? On the ‘disk space is cheap’ side of things, packaging strategies like those of Nix and Guix can go a long way toward solving the human-level problem here; I can install packages that have long been removed from NixOS on current NixOS systems just by pointing to the old copies of the package definitions. That means that if I want a Qt3 application and Qt3 has been removed, I can install it just by pointing my package manager to a copy of the package definitions from way back when that application and its toolkit dependencies were still included. App containerization stuff like Flatpak also seems like another good way to mitigate this issue without committing distros to eternal maintenance of each major version of each GUI toolkit. What do you think? Is the future for backwards compatibility of end-user applications on Linux brighter than its past despite the persistence of the API-and ABI-level churn problem?
- badsectoracula 7y ago
  Honestly i do not think that bundling everything to a container is really a solution - more of a hacky workaround for a problem that shouldn't exist. It does solve the "old program doesn't run" issue, but doesn't solve anything else. For example your old program doesn't receive new features through the shared libraries it uses - a simple example i gave elsewhere was old Windows applications receiving the ability to input emoji in recent updates to Windows 10 even though emoji wasn't a thing (outside Japan at least) when most of them were written. It also doesn't solve the issue at all from the developer's side. A developer who comes later to an application still has to find old development libraries and make sure they work on his modern system and/or update all the code (perhaps without even knowing how the original program worked). And developers who maintain an application still have to waste time and resources in keeping up (see Xfce as an example). FLOSS doesn't really solve this - if anything your average (big) distro repository is full of programs using several different "versions" of toolkits and other APIs. At "best" (from the distro maintainers perspective, not necessarily form the users' perspective) the distro drops applications. It does help with having the potential of fixing things, but that is all that there is to it - the actual effort (and thus time) needed largely depends on how much things have broken. As a personal example, a few years ago i decided to try one of the very first web browsers made, MidasWWW. I downloaded the code and tried to compile it. But of course it didn't compile out of the box, having the source wasn't much of a help here. Now, i am a bit persistent, so i decided to fix it and after a while i ended up with this: https://i.imgur.com/W37vhBW.png https://i.imgur.com/W37vhBW.png This is an example of what i mentioned in my comments here: the browser was written in Motif and Motif has generally been API and ABI stable over the years (it'd be nice if its theming support was improved - without breaking backwards compatibility of course - as i think that would make it more popular among developers) so i didn't had to do almost anything. But at the same time MidasWWW was written in some old Unix workstation that had a modified version of Motif which was incompatible with the mainline Motif - the result is the panel at the top being inside the content area instead of on top of it. I didn't knew about that, i actually realized after i made that shot :-P and i couldn't fix it because i am not really familiar with Motif and especially not familiar with the modified version that the workstation used - but i'd need to at least know something from both to figure out what changes i need to make. And see, that was just a little breaking incompatibility between versions. Having access to the source and Motif being backwards compatible helped to get it compiling, but didn't help with having it work properly because there was a breaking change somewhere in between. And since the original developers aren't around, it was up to me alone to figure things out - to do it properly, i'd have to spend considerable time. Time that i didn't want to bother spending, so i didn't :-P

pxc 7y ago

So to some extent this just reflects my prior ‘commitment’ (it doesn't feel like one at this point, because it follows from many, many preferences about what I like to use) to a Linux/free software life, but I just... don't use unmaintained software and the idea of doing so kinda disturbs me. Maybe art stuff is kinda special here? On the ‘disk space is cheap’ side of things, packaging strategies like those of Nix and Guix can go a long way toward solving the human-level problem here; I can install packages that have long been removed from NixOS on current NixOS systems just by pointing to the old copies of the package definitions. That means that if I want a Qt3 application and Qt3 has been removed, I can install it just by pointing my package manager to a copy of the package definitions from way back when that application and its toolkit dependencies were still included. App containerization stuff like Flatpak also seems like another good way to mitigate this issue without committing distros to eternal maintenance of each major version of each GUI toolkit. What do you think? Is the future for backwards compatibility of end-user applications on Linux brighter than its past despite the persistence of the API-and ABI-level churn problem?

badsectoracula 7y ago
Honestly i do not think that bundling everything to a container is really a solution - more of a hacky workaround for a problem that shouldn't exist. It does solve the "old program doesn't run" issue, but doesn't solve anything else. For example your old program doesn't receive new features through the shared libraries it uses - a simple example i gave elsewhere was old Windows applications receiving the ability to input emoji in recent updates to Windows 10 even though emoji wasn't a thing (outside Japan at least) when most of them were written. It also doesn't solve the issue at all from the developer's side. A developer who comes later to an application still has to find old development libraries and make sure they work on his modern system and/or update all the code (perhaps without even knowing how the original program worked). And developers who maintain an application still have to waste time and resources in keeping up (see Xfce as an example). FLOSS doesn't really solve this - if anything your average (big) distro repository is full of programs using several different "versions" of toolkits and other APIs. At "best" (from the distro maintainers perspective, not necessarily form the users' perspective) the distro drops applications. It does help with having the potential of fixing things, but that is all that there is to it - the actual effort (and thus time) needed largely depends on how much things have broken. As a personal example, a few years ago i decided to try one of the very first web browsers made, MidasWWW. I downloaded the code and tried to compile it. But of course it didn't compile out of the box, having the source wasn't much of a help here. Now, i am a bit persistent, so i decided to fix it and after a while i ended up with this: https://i.imgur.com/W37vhBW.png https://i.imgur.com/W37vhBW.png This is an example of what i mentioned in my comments here: the browser was written in Motif and Motif has generally been API and ABI stable over the years (it'd be nice if its theming support was improved - without breaking backwards compatibility of course - as i think that would make it more popular among developers) so i didn't had to do almost anything. But at the same time MidasWWW was written in some old Unix workstation that had a modified version of Motif which was incompatible with the mainline Motif - the result is the panel at the top being inside the content area instead of on top of it. I didn't knew about that, i actually realized after i made that shot :-P and i couldn't fix it because i am not really familiar with Motif and especially not familiar with the modified version that the workstation used - but i'd need to at least know something from both to figure out what changes i need to make. And see, that was just a little breaking incompatibility between versions. Having access to the source and Motif being backwards compatible helped to get it compiling, but didn't help with having it work properly because there was a breaking change somewhere in between. And since the original developers aren't around, it was up to me alone to figure things out - to do it properly, i'd have to spend considerable time. Time that i didn't want to bother spending, so i didn't :-P