8 ms·

I love the core concepts behind Nix, and have great respect for their engineering abilities. However I am skeptical of their ability to achieve broad adoption b

by zapita 9y ago

I love the core concepts behind Nix, and have great respect for their engineering abilities. However I am skeptical of their ability to achieve broad adoption beyond their current community of passionate experts. There are two reasons for my skepticism: 1. User experience. Unless you're one of the "passionate experts", the Nix user experience is pretty terrible. The learning curve is punishing compared to competing systems. 2. Elitist culture. In my experience, the Nix community is too smart for its own good. Their technical foundation is so far ahead of mainstream systems, and their technical design so satisfying to passionate experts, that they've forgotten how to live a day in the shoes of a mere mortal. Try pointing out flaws in the user experience, or the need to offer more pragmatic ways to migrate existing systems, and you will be met mostly with derision and reminders of Nix's superior engineering. But superior engineering is not everything. If you want to spread the amazing potential of Nix to everyone, then you need to compromise with a flawed, imperfect world. You need to meet users half-way, and guide them to the promised land, instead of waiting for them to show up on their own. Otherwise someone will come along that will do it for you. All this is eerily similar to what happened to functional programming communities.

jcrites 9y ago
I also greatly appreciate what the Nix and NixOS projects are doing. In this latest release, it looks like they're taking steps toward making Nix easier to use, in standardizing and simplifying the CLI porcelain.
taohansen 9y ago
Except that Docker et al are already that compromised solution. No need to replicate. And for what it's worth, the #nixos community is one of the kindest, most helpful communities I've ever encountered. Stop by and ask your questions!
- zapita 9y ago
  > Except that Docker et al are already that compromised solution. No need to replicate. I think you're right that Docker has embraced the "meet half-way" school of thought (maybe too much?). But that doesn't mean they have exclusivity over the approach. Docker lacks many of the features that make Nix so powerful. On the other hand Docker is much more pleasant to use, for me at least. If a tool came along that combined the simplicity of Docker with the power of Nix, I would probably stop using both, and just use that. I think Nix itself could be that tool... if only they fixed the issues I described above.
  - deleted 9y ago
    [deleted]
  - deleted 9y ago
    [deleted]
- kvz 9y ago
  But when you need to rebuild your container image, how do you make sure it builds in the same way? Nix imho is perfect for building reproducible containers, which you can then run on a minimal install of an OS with a larger ecosystem (or just GKE/EKS) to find & fix crippling bugs before you run into them.
nextos 9y ago
I agree, but I'm not so negative about its future. As a starting point, I think Nix needs to become a bit more predictable. I like Arch Linux or Slackware because they are minimal (all packages are mostly vanilla upstream, nothing installed if you don't explicitly do it yourself) plus all operations have obvious side effects. Nix is also minimal, but sometimes side effects are really non-obvious. For example, when you update your system and you are subscribed to some channels, it's not obvious whether you will get binary substitutes (packages) or you will trigger a lot of local compilation. Things are getting better, e.g. with dry-run capabilities, but a more friendly UI should be default. Furthermore, there should be better documented ways to run software that hasn't been packaged for Nix. There are tons of options: Docker, Systemd containers, FHS chroots. But it should be obvious too. On the other hand, I can honestly say that if you want a really hassle-free machine that never breaks and you are not installing stuff that isn't packaged, NixOS is arguably one of the best distros out there. I have a few remote machines overseas in my dads house for some of his simulations. He knows no Linux. I can update Nix machines and tweak configuration remotely knowing that nothing will break. I can rollback anytime. Plus the whole configuration is a single declarative file.
- pknopf 9y ago
  If you like Arch, but still want the immutability and reliability of NixOS, you should check out a project I developed, Darch. https://godarch.com/ https://godarch.com/
  - grzm 9y ago
    I understand and very much sympathize with your desire to share a project you've worked on. However, after four such comments, this is starting to look like spam.
