Speaking my language. Not binary and @qyliss’s project is called “Spectrum”. You have no idea how perfect this is @domenkozar.
3 Likes
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 
.
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 https://discourse.nixos.org/t/proposal-for-improving-nix-error-messages/, which is fantastic!
3 Likes
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
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:
-
nixos.org 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 https://status.nixos.org/ 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, nixbuild.net, 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 
(Edit: was not meant to be an answer to domenkozar’s post. But Discourse is flat anyway)
4 Likes
The
nixlanguage 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.
3 Likes
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:
2 Likes
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!
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 GitHub - LnL7/nix-darwin: nix modules for darwin 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.
2 Likes
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.
4 Likes
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:
- Discoverability and installation of software (add/remove/search packages from config graphically)
- Config backup and recovery (easy backup/restore to nixos.org, github, etc)
- Discoverability of configuration options (see what options are defined for packages/modules you’re using and set/unset them)
- Discoverability and setup of most common use cases (list and include modules for things like “kde desktop”, “steam gaming”, “lamp server”, “android development”, etc)
- 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)
- Management of generations, garbage collect, delete old (UI list of generations, diff of config between them, buttons to switch/delete)
- 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
@garbas I have some time to spend, so I sent a mail to webmaster@nixos.org
Anyway, I thought I’d post the answers to the latter questions here, too.
What is your idea what marketing team will work on, this year? Next year? Next 5 years?
We should start thinking about a rough marketing strategy mostly to be clear on what our goals are. If this is not clearly communicated, I’d be wary of subjective nit-picking in the community around what should and should not be done.
Sure, we want to make Nix more mainstream, but what exactly does that look like, if we are successful? More NixOS users? More Nix code on GitHub? More success stories about Nix adoption in organizations?
Identify a target audience that fits with the marketing strategy, e.g.
- DevOps engineers or site reliability engineers
- System administrators
- Software developers (maybe segregated by tech stack)
As we have a lot of experience in the field ourselves, we can make some assumptions around what the relevant pains and gains of our target audience are to begin with.
However, ideally this should be followed up with user research. For example, we can review research papers as far as available, create online polls or conduct interviews with people from the target audience to validate or falsify these assumptions (outside NixOS community).
In any case, when we identify the issues that Nix can solve, we know what to advertise. This can mean explaining in simple terms that Nix can solve a problem and demonstrate how Nix does this. This should be done on the website, of course, but also by strategically placing conference talks outside the Nix community. There are certainly a lot more avenues for public outreach to explore.
In addition we will likely learn about issues that Nix cannot solve well enough yet. If additional features, documentation, tooling, packages, etc. would help Nix solve these issues, we can then communicate this to the Nix community to consider prioritising their development.
While addressing issues, changing our advertising, we can continuously conduct user research to monitor how Nix is perceived by our target audience.
This would be an on-going process, but I think it is realistic to get quite far already during this year 2020.
Next year we could start to widen the target audience and address a different set of needs. Just to give an example, we may focus on making Nix a great choice for local development environments and building containers now, and continue to widen the scope to managing complex infrastructure entirely with Nix-based tooling.
With the website hopefully in much better shape we can focus our efforts next year more on driving a part of the development efforts on Nix, NixOS and nixpkgs into a direction that is aligned with the marketing strategy.
Five years is far away. But I hope that Nix will be mainstream by then. The marketing team continuously monitors the needs of Nix users, derives suggestions for features and tools for the development from insights gained and actively reaches out to more target audiences to explain them how Nix will solve many of their infrastructure issues.
What could be few easy fixes to the website that would solve problems that you heard others complain about Nix/NixOS?
Without actual research, this will naturally be a little subjective. Generally, I believe https://nixos.org should cater much more to newcomers. Here are a few things that I believe are easy to fix.
Quickstart
Right now, you have to dig a little to find out how to get started with Nix.
There should be a very smooth path for people to get into their first simple nix-shell as soon as possible. This can be done with a few shell commands. Then they could already be writing their first shell.nix to keep that shell around. This is all very easy to do on most Linux distros, but the website does not highlight this. It should be the obvious thing to try first, when you are a new visitor to the website.
My hypothesis here is that, if we can show a potential new user in a few minutes how Nix can help them manage environments, this goes a long way in creating interest and make them stick around for more.
Clean up frontpage
There is too much irrelevant info on the frontpage
- release history beyond the current release of Nix/NixOS
- blog posts are interesting much later, but should not be your first impression. I’d bet experienced users get this from discourse or reddit instead of the homepage.
Confusing navigation
The Home/Nix/NixOS/Nixpkgs split is confusing: focus the navigation around what the user wants to see or do. I would merge all the separate navigation systems into a single menu focussed around the use case. For example, nixpkgs and the package search address the same concern and should be grouped together.
This requires some iteration with user feedback, but the situation can certainly be improved.
Package search
The package search could show more relevant results, i.e. when I type in python or vim or emacs or redis, the respective packages should really show up first. This goes for nix search, too, by the way.
3 Likes
I agree with this market segmentation. I would think that software developers working with somewhat functional languages would be more receptive because they try to limit state wherever possible. I would think the Haskell, Clojure, Elm, OCamel type communities would be most interested (but I may be wrong). Funny enough, I also think the “ricing” communities would show some interest due to the ability to configure the entire system. Get a spot on Distrotube of Lukesmith’s youtube channel, lol!
I came to nix for a couple main selling points:
- Functional design with the ability to rollback
- Ability to have a pretty pure development environment
I am enjoying number 1 while still trying to figure our number 2. Do I use nix-shell or lorri? What about editor support, etc, etc. Needless to say I still don’t really know how to use nix-shell and I desperately want to learn. Documentation is painful. I wrote a beginners guide to installing Nixos with ZFS, but still haven’t posted it to a blog yet : GitHub - bhougland18/nixos_config: Nixos configuration
I can’t wait for the day there is a NixOS book that one can buy on Amazon.
I do like the package search (way better than Guix) but I think it would be better if users could contribute reviews, or report broken packages. Many people go to the Arch Wiki that don’t use Arch because it is valueable, just like many people look at reviews on Amazon before buying something at their local store. Nix has great packages, and some more obscure, but interesting, packages that you many not find on other distros. I think enhancing the search with crowd sourced knowledge might not be a bad idea.
Better documentation about what to expect on the package submission process
I don’t know what to do next in this package submission: windowchef: init at 0.5.0 by bhougland18 · Pull Request #84305 · NixOS/nixpkgs · GitHub
Am I good to go, or do I still need to do something?
2 Likes
Nix has a wonderful story for bringing in various random libraries or to try out applications and in a no-risk way. The biggest hurdle for this sort of ad-hoc and quick experimentation is ecosystems composed of packages and plugins. Using pythonPackages, haskellPackages, gstreamer plugins, qt “xcb” failure to load, etc can get aggravating even though I’ve packaged and worked with them for a few years.
The wiki and associated sections of the manual are helpful, but I’ve been to them many times and still get confused, I can image it’s far worse for someone who just wants to get something to “pip install” and make progress on a project. I’ve been putting together a pkgs-repo for AI/ml/data-science with all the the associated CUDA, python, tools, etc working. Having “blessed” ways to participate in these ecosystems helps because Nix is too powerful, there are so many ways to implement/package things that the “right” way can be elusive.
4 Likes
Absolutely. More related to the development method, but here a more kernel-like approach or splitting into flakes would help a lot I think. If the repo/topic is sufficiently popular and well-maintained I imagine it could be put on under the NixOS umbrella.
I think this is also the way forward for ML in Nixpkgs. It’s a topic a lot of Nixpkgs users work with, and it sees also a lot of activity in the repo, however, there is not as much cooperation as it needs. Example: Tensorflow. I don’t know why. Maybe it’s because these are difficult packages, or because Nixpkgs moves so fast they can’t keep up, maybe because they often can’t merge themselves and would prefer to be in control.
3 Likes