The curation of the settings to expose to the end-user depends on what is your objective.
For example the Simple NixOS Mailserver project curates the list of settings under the mailserver top-level attribute, which is used to configure a pre-selected set of programs to achieve one objective.
So, what do you want to achieve? Can you make default choices or aggregate choices on behalf of your users?
I think if you use Nix the way it is currently being used, you get a lot more out of it, than if you were only able to flick a few booleans in a gui. Though there are already plenty of attempts, and plenty of people that agree with you. But like Nix on Windows, it needs people to implement it, because it wonât exist until there is a driving force of developers making it happen.
There is one person I know who is interested in exploring and implementing Nix as a visual language, their name is Nova, the developer of Stardust XR · GitHub. You can find them on Twitter/ActivityPub talking about their views on the topic of programming interfaces (Declarative, Imperative, Visual). Though primarily they need funding to make anything happen, they have a very underfunded opencollective here Stardust XR - Open Collective.
I think they will be most successful in implementing it with tvix-serde serde « tvix - depot - monorepo for the virus lounge which describes itself as
//tvix/serde- a Rust library for using the Nix language for app configuration (from https://tvix.dev/)
Nova once said to me about Nix. âas long as the datastructures for everything are type-enforced then turning them into visual programming should be really easyâ. I tend to agree, and thatâs likely possible with serde and nixosModules.
@camtauxe thanks for saying what I tried to say, but much more clearly!
this discussion of nix GUIs reminds me of the recently posted converter to json schema, which seems to similarly promise being able to use available info to create graphical interfaces.
as a dev i might be more inclined to opt for nixdâs LSP, but iâd be curious how the JSON schema vs serde approaches mentioned by @matthewcroughan would differ in terms of type-constraining the options to narrow down what UI makes sense.
Except thatâs exactly what Linux distributions are supposed to be. Manjaro vs Arch, Ubuntu vs Debian. Itâs extremely common in distro land to have a derivative distribution that modifies the upstream/original with different goals/priorities/values (such as making the distro more accessible to new users).
Any project has core values that more or less decide how that project evolves. From the very start, the paradigm of configuration-as-code was one of the core principles of nix. Itâs one of the main selling points of nix (alongside immutability, reproducibility, purity, etc) and itâs one of the reasons why nix âtook offâ.
While simplicity and user-friendliness arenât exactly incompatible with configuration-as-code, they are at the very least in conflict with it. You can focus on simplicity/user-friendliness, or you can choose flexibility/configurability/extensibility. Trying to do both at the same time is possible, but the end result would have worse user-friendliness and worse flexibility. We should be honest with ourselves that there are trade-offs between these core values.
âMaking NixOS easier to use for momsâ at the very least makes NixOS worse for everyone else, simply by taking away resources that could have been spent on solving issues that arenât related to âmomsâ. The question isnât âshould we strive to make NixOS easier to useâ (the answer to that question is obvious), the real questions are âhow can we improve the ease of use of NixOS the most, with the least amount of effortâ and after we identified such a valid improvement direction - âwho is gonna do itâ.
Asking âthe nixos community to do Xâ or saying that âwe should do Yâ is unlikely to result in anything productive being done, unless you are prepared to really prove that your idea is worth the effort. And that âproveâ here might mean âcreate a proof-of-concept yourself and gather a team of like-minded people, willing to spend their free time to work on your ideaâ, not just convincing a few people on the forums that âyes, it would be pretty cool if you could configure NixOS from a GUIâ.
Most of the counter-arguments in this thread arenât saying it explicitly, but you should understand that when somebody says something like âNixOS isnât for momsâ what they really mean is something along the lines of âthe thing you are suggesting would benefit some users of NixOS, but the proportion of such users (and the degree of improvement brought about by these changes) is relatively small compared to the effort that would be required to implement what you are proposingâ.
IMHO, there is nothing intrinsically poisonous about this position, even if it might be discouraging to hear.
This is an understandable position, but unfortunately, itâs wrong.
Where thereâs usability, thereâs users. Where thereâs users, thereâs money. Where thereâs money, thereâs actual resources to implement whatever else the ecosystem needs. Imagine a world where SteamOS 3.0 was released based on NixOS and not on arch. A world where every steam deck sold was running NixOS. Nix then would have had 100x the number of users it has today (assuming thereâs 2m steam decks sold and 20k NixOS users (ballpark from the survey)). A lot of nix veterans probably think âwe already have more than enough noobs hereâ and theyâd be completely wrong, because where thereâs noobs, thereâs money.
While I generally agree with this assessment (although Iâd phrase it differently), the current ability of the community as âa bunch of peopleâ or the NixOS Foundation as an âorganisational frameworkâ to capture that economic potential and convert it into upstream improvements is very limited, especially relative to the money thatâs certainly available somewhere out there.
Even if the NixOS Foundation does absolutely nothing, having 10x-100x more users would at the very least result in a significantly increased number of contributors. People want to contribute to things that others use. âMoneyâ is a just a reductionism for âresourcesâ in general.
Money for whom? Money when?
My comment is an observation about the current dynamics of open source software development (which nixpkgs/NixOS definitely is). I am not saying that thatâs how things should be, I am saying that thatâs how they are now. Nobody is going to spend their free time developing a âNixOS GUI for momsâ just because 10 years down the line a multi-million mega-corp might use it for smart fridges or something and make a lot of money from that.
This is highly debatable.
I sincerely doubt that simply adding a GUI frontend to NixOS would increase the number of users tenfold (not to mention 100x).
Even if it does, the subset of users that prefer GUI configuration utilities to writing nix code is much less likely to be willing to contribute nix code.
There will certainly be an increase in the number of contributors, but it would be relatively small, compared to the effort spent. Furthermore, more users isnât always better for the ecosystem (for examples, see ecology, urban planning, etc).
All this ties back neatly into my original point - if your goal is increasing the number of contributors, adding a GUI front-end to NixOS is not a very good idea. At least not as part of the official NixOS project, it might be more viable as a separate derivative distribution with its own monetization model, support platform, etc.
And, donât forget, it takes effort to accept contributions in an orderly fashion, so a higher number of contributors also comes at a cost. It depends on the kind and size of the contribution, but itâs always nonzero.
I think itâs worth noting that âI want to be able to recommend NixOS to my non-technical momâ does not directly imply âI want my mom to be able to configure her NixOS installation herselfâ. Thereâs usually an intermediate, which is âI donât want to/canât be stuck being my momâs 24/7 tech supportâ, and there are ways we can improve that pain point without resorting to becoming your momâs 0/0 tech support.
A few not-necessarily related thoughts on how to do that:
I think this sums it up. Thanks for writing down a summary here. I fully agree with what youâve said.
That actually brings another concern, if, say, the community increases 10x thanks to some GUI, now NixOS is basically defined by that GUI. As mentioned before, itâll forever be non-exhaustive and lack flexibility. So, NixOS might just take on a bad reputation from those new users relying fully on the GUI and then failing when they do anything complicated.
Besides, NixOS already lacks a lot in terms of documentation which makes debugging harder; I cannot imagine adding a GUI on top which has even lesser docs with even more failures.
I think the whole âmomâ reference was to refer to non-technical users rather than imagining an actual family setting. Even otherwise, I donât think itâs worth considering facilitating a ring for a symbiotic family. Sorry if I understood you incorrectly.
Again, not really necessary. In my case Iâve just set up SSH via Tailscale which allows me to remotely edit the config of and rebuild a system. Anything more is a waste of effort IMO.
That does work great, as long as youâre available to initiate the support. The point of a tech support GUI program would be to allow a non-technical user to initiate a call and ask for help, automatically reaching out to whoever is available (i.e. if Bob is available, call him immediately, instead of calling you first and you having to tell them âno, I canât help you right nowâ) and doing any necessary boilerplate work. Thereâs also the fact that VPN-ing yourself to your tech support person is not always possible or desirable.
Yeah, I get that. Even though the family setting is where this situation (at least stereotypically) crops up a lot, I should honestly have emphasized the non-family setting where youâre recommending NixOS to a friend or coworker - if your elevator pitch includes âand if anything goes wrong, you can click this button and get on the phone with either me, Bob, or Charlie, and we can help get things up to speedâ, then people will be a lot more willing to either try it out or stick with it. (You could probably think of it like a multi-level marketing company, except the product is free.)
Yeah, thatâs fair. Again, this makes more sense for the non-family or extended family situation - a tightly-knit family can probably get away with calling each other physically or using a family group chat, but as distance increases, a remote tech support experience becomes more relevant.
Besides, NixOS already lacks a lot in terms of documentation which makes debugging harder; I cannot imagine adding a GUI on top which has even lesser docs with even more failures.
Itâs already happening with the graphical installer: I have tried to help three users that couldnât get full-disk encryption working and they couldnât explain what they were doing besides âI donât know, I ticked the encryption boxâ. Now I have to go through the installation or read the source code to figure out what itâs trying to do, before all I had to do was âshow me your configâ.
Eh, I see what you mean but I believe that the room for optimisation here is extremely small and the number of people whoâd use this is little too; since people would tend to go to routes they already know and love: DM or group DM people whoâre able to help on a known chat platform.
Before moving places, I just told my friend that Iâm always available on Discord if he needs help configuring or debugging something. I donât think a dedicated app for this is feasible.
Though, those are just my opinions. I could be wrong.
Iâm seeing a juxtaposition of GUIs as detracting from what we would otherwise focus on, but if this would benefit most from ways to constrain the options such as using a type system.
that would simultaneously benefit error messaging, documentation and language server checks and completion, so i feel like this was a direction we had intended to explore already anyway.
Something weâve been working on: Thymis is a WIP device-management project that manages and deploys NixOS device configurations and system images.
Architecture-wise, the Thymis-Controller is a Python-Server+SvelteKit-Frontend that allow you to edit a NixOS-Deployment state using a web interface.
The controller manages a fully valid repository that contains the NixOS configuration of the devices.
The system images are built and deployed to the devices by the controller.
Application and Configuration modules (not straight up NixOS modules) can be defined externally and integrated into the project.
So we manage to establish a split between the developer side (Module development) and the user side (Configuration of Modules and Deployment of System Images).
The user does not need to write Nix code, but can still benefit from all the advantages of NixOS in the deployment.
A good fit for Thymis would be the management of a Raspberry Pi device for Home-Automation, or a fleet of devices.
Right now, the project is in a very early stage, but weâre working on it.
Weâre looking for feedback and contributors, so if youâre interested, please check it out and let us know what you think!
OOOH. This looks interesting! Would it be reasonable to characterize it as similar to Balena, but using nix in place of docker?
Yes! It can be used for many of the purposes that Balena covers. The project includes the web-ui management in the open source part, compared to OpenBalena though, and of course we use nix.