stouset 9y ago
On the other hand, to me, this is basically the same story as `git` (sans the cultural gravity of Linus). Incredibly well thought-out internal architecture, extremely talented developers, functional-style immutable datastructures, idiosyncratic frontend that’s a low-level façade over the internals, painful learning curve, often difficult (but possible!) to recover from real-world corruption, etc. I say this as someone who has loved `git` for a long time and appreciates that knowing the internals and how the commands map onto them leads to an incredibly powerful tool.
- thomastjeffery 9y ago
  git at least had a good command-line interface and documentation from the start. Nix is getting better, especially with this release, but it's still far from friendly.
  - stouset 9y ago
    The command-line interface was about the same as it is today. Which is to say, it’s great if you understand the underlying architecture and how the commands map natively to it, but it’s a huge learning curve if you’re coming from something else, have preconceived notions of what commands like “commit”, “checkout”, “fetch” et al do, and don’t have the time or the desire to learn the about what a DAG is. The cogito interface used to be a thing, but I don’t think it ever gained widespread adoption and was pretty quickly abandoned.
    - thomastjeffery 9y ago
      > and don’t have the time or the desire to learn the about what a DAG is. That's the point people are complaining about with git. It's fine to consider that an issue, but that doesn't mean the interface or documentation are bad, it's that people want it to feel familiar. I, for one, was very comfortable with git's command line from the start. I came in wanting something different, and found the distributed model was just what was needed, and frankly, more straightforeward than the popular centralized approach. It also helps that you can play with and break things locally, rather than having to worry about a server someone else relys on.
s4vi0r 9y ago
Where have you run into derision/assholes with nix or FP? Absolutely there are assholes (or perhaps people who just don't realize how rude their words/actions are) in the community - especially on Twitter and reddit in my experience - but I've never not felt welcomed or been talked down to when I asked for help in an IRC/discord channel. I see this get mentioned all the time in respect to FP communities in particular but I really can't relate at all. And its not like I haven't asked my fair share of stupid questions in these communities or anything.
- zapita 9y ago
  I didn't encounter any assholes (or rather I didn't encounter any more than usual... I have yet to find a completely asshole-free open-source project). Maybe "derision" was the wrong term. Nobody was rude or disrespectful. Just oddly patronizing. They just didn't feel there was anything wrong with the user experience, or any need to improve Nix to better meet the needs of non-experts. The main sentiment I observed was that Nix was pretty close to perfect, but also misunderstood - and that it was mostly up to the rest of the world to better understand it. That struck me as the wrong way to go about making your project successful.
  - jcrben 9y ago
    I've experienced the opposite. The fact that this release highlights a new 'nix' command and deprecates a bunch of ugly and verbose baggage shows the commitment to UX.
    - zapita 9y ago
      That's encouraging to hear. I will give it another go soon. The area that IMO needs the most work is the packaging experience, including the DSL itself... and the "I just want to build this source without having to become a black belt functional packager first" experience.
      - pxc 9y ago
        My biggest gripe with Nix packaging is that the tooling varies so widely per ecosystem. Aside from that, though, I generally find packaging for Nixpkgs to be much, much easier than packaging for most distros. What kind of packaging experience are you used to?
