Guix seems interesting but I almost stopped reading when I read "Nix". For all the benefits the Nix ecosystem provides, they haven't crossed the usability gap for me. First was naming their packages so confusingly, Nix the language vs NixOS vs Nix the package manager. Then there's the whole promise of it being usable from multiple platforms ("you don't even have to use NixOS, just use the package manager for awesome builds") -- It was supposedly amazing for building some software packages, but the reality was always so sticky and never quite panned out.
To be fair I have seen/heard lots praise it a lot for delivering stability to the servers they manage, but in this day and age, I'm not sure it's even worth trying to learn something to manage servers when the cattle approach is so much better (just shoot it). Even when stateful applications get involved, distributed storage is springing up to make it easier than ever to take down a server but have the data it had still be accessible, granted it was replicated, and sync if/when the machine ever comes back up. If the world evolves in that direction, it seems like people will only care about packages at VM/container/whatever base layer build time.
Don't want to be the downer here but I don't think it's likely that Guix is going to cross the usability chasm. I've invested a lot of time/interest/effort in projects that were better, but never crossed the usability/mindshare chasm and while I hope I'm wrong, this feels like some of the other ones.
Completely unrelated to that though, this quote rang true to me:
> Guix is a fork of Nix and addresses the main issue that Nix didn’t get right: instead of comming up with a homebrewed domain-specific language (DSL) with its own set of limitations and idiosyncrasies, Guix uses a full-fledged programming language. (And a good one at that, since it’s Guile Scheme, a Lisp-based language.)
I think Hashicorp has this problem with HCL (see the recent updates[0] announced at the last HashiConf, the `for` keyword is now in HCL) -- though I'm not recommending they fix the problem with lisp, people need to stop making DSLs then bridging the gap between their DSL and a full programming language. I much prefer the Pulumi[1]'s approach -- though it leaves devs lots of rope to hang themselves with ("recursive infrastructure building functions...why not?").
NixOS fangirl here... you're totally right about usability!
Git was self-hosting from day 3, but consisted only of a few pieces of exposed plumbing. As more porcelain was bolted on, it got to the point where flashy UIs could exist. Porcelain isn't all trivial either - consider "git rebase"!
NixOS today is like early Git.. usable and powerful, but not user-friendly. It needs a good UI, a graphical installer, and high-level porcelain to hide the plumbing unless you need to drop into it.
As for the cattle question, I think Nix's real power will come from efficient, declarative "Dockerfiles" and serving as a Bazel-like build system. There was a project for this, Hocker, but it seems inactive.
> NixOS today is like early Git.. usable and powerful, but not user-friendly. It needs a good UI, a graphical installer, and high-level porcelain to hide the plumbing unless you need to drop into it.
I'm not sure even that's enough, Nix is trying to win the lottery 3 times -- pushing a (essentially universal) package manager, a programming language, and linux distribution into the mainstream at the same time. What you noted might solve package management, but I'm convinced no one actually knows just how to make programming languages/OSes popular enough to hit and stay in the mainstream, outside of lots of money for marketing or serendipity.
All this said... Nix (OS + package manager) is definitely on my list of things to take for a spin -- I watch and read stuff about it but haven't taken the plunge just yet. It's very popular in the Haskell Ecosystem [0].
Interestingly, historically, at first there was only Nix the package manager + language. The NixOS distribution came to be purely as a subsequent experiment, a bright idea by a single another person (AFAIK), kinda "what if?..." Which then became a runaway success (relatively speaking — not mainstream yet), with more and more people realizing the potential and the benefits. Moreover, in fact the original Nix was also a one-person experiment, a PhD thesis by Eelco Dolstra.
I believe there's not that much "pushing" anything, rather the ideas being just inherently awesome and breakthrough, and many people quickly realizing this notion after being exposed to them :)
NixOS seems in some way to have more momentum for curious hackers than any other GNU/Linux distro; people who get into it really get into it. I myself consciously try not to be evangelical about it, still many of my friends and acquaintances end up installing it because it’s just so damn cool.
NixOS lightweight but fanboy here. I really rooting for both Nix and Guix to get more attention. They are suffering from usability problems because of they lack of attention so far. But, the power they grant to make major system changes with low risk is so damn good... It seems a tragedy that market inertia is putting billions into portable snapshots while ignoring provably bit-accurate, experimentable configuration.
These are all good points. To be honest, I'm skeptical about the future of NixOS: it's wonderful as a user distribution, but for production servers it's a hard sell to migrate off a stable, enterprise-grade OS like CentOS, Debian, or openSUSE. And as you say there's a long-term trend toward cattle servers and lightweight throwaway containers, which do not need features like atomic rollback and deterministic versioning, because we can simply snapshot the image and do a blue-green deployment with easy rollback at the orchestration layer.
That said, NixPkg (the package manager) is incredibly powerful, because it can build containers more quickly than Dockerfiles [1] or other specifications -- and it can do so in an entirely reproducible manner, with efficient caches for CI servers and developers. This becomes particularly powerful if your team works in a compiled language with long build times, like C++, or if your team works with a variety of languages. Particularly in scientific computing, it's not uncommon to have a lot of Python {2,3} with C/C++ dependencies, and perhaps a cmdline utility in another language or two. At this point something like 'pip install' no longer really cuts it, and NixPkg can step in to produce app images and development/CI environments in a snap. These images can then be backed into your favorite container runtime with the confidence that you could rebuild the entire container with a 1-line patch and actually have the same contents everywhere, and the new 'nix path-info' and 'nix log' commands can give you deep introspection into the binaries: showing the full transitive closure of build-time or runtime dependencies, their sizes on disk (important for containers and cloud deployments!), their configure/compilation arguments and output, and so on.
To provide some contrasting experience:
I'm not a sysadmin nor a coder, but when I had to launch a local server with multitude of services running, including libvirt with a couple of VMs, I had to consider two possibilities:
1. Learn all the required tools and their requirements, the syntax of their respectful configs and read a ton of documentation to just install all of them.
2. Learn the basics of Nix and spin a server with centralized configuration with unified syntax, which is also resistant to my sloppiness ("I don't know what I'm doing" situation).
No need to specify which path was taken. Wasn't easy, but no regrets yet.
Would love to switch to Guix since Guile seems much saner (at least easier to quickly understand) for a non-CS guy like myself, but support and package availability is nowhere near, unfortunately.
Have you written about this anywhere? I'd love to read about what you went through.
As a side note how is it possible that you were neither a sysadmin nor coder, yet were in the position to manage a server with VMs managed by libvirt? And how did you know Nix existed, or that you wanted to manage the machines with a central configuration server/repository to start with?
No, I haven't, although I've been considering it for a while. Thanks for your interest.
There's no machines nor a central server/repository, just a single machine with a local config.
In a nutshell, I work in a very lean firm as a designer lead but since I'm fairly proficient with tech and there's no IT department, I'm in a position to make some decisions. Situation occurred when it was necessary to launch an always-on service which is strictly Windows, with RDP access from a local network. Outside specialist was brought in to set it up. However, since the service is very low on resources I suggested to launch it inside a VM and use the linux host for other needs, such as back-ups, file-sharing, etc. I had been interested in NixOS (I just try to stay aware of promising tech innovations) for a while and it looked like a good platform for the problem at hand.
The interesting bit is that I had a bit of an edge case with libvirt, since I wanted to cut Windows guest from the outside world leaving only RDP and SMB access. Default forwarding options in libvirt couldn't provide that. Someone helpful on IRC mentioned there's some network bridge configuration that's not fully described (or at least clear enough) in the docs, so I had to edit VM's XML Network part and write a bunch of NixOS firewall rules (and rewrite them more than a few times). This sounds easy but it was a bit out of my skill-set and I had to sweat over it for a while, but satisfaction was absolutely worth it.
All of this felt like an achievement for me personally, but went invisible for the management, which is both a good and a bad thing.
TLDR: A lot of complications for no particular reason except self-education and self-amusement with no monetary reward whatsoever.
> The interesting bit is that I had a bit of an edge case with libvirt, since I wanted to cut Windows guest from the outside world leaving only RDP and SMB access. Default forwarding options in libvirt couldn't provide that. Someone helpful on IRC mentioned there's some network bridge configuration that's not fully described (or at least clear enough) in the docs, so I had to edit VM's XML Network part and write a bunch of NixOS firewall rules (and rewrite them more than a few times). This sounds easy but it was a bit out of my skill-set and I had to sweat over it for a while, but satisfaction was absolutely worth it.
Yeah that doesn't sound easy -- "someone helpful on IRC" and "network bridge configuration that's not fully described" convey the difficulty quite accurately for me. Sysadmin life is death by a thousand cuts with stuff like that, which is why everyone becomes gray beards so quickly.
I bet you someone out there has already run into this and gave up when they didn't find that helpful person on IRC or somewhere else how to solve this was written down.
> All of this felt like an achievement for me personally, but went invisible for the management, which is both a good and a bad thing.
Uhhhhhh yuuuuup? I'm don't have an MBA but I'm fairly sure you should get them to compensate you more or make you CTO or at least Director of Technology or some better title if resources are constrained. Of course, that might come with being the go-to for more of these sorts of issues but if you don't mind and want a chance to build tech with real stakes that then it seems fair.
> TLDR: A lot of complications for no particular reason except self-education and self-amusement with no monetary reward whatsoever.
It might be a little late now, but when things like this come up, you need to go out and get that monetary/other reward! I don't know what the outside specialist was going to charge, but you essentially did their job... If there's no IT department, then it should be pretty easy to just make one and be the head of it :)
Thank you for your encouragement. Two things to consider:
1. It's hard to have an IT department when it's about 10 people in a whole firm.
2. I'm afraid it wouldn't be as much fun if all I did the whole time was something like this.
This is a plot that hinders my career my whole life: too interested in too many things to fully commit to one of them. And the field for which I feel enough passion (music/studio work) has no money to compete with other jobs I can do. I really wish there was some position to exercise more of my wide but not-excitingly-deep skill set.
In regards to writing it down: I have a residual sense of guilt for not expanding the libvirt wiki right after I was finished, but, honestly, I was low on energy and had a bunch of my regular work built up. And, as usual with memory, I'm already not clear enough on the details to write a coherent guide.
> 1. It's hard to have an IT department when it's about 10 people in a whole firm.
I think that's both a blessing and a curse. If it was a 10000 person firm it might be a really big step, but right now it's a small step! Nothing wrong with getting in a role early and growing with it (and the company).
> 2. I'm afraid it wouldn't be as much fun if all I did the whole time was something like this.
That's true, and there are very real downsides like burnout and there's on problem with staying where you are if you're happy and getting what you want out of your job, but if what you're doing now isn't your dream job, and you don't absolutely hate the upper tier of the company, why not do a job you like slightly less for much increased future career prospects?
> This is a plot that hinders my career my whole life: too interested in too many things to fully commit to one of them. And the field for which I feel enough passion (music/studio work) has no money to compete with other jobs I can do. I really wish there was some position to exercise more of my wide but not-excitingly-deep skill set.
Yeah, that's difficult -- Imagine how much time you'd have to be a renaissance man/woman with the money/freedom a good C-level gig might afford? Of course responsibility would also increase, but it might be possible to keep it to the same usual 9-5 schedule, and that might not be too different from what you're doing now, except with a bit more stress at work, and maybe in a year or two you can take a whole year off and just do music/studio things? or fund a "startup" that's really just you having fun in the music/studio space and maybe finding a way to make it your living (if that's what you want).
Definitely don't decide your future off of a random HN comment... But also maybe it's worth some thought.
> In regards to writing it down: I have a residual sense of guilt for not expanding the libvirt wiki right after I was finished, but, honestly, I was low on energy and had a bunch of my regular work built up. And, as usual with memory, I'm already not clear enough on the details to write a coherent guide.
Well if you've got a list of TODOs, why not write it down? even if you share something as vague as you wrote here I'm sure it'd give someone out there enough of a clue to move forward.
Thanks, this is a lot of things to ponder on, and I actually agree with you on much of this. Your feedback is much appreciated and really made me feel better!
I actually have an almost empty blog, but having ideas and writing them down in a coherent way (especially in a non-native language) is two different things. I should try to write more.
I think the throw-away-server approach you mention cannot address enough issues or fulfill enough needs; in particular, I'm thinking reproducible builds:
https://reproducible-builds.org/.
Recent years have shown how badly we need to trust our software, and Nix/Guix are two prime examples of projects trying to tackle this issue.
"Just shoot it" servers lack trust and reliability (assuming you are not shooting a reproducible distro of course :p).
Yeah that's definitely true -- throwing your server away is no good if the machine image/setup flow you're using is insecure. Nix/Guix + the long list of distros working on it are all going in the right direction to fix this problem -- but I find it hard to believe that instead of just waiting for Debian reproducible builds (or some other vendor provided option) people will all switch to Nix/Guix.
Above the VM layer (@ the sandboxed process i.e. container layer), TUF[0] + Notary[1] + compliant image registries + attestation tools are helping to solve this problem which is nice.
Indeed, many distros tackle the reproducibility issue. But for the better part (and because of history), it can only be an after-thought, some extra layers that tries to fix the existing system.
The fundamental difference with Nix and Guix is that it's "reproducibility by design". A much more sustainable approach in my opinion.
> Then there's the whole promise of it being usable from multiple platforms ("you don't even have to use NixOS, just use the package manager for awesome builds") -- It was supposedly amazing for building some software packages, but the reality was always so sticky and never quite panned out.
The vast majority of Guix users are on other (so-called "foreign") distributions (i.e. not GuixSD) -- I think the opposite is true for Nix/NixOS.
I'm not sure what's "sticky" about it, can you elaborate?
I meant "sticky" in that when I tried to evaluate NixOS vs CoreOS Container Linux + Ignition (this was a while ago), nix was much harder to install and use than suggested. I ended up going with Container Linux for that very reason and didn't look back.
There was also an issue with nix and docker compatibility that I ran into w/ nix-docker[0], but I don't remember what it was.
Here are some videos I found in my history back when I was exploring Nix (watched in end of 2017/early 2018 I believe):
It's entirely possible my anecdata is too old to be useful. Maybe nix is much easier to use (and use correctly) these days. One example of where Nix should have been able to pick up mindshare is with the same people who value linuxkit[1]. Maybe this is is another marketing/branding/hype/money disparity thing but `nix-build '<something>' -A vm` looks like exactly what linuxkit is being lauded/promoted for being a good tool for, and it's been around for so much longer.
To be fair I have seen/heard lots praise it a lot for delivering stability to the servers they manage, but in this day and age, I'm not sure it's even worth trying to learn something to manage servers when the cattle approach is so much better (just shoot it). Even when stateful applications get involved, distributed storage is springing up to make it easier than ever to take down a server but have the data it had still be accessible, granted it was replicated, and sync if/when the machine ever comes back up. If the world evolves in that direction, it seems like people will only care about packages at VM/container/whatever base layer build time.
Don't want to be the downer here but I don't think it's likely that Guix is going to cross the usability chasm. I've invested a lot of time/interest/effort in projects that were better, but never crossed the usability/mindshare chasm and while I hope I'm wrong, this feels like some of the other ones.
Completely unrelated to that though, this quote rang true to me:
> Guix is a fork of Nix and addresses the main issue that Nix didn’t get right: instead of comming up with a homebrewed domain-specific language (DSL) with its own set of limitations and idiosyncrasies, Guix uses a full-fledged programming language. (And a good one at that, since it’s Guile Scheme, a Lisp-based language.)
I think Hashicorp has this problem with HCL (see the recent updates[0] announced at the last HashiConf, the `for` keyword is now in HCL) -- though I'm not recommending they fix the problem with lisp, people need to stop making DSLs then bridging the gap between their DSL and a full programming language. I much prefer the Pulumi[1]'s approach -- though it leaves devs lots of rope to hang themselves with ("recursive infrastructure building functions...why not?").
[0]: https://www.hashicorp.com/resources/keynote-terraform-free-s...
[1]: https://pulumi.io/reference/how.html