The other week, a post of mine ended up on the front page of Hacker News. I didn’t even notice until Harlan pointed it out, which was four days later. Someone had also submitted it to lobste.rs, which another friend told me about in a more timely manner.
The post is fairly old at this point. I wrote it in January. I wrote a related post more recently, and so I thought the timing was interesting. One thing that has come to the front of my mind because of this is that I have almost no visibility into who is reading my blog. I know some people do, but… that’s about all I know. There are no comments, and I don’t have any analytics set up, so this took me a bit by surprise.
There were some points made that seemed worth commenting on, but unfortunately I missed the boat on participating in the discussion on Hacker News. Instead, that’s what I’m going to do with the remainder of this post.
First, user Irene on lobste.rs makes two interesting points:
“Do one thing and do it well” is hard to argue for or against, as it’s a question of personal goals and vision
In general I tend to agree, but my original comment was made in the context of “If your goal is to achieve X” with a well defined X. In particular, those comments were meant as suggestions for someone whose goal is to build a usable system around the “running machine as object code” model; it assumes some of Nix’s other goals (e.g. “virtualenv but for everything”) are secondary, and not important enough to compromise the primary goal.
but fortunately the author only gives one concrete example - per-user mutable environments - and I’m not sure there are others, so I’ll only address that. :) Given how much heavy lifting Nix has to do to make its core strategy work, I see this feature as easy in comparison and not a big deal. Personally, though, I don’t use it and share this author’s desire to have a way to turn it off altogether.
In the original post I gave a concrete example of where this causes problems – setuid binaries become a frequent source of bugs. If regular users can’t modify the set of installed packages (as is the case on most mainstream distros), this problem just goes away; only root can install packages, so it’s fine if packages install setuid binaries. A whole class of bugs is gone now.
Next up, majewsky on Hacker News writes:
So this probably just saved me a trip down NixOS road, which was on my (ever too long) todolist for some time now.
This was not my intent! I actually think it’s pretty neat and you should totally form your own opinions. It just didn’t cut it for my use case.
It’s also worth noting that the decision to not keep using it was in the context of something to run on my two laptops and one desktop, and frankly, as I argued in my more recent post, in that context having systems under configuration management just isn’t that critical. While I make some suggestions on how a more focused project could better achieve what I was looking for, in a context where that was actually really important, I might still seriously investigate NixOS.
It’s great to see such articles as they dive deep into psychology when it comes to new technology. It’s really hard to unlearn.
This isn’t really an issue of needing to “unlearn” anything; I was already in the mindset of doing things NixOS’s way (or arguably even more gung-ho about it), and it wasn’t that adapting to NixOS’s way of doing things was in and of itself a challenge. The biggest issue was that for a few days or so I was sending more patches at NixOS than I was the project I had meant to be working on, just trying to get my laptop working. There was a certain amount of overhead that comes from not knowing the nitty-gritty details of the tools very well, but there really wasn’t (for me) much of a conceptual barrier.
On Arch, even when I have to package something myself, needing to do more than paste the README’s build instructions into a PKGBUILD is exceedingly rare; very very few things ever need patching. There was no conceptual hurdle in working with NixOS, there was just extra work.
Some of this is just the inherent friction in building a system that does things differently, and while I’ve argued that the goal I care about would be better served if some of the other goals were abandoned, I’m not claiming it would make all of that friction disappear.
It takes effort to realize that the promised gain is bigger than the pain coming from doing what we’re used to doesn’t work.
The payoff to short-term-pain ratio is highly dependant on use case. As I’ve said, for my laptops/desktop there just isn’t that much pain to begin with. For other situations the payoff might well be worth it.
Finally, VT_Drew on Hacker News writes:
Am I the only one that caught the homestarrunner reference?
I’m glad someone did.