thomastjeffery 9y ago
Your second point is exactly what happened to me here: https://github.com/NixOS/nixpkgs/issues/9682 https://github.com/NixOS/nixpkgs/issues/9682 Sure, pinning is great, and the ability to ignore versions seems to be a great design goal. Unfortunately, that design goal is shoved down the throats of users, and makes a very messy - and difficult to traverse or use - namespace where different versions are just thrown in the name without another thought. NixOS is my favorite Linux distro, and the only OS currently installed on my laptop. It's also frustrating in unnecessary ways.
- jcrites 9y ago
  It seems like Nix could benefit from a first-class concept for pinning the channel and managing updates to the channel. To achieve build reproducibility, the default outcome of checking out a project and building it should be to get the same result as everyone else who does so at the same project revision. I'd expect there to be a way to take a snapshot of the channel and lock those versions in the project until you're ready to upgrade. I have tinkered a lot with Nix, but have not used it for any production system. I'd be reluctant to use Nix in production if there wasn't a good way to pin the channel, so that everyone who is developing on a project sees precisely the same versions as each other, and everyone who is patching a specific version of a project sees the same version as what's currently deployed. In my opinion, this should be the default behavior and not something that you have to go out of your way to achieve. Maybe you could model this as something like a "channel fork" or "user channel". When you create a new project, you also create a channel for it that inherits from an existing channel, except that the versions of all packages are pinned and you can control the way in which changes make their way into your user channel from the upstream. My company has a proprietary technology that's similar to Nix, and we tackle the build reproducibility problem in this way, by making it easy to branch off the main channel and control how updates make their way into it (which is like a merge). The default behavior when creating a project is to also create a project-specific channel, derived from the upstream, company-wide channel. Dependencies are declared at the major version level only, and versioning beneath that level happens implicitly via the project channel. In this system you think of all channels as having revisions. Developers can control how their channel merges in changes from its upstream channel, which provides stability and reproducibility: until you merge and release a new version, `my-channel` always references exactly the same package versions for all developers. The default behavior of channels is to merge new versions from the upstream channel periodically, but developers can decide what's right for them, whether staying on the bleeding edge or prizing stability. Software builds, releases, and deployments always happen in the context of a specific channel revision (`my-channel@revision`), which can be named and referenced, so if necessary you can inspect or replicate exactly the code that's part of a colleague's configuration or a production system. Not just approximately but exactly, for every package involved down to `gcc` and `glibc`. It's easy to create a workspace with the package versions specified by `my-channel@12345`. By further tracking which source code commit hash corresponds to each package release in the channel, you can trivially look up the exact source of all packages (my-channel@12345 -> FooPackage@a1b2c3d4). Extremely useful! When you work and version things in this way, you hardly need version numbers beneath the major version level. I suppose it's reasonable that the Nix project doesn't want to host binary versions of lots of old packages to make this use-case fast. In that case, I'd want it to be easy to clone the binary version of those dependencies and source them locally. Maybe this could operate as something like a caching proxy in front of Nixpkgs, that will store my own permanent copy of any package that I access or build. On the other hand, keeping builds forever is expensive, so perhaps this is an opportunity for Nix to provide a commercial offering with private channel hosting and a package cache with infinite TTL.
