NixOS needs what is IMO the killer feature of Arch: the wiki.
NixOS has a killer feature which obviates a wiki for most such purposes: NixOS options. They document themselves!
You don’t need to look up a wiki on how to install and enable i.e. paperless and all the other services it depends on, you simply set services.paperless.enable and NixOS configures everything for you internally.
The option tells you roughly what it does internally and the other options provide pointers for things you might want to tweak about it. The services.paperless.extraConfig option for example tells you how to configure it (pointing to upstream documentation in this case) and even gives an example on what you might want to do.
Another example is how to install Steam. In Arch, the wiki must tell you all the manual steps required to enable multilib, install the steam package, install 32bit dependencies, yada yada.
In NixOS, you simply set programs.steam.enable = true;. Off to your games.
You wanna customise the Steam package to add additional flags, pass env vars or add additional packages your weird Linux-native indie game needs? programs.steam.package tells you how to do that right in the place where you do it.
While you’re looking for steam, you might also come across hardware.steam-hardware.enable which you need to set in order to make your Valve Index and Steam Controller work properly.
You wanna start Steam in a gamescope session right from the display-manager? programs.steam.gamescopeSession does it for you. No need to copy paste some snippet that you’ll instantly forget about and maybe breaks in a few months. programs.steam.gamescopeSession is maintained upstream by NixOS, so if it breaks, someone will go and fix that and nobody needs to adjust any of their copy-pasta because they’ll just update as they always do and it just starts working again.
None of this is perfect yet and the quality of documentation of NixOS options really varies but I think you get the idea here. I already rarely look at the NixOS wiki to configure my system because the system configuration tells me what I need to do already and this will only get better as options get refined.
the promise of being every bit as hackable as Arch
I don’t think it makes that promise and I don’t think it’s true.
NixOS is about doing things “properly”; applying software engineering to software environment management.
Whipping up a quick hack is much more complicated and time intensive on NixOS than doing so on Arch because it’s way more abstract. You can’t just quickly replace some binary with your own compiled one, you need to use NixOS’ systems to wire in the binary and build it with Nix to begin with.
Maintaining a system (even one with terrible hacks) is much simpler in NixOS however.
You’re underrepresenting the complications of NixOS and overrepresenting the complications of Arch. For example, to install Steam I would run sudo pacman -Syu steam. On a typical Arch setup that’s all that’s needed.
Another example is how to install Steam. In Arch, the wiki must tell you all the manual steps required to enable multilib, install the steam package, install 32bit dependencies, yada yada.
And that’s why the Arch wiki is so great - it has details and links about everything that goes into making something work. If you want to learn more or if something goes wrong it’s all right there.
But yes, I think you hit the nail on the head at the end there - hackability is Arch’s strength, everything is exposed and flexible to tinkering. It’s easy to make almost anything work, and easy to learn how it works. That’s very different from NixOS’s core philosophy of stability and reproducibility.
There are inherent pros and cons to both approaches - it really comes down to a mix of personal preference and using the right tool for the right job. They’re apples and oranges, and the article framing NixOS as a superior successor to Arch is as silly as the reverse would be.
For example, to install Steam I would run sudo pacman -Syu steam. On a typical Arch setup that’s all that’s needed.
That is incorrect to my knowledge. Back when I used Arch, you still needed to enable multilib which I don’t think has changed. You need a wiki entry to tell you how to do that.
AFAIK you also need to manually install yourself a Vulkan driver. I’ve recently helped a person who had opted for AMDVLK here and it broke in one game but was working fine in others.
That sort of thing doesn’t really happen with NixOS because enabling desktop support implies the presence of a Vulkan driver and we provide a sane one by default (currently RADV via mesa or nvidia when you enable proprietary drivers).
I have tried NixOS, the documentation in many options is subpar. Only the most interesting packages get good documentation. I’ll give NixOS a few more years until I try it again, but currently it’s rather a hobbyist and ‘tinkerer’ distribution. Which is fine, but I don’t want to learn domain specific stuff which is different from all of the rest of Linux.
I installed NixOS on a laptop and tried to run a steam game and it just straight up didn’t launch anything, went to the wiki to figure out the amd drivers, opengl whatever put like 10 new lines in my nix config rebuilt restarted still nothing works, after about 2 hours i just swapped back to arch and the games launched straight away, so for me it wasnt as easy as you may claim it to be. I also tried it on my desktop before and it was a better experience, but still not great. The nix config file is a bit of a mess of options that you have to dig into wiki pages and searching stuff to figure out how to get some stuff to work
What may or may not work is doing everything programs.steam.enable does internally yourself like some outdated wiki entry might suggest you to do. Given you claim to have been manually configuring opengl stuff for instance, there’s a good chance that’s what you did. You do not have to touch any opengl settings or put steam into environment.systemPackages.
The entire point of NixOS modules is that we have the capability to abstract stuff like this so that you do not have to copy pasta dozens of lines from a possibly outdated unofficial wiki but can simply set one option.
Im like 99% sure i did have that line in my config, and it still didnt work for whatever reason.
Look im not saying NixOS is bad, in fact i really like the idea of it, but ive tried it about 2 times and always came upon something that didnt just work for me, and i end up going into the nixos search thing to try and find what variables i need to put in my config, and its not always 100% clear. On my desktop steam and everything worked fine but i was annoyed at some stuff and stopped using it, on my laptop it just didnt wanna launch any games, idk why exactly that happened but another distro worked fine.
Having options is not the same thing as documenting those options; well outlined documentation doesn’t just dictate how to do something but also points out what you may want to do i.e. filling out unknown-unknowns.
Just because NixOS makes for an excellent DevOps template doesn’t mean it can’t also be an excellent platform for hacking together random crap. I understand that NixOS advertises itself as the former, but when I say “promises to be” I don’t mean “makes a promise to be”, but “has promise for being”.
Features like: a common configuration interface, safe rollback, atomic changes, nixos-hardware all are features that enable developers to safely hack together solutions, and then have an excellent log detailing what they just did.
Having options is not the same thing as documenting those options; well outlined documentation doesn’t just dictate how to do something but also points out what you may want to do i.e. filling out unknown-unknowns.
Agreed. The point is however that, with NixOS options, you do not necessarily need such documentation for unknown-knowns.
With many things however, we can simply delegate to the upstream documentation for some thing. See i.e. the paperless extra config example. We don’t need to tell users how to configure their paperless, we just tell them that any upstream option goes into this settings option as an attrset.
NixOS options do to a degree fill out unknown-unknowns though, see I.e. the steam-hardware example. I’ve stumbled upon many handy options by searching for related options.
Just because NixOS makes for an excellent DevOps template doesn’t mean it can’t also be an excellent platform for hacking together random crap.
While the initial “hacking the crap together” phase is indeed harder in most cases, maintaining these hacks is much simpler thanks to overrides/overlays and the additive nature of NixOS options.
That quality can arguably make it “excellent” too.
NixOS has a killer feature which obviates a wiki for most such purposes: NixOS options. They document themselves!
You don’t need to look up a wiki on how to install and enable i.e. paperless and all the other services it depends on, you simply set
services.paperless.enableand NixOS configures everything for you internally.The option tells you roughly what it does internally and the other options provide pointers for things you might want to tweak about it. The
services.paperless.extraConfigoption for example tells you how to configure it (pointing to upstream documentation in this case) and even gives an example on what you might want to do.Another example is how to install Steam. In Arch, the wiki must tell you all the manual steps required to enable multilib, install the steam package, install 32bit dependencies, yada yada.
In NixOS, you simply set
programs.steam.enable = true;. Off to your games.You wanna customise the Steam package to add additional flags, pass env vars or add additional packages your weird Linux-native indie game needs?
programs.steam.packagetells you how to do that right in the place where you do it.While you’re looking for
steam, you might also come acrosshardware.steam-hardware.enablewhich you need to set in order to make your Valve Index and Steam Controller work properly.You wanna start Steam in a gamescope session right from the display-manager?
programs.steam.gamescopeSessiondoes it for you. No need to copy paste some snippet that you’ll instantly forget about and maybe breaks in a few months.programs.steam.gamescopeSessionis maintained upstream by NixOS, so if it breaks, someone will go and fix that and nobody needs to adjust any of their copy-pasta because they’ll just update as they always do and it just starts working again.None of this is perfect yet and the quality of documentation of NixOS options really varies but I think you get the idea here. I already rarely look at the NixOS wiki to configure my system because the system configuration tells me what I need to do already and this will only get better as options get refined.
I don’t think it makes that promise and I don’t think it’s true.
NixOS is about doing things “properly”; applying software engineering to software environment management.
Whipping up a quick hack is much more complicated and time intensive on NixOS than doing so on Arch because it’s way more abstract. You can’t just quickly replace some binary with your own compiled one, you need to use NixOS’ systems to wire in the binary and build it with Nix to begin with.
Maintaining a system (even one with terrible hacks) is much simpler in NixOS however.
You’re underrepresenting the complications of NixOS and overrepresenting the complications of Arch. For example, to install Steam I would run
sudo pacman -Syu steam. On a typical Arch setup that’s all that’s needed.And that’s why the Arch wiki is so great - it has details and links about everything that goes into making something work. If you want to learn more or if something goes wrong it’s all right there.
But yes, I think you hit the nail on the head at the end there - hackability is Arch’s strength, everything is exposed and flexible to tinkering. It’s easy to make almost anything work, and easy to learn how it works. That’s very different from NixOS’s core philosophy of stability and reproducibility.
There are inherent pros and cons to both approaches - it really comes down to a mix of personal preference and using the right tool for the right job. They’re apples and oranges, and the article framing NixOS as a superior successor to Arch is as silly as the reverse would be.
That is incorrect to my knowledge. Back when I used Arch, you still needed to enable multilib which I don’t think has changed. You need a wiki entry to tell you how to do that.
AFAIK you also need to manually install yourself a Vulkan driver. I’ve recently helped a person who had opted for AMDVLK here and it broke in one game but was working fine in others.
That sort of thing doesn’t really happen with NixOS because enabling desktop support implies the presence of a Vulkan driver and we provide a sane one by default (currently RADV via mesa or nvidia when you enable proprietary drivers).
Didn’t read past that as you clearly don’t understand what the differences between documentation, a tutorial and code comments are.
Do read past that and you might understand why NixOS options are a type of documentation. They’re not “code comments”.
I have tried NixOS, the documentation in many options is subpar. Only the most interesting packages get good documentation. I’ll give NixOS a few more years until I try it again, but currently it’s rather a hobbyist and ‘tinkerer’ distribution. Which is fine, but I don’t want to learn domain specific stuff which is different from all of the rest of Linux.
I installed NixOS on a laptop and tried to run a steam game and it just straight up didn’t launch anything, went to the wiki to figure out the amd drivers, opengl whatever put like 10 new lines in my nix config rebuilt restarted still nothing works, after about 2 hours i just swapped back to arch and the games launched straight away, so for me it wasnt as easy as you may claim it to be. I also tried it on my desktop before and it was a better experience, but still not great. The nix config file is a bit of a mess of options that you have to dig into wiki pages and searching stuff to figure out how to get some stuff to work
If you’re on AMD, all you have to do is
programs.steam.enable = true;. Not dozens of lines copied from some wiki. I should know because that’s all I do in my config to enable Steam on my AMD system: https://github.com/Atemu/nixos-config/blob/450bf3710c77818436f1459e3ea36bf087b6e56b/configs/HEPHAISTOS/default.nix#L16 (L17-L29 are optional customisation).What may or may not work is doing everything
programs.steam.enabledoes internally yourself like some outdated wiki entry might suggest you to do. Given you claim to have been manually configuring opengl stuff for instance, there’s a good chance that’s what you did. You do not have to touch any opengl settings or putsteamintoenvironment.systemPackages.The entire point of NixOS modules is that we have the capability to abstract stuff like this so that you do not have to copy pasta dozens of lines from a possibly outdated unofficial wiki but can simply set one option.
Im like 99% sure i did have that line in my config, and it still didnt work for whatever reason.
Look im not saying NixOS is bad, in fact i really like the idea of it, but ive tried it about 2 times and always came upon something that didnt just work for me, and i end up going into the nixos search thing to try and find what variables i need to put in my config, and its not always 100% clear. On my desktop steam and everything worked fine but i was annoyed at some stuff and stopped using it, on my laptop it just didnt wanna launch any games, idk why exactly that happened but another distro worked fine.
No, you’re holding it wrong. Should’ve looked at the options! 🤡
Having options is not the same thing as documenting those options; well outlined documentation doesn’t just dictate how to do something but also points out what you may want to do i.e. filling out unknown-unknowns.
Just because NixOS makes for an excellent DevOps template doesn’t mean it can’t also be an excellent platform for hacking together random crap. I understand that NixOS advertises itself as the former, but when I say “promises to be” I don’t mean “makes a promise to be”, but “has promise for being”.
Features like: a common configuration interface, safe rollback, atomic changes, nixos-hardware all are features that enable developers to safely hack together solutions, and then have an excellent log detailing what they just did.
Agreed. The point is however that, with NixOS options, you do not necessarily need such documentation for unknown-knowns.
With many things however, we can simply delegate to the upstream documentation for some thing. See i.e. the paperless extra config example. We don’t need to tell users how to configure their paperless, we just tell them that any upstream option goes into this settings option as an attrset.
NixOS options do to a degree fill out unknown-unknowns though, see I.e. the steam-hardware example. I’ve stumbled upon many handy options by searching for related options.
While the initial “hacking the crap together” phase is indeed harder in most cases, maintaining these hacks is much simpler thanks to overrides/overlays and the additive nature of NixOS options.
That quality can arguably make it “excellent” too.