Marketing Team: Can we present Nix/NixOS better?

That’s more like a statement than a reason, how more healthy would we be if we had about the triple size of the people that can fix things? I’d say even more healthy.

Given that onboarding is hard and there are disagreements on various things…

Do we get 4× the number of people in need of advice, 3.5× the number of people who file high-quality issues, 3× the number of people who can fix things, 2× the number of active committers and 1.5× the RFC process throughput?

This might be a worse experience for many of the contributors.

How can we get to 2× 3× 3× 4× 2×?

Things like documentation work you emphasise of course help people to start contributing, but active outreach and GUI installers feel risky from that point of view.


Another example I tend of think of is Rust. I’m somebody who uses it full time. I think it’s an amazingly well designed and well thought language. The core team members are extremely nice, as nice as Nix. However, its not for everyone. And being marketed as this “empowering” thing which is the second coming of christ means you have a lot of people using it who aren’t benefitting from it thus creating a cognitive dissonance that realizes itself in the form of a spontaneously created RITF which does things like- “” (and another one like that, vile enough that the maintainer quit open source). To be very clear, I love Rust and the people who created it. I think it’s the marketing that attracts the wrong crowd.

On the other hand, the original Mozilla’s «Annoy The Internet Into Quitting» Task Force, people complaining to the web masters about standard violations in all the web sites, was an important part of IE6 fallout cleanup, and arguably the internet now would need it again to disincentivise Chrome-on-Windows-only web development.

Many pieces of software assume that if Fedora and Ubuntu keep something in the same place, it is always there — which is bad for corner cases, bad for BSDs and bad for us; while we need to avoid being too aggressive, purely numerical clout is unfortunately more helpful than good practice arguments for getting patches accepted.

1 Like

Exactly. That’s what I mean, we have to focus to fix documentation and ergonomics to make our growing user base happier and reach far further audience.

I’ve talked to a number of people in recent months and many are waiting for us to show that we care about these things and mainstream Nix.

That has been my mission for many years and we’re getting closer.


I think a main problem with Nix(OS) is bad UX/acessibility due to bad documentation.

Documentation is scattered throughout so many different places (or not existing at all), and there’s ten ways to do things. Getting that up to shape will probably fix a lot of the problems newcomers / casual users have with it.


:grinning: Speaking my language. Not binary and @qyliss’s project is called “Spectrum”. You have no idea how perfect this is @domenkozar.


I’d love to see a “NixOS Pills.”

For installing Nix, I agree that a full-blown GUI is not necessary, but it would be great to have a cmdline program for generating an initial config based on hardware / a couple questions to the user. The few people I know that now use NixOS as a daily driver each spent 1+ full days figuring out how to boot into NixOS (myself included…). Time spent to working boot, with, say, the same initial packages as the installer, is a solveable and important issue.

One aspect I love about Nix/nixpkgs is how welcoming the community is for first-time contributers. We might top the linux distro leaderboard for ratio of contributers:users. We do an awesome job of converting users to contributers. I don’t have the faintest clue how to contribute to Debian/Ubuntu packaging after using the OS for 15yrs, but was contributing to Nixpkgs within weeks. I’m (perhaps naively) not as concerned about this.

I very much want to see the community grow in size as we would all reduce our time burden in packaging software and fixing broken packages with more users.

It might help spread the burden if it was easier to contribute to documentation. For example, it’d be awesome if there were links for each heading that took me to the source file it came from. Although maybe this is treating a symptom–the logical flow of sections doesn’t correspond to source code layout, so it’s hard to find relevant file without grepping. That said, I think the documentation is generally high-quality and beautiful :slight_smile:.

Finally, just to throw in a grenade…

The nix language itself is a major barrier to adoption. The fundamental choices are fantastic, e.g. laziness, file type, etc., but the error messages are often incomprehensible, the standard library is anything but, and the syntax/keywords are, well, unique. I won’t repeat the well-known critiques that started Guix in the first place as this ship has long sailed. But I do think it’s productive to look at Rust’s 2017 roadmap and what they achieved in 2017.

An effort around friendly error messages & perhaps even a Nix language server might go a long way. More bold ideas include gradual typing a la Racket, Julia, or Typescript, and an alternate syntax / language that compiles to Nix, like what ReasonML did for OCaML.

