4 ms·

This seems like it's just part of the general trend of abandoning dynamic libraries (or bundling them with each app, which is almost the same thing).

by api 10y ago

SwellJoe 10y ago
I don't think that's the case here. Many of your dynamic libraries will exist in the runtime (which is a mini-OS image). And, as dependencies shift, snapshots of that runtime will allow packages to keep talking to the dynamic libs they need, while others that may upgrade to require newer deps will get a new OS image. Snapshots allow them to be small (a fedora-24 and a fedora-24.1 image might only need 1.1 times the space of fedora-24 alone, and adding fedora-24.2 might only need another 5% of space). I think folks are thinking this is like Docker. It isn't. It has surface level similarities, but it seems to be trying to solve the kinda of problems that Docker does not attempt to solve, and attempts to keep many of the good ideas from past package managers that Docker (and the like) have thrown away.
- digi_owl 10y ago
  And the problem has been solved multiple times over. https://en.wikipedia.org/wiki/Soname https://en.wikipedia.org/wiki/Soname This is just another case of having a hammer (cgroups, containers) and seeing every problem as nails. The problem is not at the kernel or OS level, it is that package manager have historically been overly rigid with regards to dependencies. And it will not surprise me at all if app devs start stuffing their "flatpaks" with all manner of libs because runtimes are not changing fast enough, or to ensure their special snowflakes get just the right environment.
  - the_why_of_y 10y ago
    Let's assume that a developer wants to distribute a binary build of their application that uses the OpenSSL library that runs on every GNU/Linux system released in the last 5 years. As you might know, OpenSSL releases a new ABI-incompatible version of their library every other year or so, and so there are at least 3 different OpenSSL ABIs / SONAMEs available in the distributions the binary build should run on. So far the only choices available (edit: for desktop applications) are either static linking OpenSSL, or abandon the idea of distro independent binaries. With FlatPak, OpenSSL can be bundled in the runtime, so multiple applications can depend on the same runtime and share one dynamic library, and benefit from the runtime getting security updates for the monthly OpenSSL CVEs instead of doing that themselves.
    - digi_owl 10y ago
      Now you are looking at distro policy, especially the likes of Debian Stable. If the package manager allows for multiple version of openssl to exist without naming shenanigans, there is nothing stopping a third party package to go on top of Debian Stable and provide the most recent ABI version. In essence you are looking for technical solutions to policy/politics...
  - SwellJoe 10y ago
    That's only one facet of the problem Flatpak is trying to solve (and it's a feature Flatpak will use). But, there are other considerations. Docker, despite its several negatives, has become popular because it begins to address the repeatable infrastructure needs of a service-based architecture. e.g. say I have 10,000 servers. I can't possibly manage them all individually. The performance of using something like Kickstart to deploy them would be problematic, and each of them has a well-defined role, so having a pre-defined image (that can evolve over time) begins to make more sense. One of the things Docker got right was taking the concept of a package up a level of abstraction; so now you don't install Apache and a million other things to get your web server deployment...you install a specific bundle of things in a pre-defined image. Maybe even an immutable image that is identical on every one of your several thousand web servers (or containers or VMs, whatever). Being immutable provides some security and maintenance benefits. Being in a compressed/snapshot-able image provides deployment speed benefits and maintenance benefits. Providing dependency management at both the individual package (like RPM/deb) level and at the higher container level is also a benefit. Docker doesn't do anything along those lines (and can't, given it's implementation). This would strap into a configuration management system nicely, as well. All of it is possible the previous way. I love RPM/yum. I love Kickstart. I love Ansible (or Puppet or Chef or Salt). Those are great tools, and you can build a repeatable infrastructure using them. But, this is another layer of abstraction, and it will enable a lot of cool stuff going forward. And, soname is still part of the equation. You've got to build these runtimes. You've got to have some way of building and versioning all the software that is in them. And, you're not going to put 30 versions of OpenSSL in a runtime...you just need the latest version with the correct ABI version compatibility for the stuff you're building against it and distributing for it.

