

Omnibus – Dependency Isolation Without Docker - duggan
https://blog.barricade.io/omnibus-dependency-isolation-without-docker/

======
davexunit
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
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
>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
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.

------
atom_enger
I've been using Omnibus extensively since they introduced it at
ChefConf'13...and I just spent the last two weeks cleansing my infrastructure
of anything Omnibus related in favor of using Packer + Amazon AMI's.

Some projects may benefit from using Omnibus; being able to produce
deliverables which are just installed by the package manager. However, there
is a significant learning curve and investment of time required for the
debugging process in order to get __your __package building with Omnibus.

I finally said screw all that and I've resorted to shell scripts + packer
building my images on amazon. Now my builds don't require a complicated
omnibus builder host to be configured, or even ruby to be installed and god
damnit, I don't have to worry about doing a bundle update to get the latest
chef-sugar or omnibus gem to get it to work.

I'm tired of these complicated systems. Every new piece of tech in your stack
should be considered carefully. I could barely explain Omnibus to my dev team,
even though I knew exactly how it worked and how all the packages were built
on every build.

Omnibus is a great project with a lot of contributors, but users beware - it
comes at a price of time and complexity.

~~~
duggan
Agree on all points, particular about weighing up the pros and cons. If you
have full control of your stack, I would say Omnibus is a waste of time.

It is without a doubt most useful when you do not control the environment
where your code is going to be deployed.

~~~
atom_enger
Yeah, that's precisely where it became useful. Deploying our code into a
datacenter with extremely strict security requirements(meaning no bundle
install to get deps on the host, everything had to come with).

------
duggan
Someone also pointed me to HashDist
([https://hashdist.github.io/](https://hashdist.github.io/)) which looks like
another isolation framework, but written in Python.

