The Linux cast boys discussing Nixos… @ scrub to 9:00
I hope they know the one man nix army know as @fricklerhandwerk is improving the documentation.
11 Likes
I’m not sure, i found the comment intriguing also…
1 Like
I think the judgement about the documentation is way too harsh. And I have made critical remarks about the documentation to people.
What is interesting in this interview is that they focus so much on NixOS, rather than on Nix the language and what it does and how it relates to NixOS.
1 Like
yes, I fear that the learning curve + the lack of understanding that NixOS is better thought from nix the language and seen as a tech experiment rather than yet another Linux distro may have a negative impact on adoption.
I still hope a sizable portion of people arriving right now will be staying.
3 Likes
Valve will likely be sticking to Arch for a while on SteamOS. As of update 3.5.5, they have included the /nix directory. Once you chown it, you can run the nix-env single-user installer and can install Nix packages to your heart’s content.
I think that’s fairly common among people who share criticisms of Nix online. The linux distro community is like “wow, nix is a bit much”. The dev environment tooling people think the same thing. As do the ops/config-management crowd.
It solves (and causes) problems across so many different perspectives that it’s a reasonable choice if you wear multiple hats, but a perplexing choice if you wear only one. People who have channels like this one… they’re catering to an audience of just one persona, so they’re typically less enthused.
This also explains the docs challenge. We have more audiences than Arch. We’re simultaneously comparable to Homebrew, Arch, Vagrant, Bazel, Ansible… tools which wouldn’t normally be considered as targeting the same person.
I’ve been thinking about putting together a few nix koans. The idea would be that we let the big picture be too big for any one doc and instead focus on small insights. If we had a list of these, when one asks for help and then gets it, they can say the solution was to spend more time meditating on NK17 (KN = “nix koan”).
12 Likes
From my experience over the last 2 1/2 years after first trying Nix on Mac and then switching to NixOS on all my private machines I could identify some issues I personally have had and still have with the existing documentation or the whole documentation landscape. But maybe that is for a different thread.
I think you are right that Nix + NixOS has a more diverse technical audience than most other projects. Arch Linux is not dependent on a functional programming language. And functional programming is rarely used to declare the desired state of an operating system.
Still what is being added right now is an even different new user base, at least temporarily, of people that do not just approach it from any of these prior technical interests. I’d say this has happened over the last year or so. And they mentioned in the video that a lot of this growth in popularity is due to NixOS being advertised on social media.
If the nix world could hold a few of these people and turn some of them into contributors to the wider eco system that is a great opportunity.
In my humble opinion, enabling nix-ld by default on NixOs, with sensible defaults, or at least with a simple way to enable it using like export NIX_LD_ENABLE=true (while printing a helpful error message if it is disabled) would significantly improve the user experience, and would be close to trivial to implement. This way beginners could run non-packaged programs like on any other distribution (which can be practical when dealing with non-nix-friendly setups like java, npm, pip), while being able to use true nix where it shines.
Another issue with nix on non-nixos devices (and even sometimes on NixOs) is it’s complicated NixGl wrapper to use and the glibc version error… I still think we could make it transparent to the user but it would require certainly a major rewrite of wrapper scripts… but the issue is less visible than the first issue I mentionned, and mostly relevant outside of NixOs.
Finally, I’d love to see user-friendly tools to deal with writting/debugging a derivation (manually running phases is quite long…). I don’t even think it’s complicated to program, at least for the basic functionality. More advanced functions could automatically detect the setup (python/bash script…) and write a nix derivation for it, but it’s the next level.
3 Likes
Still what is being added right now is an even different new user base, at least temporarily, of people that do not just approach it from any of these prior technical interests.
Agreed. The new crowd appears to be interested in something they call “ricing” (found a video on it). It seems like a bit of a linux desktop demoscene. I remember running across it when I first got into linux, 2005 or so. People were very excited about wobbly windows and other whiz-bang desktop effects. At that time it was all about Ubuntu, I guess it’s still going, now at Arch.
One thing that nix could offer these people is composability. You publish a youtube video that makes people go “wow, how can I have that” and then the answer is “follow these steps”. That’s fine if you’re replicating something exactly, but if you want to draw some inspiration from multiple other ricers, you’re now in a situation where you have to navigate whatever configuration headaches arise from the merger of the two.
Publishing these… rices? as home manager modules would be a much easier way to mix and mach customizations.
2 Likes
Yes, for the desktop ricing people, https://hyprland.org/ is pretty big right now because it is the first Wayland compositor that is built more or less explicitly for this audience. They also provide the whole thing via a nix flake for the bleeding edge version of it. I played with it a bit myself, maybe it got a bit more stable by now. I might try it again some time.
And yes, home manager modules might be an excellent way of managing otherwise chaotic collections of config files to deliver a consistent experience across different machines. But so far this hasn’t caught on that much I feel. Not many people provide their individual config in this way. Maybe NixOS needs to get more popular still for that to happen.
What you can see though due to increased popularity is that NixOS is more and more a standard listing among many projects for supported / available distros. So developers that are not themselves using NixOS are more aware of NixOS as being important. Compare that to Guix for example.
I just realized that the first two entries in the hyprland hall of fame, and several others besides, have the NixOS logo on display. Way to go @FlafyDev!
1 Like
While that might be a bit controversial, there is a new PR that makes the error message in such a case much better!
5 Likes
Awesome, thanks, I’ve been waiting this for so long ^^ It’s too bad this does not directly come with nix-ld, possibly enabled behind a flag like export NIX_LD_ENABLED=true to make it super easy to enable… but still better than nothing.
Finally, I’d love to see user-friendly tools to deal with writting/debugging a derivation (manually running phases is quite long…). I don’t even think it’s complicated to program, at least for the basic functionality.
Speaking of debugging. What setup do you use for doing this? Because this is one of the main points I would have brought up as well. Once people (including myself here) get to the point of developing derivations in nix, the developer experience is a bit of a struggle. Or at least has been for me so far. And I’ve seen people drop NixOS quickly again because of this big hurdle.
Depends what you exactly put into the word “debugging”. So there exists some tools like breakpointHook to move you into the VM where the derivation failed, but what I had in mind is a bit different (breakpointHook will still ask you to recompile everything from scratch everytime you change the derivation without caching anything), and follows the proof of concept I gave here. So usually, one way to manually test a compilation workflow (while benefiting from previously cached tries), is to run:
$ nix-shell
$ export out=/tmp/out
$ source $stdenv/setup
$ export NIX_ENFORCE_PURITY=0
$ set +e
$ genericBuild
or, if you want to run only a specific phase, run phases="buildPhase" genericBuild. It does work reasonably well, but is not super handy to use:
- you need to type like 5 lines just to start debugging
- it will only work in bash shell, unless you nest shells like zsh > bash > zsh (but then you need to type all compilation commands manually).
- it is your role of knowing which command/phase to run, where to extract the source… if phase A sets a variable used in phase B, you need to be sure to run it.
- some phases might not be idempotent (like patch phase, source extraction that expects an empty folder), so usually you don’t want to run these phases twice: so you need to know which phase is safe to run twice, which phase is not safe, which phase has been run already, which environment was configured at the end of which phase…
- if you change the
.nixderivation, you need to restart everything to take it into account - for some reasons, the shell often exists by itself (e.g. if the compilation command contains a
exit 1due to an error), which is extremely annoying when debugging - it will not help you to write basic templates (if I have a simple python code, I’d like to automatically generate the derivation semi-automatically)
Direnv does make it slightly nicer to use, but it is also not completely trivial. One possibility to make it nicer to use is to create a simple wrapper around these commands, which is exactly what I did here, so nothing super fancy, just a time saver. But it would be nice to make it a bit more cleaver, for instance to automatically restart the shell if new derivations are added etc. Some random ideas I had:
- it could be cool to automatically restart the shell if the derivation is changed (that is quite nicely done by direnv right now)
- try to see automatically which phase to run depending on the phase previously run, possibly saving the environment/bash commands defined in a file, and saving the state of source before/after running a given command (this way you can run the patch phase in a copy of the source, and copy this back to the working directory to still benefit from cached builds).
- define a command like
nix help-me-write-derivationthat could try to automatically write a basic derivation, possibly by asking the user about the preferred setup :
> I see you have a single python script in your project, will your project
1) stay with a simple python script to run
2) turn into a more complex project that provides python libraries (this will create a setup.py file)
1
> After looking at the python script, I see that you import numpy and requests. Do you want to add other dependencies? Which one?
foo
> I can see that foo is not packaged in nixpkgs. Would you like instead to use dream2nix? [y/n]
y
…
Another really cool thing to have could be to have incremental pure builds, in the sense that if the build phase is successful but not the install phase (this occurs REALLY often), I would like the next build to automatically restart from the end of the build phase rather than restarting from scratch. But this involve changes directly on nix-side I guess, and saving all bash environments + functions (using maybe env and declare -f like here), so I don’t really know how easy it would be to achieve that in a highly pure way.
Anyway, my point is to say that I think nix could provide a nicer user interface to build stuff.
5 Likes
Thanks for the amazing writeup! I will go through this and see what I can improve in my own setup.
I think an approach to this is just something that should be added to nix tutorials.
Peak meme internet.
https://www.shlomifish.org/humour/by-others/funroll-loops/Gentoo-is-Rice.html
get Ricing every body…
1 Like
I just published small script which improves my package development and debugging experience a lot - see: Nix-build-phases: run nix build phases interactively
2 Likes
do you have you own blog where you put things like this.
I have a strong feeling that all nix contributors, in anyway should be putting their contributions on their own blog, owned by their own domain name.
If you need help with this, I will gladly help you get your own web service, cms and domain name established.
Why am i thinking this is a good idea?
Back in the good old days of the internet , that so many here never experienced, we had ‘web rings’.
Nix users and publishers needs web rings, so i can basically browse a list of nix related web sites at my leisure.
I feel concentrating too much information one one server will be hard to scale soon.
lets make nix resources more distributed.
1 Like