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?
![](https://discourse.nixos.org/user_avatar/discourse.nixos.org/phanirithvij/40/13057_2.png)
I didnāt think before posting about nix-gui and I apologize for it.
What about SnowflakeOS? I think it is going in the direction you want @Raikiri.
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.
![](https://discourse.nixos.org/user_avatar/discourse.nixos.org/rnhmjoj/40/1792_2.png)
I think that when you mix handwritten and autogenerated code your āconfiguration as codeā starts to revert back to āconfiguration as stateā, at least in the long run.
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.
![](https://discourse.nixos.org/user_avatar/discourse.nixos.org/rnhmjoj/40/1792_2.png)
I think that when you mix handwritten and autogenerated code your āconfiguration as codeā starts to revert back to āconfiguration as stateā, at least in the long run.
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.
![](https://discourse.nixos.org/user_avatar/discourse.nixos.org/raikiri/40/6271_2.png)
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.
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:
-
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.
-
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.
-
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!
![](https://discourse.nixos.org/user_avatar/discourse.nixos.org/polygon/40/4139_2.png)
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)
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;
vs
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.
![](https://discourse.nixos.org/user_avatar/discourse.nixos.org/polygon/40/4139_2.png)
Also, this will exclude a lot of people whose configuration is already beyond that complexity.
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.
![](https://discourse.nixos.org/user_avatar/discourse.nixos.org/raikiri/40/6271_2.png)
For sure. My mom needs none of that. Not sure about yours.
Alright then, good luck with your project.
![](https://discourse.nixos.org/user_avatar/discourse.nixos.org/raikiri/40/6271_2.png)
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.
So the latter description is actually how it currently works, it works by modifying an existing configuration.nix
for better or for worse.
![](https://discourse.nixos.org/user_avatar/discourse.nixos.org/raikiri/40/6271_2.png)
Itās not a trivial technical problem, but a solvable one.
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
![](https://discourse.nixos.org/user_avatar/discourse.nixos.org/vlinkz/40/5578_2.png)
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.
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.
![](https://discourse.nixos.org/user_avatar/discourse.nixos.org/vlinkz/40/5578_2.png)
I donāt think NixOS itself should degrade any of its experience to cater to new users, a simplification/GUI
Weāre talking about a tool to help new users, how on earth can it affect existing ones or degrade their experience?
![](https://discourse.nixos.org/user_avatar/discourse.nixos.org/raikiri/40/6271_2.png)
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!
![](https://discourse.nixos.org/user_avatar/discourse.nixos.org/vlinkz/40/5578_2.png)
So the latter description is actually how it currently works, it works by modifying an existing
configuration.nix
for better or for worse.
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 START ###
./profile/default-mum-computer.nix
./profile/any-scanner.nix
./profile/any-printer.nix
./user/name.nix
./user/email.nix
./user/timezone.nix
### MANAGED LIST END ###
];
}
![](https://discourse.nixos.org/user_avatar/discourse.nixos.org/nbp/40/545_2.png)
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
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?