It would be amazing if we had a smooth and well-documented process of setting up your nixos system offline, i.e. from your existing (nix-supporting) system. I think the biggest hurdle of installing an OS is the “downtime” on your main or only workstation.
Imagine you could
install nix on your existing ubuntu system
configure your ideal nixos system
the absolute minimum would be to create a configuration.nix
it would be great to also support setting up the drive partitioning
even better would be home-manager support
do some kind of nixos-rebuild build-vm that launches you into a VM that looks exactly like your real system will look. Ideally with support for some state, so that the user can poke around a bit.
iterate on this (maybe over the course of weeks and months, at your own time) until you’re happy
do something like nixos-rebuild build-install-medium to build an ISO. Flash that on a USB drive. Boot into it. Install exactly your system with one click, maybe with an additional confirmation prompt for the partitioning if supported.
I think that would be a lot more useful than a graphical installer and would appeal to the right kind of audience. I don’t plan on working on this, but I think it would be great.
It feels like there is way too much emphasis on making nixos easier to install.
If I am being honest, I don’t see the point. As others have already noted, it is already quite a bit easier/faster to install a working nixos system than it is to do an Arch install. But to me, that isn’t really the point.
No matter how easy you make the install, the individual still needs to go through the steep learning curve of nixos which is vastly harder than the install process. If you make the install more accessible you are just accelerating them before slamming them into a brick wall.
Learning nixos, especially if you don’t have a background in nix, requires some serious tenacity given the current state of the documentation. If you can’t get through the install guide, which is already well documented, you aren’t going to be successful in nixos.
Rather than trying to make the nixos desktop accessible to everyone, it feels to me like time would be much better spent trying to raise nixos as a desktop awareness among the community that has the best chance of being successful with it. Namely, people with a development and/or advanced scripting background. It seems like this audience would also be more likely to contribute as well.
To me, more education about what nixos is and what it isn’t in a prominent and accessible location would be more likely to dissuade the user who isn’t likely to be successful and encourage the user who is.
@dalto I agree entirely with your assessment about the installer.
I think that identifying the most common pain points in NixOS usage is the key first step to figuring out how to market NixOS better. Can we come up with a ranked list of what the most common pain points are? Once we have that list then we can better know where to focus efforts for the most impact. I’ll take a stab:
Documentation. Somebody gets interested in NixOS, installs it, then asks “How do I do X?”. If they can’t do X easily then the knowledge wall they face to figure it out is often insurmountable. They likely need to understand nix language and how to contribute to nixpks which is a ton to learn! There are already a lot of great ideas bouncing around about how to improve docs. Maybe a highly detailed list of mappings – “if you wanted to do X in other distros, this is how you do it on NixOS” is what is needed to ease the transition of people’s existing mental models into the Nix mental model.
Discoverability. This goes hand in hand with documentation, but figuring out how to configure parts of your system can be quite difficult. It often requires reading the nix expressions of packages to figure out how to configure them. This is where a packaging and configuration GUI would do wonders. Easy search and browsing of all the packages, modules, and their configuration would greatly ease the curve of learning NixOS. This would be extra beneficial if the UI were able to show the text diff of the config file – allow the user to play with options in the GUI to see how those things are accomplished in nix expressions. This would alleviate a great amount of frustration in learning how to accomplish most common tasks in the nix language.
Common patterns. A lot of users probably end up with very similar looking configurations when they’re working on common tasks. Providing a set of “recipes” for common workflows either as documentation or well commented modules could go a long way to bridging the gap between docs and “how do people actually do this on their systems?”.
Developer experience. Making a simple contribution to nixpkgs is pretty daunting for a new user. They have to understand a lot of details about nixos channels, binary caches, somewhat advanced git usage, etc in order to do small things like bump a package version or add a small option. Maybe some examples installed by default with nixos could help a great deal with this. Or perhaps an option to easily install an editor with a standard configuration of nix language support.
My personal experience is that while I love NixOS, every time I try to use it on my primary machine for work I end up switching back to something else in a couple weeks/months. I can make NixOS work for my daily driver but frequently the mental load and time cost for doing so is too high – I have work that must get done and sometimes I feel I can’t spend time working around difficult parts of nixos to do it.
Yes, documentation should be put on priority. Most of the time we would ask “How to do X in NixOS”. But currently users need to search around and look into the codebase of nixpkgs (it’s not bad but unpleasant and steep to go for beginners). And most importantly, they would need patience since writing working and aesthetic code would be different than hacking around with scattered files. (modularity and concise code always bring pain:)
It is great but it is not that prioritized. Users they are not lazy (imagine how they devote their time on Arch to resetup the whole stuff again).
Currently some module is exclusive to NixOS but not to Nix on other linux distros, so I would afraid how would nixos-rebuild handle this on places other than NixOS.
And while have an ISO cooked up is great, it is not that necessary because you could write a script to do so-called “one-key installation”. Like this: https://raw.githubusercontent.com/LEXUGE/nixos/master/install.sh
Seriously, it is way easier to work in NixOS, at least its idea of centralizing all configuration in ideally one language and one file makes it way easier to configure big systems.
I started doing a webcast series on NixOS, they are meant to be 5-15min lightning talks about a particular subject in nix/nixos/nixpkgs:
It’s my first time trying to do obs + youtube. So I’m sure there’s plenty of cringy things I’ve done, but overall I just wanted more material out there on NixOS. I was planning of extending it to do videos on packaging for particular toolchains such as: cmake, qt, autotools, python packages, gnu/makefile. Basic videos like using nixpkgs, nix (lang), and NixOS.Then doing some “intermediate” tasks, such as: using overlays, nixpkgs+python dev, shellhooks, overriding packages, nix-shell tricks/use cases, etc.
EDIT: Other topics I thought of as well: home-manager, niv, lorri, direnv, nix-shell scripts, fetchpatch, How to do a nixpkgs PR.
Thanks,
EDIT: I have watched them both now and to me they are most informative!
So keep them coming
Like timokau has mentioned they might be a bit technical for one new to Nix(OS) but I think going through them one or two times more will make things clear.
Would love to see some recordings of setting up a webserver.
Perhaps with Wordpress/Drupal or something webserver related.
Great initiative! In case you want feedback, I would try to focus a bit more on one target audience / level of abstraction. For those two videos, I wasn’t quite sure what that would be. If its people completely new to nix, it feels a bit technical / fast-paced.
Either way, I’m happy to see some more material out there
Agreed, I think my initial video was meant to be a, “what does NixOS do well?” video; which meant visiting a lot of topics at high level. Hard to restrict NixOS to a few use cases, and different people like different aspects of NixOS; is it the declarative configuration? is it the build isolation? is it the purity?
For that sort of overview, I think it would be good to focus only on “what can nix do for me” and not “how is it done”. That means ideally not opening any .nix file. Instead showing already configured things off like
I can run some tool one-off without installing it: nix run nixpkgs.sloc
I can enter some project’s environment with nix-shell.
Maybe show a tiny modification to the environment, such as adding a single package. But again, the time spent editing a .nix file should be minimized.
I can define a scripts environment in the shebang
Maybe: I can rollback my system. But it would probably be better to focus on nix first, then get into home-manager and nixos later.
In general I would keep things very shallow in the first video. Further videos could be deep-dives of certain topics.
Things like declarative configuration, build isolation, purity are closer to “how” than “what”/“why”. To get a newcomer hooked, I would start with a use-case and then go into how nix can solve it.
I hope this doesn’t sound in any way negative. I like the videos. I don’t think I could make better ones. This is just my opinion, maybe it helps
Not at all, I’ll keep that in mind if for when I’m doing higher-level topics. I still wanted to crank out the more specific topics which will be much more technical and focused.
I thought this was effective exposure! Edit: saw on HN some negative feedback. Maybe the blog post could have been better, but I definitely think industry professionals sharing how/why they use nix is (generally) useful. I think the docker comparison comes up a lot, and maybe (if not already) that should be explicitly addressed.
As a sort of one-user story, maybe someone should figure out what information this user would like to have and where he looked for it (i.e. where it should have been). The answer to that question isn’t so easy (there’s clearly more than one problem nix solves, depends on the use-case), and I don’t currently have the time to write that up myself.
I thought this was effective exposure! Edit: saw on HN some negative feedback. Maybe the blog post could have been better, but I definitely think industry professionals sharing how/why they use nix is (generally) useful. I think the docker comparison comes up a lot, and maybe (if not already) that should be explicitly addressed.
I think @burke did a great job and explaining Nix and how it works is not so easy task. Personally I tried to avoid answering the question “What is Nix?” because different people understand this title differently. Some expect you to convince them “Why to use Nix?”, others want to know “Quick overview of Nix?”, than others want “Deep dive into Nix internals” and some want everything . I guess managing expectations is one key thing when writing such a blog post. Regardless I think blog post takes a nice - adjusted to Shopify - view at Nix.
There will be always be bitter people on HN. But it would still be valuable if we could collect the pain points that some raised there and try to address them. It would mean a lot if somebody would take the time to collect this in some document, @burke maybe since you are the author and you might received even more feedback in the internal channels at Shopify.
Not actually too much feedback internally on this post. The engineering blog is not actually a big thing for us internally since the topics tend to be stuff that’s been circulating internally for a while.
I think one of the big causes of the negative feedback was, as you say, my failure to manage expectations, or rather, not giving people an opportunity to self-select out of the audience for the post. Really, it was targeted at people who already know a liiiitle bit about nix but want to develop a stronger intuitive model about what makes it interesting from the bottom up. On the other hand, the short title collected a lot of eyeballs that it wouldn’t have with a more accurate title.
This blog post actually evolved from a presentation I did internally just before the world got weird that I’ve been meaning to do again and probably release on my YouTube channel. I think I’m better able to communicate what’s going on in that format than in a blog post.
The presentation will actually figure (in a highly abbreviated form) at the start of my ShipIt! episode on Monday. The demos afterward will likely be interesting to nix community members.
I know this thread has been going on a while, but can I chime in with something?
I would like to see more emphasis on Nix/NixOS as a configuration management tool. Many of my coworkers in the last few years have grown to hate Ansible for its wacky non-deterministic behaviour, especially for large deployments. Some have gone back to Puppet. There is an opportunity to present Nix/NixOS as an Ansible/Puppet alternative, rather than as merely a Linux distribution or package manager.
All of the Kubernetes deployment tools I’ve used have kind of sucked. NixOS’s support for running k8s clusters still needs work, but I see a lot of potential there.
Though nixpkgs doesn’t include OpenStack currently, it would be the perfect thing to deploy clouds with. The current standard way (from what I’ve seen, at least) of deploying OpenStack is kolla-ansible, which is a frightening mix of Ansible and Docker.
Some have framed Nix as a competitor to Docker, but they aren’t really in the same space. Additionally, Kubernetes has become the standard way to deploy almost everything. That said, building Docker images with Nix guarantees a higher degree of repeatability than a Dockerfile with Alpine or what-have-you.
TL;DR: Nix’s strengths are as a DevOps tool in this weird little niche where Kubernetes isn’t a good fit. We should highlight that.
