
Creating bundles with guix pack - davexunit
https://www.gnu.org/software/guix/news/creating-bundles-with-guix-pack.html
======
rubiquity
Guix and Nix lack the hype of technologies/buzzwords like Docker and anything
container related, but they look incredibly pragmatic and easy to use.

Whenever I look at containers I always think they were started with trying to
solve the problem of app packaging but at some point they tugged too hard on
the tablecloth and all the other virtualization problems came tumbling down,
too. I guess you can avoid a lot of these if you stick to running 1 container
per host.

Anyway, Guix looks super user friendly and I'm going to give this a try!

~~~
_ibu9
Yeah Docker and friends exist basically because the industry is blissfully
unaware of nice things like Nix.

~~~
moosingin3space
Not exclusively. If I want to pay someone for support for running NixOS-based
servers, who do I pay? Does NixOS have a support term anywhere near Red Hat
(or even Ubuntu)? What about the awkward CLI UX? What about a turn-key
solution to deploy my app? These questions are reasonably well answered with
Docker, less so with Nix/NixOS.

I say this as someone who really likes the ideas of Nix. In fact, I see the
benefits of Docker as being solved reasonably well by Nix:

* Isolation of multiple applications on the same server are handled by NixOS containers, which use the same configuration as a NixOS system and use things like cgroups and namespaces,

* Immutable/declarative deployments (through things like docker-compose) are elegantly handled through nix-expressions,

* Multiple versions of a dependency are handled through the nix store.

I think a good measure would be to provide good tooling for generating Docker
images from Nix, and this is what `guix pack` can do today. Once Nix has
gotten over these pains, it can become a good developer tool, and from there,
ops may choose to adopt it.

~~~
equalunique
This company uses Nix & recently funded certain features. If you really want
some help with Nix, they might have expertiese for you:
[http://www.tweag.io](http://www.tweag.io)

~~~
moosingin3space
I was making a point, not actually looking for purchasing a service like this.

------
bandrami
I really love GNU GUIX SD (the distro based on this package manager). I just
wish the linux-libre crew would bite the bullet and simply publish an actual
HCL. "Some transmitters with this chipset may not work because they require
non-free firmware (that we deliberately changed the kernel to refuse to load)"
doesn't really work for me.

~~~
moosingin3space
The district looks very consistent and nice. I wish there was a version that
did have firmwares so those of us with hardware that requires non-free
firmware could use it. Yeah, idealism of FSF, but I'm not in a position to buy
a Linux-libre-compatible machine right now.

~~~
rekado
FWIW: it's not hard to obtain hardware that works with Linux-libre. My main
machine is a Thinkpad X200S where the restrictive Lenovo BIOS has been
replaced with Libreboot, allowing me to install a WiFi card from Tehnoetic
(using the Atheros driver).

I have a couple of other machines and only one of them has reduced
functionality when using Linux libre (e.g. the on-board Radeon graphics chip
needs nonfree firmware for higher resolutions).

Guix and GuixSD makes it easy to use a custom kernel package, so you can
choose to use a blobby kernel, if you can accept that.

~~~
davexunit
To share my own story, I flashed a hacked version of the proprietary BIOS on a
Thinkpad X220 and was able to replace the Intel wireless chip with an Atheros
chip. At the time Libreboot wasn't available, but it could still be a viable
method of using a newer Thinkpad with a fully free OS, downside being that the
proprietary BIOS is still in use.

------
codemac
Wouldn't this all be a bit easier if the hashes in guix/nix were relative to
some global destination store location, rather than /nix or /guix?

~~~
rekado
What would that look like?

~~~
codemac
I need to look at how pack is implemented, maybe I'm missing something. I
already used this to install guile 2.2 on a debian machine, so I'm excited for
this development.

But to clarify my point - instead of all the content hashes being based on
"/guix/store", they'd be based on "guix/store", which would be relative to a
configured "store root" to the daemon (or defaulting to /).

Then packages _generated_ would also have relative links, thus "installing a
package from guix" would just be a matter of downloading the dependency graph,
and tucking away wherever you please.

~~~
davexunit
Without using absolute file names you'd have lookup problems everywhere.

~~~
codemac
Yeah, ran into this when thinking more about this on the bus. Sorry for the
distraction.

