Would you mind explaining more about this? I'm not sure I understand completely what you mean -- glibc is basically impossible to statically build and is linked. It's part of the reason why "static" builds don't really exist on debian and many other distributions. Correct me if I'm wrong but glibc just isn't portable -- this is why I mentioned having to go into alpine & build with musl libc. Seems like the electron project has chosen not to support it[0].
Another aspect worth considering is the software logistics/delivery problem -- it absolutely would be great to have dynamically linked software updates if:
1) Your software could always ensure to get the version it expects with the version it expects
2) It wasn't hard to distribute the software (AKA X > 5 providers are hard to package for)
Assuming I'm not completely misunderstanding your point, if the electron based applications you're discussing were truly fat binaries, nothing could break them, outside of CPU architecture level impropriety.
BTW, there are some systems like Nix & Guix that have solved #1 -- it's extremely easy to ensure that your program gets the exact version of some dependency.
Another aspect worth considering is the software logistics/delivery problem -- it absolutely would be great to have dynamically linked software updates if:
1) Your software could always ensure to get the version it expects with the version it expects
2) It wasn't hard to distribute the software (AKA X > 5 providers are hard to package for)
Assuming I'm not completely misunderstanding your point, if the electron based applications you're discussing were truly fat binaries, nothing could break them, outside of CPU architecture level impropriety.
BTW, there are some systems like Nix & Guix that have solved #1 -- it's extremely easy to ensure that your program gets the exact version of some dependency.
[0]: https://github.com/electron/electron/issues/9662