Why do we need appimage when we can have single binary statically compiled executable?
Additionally, I can’t really understand why are dynamically linked libraries so popular and how on earth anyone who ever had a “.dll / .so not found” error thinks this is a good idea.
The main idea as far as I understand was to be able to share code which I think everyone knows work only in theory, besides would it not be easier to just recompile the executable from source with updated dependency statically linked?
Other idea behind dlls were that you could replace a dll with different dll as long as the api was compatible which is very unlikely scenario for average people.
Yet another possible advantage would be that the library code is shared so it takes less space on disk which might be true for some libraries which are very common but on the other hand static compilation only includes the part of library code that is used by the program so it takes less space anyway and is more optimized.
So the reasons to use the dlls can be easily dismissed.
About the disadvantages - if the dll is not present the program will not work. It’s quite simple and in my view if you create a program which does not work by itself then that’s a failure on your side.
The dlls are just nightmare most of the time, static compilation for the win. (pic for attention)
No one seems to mention license considerations when talking about static linking. Even if your app is open source, your particular license may not be legally compatible with the GPL, for example. 3BSD, MIT, and Apache most likely don’t change in a single binary but it’s kind of a new thing that no one was really thinking of before when mixing licenses together.
I think this default okay assumption comes from most developers having a cloud-centric view where there’s technically no “distribution” to trigger copyright.
Even in the cloud you need to consider licenses such as the AGPL. Personally I don’t get this almost apathetic approach many developers have towards licensing and abiding by licenses.