undefined | Better HN

0 pointsEricson231410y ago0 comments

I'm a developer. I used it.

The important thing is that the underlying idea is rock solid, and the work of taming all the crapily packaged software out there is mostly done. So yes there is work to do but its already getting easier. Big todos:

- Proper CI. We need to not merge PRs until we know the merge commit builds. (Travis is wrong in this regard.)

- Sane CLI. Things change over a decade (cough git cough), but good news is were going to replace the whole damn thing 0-fucks given for backwards compat and make something sane even for those that don't appreciate/understand the underlying elegance.

- Support for institutional installations: A central build daemon + farm is a pretty lame say to synchronize things. Should make it so anybody can build stuff, and anybody can share binaries with those that trust them, and shared NSF store or equivalent for de-dup.

None of these things are hard at all.

0 pointsEricson231410y ago0 comments

I'm a developer. I used it.

- Proper CI. We need to not merge PRs until we know the merge commit builds. (Travis is wrong in this regard.)

None of these things are hard at all.

0 comments

4 comments · 1 top-level

rekado10y ago· 3 in thread

> Support for institutional installations: A central build daemon + farm is a pretty lame say to synchronize things. Should make it so anybody can build stuff, and anybody can share binaries with those that trust them, and shared NSF store or equivalent for de-dup.

At the research site where I work as a software person, we use a central guix-daemon managing a shared NFS store. Anyone can build stuff and manage their own software profiles from cluster nodes. Works very well for us and gets us a big step closer to reproducible science.

Sharing build artifacts also works with Guix. You can either export from and import items to the store or use "guix publish" to share items via HTTP.

tgamblin10y ago

How does this work security-wise? Can any user deploy on your clusters? AFAIK Guix requires root/chroot. This would never fly at our site...

rekado10y ago

The daemon runs as root (on one server that has write access to the shared store) to spawn build processes in chroots (work is underway to use user namespaces where possible). The builds themselves are performed as unprivileged build users. Users communicate with the daemon via RPCs.

Since every build is forced to its very own unique output directory (by prepending a hash of all the inputs), one user's build/installation does not affect other users.

Ericson2314OP10y ago

Last I checked with Nix, NFS and SQLite did not play well. Does Guix work around that?

j / k navigate · click thread line to collapse