7 ms·

I've bounced off Nix a couple of times and figured that the problem is that it was too different. A lot of Linux distros (especially post-systemd) have a fair n

I've bounced off Nix a couple of times and figured that the problem is that it was too different. A lot of Linux distros (especially post-systemd) have a fair number of similarities and it's pretty easy to translate knowledge between them. NixOS _probably_ works very similarly, but it's also got this additional declarative configuration layer on top, which is the point of using NixOS, and it's got its own special way of doing things. You can't translate Linux knowledge to a NixOS config directly, you need NixOS' documentation to understand the "NixOS Way" of doing things, and the NixOS way of doing things does not translate into other distros. And the documentation is difficult to understand and at times seemingly arbitrary. You have to commit to learning NixOS and understand that you are only learning NixOS, it won't help you use anything else. Other Linux distros help you learn Linux in general and inform your understanding of Linux system construction, but NixOS is its own thing. Plenty of people learn NixOS anyway, and more power to them, but it's definitely pushed me away.

ivank 5y ago
The NixOS way of doing things (a layer on top of plain config files) is inevitable once configuration management is taken seriously: one needs to be able to merge configuration values from multiple source files; for example, a generic role plus some more machine-specific role, working together to produce one systemd unit or file in /etc. The modules in nixpkgs effectively make it possible to combine configuration values to produce most of the config files that Linux applications want. If one weren't using NixOS to do it, it would be done with your own templates and configuration management, and probably without the huge advantage of being able to rebuild a whole immutable system without leftovers from prior configurations.
- temptemptemp111 5y ago
  Where is the evidence for this? Where is the evidence that you can and should mix config management all of the way down the OS stack? How many containerization concepts do we need? Docker, lxc, VMs, and now NixOS? If it were a legitimate abstraction layer, then wouldn't it have caused fewer problems in implementation? And wouldn't it have seemed more intuitive to Unix experts? Yes... Reinventing the wheel again. I'm open to nicer restructuring of the Linux fileystem, but this is really re-inventing the wheel trying to polish over ugly parts that are ugly for a reason. Keep useful abstractions separate!
  - seniorivn 5y ago
    most people who have claim to be unix experts and cannot grasp nix are usually just don't like functional languages those who do, say that it's a great idea, but implementation is a bit hacky and not well documented
    - temptemptemp111 5y ago
      The first sentence is false - unless we cannot find anyone who both likes functional languages and does not like NixOS... Which is quite easy to do. Then you say the only reason they could state for not liking it is the "hacky implementation" and bad documentation. Sure...
  - kohlerm 5y ago
    One problem that NixOS solves is to be able to use different tools on the same host in different versions easily(1) and in a reproducible way(2). Docker containers can be used to solve 1), but they are in some sense overkill and quite a few uses cases. If you are a developer who only wants do use different compilers then Docker containers are not really ideal, because they also enforce process isolation. Also there is the popular believe that Docker containers also solve 2) that is not really completely true. Yes you can run a Docker image in a reproducible way on different machines, but cannot necessarily reproduce the Docker image, at least not with the standard Docker tools. You can use Nix to create Docker images in a reproducible way.
    - temptemptemp111 5y ago
      You say Docker is overkill when scratch images are extremely minimal - and you're comparing using containers to rewriting the entire host OS (which isn't even done yet in NixOS case)? Overkill is rewriting the host OS continually until everyone who was previously familiar with it has no clue how to use it anymore. That is just hiding complexity, it isn't simplifying it. A package manager in a good distro can install / maintain "different compilers." You can use Debian to create Docker images in a reproducible way too. NixOS isn't more reproducible or especially reproducible when compared to a distro that has also accomplished reproducibility... It merely mixes up config management code down to the bottom of your OS, thus requiring an OS/distro rewrite (which still isn't close to being done). It is shifting complexity from one place to another, like Oobleck in Dr. Seuss. You can also do OS imaging & snapshots in a distro-independent way using Darch, and then boot from those images in your bootloader. No need for NixOS there either; so what does this solve other than a massive bikeshedding project when engineers should be focusing on what is useful?
- mindslight 5y ago
  Doing programmatic configuration with a traditional distribution isn't difficult. I've got a python script that starts with a tree of config files and a top level file that says what files to consider per-machine. Each config file is run through Jinja2. Some templating even pulls data from a LibreOffice spreadsheet [0]. By default the script only pushes files that haven't been remote, so if you do deviate and edit a config file on a machine you can diff it to merge those changes back into the centralized config before overwriting. Having said that, I'm moving towards NixOS for reasons detailed in another comment. [0] It's ugly but it works. I'd love to find a lightweight curses-based data structure editor.
_2paq 5y ago
This is why I feel efforts like Fedora Silverblue might end up becoming mainstream in the years to come rather than esoteric projects like NixOS. I personally dislike both projects though, when it comes personal desktops. Silverblue is heavily influenced by Flatpak and I don't expect RPMs for GUI applications to survive in Fedora. NixOS needs you to learn Nix which is a pretty steep learning curve and like you said, that knowledge probably won't translate anywhere else. You're probably better off investing your time learning things like shell/python scripting, Ansible, and Docker/podman.
- seniorivn 5y ago
  right now NixOS is for a small subset of geeks(who are ok with using custom functional language for pretty much all configuration) but it's entirely possible to make a GUI based like a SUSE configurator based on nix, and with mature enough nix ecosystem it will work flawlessly an be powerful and simple to use for the end user
  - oneplane 5y ago
    For the end user it doesn't matter if a GUI is using some nix-thing in the background. It could just was well run dpkg/rpm behind the scenes and as long as the result is the same it really doesn't matter. This is also why Nix and NixOS painted itself in a corner; the presented value is only relevant if you are hacking away at it. When you have a smooth GUI experience it really no longer matters what the technical goodness underneath is.
    - ratorx 5y ago
      I think the point is that Nix makes it a lot easier (in some ways) to build a more reliable system GUI, rather than other package managers because of declarativity being a first-class feature. Users shouldn’t have to care what their GUI uses underneath, but it could be the difference between building your own pseudo-declarative layer (which you now have to maintain in perpetuity and handle all the small edge cases), or getting something that is already declarative as the backend and simply generating a config file from the GUI (https://github.com/nix-gui/nix-gui https://github.com/nix-gui/nix-gui). EDIT: Also composition. Users could, if they wanted to, augment the GUI generated configuration using the built-in Nix features for composition with config files, which is a lot easier than trying to do the same with traditional system managers.
deleted 5y ago
[deleted]
otabdeveloper4 5y ago
Nix isn't a package manager, it's a system for making ad-hoc, repeatable computing environments. The "package manager" paradigm doesn't fit Nix that well, which is why it's a painful experience when you come to it from the angle that it's another Linux distro. (IMO it makes more sense to think of Nix as "declarative Docker that doesn't need Linux namespaces".)
- grawp 5y ago
  Thisss! I'm very disappointed that most people seriously misunderstand what Nix is. Some calls it just another package manager and others dare to call it another Docker... while i'm screaming in horror internally.
  - piaste 5y ago
    > Some calls it just another package manager and others dare to call it another Docker To be fair, when it gets installed on a personal, non-developer desktop machine, Docker typically is just another package manager.
- pxc 5y ago
  Nix is pretty unlike the package managers of most popular distros, but it's not so dissimilar to other source-based package managers, like Gentoo's Portage. The basic idea that you have a giant monorepo of build recipes and a tool that automatically builds packages from source according to it is the same. It's absolutely true that you're missing out if all you do is use `nix profile install` like you might use `apt-get install`, though.
  - otabdeveloper4 5y ago
    No, not really. The projects do rely heavily on Nix for infrastructure stuff, and I have to explain it to unprepared developers often. The best angle is to explain it as "like Python venvs, except works for any combination of programming languages". That sets for correct expectation for feature set and complexity. P.S. The single biggest huge blocker is lack of support for nix-shell in VSCode and JetBrains IDEs. Every other complaint is a minor trifle in comparison.
rgoulter 5y ago
This is a pretty good take. Although I'd further emphasise: knowledge of Linux is "necessary but not sufficient" for using NixOS. NixOS requires additional knowledge, rather than a different set of knowledge. I think for many developers with Linux experience, probably getting a reasonable NixOS desktop setup is straightforward. There are some compelling benefits to Nix/NixOS, but these also require getting past a steep cliff in the difficulty curve.
- evh 5y ago
  >I think for many developers with Linux experience, probably getting a reasonable NixOS desktop setup is straightforward. I took this as an excuse to try NixOS myself and an opportunity to provide anecdata. Previous Linux experience: Lots, including about 7 years of Gentoo use, some Arch and the usual distro hopping before that. Mostly on laptops (not counting VMs). Lately it's mostly been the BSDs so I'm a little lost. It took me about 45 minutes from searching for their site to have a working XFCE install using their minimal install ISO with VirtualBox. Certainly a different experience, but with their install guide and searching "nixos xfce" you'll get it done. Promptly rebooted and went for an encrypted ZFS root - less straightforward but after a few PEBKAC snags I got it up in an hour or two. My immediate impression is that this is great but not being allowed to just # which zsh >> /etc/shells rubbed me the wrong way. Definitely something I'll consider using in the future, seems like a good fit for i.e. a VPS you might want to move easily. Naturally I haven't learned the config language fully, but it seems easy enough if the docs aren't terrible.
  - pxc 5y ago
    Thanks for sharing your experience! > My immediate impression is that this is great but not being allowed to just `# which zsh >> /etc/shells` rubbed me the wrong way. Yep. That kind of thing will come up; on NixOS, root's interactive whim doesn't own /etc— `nixos-rebuild` owns /etc. But of course, both root and nixos-rebuild are you, so that's not so bad. :) For those curious (I assume the parent poster already figured it out) the NixOS way of enabling ZSH as a login shell is the following one liner: programs.zsh.enable = true; which will both ensure that it is installed and on the PATH, and add it to /etc/shells for you. As a rule of thumb, it's generally a good idea to check the NixOS options to see if there's a module defined for configuring a program before just adding it to your `environment.systemPackages`. Here's NixOS' zsh configuration options, for example: https://search.nixos.org/options?channel=21.05&from=0&size=50&sort=relevance&type=packages&query=programs.zsh https://search.nixos.org/options?channel=21.05&from=0&size=5... (`programs.zsh.{shell,prompt,loginShell,interactiveShell}Init` are your escape hatches; you can put whatever custom zsh scripting you want in there)
akavel 5y ago
> "and understand that you are only learning NixOS, it won't help you use anything else" So — for one thing — in my personal case, it helped me at one time when I was experimenting with kernel build flags. With the caveat that finding how to change them was (surprise surprise) typically non-trivial in Nix in the first place... so it may be a feeble counterpoint... but still, after I found how to do it, NixOS made rebuilding new OS with different kernel flags absolute breeze, with basically 0 worry if I bork something (I mean, except maybe going to deep hardware params hacking such that would risk fraying some electronics) — I'd always automatically be just one GRUB entry away from a previous working configuration. (Though also useful to have `git commit`ed the previous /etc/configuration.nix from before I made some risky change, so that I could easily go tweaking again from there.)
- GekkePrutser 5y ago
  This is something that is coming to traditional Linux as well though, with zfs snapshots. I've had it for a long time on FreeBSD. I just snapshot before I do something big. I see the benefit of declarative configuration as an admin at work where we need to set up many systems the same way. For home desktop use I don't really see the point, I don't think it's a tech that fits perfectly in every scenario. Like most technologies there's usecases where its benefits shine and the drawbacks are irrelevant, and others where it's the opposite. For example I often come across software that isn't packaged for my OS and I like to just compile them and try them out without having to do the whole packaging routine.
  - akavel 5y ago
    As to "home use", personally I'm successfully keeping my dotfiles & $HOME/bin/ scripts managed with Nix + home-manager. Becomes useful when changing jobs, and also makes it easier to share new config tricks between work & home machine. Regardless if Linux or Mac. edit: in particular, going just Nix (not NixOS) on work machine(s) allows me to fall back to apt-get/brew quickly when a particular tool is not (yet) on Nixpkgs.
  - tux1968 5y ago
    > This is something that is coming to traditional Linux as well though, with zfs snapshots. Has there been a change in ZFS licensing? I thought it was always going to remain poorly integrated into the Linux ecosystem.
alufers 5y ago
The knowledge is one thing, because you can always learn how to do things the "Nix way" (either by reading the incomplete documentation or tinkering for hours until the thing works). But the real problem is that software does not understand nix either. For example loads of scripts expect /bin/bash to exist, but on NixOS it is missing. Want to run a random python script from github? Well that's a bummer, because there is no nix version of a random library this script uses. Also no-machine server and Chrome Remote Desktop don't work, and these are the two remote desktop solutions which work on spotty 4G. And I had to ditch NixOS, because my employer forced me to use a proprietary VPN, and I there is no way it would run on NixOS.
- nvarsj 5y ago
  Just to say, there are always ways to deal with what you describe. For /bin/bash, create a symlink from /bin/bash to bash: system.activationScripts.binbash = '' mkdir -m 0755 -p /bin ln -sfn ${pkgs.bash}/bin/bash /bin/.bash.tmp mv /bin/.bash.tmp /bin/bash # atomically replace /bin/bash ''; For python, you're best off using a virtualenv anyways. For proprietary binaries, you can almost always get them to run using steam-run. But the nicer way is a wrapper script to set up LD_LIBRARY_PATH, or custom derivation to patch their ld lib paths. Yeah it requires some elbow grease sometimes, but what distribution doesn't? Maybe Fedora/Ubuntu? I think the pain really is all that prior Linux knowledge is non-transferable and you have to learn how to fix things in the Nix way.
  - seniorivn 5y ago
    you should not create such an imperative simlink almost anything can be packages with nix in a minute or two, so any code you found out the internet would be easy to run and it will take not much more time than to simply check it's build config for malicious code, which you should do anyway
    - YuukiRey 5y ago
      Maybe if you use buildUserFHS and --impure a lot. But NodeJS applications that try to download binaries at install time or python packages with conflicting package versions definitely take more than a minute or two. Just look at the history of Anki in Nixpkgs, or the derivations for JetBrains products or Cypress or any of the other packages that took consistent effort by multiple contributors to even get them working in the first place. I think it's important to manage expectations about Nix and that includes being realistic about what's easy and simple what isn't.
huijzer 5y ago
> You have to commit to learning NixOS and understand that you are only learning NixOS, it won't help you use anything else. As a NixOS user, I did learn a lot about what is part of Linux distributions and what is part of the kernel, and how they interact. Compared to my previous Ubuntu knowledge, of course. If I would have ran Arch, I would have learned similar things.
larusso 5y ago
Same here. I still flock to the page every now and then and think about to give it yet another shot. But my main usecase is to develop software. I work with java, rust, ruby, JS and different other languages that needs custom treatment when doing things the nix way. Like writing a custom nix shell env file which deals with npm dependencies and the like to have all the glory deterministic package updates etc. I guess I will try it again at one point.
pxc 5y ago
> You have to commit to learning NixOS and understand that you are only learning NixOS, it won't help you use anything else. This is kind of true on a surface level, but NixOS experience can be super helpful for setting up other distros because it turns Nixpkgs into a repository of high quality examples and demos that are always up to date. Once you learn some basics of reading Nix code and how the NixOS module system works, the Nixpkgs repo itself becomes an excellent cross-distro resource on how to configure Linux software, much like the Arch and Gentoo wikis. I often consult Nixpkgs on how to do things in Linux for the purposes of configuring another distro or helping another user to do so! :)
mindslight 5y ago
I bounced off NixOS a few times as well. In addition to what you've said, I also didn't find it compelling because I already had a way of doing programmatic configuration and functional system management under Debian using my own scripts. So I didn't particularly see what converting everything over to NixOS configs would get me. What made NixOS stick is running up against some problems where Debian itself was ill-suited and seeing Nix's power. For example, building an image for a Raspberry Pi can be done with a handful of config lines. Changing between a cross compile and an emulated compile is also a handful of lines. This kind of power feels akin to the general lisp / functional curse where certain things become so easy they aren't even well documented because once you understand the system it's second nature. Another benefit - I've modified kernel source and I've written my own modules, but they always fell by the wayside due to the maintenance burden of a compiling a custom kernel package. With Debian, I would end up reading kernel source plenty of times to figure out what was going on, but it was effectively read only. Whereas with NixOS, adding kernel overlays is straightforward. Using what is essentially a source distribution plays to the larger philosophy of Free software.

ivank 5y ago

The NixOS way of doing things (a layer on top of plain config files) is inevitable once configuration management is taken seriously: one needs to be able to merge configuration values from multiple source files; for example, a generic role plus some more machine-specific role, working together to produce one systemd unit or file in /etc. The modules in nixpkgs effectively make it possible to combine configuration values to produce most of the config files that Linux applications want. If one weren't using NixOS to do it, it would be done with your own templates and configuration management, and probably without the huge advantage of being able to rebuild a whole immutable system without leftovers from prior configurations.

temptemptemp111 5y ago
Where is the evidence for this? Where is the evidence that you can and should mix config management all of the way down the OS stack? How many containerization concepts do we need? Docker, lxc, VMs, and now NixOS? If it were a legitimate abstraction layer, then wouldn't it have caused fewer problems in implementation? And wouldn't it have seemed more intuitive to Unix experts? Yes... Reinventing the wheel again. I'm open to nicer restructuring of the Linux fileystem, but this is really re-inventing the wheel trying to polish over ugly parts that are ugly for a reason. Keep useful abstractions separate!
- seniorivn 5y ago
  most people who have claim to be unix experts and cannot grasp nix are usually just don't like functional languages those who do, say that it's a great idea, but implementation is a bit hacky and not well documented
  - temptemptemp111 5y ago
    The first sentence is false - unless we cannot find anyone who both likes functional languages and does not like NixOS... Which is quite easy to do. Then you say the only reason they could state for not liking it is the "hacky implementation" and bad documentation. Sure...
- kohlerm 5y ago
  One problem that NixOS solves is to be able to use different tools on the same host in different versions easily(1) and in a reproducible way(2). Docker containers can be used to solve 1), but they are in some sense overkill and quite a few uses cases. If you are a developer who only wants do use different compilers then Docker containers are not really ideal, because they also enforce process isolation. Also there is the popular believe that Docker containers also solve 2) that is not really completely true. Yes you can run a Docker image in a reproducible way on different machines, but cannot necessarily reproduce the Docker image, at least not with the standard Docker tools. You can use Nix to create Docker images in a reproducible way.
  - temptemptemp111 5y ago
    You say Docker is overkill when scratch images are extremely minimal - and you're comparing using containers to rewriting the entire host OS (which isn't even done yet in NixOS case)? Overkill is rewriting the host OS continually until everyone who was previously familiar with it has no clue how to use it anymore. That is just hiding complexity, it isn't simplifying it. A package manager in a good distro can install / maintain "different compilers." You can use Debian to create Docker images in a reproducible way too. NixOS isn't more reproducible or especially reproducible when compared to a distro that has also accomplished reproducibility... It merely mixes up config management code down to the bottom of your OS, thus requiring an OS/distro rewrite (which still isn't close to being done). It is shifting complexity from one place to another, like Oobleck in Dr. Seuss. You can also do OS imaging & snapshots in a distro-independent way using Darch, and then boot from those images in your bootloader. No need for NixOS there either; so what does this solve other than a massive bikeshedding project when engineers should be focusing on what is useful?
mindslight 5y ago
Doing programmatic configuration with a traditional distribution isn't difficult. I've got a python script that starts with a tree of config files and a top level file that says what files to consider per-machine. Each config file is run through Jinja2. Some templating even pulls data from a LibreOffice spreadsheet [0]. By default the script only pushes files that haven't been remote, so if you do deviate and edit a config file on a machine you can diff it to merge those changes back into the centralized config before overwriting. Having said that, I'm moving towards NixOS for reasons detailed in another comment. [0] It's ugly but it works. I'd love to find a lightweight curses-based data structure editor.

_2paq 5y ago

This is why I feel efforts like Fedora Silverblue might end up becoming mainstream in the years to come rather than esoteric projects like NixOS. I personally dislike both projects though, when it comes personal desktops. Silverblue is heavily influenced by Flatpak and I don't expect RPMs for GUI applications to survive in Fedora. NixOS needs you to learn Nix which is a pretty steep learning curve and like you said, that knowledge probably won't translate anywhere else. You're probably better off investing your time learning things like shell/python scripting, Ansible, and Docker/podman.

seniorivn 5y ago
right now NixOS is for a small subset of geeks(who are ok with using custom functional language for pretty much all configuration) but it's entirely possible to make a GUI based like a SUSE configurator based on nix, and with mature enough nix ecosystem it will work flawlessly an be powerful and simple to use for the end user
- oneplane 5y ago
  For the end user it doesn't matter if a GUI is using some nix-thing in the background. It could just was well run dpkg/rpm behind the scenes and as long as the result is the same it really doesn't matter. This is also why Nix and NixOS painted itself in a corner; the presented value is only relevant if you are hacking away at it. When you have a smooth GUI experience it really no longer matters what the technical goodness underneath is.
  - ratorx 5y ago
    I think the point is that Nix makes it a lot easier (in some ways) to build a more reliable system GUI, rather than other package managers because of declarativity being a first-class feature. Users shouldn’t have to care what their GUI uses underneath, but it could be the difference between building your own pseudo-declarative layer (which you now have to maintain in perpetuity and handle all the small edge cases), or getting something that is already declarative as the backend and simply generating a config file from the GUI (https://github.com/nix-gui/nix-gui https://github.com/nix-gui/nix-gui). EDIT: Also composition. Users could, if they wanted to, augment the GUI generated configuration using the built-in Nix features for composition with config files, which is a lot easier than trying to do the same with traditional system managers.

deleted 5y ago

[deleted]

otabdeveloper4 5y ago

Nix isn't a package manager, it's a system for making ad-hoc, repeatable computing environments. The "package manager" paradigm doesn't fit Nix that well, which is why it's a painful experience when you come to it from the angle that it's another Linux distro. (IMO it makes more sense to think of Nix as "declarative Docker that doesn't need Linux namespaces".)

grawp 5y ago
Thisss! I'm very disappointed that most people seriously misunderstand what Nix is. Some calls it just another package manager and others dare to call it another Docker... while i'm screaming in horror internally.
- piaste 5y ago
  > Some calls it just another package manager and others dare to call it another Docker To be fair, when it gets installed on a personal, non-developer desktop machine, Docker typically is just another package manager.
pxc 5y ago
Nix is pretty unlike the package managers of most popular distros, but it's not so dissimilar to other source-based package managers, like Gentoo's Portage. The basic idea that you have a giant monorepo of build recipes and a tool that automatically builds packages from source according to it is the same. It's absolutely true that you're missing out if all you do is use `nix profile install` like you might use `apt-get install`, though.
- otabdeveloper4 5y ago
  No, not really. The projects do rely heavily on Nix for infrastructure stuff, and I have to explain it to unprepared developers often. The best angle is to explain it as "like Python venvs, except works for any combination of programming languages". That sets for correct expectation for feature set and complexity. P.S. The single biggest huge blocker is lack of support for nix-shell in VSCode and JetBrains IDEs. Every other complaint is a minor trifle in comparison.

rgoulter 5y ago

This is a pretty good take. Although I'd further emphasise: knowledge of Linux is "necessary but not sufficient" for using NixOS. NixOS requires additional knowledge, rather than a different set of knowledge. I think for many developers with Linux experience, probably getting a reasonable NixOS desktop setup is straightforward. There are some compelling benefits to Nix/NixOS, but these also require getting past a steep cliff in the difficulty curve.

evh 5y ago
>I think for many developers with Linux experience, probably getting a reasonable NixOS desktop setup is straightforward. I took this as an excuse to try NixOS myself and an opportunity to provide anecdata. Previous Linux experience: Lots, including about 7 years of Gentoo use, some Arch and the usual distro hopping before that. Mostly on laptops (not counting VMs). Lately it's mostly been the BSDs so I'm a little lost. It took me about 45 minutes from searching for their site to have a working XFCE install using their minimal install ISO with VirtualBox. Certainly a different experience, but with their install guide and searching "nixos xfce" you'll get it done. Promptly rebooted and went for an encrypted ZFS root - less straightforward but after a few PEBKAC snags I got it up in an hour or two. My immediate impression is that this is great but not being allowed to just # which zsh >> /etc/shells rubbed me the wrong way. Definitely something I'll consider using in the future, seems like a good fit for i.e. a VPS you might want to move easily. Naturally I haven't learned the config language fully, but it seems easy enough if the docs aren't terrible.
- pxc 5y ago
  Thanks for sharing your experience! > My immediate impression is that this is great but not being allowed to just `# which zsh >> /etc/shells` rubbed me the wrong way. Yep. That kind of thing will come up; on NixOS, root's interactive whim doesn't own /etc— `nixos-rebuild` owns /etc. But of course, both root and nixos-rebuild are you, so that's not so bad. :) For those curious (I assume the parent poster already figured it out) the NixOS way of enabling ZSH as a login shell is the following one liner: programs.zsh.enable = true; which will both ensure that it is installed and on the PATH, and add it to /etc/shells for you. As a rule of thumb, it's generally a good idea to check the NixOS options to see if there's a module defined for configuring a program before just adding it to your `environment.systemPackages`. Here's NixOS' zsh configuration options, for example: https://search.nixos.org/options?channel=21.05&from=0&size=50&sort=relevance&type=packages&query=programs.zsh https://search.nixos.org/options?channel=21.05&from=0&size=5... (`programs.zsh.{shell,prompt,loginShell,interactiveShell}Init` are your escape hatches; you can put whatever custom zsh scripting you want in there)

akavel 5y ago

> "and understand that you are only learning NixOS, it won't help you use anything else" So — for one thing — in my personal case, it helped me at one time when I was experimenting with kernel build flags. With the caveat that finding how to change them was (surprise surprise) typically non-trivial in Nix in the first place... so it may be a feeble counterpoint... but still, after I found how to do it, NixOS made rebuilding new OS with different kernel flags absolute breeze, with basically 0 worry if I bork something (I mean, except maybe going to deep hardware params hacking such that would risk fraying some electronics) — I'd always automatically be just one GRUB entry away from a previous working configuration. (Though also useful to have `git commit`ed the previous /etc/configuration.nix from before I made some risky change, so that I could easily go tweaking again from there.)

GekkePrutser 5y ago
This is something that is coming to traditional Linux as well though, with zfs snapshots. I've had it for a long time on FreeBSD. I just snapshot before I do something big. I see the benefit of declarative configuration as an admin at work where we need to set up many systems the same way. For home desktop use I don't really see the point, I don't think it's a tech that fits perfectly in every scenario. Like most technologies there's usecases where its benefits shine and the drawbacks are irrelevant, and others where it's the opposite. For example I often come across software that isn't packaged for my OS and I like to just compile them and try them out without having to do the whole packaging routine.
- akavel 5y ago
  As to "home use", personally I'm successfully keeping my dotfiles & $HOME/bin/ scripts managed with Nix + home-manager. Becomes useful when changing jobs, and also makes it easier to share new config tricks between work & home machine. Regardless if Linux or Mac. edit: in particular, going just Nix (not NixOS) on work machine(s) allows me to fall back to apt-get/brew quickly when a particular tool is not (yet) on Nixpkgs.
- tux1968 5y ago
  > This is something that is coming to traditional Linux as well though, with zfs snapshots. Has there been a change in ZFS licensing? I thought it was always going to remain poorly integrated into the Linux ecosystem.

alufers 5y ago

The knowledge is one thing, because you can always learn how to do things the "Nix way" (either by reading the incomplete documentation or tinkering for hours until the thing works). But the real problem is that software does not understand nix either. For example loads of scripts expect /bin/bash to exist, but on NixOS it is missing. Want to run a random python script from github? Well that's a bummer, because there is no nix version of a random library this script uses. Also no-machine server and Chrome Remote Desktop don't work, and these are the two remote desktop solutions which work on spotty 4G. And I had to ditch NixOS, because my employer forced me to use a proprietary VPN, and I there is no way it would run on NixOS.

nvarsj 5y ago
Just to say, there are always ways to deal with what you describe. For /bin/bash, create a symlink from /bin/bash to bash: system.activationScripts.binbash = '' mkdir -m 0755 -p /bin ln -sfn ${pkgs.bash}/bin/bash /bin/.bash.tmp mv /bin/.bash.tmp /bin/bash # atomically replace /bin/bash ''; For python, you're best off using a virtualenv anyways. For proprietary binaries, you can almost always get them to run using steam-run. But the nicer way is a wrapper script to set up LD_LIBRARY_PATH, or custom derivation to patch their ld lib paths. Yeah it requires some elbow grease sometimes, but what distribution doesn't? Maybe Fedora/Ubuntu? I think the pain really is all that prior Linux knowledge is non-transferable and you have to learn how to fix things in the Nix way.
- seniorivn 5y ago
  you should not create such an imperative simlink almost anything can be packages with nix in a minute or two, so any code you found out the internet would be easy to run and it will take not much more time than to simply check it's build config for malicious code, which you should do anyway
  - YuukiRey 5y ago
    Maybe if you use buildUserFHS and --impure a lot. But NodeJS applications that try to download binaries at install time or python packages with conflicting package versions definitely take more than a minute or two. Just look at the history of Anki in Nixpkgs, or the derivations for JetBrains products or Cypress or any of the other packages that took consistent effort by multiple contributors to even get them working in the first place. I think it's important to manage expectations about Nix and that includes being realistic about what's easy and simple what isn't.

huijzer 5y ago

> You have to commit to learning NixOS and understand that you are only learning NixOS, it won't help you use anything else. As a NixOS user, I did learn a lot about what is part of Linux distributions and what is part of the kernel, and how they interact. Compared to my previous Ubuntu knowledge, of course. If I would have ran Arch, I would have learned similar things.

larusso 5y ago

Same here. I still flock to the page every now and then and think about to give it yet another shot. But my main usecase is to develop software. I work with java, rust, ruby, JS and different other languages that needs custom treatment when doing things the nix way. Like writing a custom nix shell env file which deals with npm dependencies and the like to have all the glory deterministic package updates etc. I guess I will try it again at one point.

pxc 5y ago

> You have to commit to learning NixOS and understand that you are only learning NixOS, it won't help you use anything else. This is kind of true on a surface level, but NixOS experience can be super helpful for setting up other distros because it turns Nixpkgs into a repository of high quality examples and demos that are always up to date. Once you learn some basics of reading Nix code and how the NixOS module system works, the Nixpkgs repo itself becomes an excellent cross-distro resource on how to configure Linux software, much like the Arch and Gentoo wikis. I often consult Nixpkgs on how to do things in Linux for the purposes of configuring another distro or helping another user to do so! :)

mindslight 5y ago

I bounced off NixOS a few times as well. In addition to what you've said, I also didn't find it compelling because I already had a way of doing programmatic configuration and functional system management under Debian using my own scripts. So I didn't particularly see what converting everything over to NixOS configs would get me. What made NixOS stick is running up against some problems where Debian itself was ill-suited and seeing Nix's power. For example, building an image for a Raspberry Pi can be done with a handful of config lines. Changing between a cross compile and an emulated compile is also a handful of lines. This kind of power feels akin to the general lisp / functional curse where certain things become so easy they aren't even well documented because once you understand the system it's second nature. Another benefit - I've modified kernel source and I've written my own modules, but they always fell by the wayside due to the maintenance burden of a compiling a custom kernel package. With Debian, I would end up reading kernel source plenty of times to figure out what was going on, but it was effectively read only. Whereas with NixOS, adding kernel overlays is straightforward. Using what is essentially a source distribution plays to the larger philosophy of Free software.