This thread is permanently archived
Container vs. Shared libs
| It is about ease of replication and not much about ease of managing a single system where you add components. The drones want quantity which shines bright rather than solid products which are well designed to function long term. Thus this container preference out there. It is the Ford-type economy for software. Multiple buggy clone copies sell multiple bug updates, robust fine tuned to last products dont.
It is not the best tech which wins, but the one which sells more.
| shared libraries without versioned symbols is the way to go.
| >>68961
Thanks for that awesome explanation. Since I don't like Ford and prefer quality about quantity and indiduals about drones, my sceptical view on this trend just leveled up.
| >>69280
Sry. for being stupid, but could you explain more exactly what you mean by 'libs without versioned symbols'?
| >>70613
Thanks, a pleasure.
Am not the author of the symbols post, but basically that post speaks of executables using shared libraries. To use the resources of these libs, the exes need to know where such and such resource are located within the lib. For this are used the symbol tables. Think of it as a table of content sheet. When libs change/get updated/rearrange their content, the symbol table also needs to change, thus 'ignorant' exes know where to find what they need....
| ... If some exe is to work with different libs or say with libA v1 and libA v2 that differ and have resources rearranged/relocated/updated/etc, they need to know of this difference and act accordingly. These happen in runtime, and is basically how some exe can work with one version of lib.dll here and another verskon there, regardless of what version this lib is.
| >>70615
basically shared libraries were created so that when something critical and widely-used gets updated, like libc or openssl, you just have to update that one package and everything else on your system will start using it after the process is restarted. Before shared libraries/dynamic loading, you would have to recompile every piece of software on your computer, and if it was closed source you would have to wait for the vendor to release a new version, [...]
| and if you missed one then you would have a security hole.
So shared libraries fixed all that. Except sometimes updates to libraries break old programs, so people invented "versioned symbols" so that programs can continue using the old and broken parts of the libraries, both making the libraries bigger and also defeating the purpose of shared libraries in the first place
| >>71169
So this could mean an old program can still run with unsecure old libs and your hardisk will blow up because of rendundancies.
Also it makes developers less interested in maintaining their software and creating well designed libraries with backward compatibility, modularity and transparency in mind.
This sounds pretty much like proprirtary stuff like windos or the rotten codebase like you have in js development. Insecure, buggy and blowing up your Harddisk.
This thread is permanently archived
| Yo, there I a strange 'trend' comming up that really Anita me.
Since I'm used to work with 'old' hardware I switched years ago from windos to a linux distro. I liked the concept of package-management providing shared libs based on a dependency tree. My OS is also my dev-environment.
Now there is a lot of virtualization and container systems comming up like virtualenv, docker, appimages etc. used in many new projects. And this pisses me real off.
Any opinions on this here?