5 ms·

Disclaimer: I'm core NixOS developer It's great to see such articles as they dive deep into psychology when it comes to new technology. It's really hard to unl

Disclaimer: I'm core NixOS developer 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. 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.

infinity0 10y ago
It sounds like you're blaming the users for not "unlearning" enough to be able to use NixOS. As long as you have that attitude, you'll be driving away users. How do you think you can improve your software to make it easier for users to "unlearn" stuff you think is bad?
- Filligree 10y ago
  As a near-fanatic NixOS user (now!), I agree with both you and GP. The learning curve is brutal, so it took me a while to get started, but it's paid off several times over. It's unfortunate that humans can't trust each other enough that saying "You'll like it after a few months" is good enough, but it's also an inevitable fact of life; for starters, the speaker might be mistaken. I don't think NixOS is for everyone, at least not yet. And it's hard enough to run arbitrary software that, yes, you do need to learn the Nix language. In most cases it's as easy or easier to package the application for NixOS than it is to run it without packaging, which on the one hand is a benefit to the Nix ecosystem, but on the other hand can be a little annoying. There are workarounds... But the workarounds require some unusual understanding to begin with. I think one of NixOS' major flaws at the moment is documentation. There's the wiki, but it's both somewhat outdated and very much not comprehensive. As for Nix, it's been best explained in a series of blog posts, and as good as the Nix Pills series is, you have to find it before you can read it. It's also somewhat short on HOWTOs. Most people don't like to spend hours writing documentation, though. The existence of NixOS, and work done on it, is a massive positive externality. Even if it doesn't catch on, it's going to inspire half a dozen clones in the next decade or two. Unfortunately I don't see a good way to get more effort put into it, especially the boring bits (such as documentation)... I suppose this comment is my way of trying to change that.
  - zeendo 10y ago
    Would you suggest the Nix Pills series now? I notice it's 2 years old.
    - bennofs 10y ago
      I would suggest it, there is not much that has changed about the core of nix/nixpkgs, the nix language is quite stable and most changes have been additions rather than changing existing features.
    - Filligree 10y ago
      The Nix language hasn't really changed, so sure. Note that it doesn't say much about NixOS.
    - akavel 10y ago
      As a "common user", I'd say very much yes. It goes quite deep into the internals, and touches underlying ideas and basic mechanisms of Nix, which I don't think are expected to change [ever]. That said, note that it starts to be relevant when you're starting to write Nix expressions (meaning, write something in Nix language). Sometimes also when you want to read them and understand them. Which... is probably quite soon after starting to use Nix/NixOS, if you'll want to tweak some configs or add custom new packages. If you're really, really just doing first steps with Nix/NixOS, and/or just use the default packages with only simple tweaks, I'd say you don't need to read it yet (I personally wouldn't grasp enough basics then to understand WTF the articles are talking about at that point).
- iElectric2 10y ago
  Because that's fundamental to Nix. We're giving up on some current habits to get the freedom we want. This won't ever change, but people might. I'm not blaming them, I feel their pain. This is common in technology all around, think about driving a car for 25 years with manual transmission and then trying automatic transmission.
  - zzzcpan 10y ago
    While some things are fundamental for Nix's architecture, user interfaces are not. You don't even have to force people to learn the language, you can get apt-getish experience for generating .nix files with git-like commits or whatever. There are no limits in making it user-friendly and respecting people's habits and familiarity (which is actually a core concept for interfaces, that you seem to confuse with new technology).
    - Ericson2314 10y ago
      Faking destructive package management on top does exist, and we do plan on making it better, but it's lot harder to get right than you might think.
      - zzzcpan 10y ago
        I have some UI ideas of my own and could've helped, but I don't think investing time into Nix would be smart at this point. I feel like Nix lacks a clear vision of its future, focuses on desktop systems, while package management is not a big problem there, but it is on servers, and yet apart from Linux no other server systems are officially supported. No FreeBSD, OpenBSD, NetBSD.
        Ericson2314 10y ago
        Overall, I don't think the situation is as dire as you say it is, but I do understand why you think these things. > I feel like Nix lacks a clear vision of its future. There's various high-level plans that I think have a decent consensus, but not enough people have authority to make things happen. This means that more interesting PRs often rot. > focuses on desktop systems Nobody actually prioritizes desktops over servers, and the core design is quite agnostic, but because Nix is over a decade old, lots of old code and documentation do make it seem this way. > yet apart from Linux no other server systems are officially supported Other unices work do for userland Nix, and darwin has official binaries which would be the moral equivalent of official support. Also check out https://github.com/triton/triton https://github.com/triton/triton a fork of nixpkgs which aims to have a NixOS work with FreeBSD kernel, and https://github.com/cleverca22/not-os https://github.com/cleverca22/not-os to better make immutable OS images.