Edit: I just saw, which is fantastic!


I just wanted to chime in from the generic software developer side of things to say that a graphical installer would be welcome. I’ve used nix for several years, and NixOS for a couple years now, and the installation process was not fun.

I’ve never succeeded in selling any developer on NixOS, and a signficant part of that is that the developers I interact with are Linux users, but know only enough to get what tools they need running. Easing installation would be a significant improvement for such people. I know we all live in our own bubbles, so I wanted to speak for the non-server admin crowd. I’m in the demographic I speak of, so I’m comfortable saying that nix is worth using as a tool even for a non-expert user.

I’m glad you found out about the error messages proposal and there’s the first PR with new formatting.

We’re looking for individuals and companies that care about ergonomics of Nix to help with donations :slight_smile:

I’ve never succeeded in selling any developer on NixOS, and a signficant part of that is that the developers I interact with are Linux users, but know only enough to get what tools they need running. Easing installation would be a significant improvement for such people. I know we all live in our own bubbles, so I wanted to speak for the non-server admin crowd. I’m in the demographic I speak of, so I’m comfortable saying that nix is worth using as a tool even for a non-expert user.

Have you succeeded selling them on Nix-on-whatever?

Do you have anything in your configuration.nix which is not string/integer/boolean/plain-attribute-from-pkgs? (no overrided packages, no locally defined functions, no function calls, nothing interesting)

I see you consider Nix → NixOS switch a net positive for your, were the noticeable drawbacks for you despite the net benefit? Also, how much of the workflow have you moved to Nix-installed stuff by the moment of the switch?

(graphical installer rant)
I’m a bit fed up that this went again to graphical installer.

I agree that extending user base by adding a graphical installer is wrong. Do we need that? Is it good for the community?

I guess everyone here, when searching the web for an problem, found topics on the Ubuntu forum or the Archlinux forums (or pages on wikis). Which of them helped you at this point? Nowadays I just skip Ubuntu pages in my search engine results. I know that most of time I will not find the solution, so I don’t waste my time.

You may think it’s elitist, but I think that users that are unable to install the distro cannot really use the distro.
If one just want a laptop to surf the web, then she just installs Ubuntu or Manjaro or whatever.
Yes, maybe after 1 or 2 years the installation will rot, and she will be frustrated, because she cannot really use the distro. But at least it lasted 1 or 2 years.
It will be the same if she installed NixOS anyway. Do we want to target his audience?

Maintaining a graphical installer is a lot of work. Even big distributions installers (like Fedora’s) are not perfect.
I don’t see the point to put this amount of work when a shell and tools (fdisk, mkfs, nixos-install) do it right.
With NixOS, you need to edit/copy your configuration, so you cannot really bypass this step.
If you give the user a “default” installation, it will be completely unusable and unmaintainable for her.

Proposing a graphical installer would increase the number of users who “tried” NixOS, and in particular the number of users who abandoned it.

Actual proposal:
What we could do, is extend the NixOS “profile” to wrap “common” end-user use cases (say a graphical environment with working wifi, web browser, etc). The user may be invited to actually read the profile .nix file, which may be highly commented. Then she may use the profile (or a combination of them) and would be able to change it (say she wants chromium instead of firefox). This could be a smooth introduction to the configuration syntax. This could be enough for a basic usage of NixOS : changing a “firefox” line to a “chromium” line is not that hard, as soon as you’re able to locate and edit the file (thus, no graphical installer). If what the user need (working wifi, etc) works out-of-the-box, I think she does not need to tinker with most NixOS configurations (she will probably not setup sshd). If the user want more advanced configuration, she is welcome to ask for help, read the documentation, or do trial-and-error cycles. Maybe, 2 months later, she’ll do a PR to add a missing package.
(end of graphical installer rant)

