3 ms·

Or Nix https://nixos.org/ https://nixos.org/ where every package is stored by a hash of its build environment. So every version can coexist.

by wscott 11y ago

baldfat 11y ago
I have been saying for years our Linux Package System is broken and antiquated. When we had 40 MB hard drives or no hard drives at all these systems made sense. Today we can have a system that just works like this or Gobo Linux. I have hopes that with containers that we will see some major distro switch (Looking at Arch Linux) to a non-shared everything libraries.
- deleted 11y ago
  [deleted]
- lsaferite 11y ago
  Well, then why have any libs if none will be shared? Why not just statically compile the application so it's a single binary?
  - baldfat 11y ago
    I love the idea EXCEPT for Desktop Enviroments. Does that mean any KDE/Gnome App has the whole desktop installed in each folder? What about OpenSSH does that mean any program that uses SSH needs its own copy and then we have 12 different versions of SSH? Its not easy but I am sure someone is smart enough to figure this stuff out. NixOS and Gobo Linux have tried.
    - digi_owl 11y ago
      The scheme that Canonical seems to be playing with is that larger projects (DEs, central libs) are put into what they call frameworks. These are packages that other packages can refer to rather than massively duplicating the content within themselves. These frameworks will in turn be versioned, so that if package X wants framework Z, while Y wants Z+1 they can both be happy without descending into dependency hell. Note that Gobolinux gets around this to a degree by using age old soname and symlinks. This in that ld and similar is pointed at a directory containing symlinks. libxyz.so.1 will be pointing to whatever is the active version of libxyz, while something like libxyz.so.1.1 will be pointing to that specific lib version. Disabling a specific lib version is done by removing the relevant symlinks. Gobolinux provides tools for doing this, but they are basically shell scripts. And so in a pinch someone can do all that manually.
  - Kristine1975 11y ago
    Security updates perhaps: If e.g. OpenSSL is shared, a single security update will fix all applications using it. And a single update will most likely be out more quickly than updates to a dozen or so applications.
    - takeda 11y ago
      The thing is that the libraries are not shared, and every application has its own version of library in its application directory. So if you would want to update OpenSSL you would have to find openssl in every single application and update (or more likely wait for vendor to release new version with more recent openssl). At that point the shared libraries are useless, they don't provide security (update in one place and have all aps using it patched), doesn't save RAM (each app loads their own version of library, instead of multiple apps sharing the same code), and you get worse performance (there's overhead for using shared libraries). What lsaferite suggested makes sense, if the library is used only by given app, why not compile it statically? You have everything in a single file, and at least you're not losing performance by using shared objects.
- wcummings 11y ago
  How does a Gobo-style package management system deal w/ security updates for shared components? Do you rely on the vendor that packages them?
  - digi_owl 11y ago
    I guess it will depend on the size of the distro project backing it. Gobo, by "virtue" of being a small group, can't provide a large store of pre-compiled packages. Thus one at present have to rely on compiling on ones own. That said, once compiled a binary package can be produced by simply creating a compressed archive of the content of /Programs/app-name/app-version (an official binary package is a bit more involved to ensure compatibility with the latest released iso). Beyond that i am not quite sure what you are asking.
- jordigh 11y ago
  The point of the FHS is not to save disk space, although that's a nice side effect. The point is to not have multiple copies of the same bug or slightly different bug across each package.

Or Nix https://nixos.org/ https://nixos.org/ where every package is stored by a hash of its build environment. So every version can coexist.

by wscott 11y ago

Or Nix https://nixos.org/ https://nixos.org/ where every package is stored by a hash of its build environment. So every version can coexist.

baldfat 11y ago

I have been saying for years our Linux Package System is broken and antiquated. When we had 40 MB hard drives or no hard drives at all these systems made sense. Today we can have a system that just works like this or Gobo Linux. I have hopes that with containers that we will see some major distro switch (Looking at Arch Linux) to a non-shared everything libraries.

deleted 11y ago
[deleted]
lsaferite 11y ago
Well, then why have any libs if none will be shared? Why not just statically compile the application so it's a single binary?
- baldfat 11y ago
  I love the idea EXCEPT for Desktop Enviroments. Does that mean any KDE/Gnome App has the whole desktop installed in each folder? What about OpenSSH does that mean any program that uses SSH needs its own copy and then we have 12 different versions of SSH? Its not easy but I am sure someone is smart enough to figure this stuff out. NixOS and Gobo Linux have tried.
  - digi_owl 11y ago
    The scheme that Canonical seems to be playing with is that larger projects (DEs, central libs) are put into what they call frameworks. These are packages that other packages can refer to rather than massively duplicating the content within themselves. These frameworks will in turn be versioned, so that if package X wants framework Z, while Y wants Z+1 they can both be happy without descending into dependency hell. Note that Gobolinux gets around this to a degree by using age old soname and symlinks. This in that ld and similar is pointed at a directory containing symlinks. libxyz.so.1 will be pointing to whatever is the active version of libxyz, while something like libxyz.so.1.1 will be pointing to that specific lib version. Disabling a specific lib version is done by removing the relevant symlinks. Gobolinux provides tools for doing this, but they are basically shell scripts. And so in a pinch someone can do all that manually.
- Kristine1975 11y ago
  Security updates perhaps: If e.g. OpenSSL is shared, a single security update will fix all applications using it. And a single update will most likely be out more quickly than updates to a dozen or so applications.
  - takeda 11y ago
    The thing is that the libraries are not shared, and every application has its own version of library in its application directory. So if you would want to update OpenSSL you would have to find openssl in every single application and update (or more likely wait for vendor to release new version with more recent openssl). At that point the shared libraries are useless, they don't provide security (update in one place and have all aps using it patched), doesn't save RAM (each app loads their own version of library, instead of multiple apps sharing the same code), and you get worse performance (there's overhead for using shared libraries). What lsaferite suggested makes sense, if the library is used only by given app, why not compile it statically? You have everything in a single file, and at least you're not losing performance by using shared objects.
wcummings 11y ago
How does a Gobo-style package management system deal w/ security updates for shared components? Do you rely on the vendor that packages them?
- digi_owl 11y ago
  I guess it will depend on the size of the distro project backing it. Gobo, by "virtue" of being a small group, can't provide a large store of pre-compiled packages. Thus one at present have to rely on compiling on ones own. That said, once compiled a binary package can be produced by simply creating a compressed archive of the content of /Programs/app-name/app-version (an official binary package is a bit more involved to ensure compatibility with the latest released iso). Beyond that i am not quite sure what you are asking.
jordigh 11y ago
The point of the FHS is not to save disk space, although that's a nice side effect. The point is to not have multiple copies of the same bug or slightly different bug across each package.