3 ms·

The biggest reason, both historical and present, that we have many different package repositories and packaging formats is because of the concept of shared libr

by belorn 8y ago

The biggest reason, both historical and present, that we have many different package repositories and packaging formats is because of the concept of shared libraries and the desired benefits: security, stability, speed, freshness of volatile data and disk usage. And from what I have seen there is only a primary alternative being proposed; containers. Have a copy of all needed libraries in every package and leave it to the developer to patch and fix security. Occasionally put a few things into the operating system, but then you have to hope that those parts don't change or you have to make different packages for different version of the operating system.

probonopd 8y ago
What we need is a clear separation between the Core OS a.k.a. base system which should be provided by every "Desktop Linux" distribution, and the rest. Applications should only use those shared libraries that come with the Core OS a.k.a. base system, and either link statically to or bundle the rest. Like an iOS application can only consume what iOS provides or bundle any additional dependencies privately. The result would be a much simpler and more resilient system (at the expense of some storage and memory overhead, which is the lesser evil imho).
- mmt 8y ago
  > The result would be a much simpler and more resilient system (at the expense of some storage and memory overhead, which is the lesser evil imho). On balance, I agree with the conclusion. However, coming from a non-desktop viewpoint (server, not embedded, though I do sympathize with the latter), I don't think it's obvious that "some" overhead is worth it, nor has it historically been worth it. At scale, size can matter, though, like I said, I think today, nobody would even notice. It's tough to "fight" that history, though, so we go through the pain of even more overhead of full virtualization before cutting it back with OS-level virtualization (a.k.a. containters) and (re-)declaring victory.

by belorn 8y ago

probonopd 8y ago

What we need is a clear separation between the Core OS a.k.a. base system which should be provided by every "Desktop Linux" distribution, and the rest. Applications should only use those shared libraries that come with the Core OS a.k.a. base system, and either link statically to or bundle the rest. Like an iOS application can only consume what iOS provides or bundle any additional dependencies privately. The result would be a much simpler and more resilient system (at the expense of some storage and memory overhead, which is the lesser evil imho).

mmt 8y ago
> The result would be a much simpler and more resilient system (at the expense of some storage and memory overhead, which is the lesser evil imho). On balance, I agree with the conclusion. However, coming from a non-desktop viewpoint (server, not embedded, though I do sympathize with the latter), I don't think it's obvious that "some" overhead is worth it, nor has it historically been worth it. At scale, size can matter, though, like I said, I think today, nobody would even notice. It's tough to "fight" that history, though, so we go through the pain of even more overhead of full virtualization before cutting it back with OS-level virtualization (a.k.a. containters) and (re-)declaring victory.