I think a lot of the reaction is alright in here. But I didn’t really get the negative reaction to allowing multiple versions installed. Isn’t that good? It certainly makes it easier to support the slow movement towards a new API.
Whilst I agree that it is good to allow different versions to be installed side-by-side, you don’t want to have 5 different GTK versions on your system all at once because the API changes too rapidly.
Can you imagine a scenario where:
This would be madness. It would be a nightmare for packagers and what’s more, my disk is full of GTK!
So, after all our years of pointing and laughing, Unix systems are getting closer and closer to their own version of DLL hell :(
On Gentoo (if I’m not mistaken) my disk was full of autoconf/autotools, including a wrapper to distinguish between various versions. The distribution had to autoconf its autoconf! Madness.
This is one area where I like how nixos/nix handles things. Have as many versions of whatever you want, but you’ll still have a deterministic build and not have to worry about them.
This is exactly the scenario the .NET framework is in.
You’d think you could target older versions of .NET and be safe on all newer Windows releases…but surprise! .NET 3.5 is not installed on newer versions of Windows. If you use an app that depends on it, Windows prompts you to install it, which isn’t terrible, but it’s a subpar UX, especially in disconnected environments.
The result: you always bundle the .NET framework installer with your installer.
.NET 3.5 is actually just an additional set of libraries (and if you want to count it, a newer version of the C# language, which gets compiled down to .NET 2 CIL anyways) on top of 2.0, so it’s even more wasteful when you realize it’s all that for an older version of LINQ and WPF.
Well, It’s not the ability to install incompatible versions side-by-side that bothers me, so much as the fact that they are incompatible:
the real problem is the rapid-fire development with lack of API/ABI stability producing a plethora of incompatible versions. Why is this even necessary?
In general it can be, but I question whether or not an open source library like GTK has the resources to do all the complicated and extensive matrix testing that’s required to actually make this be workable without shipping broken apps to your customers all the time, or placing an undue load on developers.
Code reuse via shared libraries seems like more trouble than it’s worth, given how cheap storage has become and how little code actually gets shared in practice. I prefer the Go approach of just statically linking only the code that is actually used.
Shared library is not only about storage. It gets really usefull when you have to apply security patches. Static linking involve rebuilding everything to pull in dependancies changes vs updating a a single package and be done with it.
In theory, yes. In practice, you need to update several versions of each package because of the problem being discussed here.
I’m sure the Go folks would bring up LD_LIBRARY_PATH whenever security is mentioned :)
Libraries are not so much about reducing storage requirements but about having a clear boundary where you can plug a new implementation of the same API. Static linking takes that possibility away from the user.
That’s an advantage of dynamically linking your libraries, but not why the industry started doing it. Saving on disk use was a huge factor in the design of software 20 years ago - see also e.g. installing packages system-wide instead of per-user.
Gtk 1 is not long gone, for me at least. Not while XMMS is still around.
I wish I’d realised that XMMS still used Gtk 1 when I was writing the piece; the fact that there is software out there still using old versions of the API really bolsters the point that breaking your API is something to be avoided.
Audacious went from gtk-3 back to gtk-2 and are now in the process of moving to Qt 5!
I did not know this.
Either way, it’s not Gtk 1 ;)
If we want to change the functionality of a library function foo() incompatibly the user might get an error message telling him that the function is missing, or the program might crash. A lot of guidance in writing usable libraries amounts to “don’t do this”, but Gtk being under development for almost twenty years now, and any library under development for twenty years either needs to be:
What can we do besides “not” change things? Some things I’m thinking about:
Better who-calls information. Github is sufficiently popular it might be possible to find out what programs depend on your libraries and then allow the library-author implement the patches. This is very promising, and seems like a tooling problem with existing library distribution
This would be trivial if there were one global distributed monorepo containing all free software. Github eat your heart out :)
I saw the words “rotten foundation” in the title and then saw “wordpress.com” in the URL. I was amused.