NixOS is the best linux back-end ever designed. But it can't become mainstream without a front-end

It was just a suggestion, if the OP wants different results. If the OP likes these results, feel free to ignore.


Ignoring the debate about ‘moms’ being a target audience, I do think there is merit trying to simplify some aspects of the configuration process and a good UX seems a good idea as part of this. Why?

The ability to quickly set up a complex system in a simple way is actually useful. I imagine the approach could be used for “appliances” - how about a nix template for a NAS with an easy to use GUI to tweak some of the parameters (similar to TrueNAS for example), or a router.

I sometime find getting the Nix right for what I want to achieve can be complex - in those cases I veer towards something like Mint or Fedora as a stop-gap. A template and easy tweaks would be a much better stop gap that I could move on as I need to modifying the config directly.

And finally, there is room for both approaches…


I have made a poll on a different thread to continue the discussion on who the community considers the target audience should be, Poll: Who do you think are the target audience for nixos?

Also found these past discussions NixOS for non-technical folks and User-friendly NixOS distro?

1 Like

If a distro does not have a visual installer, nobody suggests to make another distro that’s the same thing but has a visual installer. How is it a good idea to create a separate distro because nixos does not have a gui config? It should be just an opt-in package that should become built-in over time if it gets enough traction.


I was thinking a lot about how I’d go about implementing a tool like that.

First of all, a tool like this needs to be aimed at non-technical audience, so it should be as trivial to use as possible. Even really dumb things like you should not expect the user to be able to bootstrap the tool using configuration.nix or the command line. The tool itself should be either built-in or be a flatpack that anybody can use.

Second, I’d personally prefer to use C++ or rust for writing the tool, because these are my languages of choice, but it’s actually easier for me to learn JavaScript than it is for a hundred potential contributors to learn C++ or rust. It should be as easy to maintain the tool as possible. JavaScript is a terrible language in many ways, but it’s also the most popular one, and there’s a very good reason why vscode uses JavaScript and not C++ or rust.

The way GitHub - snowfallorg/nixos-conf-editor: A libadwaita/gtk4 app for editing NixOS configurations works is by generating a file that is included into configuration.nix. Naturally, that’s the easiest way to implement it. But I think it’s the wrong approach. VS Code settings menu does not produce a generated file that’s included into the settings. It alters the settings file itself. It’s harder to implement, but it really helps to keep the configuration file clean: it maintains all of the comments, it maintains as much formatting as it can, etc etc. All of that’s important. It needs to help the user manage their configuration.nix, rather than bypassing it.

The tool should be designed with UX in mind first. Get a good existing user-facing config dialog (atom/vscode/photoshop/discord) and copy its design. There’s literally nothing in the nix ecosystem currently that’s designed well enough from UX perspective that could be used as a guideline. I know it sounds crazy, but it needs to look good.

1 Like

I agree, having configuration-as-code is clearly better than having configuration-as-state. But even having configuration-as-state coupled with the rest of NixOS ecosystem is infinitely better than what 95% of existing PC users currently have (system-as-state). It does not need to be perfect, it just needs to be better than everything else that exists. And NixOS is one step away from that.


I believe if done carefully and with limited scope (like just modifying the list of installed applications), the auto generated code can be kept free of the unreadable stench it often has in other places. The already mentioned VSCode setttings.json GUI is a good example of that imho.

Also even if the config where unreadable, it would still be a huge benifit of having it all in a single centralized place that one could easily reuse to reinstall the OS like NixOS offers.

VSCode manages plain JSON files. They do a bit of cleverness since they don’t tend to completely re-order entries in the JSON but overall it’s manageable. With Nix configs, you can have functions, aliases, configuration entries can come from multiple places (which are then merged together), and split up into many (sometimes re-used) sub-modules to a point where apparently not even Nix itself can tell you the location from where a certain configuration value was set (or chooses to not tell you). So while I would applaud your tool just for solving this issue, telling me where in my configuration a certain option value was set, I have my doubts that this is going to be an easy exercise.

Firewall config might be a good example. The list of allowed ports is often set in various modules (sometimes as a consequence of another configuration) which are then merged into the final list. How would one edit this list? And that is far from an advanced use-case.

