3 ms·

Having the source code will not help you when the APIs change - see SDL1 to SDL2, Gtk1 to Gtk2 to Gkt3 -soon- to Gkt4, Qt1 to Qt2 to Qt3 to Qt4 to Qt5, etc and

Having the source code will not help you when the APIs change - see SDL1 to SDL2, Gtk1 to Gtk2 to Gkt3 -soon- to Gkt4, Qt1 to Qt2 to Qt3 to Qt4 to Qt5, etc and all the desktop environments and tons of applications wasting their time "upgrading" from lib version N to incompatible lib version N+1 because the lib's developers do not care about their users (both in the end user and library user sense) and broke backwards compatibility), just so that these applications will do the exact same thing, just now with a different API. No, backwards compatibility isn't something you solve with open source, open source is perfectly capable of breaking it in all the fabulous ways possible as has been already demonstrated many times. Backwards compatibility is something you solve by actually caring about it when you are designing your version N+1 library (and preferably, even when designing your version 1 library's API to allow for it).

ForHackernews 8y ago
> Having the source code will not help you when the APIs change Yes it will! If it's free software, you can update to use the new APIs!
- pantalaimon 8y ago
  Developer time is neither free nor infinite.
  - silversconfused 8y ago
    Your personal dev time is as limitless as your desire allows it to be.
magpi3 8y ago
In a Linux distro you specify dependencies by library version and you are never required (as far as I know) to upgrade to a new major library revision. Games compiled for SDL1 are not required to upgrade to SDL2. There are some absolutely ancient games (Xgalaga for example) that I used to play on Linux on 1996 that still play just fine today on my Debian machine.
- badsectoracula 8y ago
  Games compiled for SDL1 are not required to upgrade to SDL2, but games compiled for SDL1 will also not get any functionality introduced in SDL2 that could have been transparently made possible to them if the API wasn't broken in SDL2 - e.g. supporting alt-tab, wayland, etc. Xgalaga works because the X11 library developers have not broken backwards compatibility. This is a good thing. This is what i'm referring to when i'm talking about a library not breaking backwards compatibility and what something like Gtk and/or Qt (and, IMO, SDL) should strive for. EDIT: i give a more detailed example here - https://news.ycombinator.com/item?id=19813074 https://news.ycombinator.com/item?id=19813074
prg318 8y ago
SDL1 can be installed alongside of SDL2. Same with GTK and Qt. I really fail to see the issue here. If a developer of a Qt4 application doesn't feel like updating to Qt5, users can still use the Qt4 version with Qt5 installed in their system. Most Linux distributions still package Qt5, Qt4, Gtk3, Gtk2, Gtk1.2, SDL1.2, SDL2... On top of that, if a binary-only application really wanted to stand the test of time, it could statically link the libraries.
- pantalaimon 8y ago
  At least Debian has dropped GTK1 and qt3 - it's not trivial to get old libraries on a modern system.
- badsectoracula 8y ago
  This doesn't help much when the specific application you want to run is not available in your system because it doesn't ship Qt3 or Qt4 or Gtk1 or whatever (note that AFAIK none of these are shipped anymore in Debian sid) and it also doesn't help much if the application you are trying to run is using a library that, even though it exists in version N, there is already a version N+Y (Y=1, 2, whatever) that essentially provides the same functionality to the application but it is backwards incompatible while providing more functionality to the user that you'd like to use. To make that last part more clear, imagine a theoretical "libopenfile" library that shows a file dialog, this library in version 1 exposes a function like "open_file(const char* path);" but in version 2 they improved the GUI a bit (e.g. making the dialog make better use of screen real estate, added a create folder button, etc) and changed the function name to "lof_select_file(const char* path);" because arbitrary tidyness reasons and in version 3 they changed the signature to "lof_select_file(const char* path, unsigned flags);" and added the ability to load plugins that could provide more actions for each file in the displayed file list, show overlay icons, etc. As things are right now, a modern Linux system would need to have all three versions of the library installed - assuming the distribution cared about backwards compatibility to provide all of them instead of the latest and perhaps the previous version - meaning there would be three different libraries providing essentially the same functionality in three slightly different ways. Moreover, and also very important, version 1 applications do not get to use any improvements introduced in version 2 and neither version 1 nor version 2 can use the plugins introduced in version 3 - even though, again, all they want is to show a dialog to choose a file. The way that would have been done right is for the version 2 of the library to still export the "open_file" function but simply make it call "lof_select_file" and version 3 make a "lof_select_file2" (or "_ex" or whatever, if the reason to not do that is because you dislike the naming, you are part of the problem) that accepts flags and have "lof_select_file" call it with a default set of flags. Then everything would work, from version 1 to version 3 and all applications would get the functionality introduced in subsequent versions (and as a sidenote, no, i wouldn't remove open_file from the header files to encourage using the renamed function since backwards compatibility in source form is very important too - not everyone who gets to compile a piece of code is the developer of that code, or even a developer). Now the above is a bit of a strawman, but it is exactly the situation you get with Gtk1, Gtk2, Gtk3, Gtk4, Qt1, Qt2, Qt3, Qt4, Qt5, SDL1, SDl2, etc and pretty much most of libraries that you find on a desktop system (notable and thankful - so far - exceptions, being the X11 libraries and... Motif, although that isn't installed by default anywhere so it isn't really something you can rely on).

ForHackernews 8y ago

> Having the source code will not help you when the APIs change Yes it will! If it's free software, you can update to use the new APIs!

pantalaimon 8y ago
Developer time is neither free nor infinite.
- silversconfused 8y ago
  Your personal dev time is as limitless as your desire allows it to be.

magpi3 8y ago

In a Linux distro you specify dependencies by library version and you are never required (as far as I know) to upgrade to a new major library revision. Games compiled for SDL1 are not required to upgrade to SDL2. There are some absolutely ancient games (Xgalaga for example) that I used to play on Linux on 1996 that still play just fine today on my Debian machine.

badsectoracula 8y ago
Games compiled for SDL1 are not required to upgrade to SDL2, but games compiled for SDL1 will also not get any functionality introduced in SDL2 that could have been transparently made possible to them if the API wasn't broken in SDL2 - e.g. supporting alt-tab, wayland, etc. Xgalaga works because the X11 library developers have not broken backwards compatibility. This is a good thing. This is what i'm referring to when i'm talking about a library not breaking backwards compatibility and what something like Gtk and/or Qt (and, IMO, SDL) should strive for. EDIT: i give a more detailed example here - https://news.ycombinator.com/item?id=19813074 https://news.ycombinator.com/item?id=19813074

prg318 8y ago

SDL1 can be installed alongside of SDL2. Same with GTK and Qt. I really fail to see the issue here. If a developer of a Qt4 application doesn't feel like updating to Qt5, users can still use the Qt4 version with Qt5 installed in their system. Most Linux distributions still package Qt5, Qt4, Gtk3, Gtk2, Gtk1.2, SDL1.2, SDL2... On top of that, if a binary-only application really wanted to stand the test of time, it could statically link the libraries.

pantalaimon 8y ago
At least Debian has dropped GTK1 and qt3 - it's not trivial to get old libraries on a modern system.
badsectoracula 8y ago
This doesn't help much when the specific application you want to run is not available in your system because it doesn't ship Qt3 or Qt4 or Gtk1 or whatever (note that AFAIK none of these are shipped anymore in Debian sid) and it also doesn't help much if the application you are trying to run is using a library that, even though it exists in version N, there is already a version N+Y (Y=1, 2, whatever) that essentially provides the same functionality to the application but it is backwards incompatible while providing more functionality to the user that you'd like to use. To make that last part more clear, imagine a theoretical "libopenfile" library that shows a file dialog, this library in version 1 exposes a function like "open_file(const char* path);" but in version 2 they improved the GUI a bit (e.g. making the dialog make better use of screen real estate, added a create folder button, etc) and changed the function name to "lof_select_file(const char* path);" because arbitrary tidyness reasons and in version 3 they changed the signature to "lof_select_file(const char* path, unsigned flags);" and added the ability to load plugins that could provide more actions for each file in the displayed file list, show overlay icons, etc. As things are right now, a modern Linux system would need to have all three versions of the library installed - assuming the distribution cared about backwards compatibility to provide all of them instead of the latest and perhaps the previous version - meaning there would be three different libraries providing essentially the same functionality in three slightly different ways. Moreover, and also very important, version 1 applications do not get to use any improvements introduced in version 2 and neither version 1 nor version 2 can use the plugins introduced in version 3 - even though, again, all they want is to show a dialog to choose a file. The way that would have been done right is for the version 2 of the library to still export the "open_file" function but simply make it call "lof_select_file" and version 3 make a "lof_select_file2" (or "_ex" or whatever, if the reason to not do that is because you dislike the naming, you are part of the problem) that accepts flags and have "lof_select_file" call it with a default set of flags. Then everything would work, from version 1 to version 3 and all applications would get the functionality introduced in subsequent versions (and as a sidenote, no, i wouldn't remove open_file from the header files to encourage using the renamed function since backwards compatibility in source form is very important too - not everyone who gets to compile a piece of code is the developer of that code, or even a developer). Now the above is a bit of a strawman, but it is exactly the situation you get with Gtk1, Gtk2, Gtk3, Gtk4, Qt1, Qt2, Qt3, Qt4, Qt5, SDL1, SDl2, etc and pretty much most of libraries that you find on a desktop system (notable and thankful - so far - exceptions, being the X11 libraries and... Motif, although that isn't installed by default anywhere so it isn't really something you can rely on).