Everyone in this thread is “enjoying the benefits of the status quo”, it’s just that some people feel entitled to tell others to make it more enjoyable for them.
I am thinking about this too.
NixOS can be a good system for “moms” (but only with tech support - they cant destroy anything and the used programs are mostly the same over the years ). But I think we should be especially open for other groups:
-
Linux gamers. NixOS can be very good for this (but it strongly depends on documentation for Steam, Lutris, HeroicLauncher, steam-run, …)
-
Just office users who most likely would not install new things and never change any dotfiles
-
System administrators who install the systems for a group of office users
-
Linux enthusiasts, who dont code
For all these groups „the code is the documentation“ is not the best approach.
My approach is: Mfake the documentation better.
The manual as of now is a bit too technical and the choice of topics is not good for the groups I mentioned above. Thats why I focus on wiki.nixos.org - and to make it better for people without that much technical knowledge.
In my personal experience: You dont need to understand nix to use NixOS as daily driver (when you belong to one of the groups). You do not need to and you should not use flakes and homemanager.
If you cut these parts of the nix ecosystem its way more approachable. Adding packages in configuration.nix, some configuration, channel updates and rebuilds and garbage collection is probably all you need.
Enhancing the wiki and making it better for the people who dont code is as step in the direction of OP ideas.
This is gonna be my last post in this thread since it’s a rabbit hole into something that’s off topic.
Firstly, having an app or a nixos module or whatever would, by nature, be opt-in, not opt-out. I don’t see how this would change the status quo for seasoned NixOS users. Bettering the experience for some others isn’t ruining it in the slightest for the rest of us in this case.
Secondly, there will be resistance in the former, and rightfully so. But that doesn’t necessarily make the ones calling for change wrong. Everyone has the right to speak up if they feel something is missing to them. Everyone else also has the right to have a different opinion.
This was uncalled for. As I said, doing the former isn’t wrong either (irrespective of which of the two choices is chosen)
Everyone in this thread is discussing the options we have and how we can better those options or create new ones. No one has forced anyone else to do something that they don’t want to.
And why do you think it’s okay to throw shade on others, call them entitled, make personal comments on what their moms use or are “forced” to use on someone trying to have a constructive discussion on whether the topic of this thread is a good idea or not.
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?
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.
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.
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.
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!
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.
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.
For sure. My mom needs none of that. Not sure about yours.
Alright then, good luck with your project.
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.
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
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.
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?
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!
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.