I’ve been thinking for a long time on how to make NixOS (not necessarily Nix) more accessible to users that just don’t have the time to learn a whole new paradigm and programming language. I’m going to dump a few thoughts here on how my version of this utility would work, and hopefully get some feedbak from both experienced and novel users. Specifically, I’m looking to do the least amount of work possible: if anyone can point me to other projects I may take anything from code to inspiration from, I’d be most thankful.
Why would such a tool be needed? Well, in my case, I would use it behind a VPN to access my installs remotely, for tasks that do not necessarily warrant, or are slower on, an ssh connection. Simply adding a package to systemPackages, or adding an SSH key, for example, would involve a few taps and a paste from a phone, while ssh’ing would be much more annoying. Potentially, it could serve as an installer. I could also more easily sell the idea of an operating system that involves mandatory configuration management to other potential users when I can say “think Windows’ Control Panel, but consistent”, or “Plasma’s System Settings, but for the whole system”. Or even “it has a graphical Ansible/Chef/Salt/Puppet/Whatever”
From this point on, I’m both requesting feedback and taking notes for myself.
If I get it my way, this would aid with discoverability of new options, specially on -unstable. It should be able to replace both nixos.org/nixos/packages.html and nixos.org/nixos/options.html , but locally, and optionally have links to the local manual build.
It would be a configuration and management tool. It would manage packages only by accident, because environment.systemPackages is an array which can be filled up. Fedora’s Cockpit and Ubuntu’s Juju would be closer to it than Discover or Gnome Software.
I think the ideal architecture for this would be a daemon and a client. Since I would only target NixOS, systemd is a given, therefore the daemon can be socket-activated and not take any resources when unused. This daemon would serve an API, and probably a web client.
I’m not married to any particular language for any of those things, BUT:
- I’m not interested on building a parser. A quick search gives me a parser in C++, another one in Haskell, one in Go and two more in Rust. Even if I only have (not that much) experience with Rust, and a single close person with C++ experience, I’m inclined to use Go, just because it’s the only one that expresses benchmarks in its README, but ideally I’d try every one of them and see for myself. Hoping for some input here. I’m most interested on this part being fast.
- The API would make it easier for the web client to interact safely with configuration.nix. Additionally, it allows for someone that prefers a native configuration tool using, say, Qt, could build one without having to worry about the backend. Also, in the future, I would like for a single client to be able to manage multiple NixOS systems. Design wise, I’m partial to the JSONAPI standard, which would make using C++ the most complicated (since I can’t see a C++ server implementation of JSONAPI in their site) but as with everything else, I’m hoping for suggestions.
I’d like to, at some point, give it buttons to run nixos-rebuild switch/boot, nix-channel --update, nix-collect garbage even. Integration with howoldis.herokuapp.com and/or channels.nix.gsc.io/graph.html. A hypothetical “installer” mode could ask for a mountpoint and use nix-generate-config. Maybe Netdata for graphs at some point? In my dream world this dashboard would replace my NewTab/Homepage in my browser.
What do you people think? I expect input from basically anyone: Developers, please input on the technology I’m planning to use, and feel free to run with the idea and start the project (I’m not going to be quick at this). Users, tell me what you would expect of such a tool: I’d like to think I’m open to ideas.