How would YOUR NixOS configuration tool look?

[Zurdo]

Greetings!

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.
• I mentioned a Web client. Obviously Javascript is basically required. I have some experience with EmberJS. If someone wants to see a project done with Ember to see how it can perform, look no further: AFAIK, Discourse uses Ember. Unless someone has a good reason, I’d rather go with it, plus Bootstrap for widgets.
• 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.

[xte]

Hy,
new NixOS user here, well… My personal preference for a nixos frontend
(that does not excite me much, text config are IMVHO the most simple and
effective way to configure a distro, IaC-way) I’d like the idea of an
Emacs integration that Guix have, i.e. a M-x package-list-packages
equivalent like “nix{,os}-packages”, perhaps coupled with Nix options
frontend, essentially a local version of
NixOS Search - Loading...
with the ability to install / upgrade / check installed / view deps
together with “nix{,os}-generations” and a local copy of
NixOS Search - Loading...
with eventually the ability to read relevant infos, change option values
for current system etc.

If designed with backend+UI it can be used both inside Emacs or with
a dedicated GUI, for that, seeing actual sorry state of UI toolkits,
my two cents are or go for classic toolkits like TTk/fltk or choose
a BASIC (CSS+html with the minimum js possible) webui with a local
server. Go, Chez/Guile Scheme, Python/Hylang or Haskell can be nice
language choice, in particular Python being already used by tons of
software and having few precoocked webUI local-GUI toolkits, for
instance Flexx, can be the simplest, Haskell seems to be really
widespread in Nix community so maybe another option, Go have a good
web-stuff support built-in so it’s another option, various scheme as
a personal preference.

Emacs part is actually another personal preference but not only that:
these days seems to regain popularity while traditional DEs/WMs seems to
decline with the “generic classic desktop”, some go for tiling WM, some
(like me) with EXWM, some rediscover ancient WM from fluxbox to sawfish
passing through Enlightenment. Only Emacs already have a built-in
package management (for itself) + Guix{,SD} and Arch package manager
frontends + various system utilities like proced (top-like equivalent)
few network configuration tools etc. Long story short Emacs already can
be a modern computing environment and NixOS users are AFAICT not
GNU/Linux newcomers but “seasoned enough” users so it’s likely not
interested in complex / for dummies apps tied to classic Gnome/Kde or
nor something like the ancient Webmin.

Also toward an “Emacs computing environment” having an Emacs interface
can means having homeManager inside of Emacs so our Emacs config may
contain also our Nix{,OS} config creating a sort of “portable personal
environment” that can be easily replicated elsewhere, document literate
programming style with org and shared etc.

Honestly I think that GNU/Linux as a generic desktop is a dead when
Ubuntu drop Unity 7 and essentially ditch desktop, so GNU/Linux desktop
future IMO is again a niche for tech-savvy users and geeks and in that
sense being the one (and already substantially the only) that can do
things like safe upgrades, replication, IaC built-in, home management
etc well… It’s appealing.

– Ingmar

[Zurdo]

@xte

[…] text config are IMVHO the most simple and
effective way to configure a distro […]

I agree with this enough to prefer it for myself, but I think a text file is not always the quickest, most comfortable or most accessible way to configure a full operating system.

@xte

I’d like the idea of an
Emacs integration that Guix have, i.e. a M-x package-list-packages
equivalent like “nix{,os}-packages”, perhaps coupled with Nix options
frontend, essentially a local version of
NixOS Search - Loading...
with the ability to install / upgrade / check installed / view deps
together with “nix{,os}-generations” and a local copy of
NixOS Search - Loading...
with eventually the ability to read relevant infos, change option values
for current system etc.

If designed with backend+UI it can be used both inside Emacs or with
a dedicated GUI […]

Interesting, I should try GUIX in general since I didn’t know they had builtin emacs integration. I want to learn emacs at some point, so this may be something I try? Surely not as a pre-1.0 priority, since more people use and understand web browsers than emacs :).

In any case, I intended to go the client-server way, so additional UIs could be written after the fact.

@xte

my two cents are or go for classic toolkits like TTk/fltk or choose
a BASIC (CSS+html with the minimum js possible) webui with a local
server. Go, Chez/Guile Scheme, Python/Hylang or Haskell can be nice
language choice, in particular Python being already used by tons of
software and having few precoocked webUI local-GUI toolkits, for
instance Flexx, can be the simplest, Haskell seems to be really
widespread in Nix community so maybe another option, Go have a good
web-stuff support built-in so it’s another option, various scheme as
a personal preference.

My language choice would be the ones that give me the least amount of work first, personal preference second. So, from the list of languages that have a Nix parser available, keep the ones that have a JSONAPI implementation, and from those, use the most practical. That leaves us with, AFAICT, Haskell, Rust and Go.

