5 ms·

Omnibus does nothing to resolve the real issues behind dependency management, it just masks it by bundling everything in a single package. This approach is ver

Omnibus does nothing to resolve the real issues behind dependency management, it just masks it by bundling everything in a single package. This approach is very bad because it burdens the developer with providing security fixes to bundled applications, and it burdens the user because they now depend on one or more third parties for security to updates to bundled software that could be duplicated in many such packages. The real solution is to use a package manager that doesn't install everything into a global /usr directory where only one version of any given piece of software can exist. I recommend exploring what GNU Guix and Nix do to solve the dependency isolation problem without introducing the harmful side-effects of bundling. They are general-purpose, fit for packaging any type of software, and offer additional features beyond dependency isolation such as atomic upgrades/rollbacks, unprivileged package management, and reproducible builds with a complete, precise dependency graph all the way down to the coreutils/gcc/etc. that bootstrapped it.

FooBarWidget 11y ago
As opposed to Docker which also bundles everything, or Go which basically statically links everything? And what if your goal is to distribute software to users that may be running any arbitrary OS? You can't tell them "install Guix, learn how to use it, then use Guix to install my app". You'll lose a lot of users that way. At the end of the day, users care most about getting stuff done. I am the author of a popular app that is written in C++ and uses Boost. Many users literally begged me to bundle Boost because installing Boost is so much of a pain for them.
- davexunit 11y ago
  >As opposed to Docker which also bundles everything, or Go which basically statically links everything? Yes, you've identified a bad trend. I am trying to raise awareness to stop it. >And what if your goal is to distribute software to users that may be running any arbitrary OS? You can't tell them "install Guix, learn how to use it, then use Guix to install my app". You'll lose a lot of users that way. You can actually use Guix to export the closure of the build and distribute that, if that's your thing. We do this for Guix itself to greatly simplify the installation process for new users, though for your use-case there would be some adjustment needed. The resulting binary distribution would work on any GNU/Linux system. Nix additionally offers OS X support. But yes, not everyone's use-case can be covered by Guix right now, but I strongly feel it's the direction we should be moving in.
  - duggan 11y ago
    Sounds interesting, I'm familiar with Nix, but not Guix. The core tenets of Nix really resonate with me, and you're 100% right in your parent post: this does not solve dependency management. It is a hack which trades long term reliability for short term stability and ease of installation. It is not The Answer, it's just an answer until we (and I'm glad to see there are people like yourself on the case) can do better.
- vezzy-fnord 11y ago
  Well, first of all, this isn't about user acquisition. It's about solving technical problems. Linking strategy is a totally orthogonal concern to package management, though I prefer static linking myself for not having to deal with the broader issues of the shared library namespace.
GlennS 11y ago
How well does Nix interact with inherently stateful things like databases? If I'm deploying a newer version of some project, which depends on a more recent version of a database which requires some schema migration (e.g. my PostGIS types are out of date and need upgrading), what happens to my data?
- davexunit 11y ago
  >How well does Nix interact with inherently stateful things like databases? This is a frequently asked question. Nix/Guix do not interact with such files, and we make it a point to differentiate between stateful and stateless. Nix and Guix manage the stateless, deterministic stuff, and system services or other mechanisms manage the stateful stuff. For example, there's a postgresql package in Guix, but installing it doesn't create a db cluster in /var/lib, it just installs the binaries, docs, etc to the user's package profile. However, GuixSD, the distro built on Guix, comes with a postgresql system service that creates the system db cluster before launching the postgresql server. In other words, stateful things are handled at a different layer than the packaging layer. If a new version of an application requires a schema migration, then that would be something for a system service to perform with the updated binaries from the package manager. You still need to take care to back up your databases, home directories, etc.

FooBarWidget 11y ago

As opposed to Docker which also bundles everything, or Go which basically statically links everything? And what if your goal is to distribute software to users that may be running any arbitrary OS? You can't tell them "install Guix, learn how to use it, then use Guix to install my app". You'll lose a lot of users that way. At the end of the day, users care most about getting stuff done. I am the author of a popular app that is written in C++ and uses Boost. Many users literally begged me to bundle Boost because installing Boost is so much of a pain for them.

davexunit 11y ago
>As opposed to Docker which also bundles everything, or Go which basically statically links everything? Yes, you've identified a bad trend. I am trying to raise awareness to stop it. >And what if your goal is to distribute software to users that may be running any arbitrary OS? You can't tell them "install Guix, learn how to use it, then use Guix to install my app". You'll lose a lot of users that way. You can actually use Guix to export the closure of the build and distribute that, if that's your thing. We do this for Guix itself to greatly simplify the installation process for new users, though for your use-case there would be some adjustment needed. The resulting binary distribution would work on any GNU/Linux system. Nix additionally offers OS X support. But yes, not everyone's use-case can be covered by Guix right now, but I strongly feel it's the direction we should be moving in.
- duggan 11y ago
  Sounds interesting, I'm familiar with Nix, but not Guix. The core tenets of Nix really resonate with me, and you're 100% right in your parent post: this does not solve dependency management. It is a hack which trades long term reliability for short term stability and ease of installation. It is not The Answer, it's just an answer until we (and I'm glad to see there are people like yourself on the case) can do better.
vezzy-fnord 11y ago
Well, first of all, this isn't about user acquisition. It's about solving technical problems. Linking strategy is a totally orthogonal concern to package management, though I prefer static linking myself for not having to deal with the broader issues of the shared library namespace.

GlennS 11y ago

How well does Nix interact with inherently stateful things like databases? If I'm deploying a newer version of some project, which depends on a more recent version of a database which requires some schema migration (e.g. my PostGIS types are out of date and need upgrading), what happens to my data?

davexunit 11y ago
>How well does Nix interact with inherently stateful things like databases? This is a frequently asked question. Nix/Guix do not interact with such files, and we make it a point to differentiate between stateful and stateless. Nix and Guix manage the stateless, deterministic stuff, and system services or other mechanisms manage the stateful stuff. For example, there's a postgresql package in Guix, but installing it doesn't create a db cluster in /var/lib, it just installs the binaries, docs, etc to the user's package profile. However, GuixSD, the distro built on Guix, comes with a postgresql system service that creates the system db cluster before launching the postgresql server. In other words, stateful things are handled at a different layer than the packaging layer. If a new version of an application requires a schema migration, then that would be something for a system service to perform with the updated binaries from the package manager. You still need to take care to back up your databases, home directories, etc.