There’s a degree of negative opinion toward the gui installer among a number of NixOS devs.
It’s been described as a bit like taking a limo to the middle of the desert. NixOS is complicated, and a significant amount of technical knowledge is necessary to manage it. The gui installer does nothing to introduce you to what you need to know to manage your system, nor to the level of complexity required. It’s arguably kinder for those people who aren’t ready to manage a NixOS system to look at the installation instructions and nope out than it is to lead them into a working system without any information about how to manage it from there.
The other reason for the negative opinion is just that it doesn’t actually work that well outside of the most obvious and “normal” usecases. It generates bad configs for more complex cases, I suspect in part because Calamares’ abstractions don’t really match the model of NixOS as well as you might wish.
Regardless of the reasons, a lot of NixOS devs have never even used the gui installer, and don’t really expect to ever use it, myself among them. If the gui installer is going to improve, someone with both the necessary knowledge and an interest in improving it is going to need to spend the time figuring out what the issues are, and I suspect people fitting those criteria are rather rare.
The calamares plugin being in a separate repo was about the only good thing…
In my opinion we should pull out as much nixos tooling out of nixpkgs into distinct repos with distinct bug trackers, distinct permissions, etc because that will make things easier. Issues and PRs would not be buried anymore between issues and PRs about nixpkgs as a whole.
Most people aren’t aware of the upstream repo so they file issues in nixpkgs (and don’t contribute upstream). It’s hard enough to get people to distinguish nix vs nixpkgs repos, so I don’t think having separate repos (for at least things that new end users and contributors would use) is that productive. If the calamares issues already end up in nixpkgs, now we don’t have to tell them it’s the wrong repo.
I agree, the linux ecosystem is already very fragmented, if you have 1 repo for every package it reduces visibility on the issues and makes it hard to track progress and dependencies between issues of different packages.
Imho I prefer Monorepos for OSS for that simple reason, its easier to track dependencies and run tests from dependent packages when you make a change to one of them (if you have competent monorepo tooling, like Nrwl Nx, shame it’s so focused on the JS ecosystem).
I agree with every that tejing said and I can add one more point to the cons: the installer makes helping new users more difficult because I don’t know what configuration it has generated and the users themselves don’t know. So, I can’t reproduce their setup or quickly spot a problem.
tbh often it’s initially unclear whether the root of the problem is on the nixpkgs side (packaging or iso creation), on the calamares-nixos-extensions side, or on the upstream calamares side. Tracking such issues in nixpkgs seems pretty reasonable. I think I can transfer issues between nixpkgs and calamares-nixos-extensions, LMK when that’s desired. We already have the 6. topic: installer tag, perhaps we should use that more?
I’m somewhat suspicious of vendoring stuff into nixpkgs, as it’ll be useless to the vast majority of use cases for which nixpkgs needs to be checked out, but I’m confident the maintainers will make a well-balanced decision.
Good templates for the issue usually help, a good checklist of information required/nice to have, maybe even select fields for packages or discrete options used for filtering (templates are fairly flexible nowdays).
You could have different templates for different parts of the monorepo, (OS level issues, package level issues, kernel issues, for example, though maybe not the best examples around).
Could you expand more on this, or share links to related discussions?
Curious… Any notorious examples?
As a newcomer from the Debian world, I appreciated the live installer providing me a familiar GUI to config local, partitions, desktop environment selection, and user login. Being able to reboot and seamlessly login to system with a working DE, networking, text editor, and browser was all I hoped for in order to continue with an online tutorial.
I suppose its autogenerated configuration.nix and hardware.nix worked as expected for my normal use case, but then what other use cases do we envision for the graphical installer?
Are we talking about more advance installation setups like for ZFS or BTFS, encrypted discs, digital signing for secure boot, and what else?
Or more introductory hand holding, like suggesting first edits to add common user packages to the auto generated config, or showcasing the respective diff that one’s currently selected choices in the installer wizard correspond to?
Yes, more complex partitioning setups was mainly what I was referring to when talking about more complex cases.
This is the other issue. Someone who goes through the manual install tends to come away with a few bits of background information:
The knowledge that configuration.nix is central to the management of the system.
The idea that the system is built from this file.
Some basic degree of familiarity with the file’s contents.
By contrast, it’s rather easy for someone using the gui installer to never learn these incredibly basic aspects of NixOS. They search the web for “how do I install a package on nixos?”, and unfortunately, they probably get an answer that says to use nix-env -iA <package>. They try this, and it kind of works, but some packages don’t really work, and updates behave strangely, or don’t happen at all, and they either:
Give up and decide NixOS is pretty terrible.
Ask for help about something at some point and we need to unravel a whole tangle of inaccurate assumptions.
I have used NixOS in some shape and form since 2018 and did a gazillion of non-GUI installs. Nowadays I just use the graphical installer (except on AWS, etc.) and clone my NixOS configuration afterwards. Why? Going through the graphical installer is just a lot faster for relatively standard configurations and installation is boring and I do not want to spend too much time on it.
I just wanted to post this to say that there are also (probably a lot of) people who get a lot of value out of the graphical installer. While I also agree that for beginners it hides away some details, stepping into NixOS can be pretty daunting, and it’s really nice to be able to get a fully booting system and explore from there.
They search the web for “how do I install a package on nixos?”, and unfortunately, they probably get an answer that says to use nix-env -iA <package> .
It doesn’t help that for a long time this was the first recommendation of the NixOS Manual (luckily fixed now).
Exactly my same flow, I have a flake dotfiles in GitHub and what I do (except for the last attempt where it failed and I had to work around the installer) is use the Installer to get the hardware-config.nix, keyboard layout, partitions with LUKS encryption and base user set up, then clone my dotfiles and copy the config and hardware config files to my repo’s hosts folder, then tweak it a bit (mostly to remove duplicated config values with my OS modules and import the modules I need), run the OS build, and Home Manager build.
The GUI installer just expedites that process, unless you have those parted commands fresh in memory, it takes a while to run all the commands just to setup the partitions, way longer than the GUI installer.
I think there are two interlinked threads to unpick.
The installer could be continuously extended to cover more and more use-cases (more partitioning schemes, diverse hardware (wifi, cpu) etc.
The installer should be modified such that before the end of the installation process the user has touched /etc/nixos/configuration.nix
Basically this feels like a rehash of the kajillion words that have spilt on archinstall scripts vs following the wiki and the standard attendant arguments (users running the script don’t know how the system is built, requiring people to read is elitist, automation saves time for people that have done it once etc etc) with the added twist that in NixOS land there are multiple conflicting ways to install packages and the installer currently doesn’t teach you the right mechanic.
Alternatively this is the same argument being had about a graphical software centre vs a nix file, just at a different point in the systems lifecycle.
I’d just bin the installer, and if it means less users, so be it. I think communities should aim for growth at a rate that can be sustained and having fewer users that impose less of a support burden and are overall more satisfied with their experience of the ecosystem as it is today would be a good thing. Although I’m probably delusional and we’d just get more users arriving needing help earlier in the pipeline!
I guess there is yet another dimensions of «the installer could be extended to help update the configuration post-install», at least within the scope of things configurable in the installer and updatable post-factum?
I will say, it’s grown on me in principle. It still has a variety of technical issues, but I have come around to the opinion that it eases the on-ramping experience for new NixOS users. And even for experienced users, it’s a very quick and convenient way to get a basic config set up on a new machine. As much as I dislike trying to maintain the GUI installer, it’s probably good that we have it.
Believe me, it has been much more of a problem than a good thing. When it had a major security vulnerability last year, it took months to get the fix into NixOS, because of the limited commit access. That’s why I ended up being added as an emergency committer on it; not to actively improve it, but just to have someone to put out fires.
Of these, I think upstream calamares is the least problematic. Usually, the weird stuff we do in calamares-nixos-extensions or the way we package it in nixpkgs is the source of problems with the GUI installer.
For instance, the GUI installer includes a screen for setting up LVM, but it crashes if you try to use it.
It doesn’t even have to be that complicated for it to produce questionable configs. If your machine boots in legacy BIOS mode and you want the drive to be encrypted, it ends up configuring grub cryptodisk and boot.initrd.secrets, which is very much not a recommended configuration. The reason for this is that calamares prevents us from doing a separate /boot partition for BIOS systems because it basically thinks that path can only be used for the ESP and only on EFI systems. Though, granted, there’s things we could be doing to work around this, and arguably should be doing since a lot of people will have a 100M Windows ESP, i.e. separate /efi and /boot.
I definitely agree with the idea that you want the growth rate of a project to be at a sustainable sweet spot, and the GUI installer has certainly risked exceeding that. Overall, I think it’s fine, but it’s almost certainly the reason for the explosion in new NixOS users from the past couple years. I think the creation of the GUI installer probably is what led to a bunch of youtubers showcasing NixOS a couple years ago which probably is what led to so many of the new users. But at the moment, I think we’re still within the sweet spot.
I’d not even made the association. I’d mostly attributed it to the marketing (both deliberate and implicit by the proliferation of flake.nix) of flakes, but I think you’re right - the availability of a graphical installer is probably much more impactful. Guess it’s a bit of a reminder of the impact of perspective - I didn’t really think anyone pays enough attention to the tech blogs and YouTube channels for them to have an impact.
(luckily fixed now).