derefr 9y ago
I've found that within other ecosystems, people are increasingly considering replacing existing tooling with Nix. For example, I've heard some rumblings in the Elixir space considering using Nix for managing SDK versions, for native/binary package dependencies, and for generating release packages. To accelerate the adoption of Nix, the Nix maintainers would need to reach out and help other ecosystems adopt Nix or Nix-like logics. But I think, as it stands, other ecosystems will eventually look toward Nix on their own, as they grow and attempt, one by one, to solve all the same problems Nix already has 100% solved.
deleted 9y ago
[deleted]
kovek 9y ago
I've found kind experienced users who supported me on webchat.freenode.net , #nixos. I always make sure to say thanks when they help!
wocram 9y ago
What kind of user experience are you talking about? As someone who uses it as just a package manager, I have had no complaints around using `nox`, `nix-env -i`, and `nix-env -e`. It does seem to have a sprawling cli and many additional purposes, so I can imagine the argument, but am curious as to what part of UX you're talking about in particular.
grantwu 9y ago
This, 100%. Pain points I've run into: 1. Lack of clarity as to how language/application package managers interact with Nix (pip, stack, Vundle). Pretty much every time I've asked about this, I've been told to go use `nix-shell` or to install things through Nix. Increasingly, when I get odd behavior with applications I install through Nix, my first resort is to uninstall the Nix version and install it from apt; it might be a bit older, but I'm sure it'll work as expected. I've went through the apt package -> Nix package -> apt package cycle three times from what I remember off the top of my head, with python/ipython, Haskell tooling, and Vim. 2. Nix on Ubuntu feels like a second class citizen. Things that interact with graphics drivers often don't work properly, e.g. video players. (I understand that there are technical reasons why this is the case, but there's no warning that this is the case.) There only appears to be online package search for NixOS (https://nixos.org/nixos/packages.html# https://nixos.org/nixos/packages.html#) and not for Nix on other platforms. Nox helps, but it doesn't seem to be the same feature wise (no ability to see the info you get by clicking the package name) and is also slow. 3. In general package quality is not great for less frequently used packages. Inkscape was missing potrace for a while. Rarely used packages go unmaintained. 4. Poor CLI. Needing to pass `-A` to a lot of commands to use them the "right way" smells of a poorly thought out design. No feedback or suggestions if you type the wrong thing to `nix-env -e`. It looks like there are major changes to this in 2.0, so this might have been improved. Despite being someone who's gotten their toes wet contributing to nixpkgs, I'm likely not going to be installing Nix when I upgrade from Ubuntu 16.04 to 18.04.
- thomastjeffery 9y ago
  > Needing to pass `-A` to a lot of commands to use them the "right way" smells of a poorly thought out design. That stems from the namespace problem that Nix devs seem to think doesn't exist. Packages that have the same name, or belong in a different namespace (hackage, pip, etc.) are confusing to find from a user's perspective. The real problem is that every package in a channel has to go into the same global namespace. Practically every package manager has this problem, but, in my opinion, Nix deals with it the most poorly. To make matters worse, it isn't obvious which namespace .nix files are supposed to reference, or what functions exist globally. Nix really does need a lot of UX work, and I'm glad to hear it is getting some.
whateveruser 9y ago
I've been kinda waiting for something like what Ubuntu is/was to Debian. Approachable. Last time I tried nix, learning curve was too steep. This update looks like they've started to work towards approachability a bit, so I might give it another go.
paride5745 9y ago
My thoughts exactly. Some time ago, I asked how to integrate NixOS in an existing infrastructure managed by Chef/Ansible. I was told I was wrong to even think about that and that Nix is a better system. Well, wrong. If you have a few thousands servers with a system, you cannot ask to migrate all to a new system without some integration with the old one first.
- Mic92 9y ago
  Instead of deploying individual configuration files, you would generate `/etc/nixos/configuration.nix` + some modules maybe followed by a `nixos-rebuild switch`. There is not special support required in Chef/Ansible to support this feature. Both Chef and Ansible are available in nixpkgs.
jimnotgym 9y ago
You may be right here. I like to think I am not a complete idiot, but I just read their 'about' page and now I know Nix has a folder naming convention and something about functional programming, but I have no idea how it is going to solve the issues I have with pip/apt/conda etc. In fact I am not really sure if it is supposed to, apart from seeing that it is a package manager. Now I have filed it mentally under 'too much trouble to learn'
- pxc 9y ago
  What are the issues you have with pip/apt/conda etc.?

by zapita 9y ago

jcrites 9y ago

I also greatly appreciate what the Nix and NixOS projects are doing. In this latest release, it looks like they're taking steps toward making Nix easier to use, in standardizing and simplifying the CLI porcelain.

taohansen 9y ago

Except that Docker et al are already that compromised solution. No need to replicate. And for what it's worth, the #nixos community is one of the kindest, most helpful communities I've ever encountered. Stop by and ask your questions!

zapita 9y ago
> Except that Docker et al are already that compromised solution. No need to replicate. I think you're right that Docker has embraced the "meet half-way" school of thought (maybe too much?). But that doesn't mean they have exclusivity over the approach. Docker lacks many of the features that make Nix so powerful. On the other hand Docker is much more pleasant to use, for me at least. If a tool came along that combined the simplicity of Docker with the power of Nix, I would probably stop using both, and just use that. I think Nix itself could be that tool... if only they fixed the issues I described above.
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
kvz 9y ago
But when you need to rebuild your container image, how do you make sure it builds in the same way? Nix imho is perfect for building reproducible containers, which you can then run on a minimal install of an OS with a larger ecosystem (or just GKE/EKS) to find & fix crippling bugs before you run into them.

nextos 9y ago

I agree, but I'm not so negative about its future. As a starting point, I think Nix needs to become a bit more predictable. I like Arch Linux or Slackware because they are minimal (all packages are mostly vanilla upstream, nothing installed if you don't explicitly do it yourself) plus all operations have obvious side effects. Nix is also minimal, but sometimes side effects are really non-obvious. For example, when you update your system and you are subscribed to some channels, it's not obvious whether you will get binary substitutes (packages) or you will trigger a lot of local compilation. Things are getting better, e.g. with dry-run capabilities, but a more friendly UI should be default. Furthermore, there should be better documented ways to run software that hasn't been packaged for Nix. There are tons of options: Docker, Systemd containers, FHS chroots. But it should be obvious too. On the other hand, I can honestly say that if you want a really hassle-free machine that never breaks and you are not installing stuff that isn't packaged, NixOS is arguably one of the best distros out there. I have a few remote machines overseas in my dads house for some of his simulations. He knows no Linux. I can update Nix machines and tweak configuration remotely knowing that nothing will break. I can rollback anytime. Plus the whole configuration is a single declarative file.