- chriswarbo 10y ago
  It's really a collective problem caused by user requirements (e.g. needing packages X, Y and Z), upstream practices (e.g. assumptions made by developers of X, Y and Z) and NixOS's unconventional approach (almost everything living in /nix/store/<hash>-<name>). There's no need to blame anyone, we're just caught in an accident of history. If there is a cause of problems, it's Nix's unconventional approach; but if Nix didn't take that approach it would be just another run-of-the-mill distro with no distinguishing features. I'd rather live in a world where I can choose whether or not to use NixOS's features, at the expense of its rough edges.
- Ericson2314 10y ago
  We're not running a startup here Ok? It's not "grow or die". Priority #1 is make sure all the proper abstractions are in place: foundations before furnature. And while we're pretty good on that front, there are a few things left. That's said we've got some CLI stuff being rewritten and other work that will help new users.
dorfsmay 10y ago
I would love to hear your thoughts on Guix.
- wtbob 10y ago
  I love that Guix chose a nice, clean (i.e., S-expression-based) representation for all of its code and data, but it's unfortunate that they chose Scheme instead of Lisp.
  - chriswarbo 10y ago
    I much prefer Scheme (and Racket) to the other Lisps I've tried (Common Lisp and Emacs Lisp), since it emphasises functional programming. Since the ideas of Nix come from functional programming (e.g. conceptually, the Nix store contains all packages, the "install" commands just force their evaluation) Scheme seems like a closer fit.
    - wtbob 10y ago
      Functional programming is cool, and it's possible in Lisp, but I prefer multi-paradigm. Sometimes one wants functions, sometimes procedures, sometimes objects & methods; sometimes one just wants to declare stuff.
- teh 10y ago
  Guix comes up on every Nix thread on HN and it's a bit frustrating. Guix runs on Nix technology with a new config language for packages & a different philosophy about what can go into its core package set (it's a GNU project). My personal take is that the difference isn't large enough to warrant a new distribution and if you want to choose you should go with the momentum and that's with core Nix (10-30x contributors, 10-100x packages, depending on how you count). People also think scheme is better than Nix as a language, but if you reason backwards from the requirements that's not at all clear to me. I think Nix-the-language would be better off with types, but the lazy, functional & pure parts are necessary for the concept.
  - 10y ago
pmarreck 10y ago
> 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. This could almost be the subtitle for "Functional Languages: Those Things Your Manager Won't Allow You To Use Yet" I think that a day will come when everyone will realize, and we'll have the tools to do, "functional" all the way to the metal. I like to quote John Carmack from http://www.gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php http://www.gamasutra.com/view/news/169296/Indepth_Functional..., "A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible... No matter what language you work in, programming in a functional style provides benefits. You should do it whenever it is convenient, and you should think hard about the decision when it isn't convenient." I think this paradigm applies at the OS and filesystem levels as well (ideally). The better control you (and your code) have over the states of everything in your system, the more deterministic your system behaves, the fewer unexpected bugs you have to chase down, the better you can reason about the computing you're doing and the programming you're responsible for making work. I mean, what's the big advantage of Docker and the whole "container" movement? You are guaranteed (more or less) to have a known state. Why does resetting hardware fix problems? Because it resets things to a known state. Managing state is the problem, and functional paradigms are the solution.
- lfam 10y ago
  > I mean, what's the big advantage of Docker and the whole "container" movement? You are guaranteed (more or less) to have a known state. Why does resetting hardware fix problems? Because it resets things to a known state. Managing state is the problem, and functional paradigms are the solution. I would argue that, with Docker, you may or may not have a known state. You certainly have a fixed state, but whether or not the state is "known" depends on how you generated it. If you use something like Nix (or Guix) to create the image, then you have a chance of knowing the state and being able to understand it. But if you build the image in some other way, there's a good chance that you won't be able to understand the relationships between the components, and that you won't be able to change the relationships safely and effectively later on.