More interesting (IMHO) thoughts, related to the original post:

  • content:
    • we could write a smoother introduction document to concepts than a raw manual. The manual is really useful, but need time to assimilate in your head. For welcoming new users, maybe we need another form of “manual” (this ties with what I said with the profile. It’s easier to learn from examples).
    • searching the NixOS configuration options, the packages definitions, the module definitions, the function (e.g: mkDerivation, concatMapStrings) definitions is a bit cumbersome and scattered in several places. We could write a document on what are the entry-point for each of them, how to find them from the repl, the , etc. I think this is scattered in to many places today (wiki, manual, old blog posts, power user’s head, nowhere).
    • in fact, do we want average* people to search through the git repository or their <nixpkgs> installation, or do we want nice interfaces (when they are doable)?
    • more “modern” tools such as are a big improvements IMHO, big thanks to those who put that in place. Maybe we need web developers, UX designers, etc who are not Nix power users but can build better tools.
    • we could make a “showcase” “built with Nix” page. People built really nice things on top of Nix, beside the desktop/server usage. For instance a risc-v emulator, Nixery, cachix, CIs,, etc. But there’s also the cross-compilation infrastructure (for embedded device developers), the docker tools, Hydra’s “reproduce locally” feature, etc.
  • completely agree on the audience question. Should desktop still be considered as the main target?
  • we may improve “selling” points and resources for new users, but I think we could also improve resources for power users. For instance, if one want to understand how C compilation works (gcc and friends packages, wrapper, NIX_*FLAGS, etc), she needs to dig into the Nix files. A bit of meta information from the authors (why? how? the plan, the big picture) could be useful to hack these things faster (Note that there’s a unofficial wiki page for this one). I guess it’s better nowadays for new things, when PR reviewers ask for documentation for non trivial PRs.

* off topic: in french we can say lambda people for average people. Not sure it translates to english, but anyway in our context this may be confusing :smile:

(Edit: was not meant to be an answer to domenkozar’s post. But Discourse is flat anyway)


The nix language itself is a major barrier to adoption.

There are ideas about replacing the Nix language (e.g. with a more CUE-like language) but that’s waaaay beyond the scope of the marketing team.

I’ve never succeeded in selling any developer on NixOS

So the choice we’re making is that we don’t try to sell developers on NixOS (for desktop use). Rather we try to sell them on Nix (and NixOS for servers like EC2 instances). For Nix I don’t think a graphical installer would help. You just want curl | sh doing the right thing.


Not that I agree that NixOS installation should be graphical or any easier (it should be easier but won’t help in long term adoption) perhaps somebody could point out what ehxactly are the pain points? In the “worst” case, there could be a TUI?

I see only two things- one is (even scary to me who claims to have written an x86 bootloader) disk partitioning. Other, before that is starting internet. Are there even any other steps in existence? For the latter we could just have iwd as default. Which has a much simpler interface using iwctl tui. No more wpa_supplicant and it’s quirks. But even otherwise, there could be a tui that asks user to enter username and pwd for wifi, and do a rebuild switch in the live environment (if it works at all).

Also, disk partition has a TUI tool available too. And the graphical Live CD o lf course comes with gparted.

1 Like

Since i think we all agree going into detail on this is off-topic for the marketing team, let’s move this to its own thread? Started one:


Does the “CUE-like language” refers to cuelang? Where is it better than nix? This may be off topic, do you have a discussion link that I could read? Thanks!

I’m assuming he is talking about

1 Like

Not yet!

Yes. I have various overlays, package overrides, and sometimes kernel patches.

I was mostly nix-ified before using NixOS. The only downside of NixOS beyond nix was the installation. It’s an uncomfortable half a day if you’ve already identified the handful of posts (e.g.) that walk through it.

I’m not sure what you meant by “were the noticeable drawbacks for you despite the net benefit,” but, iiuc, the thing for me is that nix packaging is the main pain point of using nix. NixOS on top of that means you get what is, to me, a nicer way to deal with kernel customization and driver wrangling than you get elsewhere.

Better desktop installation seems like a small thing to me in the grand scheme of things, and there is apparently someone (or some people) working on improving it, so I’m slightly disappointed to see their efforts discouraged given that this was the one annoyance in going from nix to NixOS.

Thanks for your reply!

but, iiuc, the thing for me is that nix packaging is the main pain point of using nix.

Depends on the workflow, of course. Some people need software with an annoying number of FHS assumptions, for example.

Yes. I have various overlays, package overrides, and sometimes kernel patches.

