I wouldn’t expect them to have many libraries in common, other than platform libraries like libc, since they have completely different purposes.
I was under the impression that Docker is for server applications. Is it even possible to run a GUI app inside a Docker container?
Also, if you are going to make something that have more than one binary
If they’re meant to run on the same machine and are bundled together in the same container image, I would call that a questionable design choice.
In the time i was thinking about some kind of toolkit installed though distrobox. Distrobox, basically, allows you to use anything from containers as if it was not. It uses podman, so i guess it could be impossible to use docker for GUI, although i cant really tell.
inlining is, as matklad once put it, the mother of all other optimizations. Dynamic linking leaves potentially a lot of performance on the table.
Yes, but static linking means you’ll get security and performance patches with some delay, while dynamic means you’ll get patches ASAP.
Yeah, but there’s by lot more security improvement by having ability to apply fix for severe vulnerability ASAP than weakening from possible incompativilities. Also, i wonder why i never brought it up, shared libs are shared, so you can use them across many programming languages. So, no, static is not the way to replace containers with dynamic linking, but yes, they share some use cases.
Yeah, but there’s by lot more security improvement by having ability to apply fix for severe vulnerability ASAP than weakening from possible incompativilities.
Um, we’re talking about undefined behavior here. That creates potential RCE vulnerabilities—the most severe kind of vulnerability. So no, a botched dynamically-linked library update can easily create a vulnerability worse than the one it’s meant to fix.
Also, i wonder why i never brought it up, shared libs are shared, so you can use them across many programming languages.
Shared libraries are shared among processes, not programming languages.
In the time i was thinking about some kind of toolkit installed though distrobox. Distrobox, basically, allows you to use anything from containers as if it was not. It uses podman, so i guess it could be impossible to use docker for GUI, although i cant really tell.
Yes, but static linking means you’ll get security and performance patches with some delay, while dynamic means you’ll get patches ASAP.
Some claim this doesn’t work in practice because of the ABI issues I mentioned earlier. You brought up Semver as a solution, but that too doesn’t seem to work in practice; see for example OpenSSL, which follows Semver and still has ABI issues that can result in undefined behavior. Ironically this can create security vulnerabilities.
Yeah, but there’s by lot more security improvement by having ability to apply fix for severe vulnerability ASAP than weakening from possible incompativilities. Also, i wonder why i never brought it up, shared libs are shared, so you can use them across many programming languages. So, no, static is not the way to replace containers with dynamic linking, but yes, they share some use cases.
Um, we’re talking about undefined behavior here. That creates potential RCE vulnerabilities—the most severe kind of vulnerability. So no, a botched dynamically-linked library update can easily create a vulnerability worse than the one it’s meant to fix.
Shared libraries are shared among processes, not programming languages.
You still can use them in any programming language