setori88 10y ago
Actually iElectric was one of the people who encouraged me to learn the Nix Expression language. Now we're doing stuff over at github.com/fractalide/factalide I could never have imagined. The promised gain iElectric hints at can only be earned by learning the Nix Expression language.

infinity0 10y ago

It sounds like you're blaming the users for not "unlearning" enough to be able to use NixOS. As long as you have that attitude, you'll be driving away users. How do you think you can improve your software to make it easier for users to "unlearn" stuff you think is bad?

Filligree 10y ago
As a near-fanatic NixOS user (now!), I agree with both you and GP. The learning curve is brutal, so it took me a while to get started, but it's paid off several times over. It's unfortunate that humans can't trust each other enough that saying "You'll like it after a few months" is good enough, but it's also an inevitable fact of life; for starters, the speaker might be mistaken. I don't think NixOS is for everyone, at least not yet. And it's hard enough to run arbitrary software that, yes, you do need to learn the Nix language. In most cases it's as easy or easier to package the application for NixOS than it is to run it without packaging, which on the one hand is a benefit to the Nix ecosystem, but on the other hand can be a little annoying. There are workarounds... But the workarounds require some unusual understanding to begin with. I think one of NixOS' major flaws at the moment is documentation. There's the wiki, but it's both somewhat outdated and very much not comprehensive. As for Nix, it's been best explained in a series of blog posts, and as good as the Nix Pills series is, you have to find it before you can read it. It's also somewhat short on HOWTOs. Most people don't like to spend hours writing documentation, though. The existence of NixOS, and work done on it, is a massive positive externality. Even if it doesn't catch on, it's going to inspire half a dozen clones in the next decade or two. Unfortunately I don't see a good way to get more effort put into it, especially the boring bits (such as documentation)... I suppose this comment is my way of trying to change that.
- zeendo 10y ago
  Would you suggest the Nix Pills series now? I notice it's 2 years old.
  - bennofs 10y ago
    I would suggest it, there is not much that has changed about the core of nix/nixpkgs, the nix language is quite stable and most changes have been additions rather than changing existing features.
  - Filligree 10y ago
    The Nix language hasn't really changed, so sure. Note that it doesn't say much about NixOS.
  - akavel 10y ago
    As a "common user", I'd say very much yes. It goes quite deep into the internals, and touches underlying ideas and basic mechanisms of Nix, which I don't think are expected to change [ever]. That said, note that it starts to be relevant when you're starting to write Nix expressions (meaning, write something in Nix language). Sometimes also when you want to read them and understand them. Which... is probably quite soon after starting to use Nix/NixOS, if you'll want to tweak some configs or add custom new packages. If you're really, really just doing first steps with Nix/NixOS, and/or just use the default packages with only simple tweaks, I'd say you don't need to read it yet (I personally wouldn't grasp enough basics then to understand WTF the articles are talking about at that point).
iElectric2 10y ago
Because that's fundamental to Nix. We're giving up on some current habits to get the freedom we want. This won't ever change, but people might. I'm not blaming them, I feel their pain. This is common in technology all around, think about driving a car for 25 years with manual transmission and then trying automatic transmission.
- zzzcpan 10y ago
  While some things are fundamental for Nix's architecture, user interfaces are not. You don't even have to force people to learn the language, you can get apt-getish experience for generating .nix files with git-like commits or whatever. There are no limits in making it user-friendly and respecting people's habits and familiarity (which is actually a core concept for interfaces, that you seem to confuse with new technology).
  - Ericson2314 10y ago
    Faking destructive package management on top does exist, and we do plan on making it better, but it's lot harder to get right than you might think.
    - zzzcpan 10y ago
      I have some UI ideas of my own and could've helped, but I don't think investing time into Nix would be smart at this point. I feel like Nix lacks a clear vision of its future, focuses on desktop systems, while package management is not a big problem there, but it is on servers, and yet apart from Linux no other server systems are officially supported. No FreeBSD, OpenBSD, NetBSD.
      - Ericson2314 10y ago
        Overall, I don't think the situation is as dire as you say it is, but I do understand why you think these things. > I feel like Nix lacks a clear vision of its future. There's various high-level plans that I think have a decent consensus, but not enough people have authority to make things happen. This means that more interesting PRs often rot. > focuses on desktop systems Nobody actually prioritizes desktops over servers, and the core design is quite agnostic, but because Nix is over a decade old, lots of old code and documentation do make it seem this way. > yet apart from Linux no other server systems are officially supported Other unices work do for userland Nix, and darwin has official binaries which would be the moral equivalent of official support. Also check out https://github.com/triton/triton https://github.com/triton/triton a fork of nixpkgs which aims to have a NixOS work with FreeBSD kernel, and https://github.com/cleverca22/not-os https://github.com/cleverca22/not-os to better make immutable OS images.