This seems like it's just part of the general trend of abandoning dynamic libraries (or bundling them with each app, which is almost the same thing).

by api 10y ago

This seems like it's just part of the general trend of abandoning dynamic libraries (or bundling them with each app, which is almost the same thing).

SwellJoe 10y ago

I don't think that's the case here. Many of your dynamic libraries will exist in the runtime (which is a mini-OS image). And, as dependencies shift, snapshots of that runtime will allow packages to keep talking to the dynamic libs they need, while others that may upgrade to require newer deps will get a new OS image. Snapshots allow them to be small (a fedora-24 and a fedora-24.1 image might only need 1.1 times the space of fedora-24 alone, and adding fedora-24.2 might only need another 5% of space). I think folks are thinking this is like Docker. It isn't. It has surface level similarities, but it seems to be trying to solve the kinda of problems that Docker does not attempt to solve, and attempts to keep many of the good ideas from past package managers that Docker (and the like) have thrown away.

digi_owl 10y ago
And the problem has been solved multiple times over. https://en.wikipedia.org/wiki/Soname https://en.wikipedia.org/wiki/Soname This is just another case of having a hammer (cgroups, containers) and seeing every problem as nails. The problem is not at the kernel or OS level, it is that package manager have historically been overly rigid with regards to dependencies. And it will not surprise me at all if app devs start stuffing their "flatpaks" with all manner of libs because runtimes are not changing fast enough, or to ensure their special snowflakes get just the right environment.
- the_why_of_y 10y ago
  Let's assume that a developer wants to distribute a binary build of their application that uses the OpenSSL library that runs on every GNU/Linux system released in the last 5 years. As you might know, OpenSSL releases a new ABI-incompatible version of their library every other year or so, and so there are at least 3 different OpenSSL ABIs / SONAMEs available in the distributions the binary build should run on. So far the only choices available (edit: for desktop applications) are either static linking OpenSSL, or abandon the idea of distro independent binaries. With FlatPak, OpenSSL can be bundled in the runtime, so multiple applications can depend on the same runtime and share one dynamic library, and benefit from the runtime getting security updates for the monthly OpenSSL CVEs instead of doing that themselves.
  - digi_owl 10y ago
    Now you are looking at distro policy, especially the likes of Debian Stable. If the package manager allows for multiple version of openssl to exist without naming shenanigans, there is nothing stopping a third party package to go on top of Debian Stable and provide the most recent ABI version. In essence you are looking for technical solutions to policy/politics...
- SwellJoe 10y ago
  That's only one facet of the problem Flatpak is trying to solve (and it's a feature Flatpak will use). But, there are other considerations. Docker, despite its several negatives, has become popular because it begins to address the repeatable infrastructure needs of a service-based architecture. e.g. say I have 10,000 servers. I can't possibly manage them all individually. The performance of using something like Kickstart to deploy them would be problematic, and each of them has a well-defined role, so having a pre-defined image (that can evolve over time) begins to make more sense. One of the things Docker got right was taking the concept of a package up a level of abstraction; so now you don't install Apache and a million other things to get your web server deployment...you install a specific bundle of things in a pre-defined image. Maybe even an immutable image that is identical on every one of your several thousand web servers (or containers or VMs, whatever). Being immutable provides some security and maintenance benefits. Being in a compressed/snapshot-able image provides deployment speed benefits and maintenance benefits. Providing dependency management at both the individual package (like RPM/deb) level and at the higher container level is also a benefit. Docker doesn't do anything along those lines (and can't, given it's implementation). This would strap into a configuration management system nicely, as well. All of it is possible the previous way. I love RPM/yum. I love Kickstart. I love Ansible (or Puppet or Chef or Salt). Those are great tools, and you can build a repeatable infrastructure using them. But, this is another layer of abstraction, and it will enable a lot of cool stuff going forward. And, soname is still part of the equation. You've got to build these runtimes. You've got to have some way of building and versioning all the software that is in them. And, you're not going to put 30 versions of OpenSSL in a runtime...you just need the latest version with the correct ABI version compatibility for the stuff you're building against it and distributing for it.