pknopf 9y ago
If you like Arch, but still want the immutability and reliability of NixOS, you should check out a project I developed, Darch. https://godarch.com/ https://godarch.com/
- grzm 9y ago
  I understand and very much sympathize with your desire to share a project you've worked on. However, after four such comments, this is starting to look like spam.

stouset 9y ago

On the other hand, to me, this is basically the same story as `git` (sans the cultural gravity of Linus). Incredibly well thought-out internal architecture, extremely talented developers, functional-style immutable datastructures, idiosyncratic frontend that’s a low-level façade over the internals, painful learning curve, often difficult (but possible!) to recover from real-world corruption, etc. I say this as someone who has loved `git` for a long time and appreciates that knowing the internals and how the commands map onto them leads to an incredibly powerful tool.

thomastjeffery 9y ago
git at least had a good command-line interface and documentation from the start. Nix is getting better, especially with this release, but it's still far from friendly.
- stouset 9y ago
  The command-line interface was about the same as it is today. Which is to say, it’s great if you understand the underlying architecture and how the commands map natively to it, but it’s a huge learning curve if you’re coming from something else, have preconceived notions of what commands like “commit”, “checkout”, “fetch” et al do, and don’t have the time or the desire to learn the about what a DAG is. The cogito interface used to be a thing, but I don’t think it ever gained widespread adoption and was pretty quickly abandoned.
  - thomastjeffery 9y ago
    > and don’t have the time or the desire to learn the about what a DAG is. That's the point people are complaining about with git. It's fine to consider that an issue, but that doesn't mean the interface or documentation are bad, it's that people want it to feel familiar. I, for one, was very comfortable with git's command line from the start. I came in wanting something different, and found the distributed model was just what was needed, and frankly, more straightforeward than the popular centralized approach. It also helps that you can play with and break things locally, rather than having to worry about a server someone else relys on.

s4vi0r 9y ago

Where have you run into derision/assholes with nix or FP? Absolutely there are assholes (or perhaps people who just don't realize how rude their words/actions are) in the community - especially on Twitter and reddit in my experience - but I've never not felt welcomed or been talked down to when I asked for help in an IRC/discord channel. I see this get mentioned all the time in respect to FP communities in particular but I really can't relate at all. And its not like I haven't asked my fair share of stupid questions in these communities or anything.

zapita 9y ago
I didn't encounter any assholes (or rather I didn't encounter any more than usual... I have yet to find a completely asshole-free open-source project). Maybe "derision" was the wrong term. Nobody was rude or disrespectful. Just oddly patronizing. They just didn't feel there was anything wrong with the user experience, or any need to improve Nix to better meet the needs of non-experts. The main sentiment I observed was that Nix was pretty close to perfect, but also misunderstood - and that it was mostly up to the rest of the world to better understand it. That struck me as the wrong way to go about making your project successful.
- jcrben 9y ago
  I've experienced the opposite. The fact that this release highlights a new 'nix' command and deprecates a bunch of ugly and verbose baggage shows the commitment to UX.
  - zapita 9y ago
    That's encouraging to hear. I will give it another go soon. The area that IMO needs the most work is the packaging experience, including the DSL itself... and the "I just want to build this source without having to become a black belt functional packager first" experience.
    - pxc 9y ago
      My biggest gripe with Nix packaging is that the tooling varies so widely per ecosystem. Aside from that, though, I generally find packaging for Nixpkgs to be much, much easier than packaging for most distros. What kind of packaging experience are you used to?

