Marketing Team: Can we present Nix/NixOS better?

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.

15 Likes

Thanks,
EDIT: I have watched them both now and to me they are most informative!
So keep them coming :slight_smile:
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.

2 Likes

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 :slight_smile:

1 Like

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 :slight_smile:

4 Likes

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.

2 Likes

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.

5 Likes

We could make an Youtube video of it!

1 Like

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.

https://engineering.shopify.com/blogs/engineering/what-is-nix

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 :slight_smile: . 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.

8 Likes

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.

12 Likes
  • 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.

This is planned, but is going to take some time before we get there.

  • 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.

I can only agree with you. But this use case needs to be polished before we can promote it on the website.

  • 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.

As with kubernetes, when somebody will polish the solution and document it I don’t see a reason why not to promote it.

  • 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.

Building docker images with Nix is going to be features on the landing page. Very soon.

Thank you for the suggestions. I hope somebody takes on the Kubernetes and OpenStack use case.

2 Likes

As with kubernetes, when somebody will polish the solution and document it I don’t see a reason why not to promote it.

I was an OpenStack admin for a few years, so I can probably be of some help here, assuming I can find some free time.

1 Like

NixOps does a pretty good job in that regard, though it is a bit less general-purpose than Ansible since it assumes the configuration it will be managing is for NixOS machines.

1 Like

I think we need a very good default config for desktop NixOS. One that supports a lot of hardware, etc. It would be nice if users can use the default config as their primary OS as they still adapt to the Nix operating system. This idea is based on helping two people move to NixOS.

4 Likes

I think the opposite. We could make a repository like https://github.com/NixOS/nixos-hardware but contains more features. For example:

  • Config specific to a laptop/machine hardware
  • Config for laptop, max battery life/balance/max performance
  • Config for gaming
  • C++ dev env, AI/machine learning dev env, Web dev env …
  • User can easily choose the features that they want by just import the config file to configuration.nix, or select in a GUI tool
  • User can contribute their config file to the repo by make a pull request.

For example:

  • A teacher could just tell his student to open nix-module-manager, select the module dev/c++ with option vscode and rebuild, then they could start writing C++ code with all environment set up by nix: compiler, editor, tool chain, lsp…
  • If I buy a new laptop, I could just install nixos, select the hardware/brand/my-laptop then install. It will solve most of problems: drivers, finger print not working, HiDPI for 4k laptop, power saving, brightness control, …

ArchLinux has great wiki but we can make it better, we can apply the fix in the wiki automatically. The idea is user only need to tell what they want, and the repo figure out what need to do.

7 Likes

I’m committed to evolving this idea, waiting currently for some feedback from @garbas & @samueldr. Or anyone who’s got a great idea how this idea can be put to use.

Or …

… I might just ask for becoming part of the marketing team :stuck_out_tongue_winking_eye:

For my part, I am mainly interested in the process of developing a system config from scratch. My current config works and is pretty solid, but it’s built up on a bunch of ideas and structures that aren’t mine. I stole useful looking stuff from a bunch of other configs and sort of just jammed it all together until it did the stuff I wanted. This got me over part of the learning curve, but it leaves me in the awkward position of basically understanding the components, but not really being able to explain the “why” of all those choices.

For instance, I’d love to replace my Emacs overlay with emacs-overlay or rework my Haskell overlay to use haskell.nix. I think I know enough to do the former with some thought, but I have no idea if it’s sensible or even possible to use haskell.nix for a system-wide GHC or if it’s really just for projects, and I don’t know where to look to determine that.

I decided to just start reading the manuals and the pills end to end and taking notes to start tying ideas together, but the primary target of the Nix and nixpkgs manuals definitely appears to be people writing packages. This is fine and sensible, but it leaves me a bit adrift in answering the question “how do I, starting from nothing, write a quality system config that I can version control?”

The extra sticky bit is that I primarily use Darwin, so most of the NixOS documentation that might go toward answering this question is of varying usefulness. Most blog posts are about how to package such and such type of software or a recapitulation of the "how to package GNU hello" exercise, which tells me little about how to actually configure my machine the way I want it.

All of this is to say, I would be extremely interested in seeing (and even helping to write) a “Nix book” that isn’t just a manual.

Example: This is a really slick config, with a really straightforward installation and support for multiple machines and all that cool stuff. But! I have no idea what the assumptions made in this config are, what structural choices are good or just interesting, how I could write my own config like this other than copying it and tweaking. It even installs nix-darwin as part of its setup, which would remove one more manual step from applying my config on a new machine.

What is the gap in my knowledge that lets me read this config, basically understand what it’s doing, but not be at all certain where to start to make my own?

Parts of these could (and perhaps should) be addressed in the documentation of the projects themselves, but some kind of unified “Configure your machine with Nix” or even just a “Nix config cookbook” would be huge for me (and, again, I’d be happy to help). Figuring out and documenting these patterns centrally may also encourage their conversion to modules, so that users can say “yes, I want to interact with x in this way, so I just import the module and set some variables” or “no, I want to use this differently, but now I have the mental tools to write my own module to manage this”.

From a consumer perspective, it’s also a whole lot easier for me to pitch Nix to my team if I can say “just read this book and you’ll know a bunch of things you need to know” rather than “go read the manual to learn the vocabulary, now go read these 15 blog posts, but also ignore about a third of that content because Nix and nixpkgs have improved a bunch in the last year”.

To draw an analogy, there are a handful of books on how to use any given Linux build system, and a dozen “how to use Linux to do stuff” books. On the other hand, there a dozen books worth of content on the Nix build system, but only a handful of non-source-code resources for “how to use Nix to do stuff” (where “stuff” is “anything but building packages”).

4 Likes

You should take a look at https://github.com/LnL7/nix-darwin which is the macos equivalent.

I agree, it would be nice to have more of a narrative with nix/nixpkgs/nixos.

I started doing some videos https://www.youtube.com/channel/UC-cY3DcYladGdFQWIKL90SQ
I was going to do a more polished (slides, final voice over, graphics, maybe transitions) video series, after the 20.09 release. Maybe have them as the “unofficial” NixOS series.

Yea… unfortunately a lot of the conventions for nixpkgs all exist in the nixpkgs repo, which means they are subject to change over time. Nix allows for a pretty large breadth of expressiveness, and this means that there’s usually no idiomatic way to do something. Certain aspects are “too painful to change” (e.g. stdenv usage), but almost everything else could be changed.

3 Likes