I wonder if wingo knows about the 'guix environment' tool or not. It can create dev environments with the correct environment variables configured on the fly, without creating a new profile or polluting an existing one. Profiles are still useful for persistence, but I use 'guix environment' for all of my day-to-day hacking so I don't have to periodically delete generations of a profile in order for the GC to collect them.
I've tried using Nix a few times. The idea is in principle not bad, but the actual deployment for, say... an API endpoint? Horrendous.<p>Problems include:<p>1. Scripts deployed almost never appeal to /usr/bin/env, they tend to hardwire interpreters to /bin/sh. This flat out doesn't work in NixOS, and the Nix team is ideologically opposed to maintaining a compat layer for specific cases like this.<p>2. Compiled binaries are compiled to this SPECIFIC version of Nix. That may not seem like a bad thing, but the reality is that it's very abusive to work with. Your binaries cannot even be invoked becuase they cannot <i>find</i> their links (including, you know, the C bootstrapping lib). This means you can make an executable on your dev box, try and push it to prod, and because prod doesn't have something like a dtrace library the entire system is incompatible with your executable.<p>3. There are tools to assist with these problems, because they're so common. However, they themselves are full of edge cases they don't solve for that they're very hit-or-miss. While this isn't bad in and of itself, it tends to make the established userbase very unsympathetic and often very formulaic when you approach them with more subtle linking issues. This can be quite frustrating.<p>I found the entire system somewhat unworkable. I also feel like Docker or Rocket solves a lot of the practical problems I have there, despite protestations. Container images are perfectly reproducible, but also easy to update. They also tend not to rip themselves apart if you, in a moment of intellectual weakness, give a slightly confusing order to the nixos package manager and rip your system in half.
<i>They use "deco" as an init system, for example, which is kinda like systemd but not.</i><p>The init system is actually GNU dmd. deco is the name of the control utility (like systemctl is to systemd).<p>It also has absolutely nothing in common with systemd, so I don't know why the author made that comparison.
> but it is just unacceptable and revolting that software development in 2015 is exposed to an upgrade process which (1) can break your system (2) by default and (3) can't be rolled back.<p>I would like to add that building a system that makes it difficult to reproduce the exact same state on another machine, even if the central/distributed repository it originated from is not available, should be considered malpractice.
Just an anecdote: Since I started using Slackware Linux, I have never had any problem with my system.<p>I like the idea of functional package managers, Guix especially. But for me personally the problem they are trying to solve does not exist.
Huh... I had no idea Nix and Guix could be used this way. I viewed them as replacements to <i>apt</i>, but what I'm hearing is I could just as easily use it as a souped up <i>stow</i>... interesting...
IMHO, there is only a little bit of separation between Docker and Nix/Guix.<p>I wonder if the Linux desktops of tomorrow will be a thin hypervisor (or something like CoreOS), running a immutable VM on top.
What's the significance of "V8"? He means the javascript engine, right? But that never enters into the story.... It's really just "Developing with Guix".
I'm a little surprised that a veteran Debian user would fall into this kind of trap (again :). I think guix looks very interesting, but a couple of tips if "all" you need is to "code on the edge" in Debian:<p>1) Run Debian stable. Possibly add stuff from backports if you <i>need</i> to (eg: newer kernel for drivers. Newer xorg. Hopefully this shouldn't ever be needed for mainstream workstations - modulus closed source graphics drivers).<p>2) Don't mix'n'match [packages from testing/unstable with stable]. Don't pin. Just do not do it. [Don't run testing/unstable... unless you <i>are testing</i> testing].<p>3) For utilities not in stable - some can go in ~/opt/{bin,lib,man} -- living in ~/opt/xstow/$package-$version/ -- see "man xstow/apt-get install xstow" -- and set your path, ld-path, man-path ("man man") and friends to point to ~/opt/man etc.<p>I also have a ~/opt/venv/util/bin in my path so I can go "pip install mercurial" without worrying about system python packages etc. If you go down this path be aware of "apt-get build-dep mercurial|python-$foo" as a reasonably sane way to get system dev headers for c libraries things you pip install in your venv(s).<p>Think of the venvs as disposable! Might have to trash them on a dist-upgrade and recreate. Ditto for ~/xstow.<p>But none of that is <i>much</i> better than the mess Wingo found himself in, therefore:<p>4) Embrace the glorious trinity formed by lvm, schroot and debootstrap! With lvm-backed schroots you can have a source-chroot for each of testing, sid/unstable and experimental. Complete with rollback, named snapshots and automagic binding of $home (with among other obvious benefits - your x session cookie).<p>Schroot documentation/wiki/howto do need a facelift, though.<p>See also:<p><a href="https://www.pseudorandom.co.uk/2007/sbuild/" rel="nofollow">https://www.pseudorandom.co.uk/2007/sbuild/</a><p><a href="https://wiki.debian.org/Schroot/e" rel="nofollow">https://wiki.debian.org/Schroot/e</a><p><a href="https://wiki.debian.org/CrossCompiling" rel="nofollow">https://wiki.debian.org/CrossCompiling</a><p>[Note that auto-bind-mounting home can now be set in schroot.conf IIRC -- see man schroot]<p>PS: If you have $home on nfs and mount it on both 32bit/64bit linux as well as Solaris... you can put stuff in ~/opt/$arch/.. and dance around in .xsession and/or .bashrc... but I don't recommend it unless you have to...