Unfortunately, even if, on principle, the idea of a JS-less site is attractive to us nerds, reality is that the experience is not the same. Things like client-side validation or live updates cannot be done, or are harder, without JS. I mentioned Discourse as a good example of a web-app that proves both the feasibility of Ember and the kind of responsitivity one could expect.

However, I think starting from a JS-reduced application and building up from there to guarantee graceful degradation is not only reasonable, but desirable. I have not tested Ember in such circumstances, so this is something else where I’d like additional feedback: Is there any particular framework that would make it easier to build a web-app in this spirit? I think I will check out what sircmpwn is doing with sr.ht, as a good example of something like this.

@xte

Long story short Emacs already can
be a modern computing environment and NixOS users are AFAICT not
GNU/Linux newcomers but “seasoned enough” users so it’s likely not
interested in complex / for dummies apps tied to classic Gnome/Kde or
nor something like the ancient Webmin.
[…]
Honestly I think that GNU/Linux as a generic desktop is a dead when
Ubuntu drop Unity 7 and essentially ditch desktop, so GNU/Linux desktop
future IMO is again a niche for tech-savvy users and geeks and in that
sense being the one (and already substantially the only) that can do
things like safe upgrades, replication, IaC built-in, home management
etc well… It’s appealing.

I think this is the issue we would be trying to solve. There is something to be said for widening our audience, since at some point the ideas we can come up with stagnate without additional outside input. If we stop having new people, we get used to what we have, and die off without innovation. Newcomers are good, even if sometimes we may feel the signal-to-noise ratio worsens, because they help us question what we’re doing.

[xte]

I agree with this enough to prefer it for myself, but I think a text
file is not always the quickest, most comfortable or most accessible
way to configure a full operating system.
These days quick means reproducible, newcomers certainly like the idea
of installing a single package via CLI but then they loose replication
ability and they end up in an “unknown” system state. That’s why in the
past concept like “immutable servers” and “infrastructure as code” came
out. Having a config like NixOS means being able to know and replicate
a system for any reason (debug, expansion, new hw, …) and even track
history etc. In the end “quick solutions” means “big work sooner or
later in the worst welcomed time”…

Interesting, I should try GUIX in general since I didn’t know they had
builtin emacs integration.
For my VERY small try it’s far less than mature, usable perhaps in HPC
environments but not as a generic desktop or server… For Emacs they
have guix.el, a small intro docs is here
Introduction (Emacs-Guix Reference Manual)

I want to learn emacs at some point, so this may be something I try?
Well, if you do not know already Emacs… Consider that is not an editor
but a modern implementation of ancient LispMachines or IOW an OS lacking
a kernel and a bootloader, the core is a elisp VM and the rest is built
on top of that, changeble at runtime, any code/variables/function, and
anything works via a text-centric UI. I’m write this response in Emacs,
in notmuch-message-mode, and in this message using org minor mode I can
execute code in any language supported by babel (a big list) having the
result printed in-buffer, passing data between different listings in
different language or simply execute local lisp code with C-x C-e…
Long story short, if you do not already know it you can start using it
and being productive in few months, but to write a major mode well. IMO
it demand at least an year of learning…

Unfortunately, even if, on principle, the idea of a JS-less site is
attractive to us nerds, reality is that the experience is not the
same. Things like client-side validation or live updates cannot be
done, or are harder, without JS. I mentioned Discourse as a good
example of a web-app that proves both the feasibility of Ember and the
kind of responsitivity one could expect.
Hum, but you are talking about a single/local system config, am I
right? In that case I imaging it can be something like a form-UI
with a “spirit” similar to Rundeck…

However, I think starting from a JS-reduced application and building
up from there to guarantee graceful degradation is not only
reasonable, but desirable. I have not tested Ember in such
circumstances, so this is something else where I’d like additional
feedback: Is there any particular framework that would make it easier
to build a web-app in this spirit?
If you want to be quick I imaging that goin for pre-built “local website
apps” can be a quicker and simple choice than a “real web framework”,
however my experience in web-dev is close to zero so I can’t really
help unfortunately…

I think this is the issue we would be trying to solve.
It’s not a matter of offer a “newbie friendly distro”, is far more
complex: we need a new desktop environment at least, Gnome due to
it’s evolution is not much interesting in the medium term, Kde is
not really appealing for generic user (to complex and buggy). Also
we start, again, to have hw compatibility problems due to the more
and more big amount of crap OEM fit into what they call hardware…

I imaging in a not so distant future “Linux laptops” that have a
Windows kernel and basic userland built-in in the UEFI and “Linux”
is a GNU environment on top of WSL/DeX/Crostini or something like
that, so a formally free system trapped in a proprietary jail. Of
course having non-disableable (in)secure-boot etc.