thomastjeffery 9y ago

Your second point is exactly what happened to me here: https://github.com/NixOS/nixpkgs/issues/9682 https://github.com/NixOS/nixpkgs/issues/9682 Sure, pinning is great, and the ability to ignore versions seems to be a great design goal. Unfortunately, that design goal is shoved down the throats of users, and makes a very messy - and difficult to traverse or use - namespace where different versions are just thrown in the name without another thought. NixOS is my favorite Linux distro, and the only OS currently installed on my laptop. It's also frustrating in unnecessary ways.

jcrites 9y ago
It seems like Nix could benefit from a first-class concept for pinning the channel and managing updates to the channel. To achieve build reproducibility, the default outcome of checking out a project and building it should be to get the same result as everyone else who does so at the same project revision. I'd expect there to be a way to take a snapshot of the channel and lock those versions in the project until you're ready to upgrade. I have tinkered a lot with Nix, but have not used it for any production system. I'd be reluctant to use Nix in production if there wasn't a good way to pin the channel, so that everyone who is developing on a project sees precisely the same versions as each other, and everyone who is patching a specific version of a project sees the same version as what's currently deployed. In my opinion, this should be the default behavior and not something that you have to go out of your way to achieve. Maybe you could model this as something like a "channel fork" or "user channel". When you create a new project, you also create a channel for it that inherits from an existing channel, except that the versions of all packages are pinned and you can control the way in which changes make their way into your user channel from the upstream. My company has a proprietary technology that's similar to Nix, and we tackle the build reproducibility problem in this way, by making it easy to branch off the main channel and control how updates make their way into it (which is like a merge). The default behavior when creating a project is to also create a project-specific channel, derived from the upstream, company-wide channel. Dependencies are declared at the major version level only, and versioning beneath that level happens implicitly via the project channel. In this system you think of all channels as having revisions. Developers can control how their channel merges in changes from its upstream channel, which provides stability and reproducibility: until you merge and release a new version, `my-channel` always references exactly the same package versions for all developers. The default behavior of channels is to merge new versions from the upstream channel periodically, but developers can decide what's right for them, whether staying on the bleeding edge or prizing stability. Software builds, releases, and deployments always happen in the context of a specific channel revision (`my-channel@revision`), which can be named and referenced, so if necessary you can inspect or replicate exactly the code that's part of a colleague's configuration or a production system. Not just approximately but exactly, for every package involved down to `gcc` and `glibc`. It's easy to create a workspace with the package versions specified by `my-channel@12345`. By further tracking which source code commit hash corresponds to each package release in the channel, you can trivially look up the exact source of all packages (my-channel@12345 -> FooPackage@a1b2c3d4). Extremely useful! When you work and version things in this way, you hardly need version numbers beneath the major version level. I suppose it's reasonable that the Nix project doesn't want to host binary versions of lots of old packages to make this use-case fast. In that case, I'd want it to be easy to clone the binary version of those dependencies and source them locally. Maybe this could operate as something like a caching proxy in front of Nixpkgs, that will store my own permanent copy of any package that I access or build. On the other hand, keeping builds forever is expensive, so perhaps this is an opportunity for Nix to provide a commercial offering with private channel hosting and a package cache with infinite TTL.

derefr 9y ago

I've found that within other ecosystems, people are increasingly considering replacing existing tooling with Nix. For example, I've heard some rumblings in the Elixir space considering using Nix for managing SDK versions, for native/binary package dependencies, and for generating release packages. To accelerate the adoption of Nix, the Nix maintainers would need to reach out and help other ecosystems adopt Nix or Nix-like logics. But I think, as it stands, other ecosystems will eventually look toward Nix on their own, as they grow and attempt, one by one, to solve all the same problems Nix already has 100% solved.