chriswarbo 10y ago
It's really a collective problem caused by user requirements (e.g. needing packages X, Y and Z), upstream practices (e.g. assumptions made by developers of X, Y and Z) and NixOS's unconventional approach (almost everything living in /nix/store/<hash>-<name>). There's no need to blame anyone, we're just caught in an accident of history. If there is a cause of problems, it's Nix's unconventional approach; but if Nix didn't take that approach it would be just another run-of-the-mill distro with no distinguishing features. I'd rather live in a world where I can choose whether or not to use NixOS's features, at the expense of its rough edges.
Ericson2314 10y ago
We're not running a startup here Ok? It's not "grow or die". Priority #1 is make sure all the proper abstractions are in place: foundations before furnature. And while we're pretty good on that front, there are a few things left. That's said we've got some CLI stuff being rewritten and other work that will help new users.

dorfsmay 10y ago

I would love to hear your thoughts on Guix.

wtbob 10y ago
I love that Guix chose a nice, clean (i.e., S-expression-based) representation for all of its code and data, but it's unfortunate that they chose Scheme instead of Lisp.
- chriswarbo 10y ago
  I much prefer Scheme (and Racket) to the other Lisps I've tried (Common Lisp and Emacs Lisp), since it emphasises functional programming. Since the ideas of Nix come from functional programming (e.g. conceptually, the Nix store contains all packages, the "install" commands just force their evaluation) Scheme seems like a closer fit.
  - wtbob 10y ago
    Functional programming is cool, and it's possible in Lisp, but I prefer multi-paradigm. Sometimes one wants functions, sometimes procedures, sometimes objects & methods; sometimes one just wants to declare stuff.
teh 10y ago
Guix comes up on every Nix thread on HN and it's a bit frustrating. Guix runs on Nix technology with a new config language for packages & a different philosophy about what can go into its core package set (it's a GNU project). My personal take is that the difference isn't large enough to warrant a new distribution and if you want to choose you should go with the momentum and that's with core Nix (10-30x contributors, 10-100x packages, depending on how you count). People also think scheme is better than Nix as a language, but if you reason backwards from the requirements that's not at all clear to me. I think Nix-the-language would be better off with types, but the lazy, functional & pure parts are necessary for the concept.
- 10y ago

pmarreck 10y ago

> 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. This could almost be the subtitle for "Functional Languages: Those Things Your Manager Won't Allow You To Use Yet" I think that a day will come when everyone will realize, and we'll have the tools to do, "functional" all the way to the metal. I like to quote John Carmack from http://www.gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php http://www.gamasutra.com/view/news/169296/Indepth_Functional..., "A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible... No matter what language you work in, programming in a functional style provides benefits. You should do it whenever it is convenient, and you should think hard about the decision when it isn't convenient." I think this paradigm applies at the OS and filesystem levels as well (ideally). The better control you (and your code) have over the states of everything in your system, the more deterministic your system behaves, the fewer unexpected bugs you have to chase down, the better you can reason about the computing you're doing and the programming you're responsible for making work. I mean, what's the big advantage of Docker and the whole "container" movement? You are guaranteed (more or less) to have a known state. Why does resetting hardware fix problems? Because it resets things to a known state. Managing state is the problem, and functional paradigms are the solution.

lfam 10y ago
> I mean, what's the big advantage of Docker and the whole "container" movement? You are guaranteed (more or less) to have a known state. Why does resetting hardware fix problems? Because it resets things to a known state. Managing state is the problem, and functional paradigms are the solution. I would argue that, with Docker, you may or may not have a known state. You certainly have a fixed state, but whether or not the state is "known" depends on how you generated it. If you use something like Nix (or Guix) to create the image, then you have a chance of knowing the state and being able to understand it. But if you build the image in some other way, there's a good chance that you won't be able to understand the relationships between the components, and that you won't be able to change the relationships safely and effectively later on.

setori88 10y ago

Actually iElectric was one of the people who encouraged me to learn the Nix Expression language. Now we're doing stuff over at github.com/fractalide/factalide I could never have imagined. The promised gain iElectric hints at can only be earned by learning the Nix Expression language.