Nix feels like a dead end.
Huh? I see nix more and more in the wild.
20 years of Nix
61–70 of 113 posts
Re: 20 years of Nix
#62I have been exploring nix for the past few months and my experience with nix has been both exhilarating and frustrating, simultaneously. On one hand, I find it hard to imagine not using nix now, but on the other hand, I hesitate to recommend it to other colleagues due to its steep learning curve, ux issues and potential for footguns. I sincerely hope that nix community improves the UX to make it more accessible to ne…
What I see as a barrier for entry to Nix/NixOS is not the UX, but the available documentation, or lack of thereof. One may consider the docs being part of UX though. I am in the process of writing a book about NixOS, you may track the progress here:
https://drakerossman.com/blog/practical-nixos-the-book
The emphasis is on how to make it as practical as possible, plus cover the topics which may apply to Linux in general, and in great detail.
Re: 20 years of Nix
#63Earlier quoted context omitted.
Agreed, reproducibility is only one aspect of Nix and doesn't quite capture the whole picture. That's why so many newcomers see Nix as nothing more than a Docker replacement. There's also too much misconceptions about Nix the language that's scaring people off. I'd like to see more being discussed about: * Its unique ability to treat packages as programmable data (i.e., derivations) * Its use case as a building block…
> Its unique ability to treat packages as programmable data (i.e., derivations) How is this useful in practice?
It's super easy to extend packages. For example, I was playing with Kafka and wanted the standard package to coexist with a separate install of Kafka with some jar files I needed. It was super easy to create a new package of Kafka with extra install steps that downloaded and placed those jar files where I needed.
Re: 20 years of Nix
#64I have been exploring nix for the past few months and my experience with nix has been both exhilarating and frustrating, simultaneously. On one hand, I find it hard to imagine not using nix now, but on the other hand, I hesitate to recommend it to other colleagues due to its steep learning curve, ux issues and potential for footguns. I sincerely hope that nix community improves the UX to make it more accessible to ne…
What I see as a barrier for entry to Nix/NixOS is not the UX, but the available documentation, or lack of thereof. One may consider the docs being part of UX though. I am in the process of writing a book about NixOS, you may track the progress here: https://drakerossman.com/blog/practical-nixos-the-book The emphasis is on how to make it as practical as possible, plus cover the topics which may apply to Linux in gener…
Your email form to follow the book is returning errors to me. And you have no other contact channels I can find. Might want to look into that.
Re: 20 years of Nix
#65Earlier quoted context omitted.
What I see as a barrier for entry to Nix/NixOS is not the UX, but the available documentation, or lack of thereof. One may consider the docs being part of UX though. I am in the process of writing a book about NixOS, you may track the progress here: https://drakerossman.com/blog/practical-nixos-the-book The emphasis is on how to make it as practical as possible, plus cover the topics which may apply to Linux in gener…
Your email form to follow the book is returning errors to me. And you have no other contact channels I can find. Might want to look into that.
Thank you for pointing that out! I have a twitter with the same handle, if you would like to subscribe to that. If not - wouldn't you mind a follow-up email when I fix the subscription form?
Re: 20 years of Nix
#66I have been exploring nix for the past few months and my experience with nix has been both exhilarating and frustrating, simultaneously. On one hand, I find it hard to imagine not using nix now, but on the other hand, I hesitate to recommend it to other colleagues due to its steep learning curve, ux issues and potential for footguns. I sincerely hope that nix community improves the UX to make it more accessible to ne…
There are two sides to this problem, the first is to improve the UX, but the second is to clearly describe a compelling reason for people to adopt. It is very tempting to only blame the first, but I think we need to also need to tell a better story and highlight the values in a better way. This would then give people a reason to get past the UX issues in the hopes of achieving those desired values. For example; peopl…
> but the second is to clearly describe a compelling reason for people to adopt.
Build source straight from Git:
nix run github:someuser/someproject
nix run github:someuser/someproject?ref=v1.0.0
nix run \
--override-input somelib github:someotheruser/somelib \
github:someuser/someproject
git clone https://github.com/someuser/someproject
# do your changes
nix run someproject/
NixOS just feels like a distribution build from the ground up for Free Software. The "reproducibility" in every day use just means that stuff won't randomly break for no reason. And if you don't wanna go the full NixOS route, you can just install the Nix package manager itself on any other distribution.
That said, the part where Nix gets painful is when it has to interact with the rest of the software world. Things like software that wants to auto-update itself really does not fit into the Nix ecosystem at all and can be rather annoying to get to work.
There are of course numerous other pain points, missing features and all that. But being able to flip between versions, fork, compile and all that with feels just so much better than anything else.
Re: 20 years of Nix
#67Nix feels like a dead end.
Can you elaborate? Personally I feel like everything else is a dead end compared to Nix
I personally would prefer a build and environment tool which uses the modern Linux namespaces to prepare isolated filesystems without needing to reinvent a whole bunch of wheels.
A number of problems that I would like to be fixed: - Post-build patches to insure correct shared library paths in artifacts due to requirement to use absolute /nix/store instead of using the traditional Linux filesystem. - Numerous wrappers around existing build tools to move dependencies into nix packages to generate stuff like Cargo.nix. - Not so good handling of content-addressable packages due to historic cruft. - Horrible-horrible way to compute runtime-dependencies of packages [1]. This may be okay as a heuristic to initialize a project, but in the end it must be tweakable manually.
I see a future where a package manager builds a fully-isolated environment with only and only required dependencies for my app, using CAS but not forcing it's style of the filesystem on me. Nix is a good step into that direction, but that's not a usable product in my view, just a research project.
[1]: https://nixos.org/guides/nix-pills/automatic-runtime-depende...
Edit: Forgot to add, Nix the language is also not good, but I'd like not to discuss that matter. This would be solved by a more modular architecture, where we can manage package with a one tool and build packages with a different tool. Until then, I would be forced to code in Nix, and that's problematic no matter how good the package management is.
Re: 20 years of Nix
#68Earlier quoted context omitted.
Agreed, reproducibility is only one aspect of Nix and doesn't quite capture the whole picture. That's why so many newcomers see Nix as nothing more than a Docker replacement. There's also too much misconceptions about Nix the language that's scaring people off. I'd like to see more being discussed about: * Its unique ability to treat packages as programmable data (i.e., derivations) * Its use case as a building block…
> Its unique ability to treat packages as programmable data (i.e., derivations) How is this useful in practice?
I'm surprised that nix never ended up using augeas for package configuration because last I checked every upstream build option has to be reproduced in nix script by the packager.
Re: 20 years of Nix
#69Nix feels like a dead end.
Can you elaborate? Personally I feel like everything else is a dead end compared to Nix
Sure; from an industry adoption point of view.
I don't think it will ever gain widespread industry adoption. All signs point to it remaining in niche, even if growing currently, user communities while being a curiosity to the wider IT world.
It's not even in the conversation in most of the professional world. A large portion those who use, like it, and write about it say they wouldn't recommend it to anyone.
Re: 20 years of Nix
#70Earlier quoted context omitted.
Can you elaborate? Personally I feel like everything else is a dead end compared to Nix
I personally would prefer a build and environment tool which uses the modern Linux namespaces to prepare isolated filesystems without needing to reinvent a whole bunch of wheels. A number of problems that I would like to be fixed: - Post-build patches to insure correct shared library paths in artifacts due to requirement to use absolute /nix/store instead of using the traditional Linux filesystem. - Numerous wrappers…
The filesystem complaint seems so fundamental, you might as well be complaining that Linux didn't use C:\ as its filesystem root.