NixOS on top of that means you get what is, to me, a nicer way to deal with kernel customization and driver wrangling than you get elsewhere.

Note that letting you set all of this up via a GUI installer is an even harder problem than an installer for minimal-viable-NixOS-configuration. Having a GUI tool that discourages doing the things that provide the most value (but also require the most understanding) has some drawbacks.

Maybe what would be good is more like porting back to Linux, in the sense of managing small pieces of a non-NixOS Linux setup with Nix until conversion to NixOS requires just mounting the partitions and auto-generating the hardware config. Thus there would be less of a leap of faith between just using Nix and installing NixOS.


The main reason I use nix (as a ML/robotics person) is the ability to use nix-shell to ensure that the libraries I need for opencv/cuda compute are readily available on the cluster and on my workstation. I think this a huge target demographic (see GitHub - spack/spack: A flexible package manager that supports multiple versions, configurations, platforms, and compilers. for a nix-inspired implementation). On our compute cluster, nix also solves a problem with userspace library duplication which just eats memory when you’re dealing with several hundred users who all want to store their home directories on limited SSD space, and also want to install their own cuda/python/r/conda environments.

I also think that desktop-nix is an important component of drawing people into the ecosystem. I’ve sold several friends on home-manager for keeping consistent configuration across mac/linux/cloud/cluster, and also several former arch people on the bleeding edge, but stable and if not atomic rollbacks concept.


IMO a web/app interface for managing common parts of Nix systems would go a long way to easing day to day pain points. It could be a strategy that hits a lot of people’s use cases, including ease of installation, offering something relevant and useful for almost all nix users.

I wrote a long post describing the idea here: User-friendly NixOS distro? - #41 by imagio but the gist of it is to use an (web)app to take care of everyday pain points like:

  1. Discoverability and installation of software (add/remove/search packages from config graphically)
  2. Config backup and recovery (easy backup/restore to, github, etc)
  3. Discoverability of configuration options (see what options are defined for packages/modules you’re using and set/unset them)
  4. Discoverability and setup of most common use cases (list and include modules for things like “kde desktop”, “steam gaming”, “lamp server”, “android development”, etc)
  5. Developer experience of working on nix (embed a monaco editor with nix syntax extension, quick access to key files, links to docs, maybe other tools)
  6. Management of generations, garbage collect, delete old (UI list of generations, diff of config between them, buttons to switch/delete)
  7. Configuration during installation (use the above tools during installation to ease the experience, make headless, remote, etc config awesome and easy)

As I’m sure you can guess based on the above, IMO the thing that makes NixOS hardest to sell is the knowledge curve (or maybe cliff). Everybody loves the concept of reproducible configs and atomic upgrades but actually getting the benefit of those things requires too much knowledge and work up front to be practical and attractive for most users. As others have pointed out even the process of acquiring that mountain of knowledge is currently a barrier due to documentation issues. Nix has a very high up front cost in time/knowledge to be able to use it. Easing the transition into that knowledge and presenting it at appropriate times via more discoverable/usable management tools is IMO the key – market nix as “start easily, gain uniquely powerful tools as you learn”

1 Like

That is such a great news ! Now that I’ve started using Nix and NixOS, I can hardly imagine going back to Manjaro, Ubuntu or others, but often when I talk about NixOS to other people they think I’m some sort of black wizard. I don’t know many people who would choose to install NixOS on their laptop.

My two cents about NixOS:

  • A graphical interface for installation is required

This is only if you target a very wide range of users. The truth is that (for now) NixOS can’t.

In most cases, a user will want to use a software that is not on Nixpkgs and in such recurrent case he/she will most likely have to make the package him/herself, which is only possible if said user has a developper background.

My opinion is that for now, NixOS is well suited for people who can (and WANTS TO) get the expertise on how to use it: not quite your average user.

  • NixOS has a steep learning curve/it is hard to learn how to use NixOS

I made a rant on r/nixos, let’s not repeat over and over. TL;DR: using the documentation to get sht done is fcking annoying. I see the table of contents as a realization of that from the NixOS team, which is great.

  • Nix error messages are bad

I would even say that we lack proper tooling for developping Nix expressions.

1 Like