So I see three things that can happen:

  1. There is going to be a cutoff point of configuration complexity that this tool can handle. Then it’s going to be like all these flake frameworks. They will work until you hit their limits and then you need to either settle with the limitations or have to re-learn the more generic way. Also, this will exclude a lot of people whose configuration is already beyond that complexity.

  2. The tool settles into managing just parts of the configuration and excludes others, but is still well workable. Then it might still be useful even in the context of more complex configurations.

  3. You do the impossible and create something truly generic, there will be a lot of applause. Personally, I have my doubts because that would be, IMHO, relatively similar to all these tools that are supposed to make programming simple and accessible for everyone and IMHO they all either fell short of being truly universal or got so complex that actually learning the language would have been not much more difficult.

Also generally, if you want to lead those efforts, I’m sure no one is going to be opposed. It also happened with the graphical installer. Someone made it, and now it’s there. Though I have to admit that your initial post sounded like “someone (not me) should do this GUI that makes Nix super easy, thanks for coming to my TED talk” which might have triggered some of the less excited reactions that you got. People don’t like being told that they spend their free time wrong.


Apologies for only have skimmed this thread - partly due to crummy reading comprehension these days, also partly because it’s got a little heated. Just going to chuck out some random thoughts:

I’m pretty technical, been using Linux since the mid 90s, etc, but also have only ever really programmed imperatively, and these days have to deal with enough physical / mental / cognitive issues that learning new stuff is quite hard. I also support Linux laptops for a couple of elderly relatives.

Now, I don’t expect those relatives to manage their machines at all, just use them. Over the years their installs, managed by me, have slowly “crufted up”, as is the nature of non-declarative deployments. I’d love something that made it easier for me to admin their machines - and while Nix initially seemed like overly complex overkill, I’m definitely coming around to the idea. (I’ve been trying Silverblue etc., but stepping away from their default configs gets surprisingly complex quite quickly too.)

I’ve been a little surprised not to “bump into” something like devbox but for managing host configurations. I fully expect that I will eventually need / want to become more proficient with nix (and flakes), but in the meantime something I could use to generate the basics of a config with less plumbing / boilerplate would be great. (I know there are lots of flake helper libs etc out there, but that still feels a little low-level.)

I would agree that a “gui” that just presents the underlying syntax in a different way isn’t really much use - after 30 years I’m not scared of vim, after all. I also freely concede that there will come a point where you outgrow higher-level tooling, but if there was a capability to override or include raw nix code in the generated output, that would probably provide a gentler pathway to actually learning nix properly.

I hope that makes sense!


For sure. My mom needs none of that. Not sure about yours.