deleted 9y ago

[deleted]

kovek 9y ago

I've found kind experienced users who supported me on webchat.freenode.net , #nixos. I always make sure to say thanks when they help!

wocram 9y ago

What kind of user experience are you talking about? As someone who uses it as just a package manager, I have had no complaints around using `nox`, `nix-env -i`, and `nix-env -e`. It does seem to have a sprawling cli and many additional purposes, so I can imagine the argument, but am curious as to what part of UX you're talking about in particular.

grantwu 9y ago

This, 100%. Pain points I've run into: 1. Lack of clarity as to how language/application package managers interact with Nix (pip, stack, Vundle). Pretty much every time I've asked about this, I've been told to go use `nix-shell` or to install things through Nix. Increasingly, when I get odd behavior with applications I install through Nix, my first resort is to uninstall the Nix version and install it from apt; it might be a bit older, but I'm sure it'll work as expected. I've went through the apt package -> Nix package -> apt package cycle three times from what I remember off the top of my head, with python/ipython, Haskell tooling, and Vim. 2. Nix on Ubuntu feels like a second class citizen. Things that interact with graphics drivers often don't work properly, e.g. video players. (I understand that there are technical reasons why this is the case, but there's no warning that this is the case.) There only appears to be online package search for NixOS (https://nixos.org/nixos/packages.html# https://nixos.org/nixos/packages.html#) and not for Nix on other platforms. Nox helps, but it doesn't seem to be the same feature wise (no ability to see the info you get by clicking the package name) and is also slow. 3. In general package quality is not great for less frequently used packages. Inkscape was missing potrace for a while. Rarely used packages go unmaintained. 4. Poor CLI. Needing to pass `-A` to a lot of commands to use them the "right way" smells of a poorly thought out design. No feedback or suggestions if you type the wrong thing to `nix-env -e`. It looks like there are major changes to this in 2.0, so this might have been improved. Despite being someone who's gotten their toes wet contributing to nixpkgs, I'm likely not going to be installing Nix when I upgrade from Ubuntu 16.04 to 18.04.

thomastjeffery 9y ago
> Needing to pass `-A` to a lot of commands to use them the "right way" smells of a poorly thought out design. That stems from the namespace problem that Nix devs seem to think doesn't exist. Packages that have the same name, or belong in a different namespace (hackage, pip, etc.) are confusing to find from a user's perspective. The real problem is that every package in a channel has to go into the same global namespace. Practically every package manager has this problem, but, in my opinion, Nix deals with it the most poorly. To make matters worse, it isn't obvious which namespace .nix files are supposed to reference, or what functions exist globally. Nix really does need a lot of UX work, and I'm glad to hear it is getting some.

whateveruser 9y ago

I've been kinda waiting for something like what Ubuntu is/was to Debian. Approachable. Last time I tried nix, learning curve was too steep. This update looks like they've started to work towards approachability a bit, so I might give it another go.

paride5745 9y ago

My thoughts exactly. Some time ago, I asked how to integrate NixOS in an existing infrastructure managed by Chef/Ansible. I was told I was wrong to even think about that and that Nix is a better system. Well, wrong. If you have a few thousands servers with a system, you cannot ask to migrate all to a new system without some integration with the old one first.

Mic92 9y ago
Instead of deploying individual configuration files, you would generate `/etc/nixos/configuration.nix` + some modules maybe followed by a `nixos-rebuild switch`. There is not special support required in Chef/Ansible to support this feature. Both Chef and Ansible are available in nixpkgs.

jimnotgym 9y ago

You may be right here. I like to think I am not a complete idiot, but I just read their 'about' page and now I know Nix has a folder naming convention and something about functional programming, but I have no idea how it is going to solve the issues I have with pip/apt/conda etc. In fact I am not really sure if it is supposed to, apart from seeing that it is a package manager. Now I have filed it mentally under 'too much trouble to learn'

pxc 9y ago
What are the issues you have with pip/apt/conda etc.?