In that sense GNU/Linux desktop is dead and well… Solve this issue
means educate a big enough amount of people to impose by law free
software and open hardware, starting to tax any anti-user product,
any closed, hard-to-repair etc product. Not exactly a programming
task but a political one, and really big…

– Ingmar

[Wolfereign]

TBH before making a gui application it would be a nice start to get a cli tool that can get/set values in the config file. Another nice thing would be for something like “nixos install firefox” to not only install firefox but add it to the config file.

[regnat]

Just for reference, there’s the (unmaintained for a long time) nixui tool which provided a simple GUI for Nix(OS).

[Zurdo]

True on the command idea, but the thing is, that particular pattern I’d like to avoid. In the end, this nixos install firefox is just a special case of nixos append item array (or however that syntax ends up being implemented). nixos append firefox environment.systemPackages is more verbose, but I’d prefer this CLI to be just a debugging tool. If you’re already on the command line, you aren’t that far from appending manually, and the verbose syntax would still be an improvement… I think?

You’re definitely right in that this should be an intermediate step for aiding debugging.

[Zurdo]

Nice! You saved me from doing some research I didn’t do!

A quick glance tells me we might be targeting different things (nix-env vs configuration.nix), but reading that source might help in solving the parsing topic. Thanks!

[davidak]

Creating a concept for a graphical configuration tool is on my to-do list. I think it is important to start with design, since the used technology is just implementation detail.

The end goal should be to make maintaining servers accessible for everyone.

It would be a solution like YunoHost and Sandstorm but with the reliability of NixOS.

A big list of similar solutions is here: #52 - Improve Self-Hosting list - website - Codeberg.org

That might be too simple to manage hundreds of servers, so we should also see how UIs for common configuration management tools work. But they are too complex for home users. So we need good design to make it as easy to use as possible while being flexible enough for professional use. We probably need a professional UX designer for that.

(Ansible Tower has just a text field for the YAML config, lame)

hosting control panels are also a good reference since you can configure webspaces, databases, cronjobs etc.

ISPConfig

And sure, directly editing the config. file and a cli tool should be supported for people who prefer that.

Update: Here is a quick mockup of what i have in mind.

[7c6f434c]

Creating a concept for a graphical configuration tool is on my to-do list. I think it is important to start with design, since the used technology is just implementation detail.

The end goal should be to make maintaining servers accessible for everyone.

It would be a solution like YunoHost and Sandstorm but with the reliability of NixOS.

Also WebMin?

(what we should not forget is that we do not have data schema migration management yet)

[davidak]

@7c6f434c

Also WebMin?

Yes, that’s the categorie of tools i would look at for inspiration. Even when it is inspiration how not to do it.

It would probably become a tool to do common tasks easily, but for more complex tasks you have to edit the configuration file yourself. It should cover desktop users completely, but i’m not sure if it can cover all possibilities NixOS offers.

There can be a Setup Wizard, that opens after first basic install and can get opened anytime from the System menu. There you decide to use a Server or Desktop profile, in the latter case which desktop(s) etc.

For the best user experience we might have to decide for the user which webserver, mailserver etc to use. That’s already how webservice modules work. But maybe not everyone would be happy with that.

This webinterface would be a service itself that you can disable if you want. Than you have full manual configuration like now.

[dramforever]

To me, I’m sure I might not represent you since I’m familiar with code, but I’d be absolutely happy if we could just make the process of editing NixOS modules easier. With the Nix language, I can easily write something like this:

let
  btrfsDev = "/dev/disk/by-uuid/<uuid-of-my-btrfs-partition>";

  subvolume = name: {
    device = btrfsDev;
    fsType = "btrfs";
    options = [ "subvol=/${name}" ];
  };

in {
  fileSystems = {
    "/" = subvolume "@root";
    "/home" = subvolume "@home";
    "/nix" = subvolume "@nix";
    "/.subvols" = subvolume "";

    # ...
  }
}

With some other language like maybe Dhall, it might (or might not) be even better. However, I don’t think a GUI configuration tool could actually do this. Also I really like that the configuration is a simple file. I honestly don’t like clicking around.

Now, if only we had some intellisense here that could autocomplete as I type, and depending on what I’m typing and where I’m typing, automagically call up some documentation. Enums should autocomplete values, pkgs and config should autocomplete, etc. That’s probably going to be what I want to use.

On the flip side, something like VSCode’s GUI for editing configuration is probably a nice way to complement this. The options can be shown in a GUI, and if an option is ‘editable in GUI’ (say, not set yet or set in GUI not in code) then the user can edit it and save it to a specific machine generated module. (VSCode doesn’t have this dynamically editable thing.) Some lists or sets may be partially editable and partially non-editable, although it’s probably a bit too complicated. This would be a good way to provide a interface that facilitates exploration of options.