It just crossed my mind that, at some point in history,
every software had their own library shipped with them,
which made them big. So we thought why don't we all put
common useful code in Dynamic libraries that are
shipped just one time for all the software that's on a
given system, that way, any software that needs, say,
the math sin function can just load the libm.so library
and use it from there, instead of every software having
its own math library inside it. It also makes
maintaining the software easier. But we forgot that
libraries are also software in their own right and they
evolve just as software do : new functions get added,
and the last version of your favorite software needs a
newer version of that library to work. At the same time,
critical parts of your system need the old version !
So we decided to create containers, virtual
environements, and technologies like snaps... aren't we
going back to the original state where every software
had their own libraries and dependencies shipped with
them ? what are your thoughts ?

Microsoft windows can keep that. Having 12 different versions of the same library on a box. I like the linux way, you only need a library once. Keeping everything matching is what a package manager is for. It works well, and the file tree is small.

You can always install something to a directory in $HOME and not mess up the whole file tree.

that is an interesting question. snap, appimage looks like that, but don't forget now we have VM, containers, multithreading. Sometimes I need to reboot to a different OS to use my [other] software. Sometimes I want to be more secure.
And now we have uncountable number of programs created by different people.

What are containers for anyway? I can understand the use of something like virtualbox, which enables you to run a completely different OS (so you can play games on Windows without having to dual-boot). But why do people want to have bits of Linux partitioned off in this way?

Thanks, Pan. But does that mean that the software in the container has to be the same OS, only with some bits different (for example different library versions)?

container uses the kernel of the OS, so it cannot be different. container has no full access to the system (hardware), but probably that is not that important. Otherwise you can put a [slightly] different OS into the container.

1 members found this post helpful.

Interesting thoughts.
But thankfully there's still plenty of "real" Linux distributions and software around; I don't see the glorious concept of package management & shared libraries going away anytime soon.
Going full circle would mean that a) containers are the new default - I disagree - and b) we actually know where we started from - do we?

The original purpose of containers was to provide security amongst several users on the same machine. Red Hat took the chroot jail concept and made the separation between users even stricter. Thus the accountants could not access the engineering specifications and the engineers could not access the payroll files and so on. It also helps in external security because if one user is hacked the intruder cannot then use that user's ID as a base to attack other users on the same system. The original intent was not to have bits of Linux partitioned off. That is a secondary effect of having users more strictly partitioned off from each other.

-------------------------
Steve Stites

1 members found this post helpful.

Not quite. In a container or a VM, you run several processes that share libraries.

You encapsulate applications in containers and VMs for security reasons, but also to allow your software to be independent of the platform (the original promise of Java, now fulfilled by Docker). Platform independence requires shipping your own libraries, that's true.

Not full circle, but perhaps half circle?

I can't comment on snaps.

Docker is the new Java

Tried a app image yesterday and it required a library like any other program. Compiled it and now it requires another one :P (and now I don't know the correct version to be compiled, at least until someone on its mailing list reply to my question)

That's not supposed to happen or I am understanding things terribly wrong

On my system there is a
...

appimage (the app itself) should assume a working OS with a kernel, libc and some other base packages.
There can be incompatibilities. But without details hard to say anything [more]