I think you’re spot on. I had the idea the other day of a web based Nix configuration system + native mobile app being a potentially killer combination enabling a lot of unique features people would love including easier installation.
Imagine a system like this:
Nix(OS) runs a webserver that can be connected to locally via a browser
This interface acts as a graphical configuration editor. The “app store” portion is essentially just adding/removing packages to an array.
When the user is done making changes there’s a “make it so” button to apply the config
The interface offers easy rollback and management of generations
Now that would be useful on its own, but if we take the concept a little further it becomes unique and IMO a highly awesome way anybody manage their system(s) that doesn’t exist elsewhere
The webapp is also a mobile app (use react-native for a single codebase)
Offer services via nixos.org (of course also with option to self host). These services would include:
Allow for easy connection via proxy (for example: https://connect.nixos.org/{identifier} to reach your machines from anywhere as long as it has internet)
Auto-backup and versioning of configurations
Sharing of configuration pieces, to make common use cases easier. For example an option for “android development” or “lamp server” or “steam gaming” or “nodejs development” or “kde desktop” IIRC nix modules already enable this, but discoverability and sharing isn’t easy.
Use the app for installation. Pop installation media into a machine then open the app, auto-detect the installer or scan the displayed QR code (or navigate to the url) to configure and install the machine remotely. Apply your saved configs to do it quickly. Quickly and easily set up multiple or headless machines!
Notifications. Machine rebooted? Service crashed? The Nix app could be your hub for managing all your nix deployments.
Expert mode: raw config editing but nice to use via an embedded monaco editor (the editor vscode uses) with nix extension.
Crazy idea: auto-packaging (or guided packaging) of apps that aren’t in nixpkgs yet. For many apps adding them to nixpkgs seems to be just boilerplate of getting the url and hash then putting them into the standard builder, checking they work, then submitting a PR. Could that be largely automated?
All of this combined would be amazing for day-to-day use of NixOS and for building/managing deployments of multiple NixOS machines.
I love Nix and NixOS but I always find myself back on MacOS after several months of nix-ing because the day to day usage and management of NixOS gets in the way of other things I need to do. Right now there’s a lot of hoops to jump through in order to do “simple” things in NixOS. Most of those things aren’t hard to do, but there are a lot of steps and minutia to remember to get them done. Most of the time I don’t remember that stuff and have to go searching. Most of the time I don’t have time to do that at the moment.
I’m guessing others feel this way as well and that an easier way to manage nix systems would go a long way to easing the most common use cases. I’m a web/react-native dev by trade so I’d love to hack on something like this but unfortunately for the foreseeable future I’m not realistically going to have the time to put together anything of substance.
what you’re describing feels like a nicer NixOps frontend intended for end-users (while NixOps was originally targeted at DevOps engineers and system administrators) that has lots of new features and integrations, especially number 6 and 7.
A proxy-server integration for easy connection feels like a nice idea… for a backdoor. This might need to be password-protected somehow, or better cryptographically, since it opens a large attack surface - essentially, you’re asking for a reverse shell. I think it’s better to do remote access with SSH, using domain names like computer.username.manage.nixos.org, where manage.nixos.org is the management server’s domain name.
Auto-versioning could be performed with Git under the hood.
Sharing of configuration pieces could be a bit easier with the emerging flakes RFC - as Nix flakes are pure, and there’s a proposed central flake registry (with support for local registries for extension) you could import flakes that contain NixOS modules to configure your system faster. Outlining a standard for inclusion into the official registry will be great for allowing others to publish on this platform.
For installation, I think that Nixpart should be finished and included into NixOS before this can proceed, for unattended partitioning. A guided partitioning option could also be available.
Notifications - this feels nice, especially for me - someone who never knows when her server crashed. This will require a daemon to be present on the system constantly, but systemd could probably handle another daemon, couldn’t it? :3
Expert mode - as flakes are essentially Git repos hosted somewhere for access, this is essentially provided by services like GitHub already. No need to invent something special :3
I use netdata for that. It discovers services by itself and sends e-mails when a mailserver is installed and a rootAlias is given. But you also want external monitoring to see if the system is available, like Uptime Robot (checks every 5 minutes are free).
The guys at https://mercode.org seem to have begun some work in the ‘friendly NixOS’ department, although it seems they do struggle with the effort somewhat.
If you have comments, I can improve it. It’s only a skeleton now but there would be lots of settings for each module so a user can uncomment a single import and easily get configuration he needs without going through the wiki.
I’m one of those average users. Just this week I got NixOS installed easily…on a computer with ethernet. I couldn’t get it on my laptop, which has only a WiFi card, because the driver for said card isn’t in the install image.
Now, I don’t care about proprietary vs. free when it comes to something this basic. I just want to install the system, which is impossible without internet. (That seems to be the norm in Linux.)
Forgive my ignorance, but it seems there are are two different tools for connecting to the web here: NetworkManager (graphical system) and wpa_supplicant (text-mode, WiFi only). Either way, I don’t benefit from not being able to get online. Tl;dr: make sure new users have their wireless drivers, proprietary or not.
Especially the firmware needed for some RealTek chipsets is not allowed to be redistributed. They can not legally put these firmware on the ISO.
Neither would a RedHat or Canonical be allowed to put these firmware on the ISOs, unless they perhaps paid RealTek or otherwise have contracts with them.
The golden rule for WiFi on Linux is, have your ethernet ready to back you up.
Also you can build your own installation ISO which already contains all necessary firmware and kernel modules. Even the unfree ones, but you are not allowed to share it.
We could however make creating such a custom ISO easier.
It’d be really cool if we could have a Docker command that builds custom ISOs with proprietary firmwares, modules etc. right on the download page for people who need it so that they don’t have to go digging and/or understand both Nix and Docker.
Would be a very cool showcase of the power of Nix too, I don’t think this would be as easy and portable using other build systems.
Yeah like that but ideally with pre-made configs for commonly needed drivers and without having to install Nix manually (for example, like I mentioned, running via something super portable like a container).
This imo would be the most useful thing to have. A set of packages that could create a few usable desktop environments with commonly used software. I remember the first time I installed it, I forgot to turn on any kind of networking and it was very awkward. I found myself very often running back to /etc/nixos/configuration.nix to install common packages that I normally wouldn’t think twice about installing.
It’s unfortunate about the driver situation. Being able to create our own livecds isn’t awful though.
That looks interesting, but yes it does seem to have slowed down almost to a halt. I think they deserve some exposure so that devs can find their way to help out. Maybe a mention in some blog post?
transfer another working installation (I made a earlier post about transferring working installation from vbox, you could do the same from box or desktop)