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.
@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?
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.
I think they will be most successful in implementing it with tvix-serde serde - depot - Sourcegraph 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.
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.
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:
It would be nice if there was a simple way to set up tech support coalitions for small groups of people alongside a standard GUI for contacting them. For instance, two or three siblings or cousins might agree to take on-call shifts for the rest of the family’s systems, and the family members could click an icon on their desktops to text or call whoever’s on shift. Such a tech-support ring could be configured during installation.
A good tech support tool would honestly be helpful for any Linux distribution, but NixOS enables a more straightforward workflow in that instead of having to start with the usual screenshare tech support call and figure out where all the appropriate settings are, the caller’s client can immediately send the support person their system’s currently applied NixOS configuration (as it exists in the Nix store) to get context for the call. (This would also naturally encourage users to put as much configuration into the Nix files as possible)
A support tool working with NixOS could either let the support person apply new configurations remotely, or show a (user-friendly) diff to the user and ask for their approval.
Such a support tool should also be available as a configurable live disk, so that a call is still possible if the system won’t boot. Bonus points if we can initiate a full-featured call from an iOS or Android device somehow.
Businesses, especially smaller ones, would definitely use a tool like this to manage fleets of machines, so that could definitely be a source of income.
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!