Obviously I’m being facetious, but only a little bit: the parser does indeed have to parse at least some of the basic things that even non-advanced users routinely deal with. Things such as this:

 hardware.bluetooth.enable = true;
 hardware.bluetooth.powerOnBoot = true;


 hardware.bluetooth = {
   enable = true;
   powerOnBoot = true;

Just have to be supported at the same time and the parser has to be able to modify the user settings in both cases without changing the file structure. It’s not a trivial technical problem, but a solvable one. Ideally I was hoping there would be a nix language parser that could do some heavy-lifting to facilitate this. If not, the parser/patcher should be completely separated into its own middleware, if needed written in a different language from the GUI. It is indeed a completely orthogonal problem from making the UX part good. VS Code did it for JSON, it’s obviously harder for nix but still possible for most basic usecases.

People that have already configured their system to any degree, don’t need a GUI to do that. The whole purpose of the tool is to help people who don’t know (or don’t care) how to do that with code.

Alright then, good luck with your project.


So the latter description is actually how it currently works, it works by modifying an existing configuration.nix for better or for worse.

GitHub - snowfallorg/nix-editor: A simple rust program to edit NixOS configuration files with just a command Far from perfect and in desperate need of a refactor, but works for the case described.

But to give my two cents on the discussion I’ve been trying to work around and with Nix’s complexity on SnowflakeOS and I think simplifying Nix/NixOS to cater to new users at any cost to its current complexity is bad. That being said, I think that having tools that simplify the experience while not impacting current NixOS features are great. I don’t think NixOS itself should degrade any of its experience to cater to new users, a simplification/GUI, an abstraction on top of an abstraction, will always be limiting and in NixOS’ case I don’t want to impose a “correction” opinion on what a configuration should look like.

I call SnowflakeOS a separate “OS” for ease of understanding, but in reality it’s just an opinionated NixOS configuration. My plan is to add all of its individual tools from SnowflakeOS back to nixpkgs so that anyone using NixOS has the choice to use them. However I don’t think enabling them by default with an opinionated config such as SnowflakeOS’ is a good idea.


I think there’s a pretty comfortable middle-ground between highly-technical and “for Moms” that I think Nix has yet to expand into. There’s a large demographic of what I would call “casual developers”: People who are comfortable with the command-line and code editors, but are still mostly unaware of the inner-workings of the tools they use.

I’m thinking of command-line tools that, while still limited to the terminal, offer a highly polished and simplified UX. Packagers/Builders like Cargo and Npm, or static site generators like Hugo offer a CLI with a small-ish set of subcommands for high level operations (cargo build, npm init, hugo new, hugo server…). They also prioritize user-friendliness in their output, with colored text and progress bars, and other widgets.

Imagine something like:

$ nix new --template nixos my_config/
$ cd my_config/
# Edits some files
$ nix build
$ nix deploy

Obviously this is a lot like what’s been going on with the experimental nix command, and it definitely has the outward appearance of a user-friendly CLI. But in practice, it comes with all the baggage that Flakes bring, and still isn’t that intuitive to use. nix shell and nix develop for example, seem to do basically the same thing but are different in some unclesr, but probably important way. And I always feel overwhelmed when I run nix flake --help and the first thing it tells me is 20 different ways to specify the URI of a Flake.

I guess what I’m just saying is that a real/official polished and user-friendly CLI is an important first step to take before GUIs enter the picture. And that step alone could make a huge difference in getting people interested in, using, and getting involved with Nix.


You might be onto something… Actually we already have flake templates, so the example you gave might already be almost attainable if we would have “preset templates” that are somewhat opinionated and accessible by a simple keyword like nixos, devshell-python, etc…

At least for flakes it’s the boiler plate that is hard to remember and constitutes unnecessary effort every time


I think that’s a very important part of the puzzle. There’s some functionality that I don’t see in its interface, but it has almost everything that a nix GUI manager would need to interact with the config.

We’re talking about a tool to help new users, how on earth can it affect existing ones or degrade their experience?

That was poorly worded. I mean in the sense of having something enabled/installed by default promoting one opinionated configuration format. But I’m always excited to see and work on more tools that help new users!


I’m thinking of reusing as much of your code as possible and probably nix-editor is a really good clear cut of what can be re-used vs what I think has to be implemented in a different way (the UI part as well as its distribution model). I really want the tool to be as accessible to designers as possible to enable skilled web designers and artists to contribute, without requiring them to have C++/rust knowledge. It’s just much easier to find a UX designer/collaborator capable of javascript/CSS.

Btw none of what’s being discussed here would have been possible without the installer. No point in trying to make an OS accessible if it doesn’t even have an accessible installer. Now that we do have an installer, making NixOS accessible is one step away.

I myself tried a long time ago to make a UI for looking at the content of the configuration. Making a User Interface for NixOS is challenging, because NixOS has a lot of knobs that could be tuned to express anything. I agree that whatever UI is chosen, having a curated list of settings is a good way forward, but it would have to be bi-directional.

The module system is great because it offers the ability to be modular and to build abstractions.

The simplest tool you can make to manage a NixOS configuration should not attempt to manipulate Nix code, but it should look into managing the imports list only, which could be delimited using some tags and used to enumerate one file path per line:

  imports = [
    ### MANAGED LIST END ###
1 Like

The point is not to implement it in the simplest way possible, the point is to implement it in a way that can eventually teach the user how to edit configuration.nix manually. If you start including parser tags into the config, it will make it harder for the user to read. No, the burden of dealing with the complexities of nix syntax in this case should be on the developer of the tool, it needs to write it the way a user is expected to write it, and it also should be able to catch basic changes that the user makes too.

Fortunately, @vlinkz realized this a long time ago and has already done most of the heavy lifting with his middleware that does most of it exactly the way it should be done for this purpose: GitHub - snowfallorg/nix-editor: A simple rust program to edit NixOS configuration files with just a command . It’s sufficient for the UI to just use CLI to interact with it.

@nbp wrote: „I agree that whatever UI is chosen, having a curated list of settings is a good way forward, but it would have to be bi-directional.“

I am interested in this curated list of settings. These are are exactly the things that some other groups need („I just use Linux instead of Windows as my operating system, I can edit text files, but I cannot develop programs“) : Documentation in Wiki and NixOS Manual.

Some parts of the documentation is missing: What parts? (or: How do we create this curated list of settings to change configuration and programs to install?)

Just email-client, webbrowser, PDF tool, office document editing and printing?