12 ms·

My experience with NixOS

289 points by matsutsu 6y ago

dragonsh 6y ago
NixOS is good, if you found not enough documentation, try Guix and may be GuixSD. It uses guile (scheme) and has fantastic documentation. [1] Earlier Nix had additional NixOps but that too now is available with Guix deploy. I am waiting when I can run Guix within a lxd container, shepherd init still has some rough edges with LXD container init. Both are great piece of software and a new take on building OS and distribution. They are ahead of their time might take another 4-5 years before they become more mainstream. [1] https://guix.gnu.org/help/ https://guix.gnu.org/help/
- eadmund 6y ago
  How is Shepherd broken with LXC? Is it sufficient to run Guix atop another distribution, or run Guix SD in a qemu VM?
  - dragonsh 6y ago
    GuixSD does not work without making changes within a LXD container (not VM). One of the details on how to do it is in mailing list. [1] [1] https://lists.gnu.org/archive/html/help-guix/2018-10/msg00062.html https://lists.gnu.org/archive/html/help-guix/2018-10/msg0006...
- throwaway894345 6y ago
  Our organization tried Nix for many years. Most of our problems were around usability, lack of documentation (including zero docstrings or type annotations in nixpkgs), and the overt unfamiliarity of the Nix expression language (asking a whole organization to learn something that seems deliberately cryptic isn't a recipe for success), and a long tail of other things. Still, at its core Nix for package management seems like the future; I just have no confidence that they're going to iron out those issues in the next 4-5 years. Of course, none of that speaks to Guix as I haven't used it, but hopefully it's awesome and solves all of those problems.
  - lidHanteyk 6y ago
    To me, this is a success story; your organization wasn't sufficiently flexible to adopt new technologies which require rethinking the fundamentals of package management. Take this as a warning sign and re-orient your organization. I do wonder about the "deliberately cryptic" nature of Nix's expression language. It is, in fact, deliberately designed for simplicity, to be a basic syntax for a language that is purely functional and lazy but not much else ([0] p69). When folks complain about the Nix expression language, as they often do, I ask them: What would you change? How would you do it? I think that it is bad that an entire team does not have the bandwidth to learn an entirely new language, but good that the team is not willing to spend time on things which they don't think are important. [0] https://edolstra.github.io/pubs/phd-thesis.pdf https://edolstra.github.io/pubs/phd-thesis.pdf
    - rkangel 6y ago
      Do you have any evidence to support your assertion that it was an issue with an organisation rather than the technology? Not all technologies are good. Not all organisations are good. Sometimes it's one. Sometimes it's the other.
      - lidHanteyk 6y ago
        Sure. Given code which works for a lot of people, versus some organization composed of people, the fault is probably with people and not with code. This follows from the formal properties of code as mathematical objects, plus the property of probabilistically-checked proofs: If code works for a lot of people, then the code is expected to work generally with high probability. Moreover, there are lots of folks having professional success with Nix, and having consumed enough of their stories, I think that the stumbling blocks that the parent identified are faults of their organization and not of Nix in particular. To see this, first replace "Nix" with "Brand X" and note that the complaints are generic to any community-developed software which doesn't have B2B resellers. Then, consider your own experience learning Nix, and note that usability, poor documentation, and a feeling that things are deliberately cryptic are all common to learning any new tool or programming language. We can comfortably conclude that Nix did not prevent itself from being adopted by the parent's organization. Indeed, it would seem that Nix made itself extremely attractive and adoptable, else it would not have been under consideration!
- rauhl 6y ago
  Guix looks really cool. I wish that it used Lisp rather than Scheme (because IMNSHO Lisp is better-suited to this kind of system software), but that ship has sailed. It’s a real shame that rms had such a dislike of Common Lisp. The mind boggles at where the cutting edge of computing would be today had Emacs upgraded from Elisp to Common Lisp twenty or thirty years ago. Instead GNU has spent 27 years trying to turn Scheme into a sufficient systems programming language, once again illustrating the truth of Greenspun’s Tenth Law: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. I would add a corollary: this also applies to any sufficiently complicated Scheme program.
  - flavio81 6y ago
    RMS dislike of CL was purely due to personal factors: He felt cheated by the Lisp machine industry.
    - gjvc 6y ago
      Never heard this before -- quite plausible. Do you have any references out in the wider world?
- kalium-xyz 6y ago
  I don't see why you say that NixOS does not have enough documentation, a commonly cited problem is the lack of tooling rather than the lack of documentation which would be fair. NixOS has the most extensive documentation out there for any linux distribution which I've used [0] and each package is documented and contains the information of any option it offers from the nix code itself and the tooling [1]. Furthermore I do not think you can compare Guix to Nix for commercial work as Nix is LGPL [2] with the packages being MIT [3] where Guix is GPL [4] allowing for Nix derivative work to be used commercially with little restriction. I wish Guix had stayed as a guile layer for Nix and not gone off in its own direction because of the licensing ambiguity (as far as I can tell this is the reason) in Nix packages. If anyone has more insight on why this split happened or the possibility of making such layers for Nix I'm very interested in this topic. [0] https://nixos.org/learn.html https://nixos.org/learn.html [1] https://nixos.org/nixos/packages.html?channel=nixos-19.09 https://nixos.org/nixos/packages.html?channel=nixos-19.09 [2] https://github.com/NixOS/nix#license https://github.com/NixOS/nix#license [3] https://github.com/NixOS/nixpkgs/blob/master/COPYING https://github.com/NixOS/nixpkgs/blob/master/COPYING [4] https://guix.gnu.org/about/ https://guix.gnu.org/about/
  - dragonsh 6y ago
    In the blog post if you read the person complained about it, so said can give a try to Guix. I think both Nix and Guix are good, personally I like Guix being familiar with lisp and scheme feels very natural to work with Guix, with Nix need to learn new declarative syntax. Linux kernel itself is GPL, so not sure what’s the issue with Guix. Obviously Guix package repository only support libre software, but if you need to use proprietary repository try Guix-nonfree[1]. I am happy Guix and GuixSD exist. Check the gnu Guix mailing list archive both have same roots but are sufficiently different[2]. [1] https://github.com/guix-users/guix-nonfree https://github.com/guix-users/guix-nonfree [2] https://lists.gnu.org/archive/html/guix-devel/2019-09/msg00235.html https://lists.gnu.org/archive/html/guix-devel/2019-09/msg002...
    - ymse 6y ago
      The vanilla Linux kernel contains many proprietary firmware blobs, which is why GNU and Guix uses the "Linux-Libre" fork. There is a maintained nonfree Guix channel here if you don't care about such blobs or need other proprietary software: https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix
- ymse 6y ago
  GNU Guix 1.1.0 was released just hours ago, so now is a good time to try it: https://news.ycombinator.com/item?id=22877788 https://news.ycombinator.com/item?id=22877788 :-) Rumor has it that Guix will be included in a future Debian release too. It is already available in Arch, Gentoo, and OpenSUSE.
  - rudolph9 6y ago
    It’s really great that functional package managers are getting all this attention! Nix package manager can run on Arch and Gentoo and OpenSUSE also.
    - ymse 6y ago
      It's one of the things you just can't do without once you become accustomed to it. I can not imagine going back to needing root privileges just to install or try a package, or being unable to roll back to earlier revisions. I hear Nix even works on macOS too! :-)
    - mouldysammich 6y ago
      nix doesn't have a package on OpenSUSE so you need to manually instlal, guix does have one though
      - takeda 6y ago
        Nix doesn't really come with packages to be installed, you can create one though. You install it by running this installation script: https://nixos.org/nix/install https://nixos.org/nix/install It should work on any Linux and OS X.
    - slightwinder 6y ago
      How does using nix on other distributions work? Can it access their local packagemanagers and install the distribution-packages, or is it a parallel world that just happens to live on the same machine?
      - 6y ago
- downerending 6y ago
  I recently read that Guix was dropping support for the Linux kernel, but apparently that was a Apr 1 joke. Argh. https://guix.gnu.org/blog/2020/deprecating-support-for-the-linux-kernel/ https://guix.gnu.org/blog/2020/deprecating-support-for-the-l...
haolez 6y ago
Forgive me for using buzzwords, but what's the "cloud native" story on NixOS? Can I easily create containers and update my orchestrator's deployment? Can I abstract things like AWS Lambdas into this immutable build structure?
- bennofs 6y ago
  You can build docker images with Nix (https://nixos.org/nixpkgs/manual/#sec-pkgs-dockerTools https://nixos.org/nixpkgs/manual/#sec-pkgs-dockerTools), but right now it wouldn't make much sense to use the NixOS modules (like nginx) for that. The modules in NixOS assume a systemd based environment and are thus not suitable for use in containers (in the end, most service modules generated systemd units). What you can do, though, is use Nix to build a container image with an nginx config. You just can't use the abstractions present in NixOS as-is to generate the nginx config, you'd have to write the nginx config yourself (just as you would if you use a Dockerfile). You could perhaps re-use parts, or modify the NixOS modules, though.
  - slobotron 6y ago
    We are using Continix[0] to package up regular NixOS modules in docker [0] https://github.com/notgne2/continix https://github.com/notgne2/continix
- jarvuschris 6y ago
  Chef Habitat might be more what you're looking for in that regard, it very much feels like an intellectual derivative of NixOS and focuses on the cloud native story
- wyager 6y ago
  Not having used it, maybe NixOps is the thing you want.
  - haolez 6y ago
    I think it's more geared towards creating VM instances. I'm thinking about other resources as well, such as Lambdas.
golergka 6y ago
I'm yet to see a backend app architecture that both is elegant and effective from developer perspective and at the same time doesn't push her to make unneccessary database calls for each request when business logic becomes significantly complex.
- yjftsjthsd-h 6y ago
  > doesn't push her to make unneccessary database calls for each request when business logic becomes significantly complex. Are you objecting to holding all state in a database, or something else? If so, the only real alternative is to have individual servers hold state, which seems like a poor choice; one way or another you're going to hit the CAP theorem, and databases are well-optimized for getting you the best results from CAP that you're going to.
  - golergka 6y ago
    Absolutely not. On the contrary, I'm one of those developers who prefer to do things in SQL rather than application logic.
- Zinggi 6y ago
  You might be interested in lamdera. It abstracts away database access, data transport and data encoding between client end server. Here is a talk about it: https://www.youtube.com/watch?v=nSrucNcwlA8 https://www.youtube.com/watch?v=nSrucNcwlA8 If you're interested, you can probably get an invite from @supermario on the elm slack, or on: https://lamdera.app/ https://lamdera.app/ Disclaimer: I'm not affiliated with the project, but I've met Mario in person and he's a cool dude with great ideas ;)
gt565k 6y ago
We used their build system Hydra at a previous company and all of our deployments were on NixOS. Check this video out from Rob Vermaas. It's a decent case study of how Nix was applied at LogicBlox https://www.youtube.com/watch?v=nuyuA43q9NE https://www.youtube.com/watch?v=nuyuA43q9NE
exdsq 6y ago
I moved to NixOS the other week and love it. Being able to play about and roll back to previous configurations is honestly amazing once you get into a position that you need it. I tinker with my OS and this happens more often than I’d care to admit! Nix as a build tool is also quite nice, but honestly NixOS is the main attraction for me.
rudolph9 6y ago
I recently switched to NixOS and have essentially configured my OS from scratch in less than a week and now use it as my main system. The thing to remember about NixOS is it’s not a distribution of KDE or Gnome or manager of anything, it’s a declarative way of configuring those things and allows you to easily roll back changes to entire OS. It’s a little bit of investment to get started but one you get rolling it’s such a breath of fresh air to be able to manipulate your whole OS in the similar pragmatic way to you iterate code in a git repo.
- darau1 6y ago
  > manipulate your whole OS in the similar pragmatic way to you iterate code in a git repo I've been trying to do this for ages with a dotfiles repo and some git aliasing. I really want to try it out, though. Any gotchas or hidden pitfalls I should look out for?
  - ymse 6y ago
    One common beginner mistake is attempting to modify files in the immutable store directly. Don't do that. The system is read only for a reason. Also make sure you allocate enough space on your root partition so you don't have to run garbage collection all the time.
    - Shoue 6y ago
      You might want to enable automatic gc either way just so it's cleared out every now and then. https://nixos.org/nixos/options.html#nix.gc https://nixos.org/nixos/options.html#nix.gc
    - therein 6y ago
      I made the switch from Arch about a week ago. So far, great experience. I love the fact that my system state is reproducible and if I use version control on my dotfiles, I basically have a full backup of the look and feel of my workstation. VFIO with GPU passthrough works flawlessly. Setting up FDE with LUKS during and after the install was a breeze as well. Really enjoyed the whole experience. Being able to switch between wildly different possible system configurations like xorg+i3 and wayland+sway by executing a few commands and having version control while doing so is incredible. However one thing I'm struggling with now is "overlays". Simply trying to get "electrum" to install but nixpkgs has 3.3.8, I am looking to build 4.0.0a from HEAD of master. This should be simple to do with something like overlaying this portion from file electrum/default.nix [0] src = fetchurl { url = "https://download.electrum.org/${version}/Electrum-${version}.tar.gz"; sha256 = "1g00cj1pmckd4xis8r032wmraiv3vd3zc803hnyxa2bnhj8z3bg2"; }; with something like: fetchFromGitHub { owner = "spesmilo"; repo = "electrum"; sha256 = "LATESTHASH"; }; But for the life of me, I can't figure out how to do this overlay stuff. ( In fact I'd appreciate any help on this otherwise at this point I'm even jokingly considering an Arch container :) ) Python, NodeJS and Ruby development might also be slightly frustrating if you are used to installing things globally. [0] https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/misc/electrum/default.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio...
DethNinja 6y ago
Could someone summarise what is the advantage of NixOS compared to something like Ansible or Saltstack + any other Linux distribution?
- tbenst 6y ago
  I used a Ansible for years before switching to NixOS. The problem with ansible is it is an imperative configuration tool that makes efforts to be declarative, but is not fully. Most runs fail to be declarative, eg even something as basic as “apt update” is irreversible. Ultimately, Ansible requires you to write code that is (State, Code) -> New State, whereas NixOS is truly Code -> State
- jordanbeiber 6y ago
  NixPkgs amongst other things replace rpm/deb packages - and having a package install declared in a git repo is awesome compared to installing a pre-packaged compressed blob. Nixos keeps the entire system state based on a declaration and lets you move back/forward on whole system configurations super quick. Ansible and salt does not really declare a complete system state but rather try to manipulate the underlying system. Ansible keeps no state at all actually. Nixos+pkg is all about declaring and keeping a state of a machine as much as reasonably possible. It has it’s flaws but the end result is still much more coherent and predictable compared to traditional configuration management.
- takeda 6y ago
  It's similar n some way, but totally rethinking the problem. Ansible or saltstack are essentially programs that configure your system in specific way. Ansible takes more of a list of things what to change and how, while saltstack tries to be declarative. NixOS is essentially a Linux system described using Nix language. Whenever you make change and run nixos-rebuild, as name suggests it actually rebuilds your entire system from scratch, it is just smart enough to not do work that was already done. Benefits of it is that you will always get to the same state no matter what. Another benefit that is quite annoying with saltstack/ansible if you remove specific application/service/whatever once you rebuild the system, it is gone, like it was never there. You also get Nix benefits, nix never leaves anything in half state changes are atomic, either they are applied successfully or not, if a change broke something, you can easily rollback. Things like for example changing KDE to Gnome or replacing Xorg with Wayland is no harder than replacing emacs with vim (or vim with emacs, if I upset you). The way how Nix works allows different packages using even conflicting libraries. For example you can have two applications using different openssl version etc. If you have one application and you need to apply a custom patch to it or maybe even use a different version. In traditional OS good sysadmins would create a custom RPM package an install it. In Nix you just override the definition, and if a cached build is not available, Nix will be smart enough to compile the code (this means no need for artifactory and uploading custom packages there, though to prevent recompiling every time, you should set up a caching server (there's also caching as a service option if you don't want to manage it) or you can even use S3 bucket. Basically Nix and NixOS is rethinking how building/deploying/packaging does it offers many benefits, CMS like ansible/saltstack/chef/puppet/cfengine etc are no longer needed. It can be used for having comon developement environment, can be used for building, ci/cd etc.
ghuntley 6y ago
Here's my dotfiles for some of my nixos servers and home computers. https://github.com/ghuntley/dotfiles-nixos https://github.com/ghuntley/dotfiles-nixos Steal away and enjoy.
- ghuntley 6y ago
  Check out the NixOS for existing sysadmins workshop over at — https://github.com/ghuntley/workshops/tree/master/nixos-workshop https://github.com/ghuntley/workshops/tree/master/nixos-work... If you want a TL;DR overview of NixOS then start here — https://github.com/ghuntley/workshops/tree/master/nixos-workshop/modules/01-introduction-to-nixos https://github.com/ghuntley/workshops/tree/master/nixos-work... For an advanced example of overriding nixpkg and usage of pinning/override layers (ie some mandate or reason to run super old version of grpc) — https://github.com/digital-asset/daml/blob/master/nix/nixpkgs.nix#L10 https://github.com/digital-asset/daml/blob/master/nix/nixpkg...
gt565k 6y ago
There's a good write up of how Cardano, the blockchain project, uses Nix. Not surprising, given that Nix was a academic research project, and Cardano has a good network of academic researchers working to solve hard blockchain problems. https://iohk.io/en/blog/posts/2019/02/06/how-we-use-nix-at-iohk/ https://iohk.io/en/blog/posts/2019/02/06/how-we-use-nix-at-i...

289 points by matsutsu 6y ago

NixOS is good, if you found not enough documentation, try Guix and may be GuixSD. It uses guile (scheme) and has fantastic documentation. [1] Earlier Nix had additional NixOps but that too now is available with Guix deploy. I am waiting when I can run Guix within a lxd container, shepherd init still has some rough edges with LXD container init. Both are great piece of software and a new take on building OS and distribution. They are ahead of their time might take another 4-5 years before they become more mainstream. [1] https://guix.gnu.org/help/ https://guix.gnu.org/help/

eadmund 6y ago
How is Shepherd broken with LXC? Is it sufficient to run Guix atop another distribution, or run Guix SD in a qemu VM?
- dragonsh 6y ago
  GuixSD does not work without making changes within a LXD container (not VM). One of the details on how to do it is in mailing list. [1] [1] https://lists.gnu.org/archive/html/help-guix/2018-10/msg00062.html https://lists.gnu.org/archive/html/help-guix/2018-10/msg0006...
throwaway894345 6y ago
Our organization tried Nix for many years. Most of our problems were around usability, lack of documentation (including zero docstrings or type annotations in nixpkgs), and the overt unfamiliarity of the Nix expression language (asking a whole organization to learn something that seems deliberately cryptic isn't a recipe for success), and a long tail of other things. Still, at its core Nix for package management seems like the future; I just have no confidence that they're going to iron out those issues in the next 4-5 years. Of course, none of that speaks to Guix as I haven't used it, but hopefully it's awesome and solves all of those problems.
- lidHanteyk 6y ago
  To me, this is a success story; your organization wasn't sufficiently flexible to adopt new technologies which require rethinking the fundamentals of package management. Take this as a warning sign and re-orient your organization. I do wonder about the "deliberately cryptic" nature of Nix's expression language. It is, in fact, deliberately designed for simplicity, to be a basic syntax for a language that is purely functional and lazy but not much else ([0] p69). When folks complain about the Nix expression language, as they often do, I ask them: What would you change? How would you do it? I think that it is bad that an entire team does not have the bandwidth to learn an entirely new language, but good that the team is not willing to spend time on things which they don't think are important. [0] https://edolstra.github.io/pubs/phd-thesis.pdf https://edolstra.github.io/pubs/phd-thesis.pdf
  - rkangel 6y ago
    Do you have any evidence to support your assertion that it was an issue with an organisation rather than the technology? Not all technologies are good. Not all organisations are good. Sometimes it's one. Sometimes it's the other.
    - lidHanteyk 6y ago
      Sure. Given code which works for a lot of people, versus some organization composed of people, the fault is probably with people and not with code. This follows from the formal properties of code as mathematical objects, plus the property of probabilistically-checked proofs: If code works for a lot of people, then the code is expected to work generally with high probability. Moreover, there are lots of folks having professional success with Nix, and having consumed enough of their stories, I think that the stumbling blocks that the parent identified are faults of their organization and not of Nix in particular. To see this, first replace "Nix" with "Brand X" and note that the complaints are generic to any community-developed software which doesn't have B2B resellers. Then, consider your own experience learning Nix, and note that usability, poor documentation, and a feeling that things are deliberately cryptic are all common to learning any new tool or programming language. We can comfortably conclude that Nix did not prevent itself from being adopted by the parent's organization. Indeed, it would seem that Nix made itself extremely attractive and adoptable, else it would not have been under consideration!
rauhl 6y ago
Guix looks really cool. I wish that it used Lisp rather than Scheme (because IMNSHO Lisp is better-suited to this kind of system software), but that ship has sailed. It’s a real shame that rms had such a dislike of Common Lisp. The mind boggles at where the cutting edge of computing would be today had Emacs upgraded from Elisp to Common Lisp twenty or thirty years ago. Instead GNU has spent 27 years trying to turn Scheme into a sufficient systems programming language, once again illustrating the truth of Greenspun’s Tenth Law: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. I would add a corollary: this also applies to any sufficiently complicated Scheme program.
- flavio81 6y ago
  RMS dislike of CL was purely due to personal factors: He felt cheated by the Lisp machine industry.
  - gjvc 6y ago
    Never heard this before -- quite plausible. Do you have any references out in the wider world?
kalium-xyz 6y ago
I don't see why you say that NixOS does not have enough documentation, a commonly cited problem is the lack of tooling rather than the lack of documentation which would be fair. NixOS has the most extensive documentation out there for any linux distribution which I've used [0] and each package is documented and contains the information of any option it offers from the nix code itself and the tooling [1]. Furthermore I do not think you can compare Guix to Nix for commercial work as Nix is LGPL [2] with the packages being MIT [3] where Guix is GPL [4] allowing for Nix derivative work to be used commercially with little restriction. I wish Guix had stayed as a guile layer for Nix and not gone off in its own direction because of the licensing ambiguity (as far as I can tell this is the reason) in Nix packages. If anyone has more insight on why this split happened or the possibility of making such layers for Nix I'm very interested in this topic. [0] https://nixos.org/learn.html https://nixos.org/learn.html [1] https://nixos.org/nixos/packages.html?channel=nixos-19.09 https://nixos.org/nixos/packages.html?channel=nixos-19.09 [2] https://github.com/NixOS/nix#license https://github.com/NixOS/nix#license [3] https://github.com/NixOS/nixpkgs/blob/master/COPYING https://github.com/NixOS/nixpkgs/blob/master/COPYING [4] https://guix.gnu.org/about/ https://guix.gnu.org/about/
- dragonsh 6y ago
  In the blog post if you read the person complained about it, so said can give a try to Guix. I think both Nix and Guix are good, personally I like Guix being familiar with lisp and scheme feels very natural to work with Guix, with Nix need to learn new declarative syntax. Linux kernel itself is GPL, so not sure what’s the issue with Guix. Obviously Guix package repository only support libre software, but if you need to use proprietary repository try Guix-nonfree[1]. I am happy Guix and GuixSD exist. Check the gnu Guix mailing list archive both have same roots but are sufficiently different[2]. [1] https://github.com/guix-users/guix-nonfree https://github.com/guix-users/guix-nonfree [2] https://lists.gnu.org/archive/html/guix-devel/2019-09/msg00235.html https://lists.gnu.org/archive/html/guix-devel/2019-09/msg002...
  - ymse 6y ago
    The vanilla Linux kernel contains many proprietary firmware blobs, which is why GNU and Guix uses the "Linux-Libre" fork. There is a maintained nonfree Guix channel here if you don't care about such blobs or need other proprietary software: https://gitlab.com/nonguix/nonguix https://gitlab.com/nonguix/nonguix
ymse 6y ago
GNU Guix 1.1.0 was released just hours ago, so now is a good time to try it: https://news.ycombinator.com/item?id=22877788 https://news.ycombinator.com/item?id=22877788 :-) Rumor has it that Guix will be included in a future Debian release too. It is already available in Arch, Gentoo, and OpenSUSE.
- rudolph9 6y ago
  It’s really great that functional package managers are getting all this attention! Nix package manager can run on Arch and Gentoo and OpenSUSE also.
  - ymse 6y ago
    It's one of the things you just can't do without once you become accustomed to it. I can not imagine going back to needing root privileges just to install or try a package, or being unable to roll back to earlier revisions. I hear Nix even works on macOS too! :-)
  - mouldysammich 6y ago
    nix doesn't have a package on OpenSUSE so you need to manually instlal, guix does have one though
    - takeda 6y ago
      Nix doesn't really come with packages to be installed, you can create one though. You install it by running this installation script: https://nixos.org/nix/install https://nixos.org/nix/install It should work on any Linux and OS X.
  - slightwinder 6y ago
    How does using nix on other distributions work? Can it access their local packagemanagers and install the distribution-packages, or is it a parallel world that just happens to live on the same machine?
    - 6y ago
downerending 6y ago
I recently read that Guix was dropping support for the Linux kernel, but apparently that was a Apr 1 joke. Argh. https://guix.gnu.org/blog/2020/deprecating-support-for-the-linux-kernel/ https://guix.gnu.org/blog/2020/deprecating-support-for-the-l...

haolez 6y ago

Forgive me for using buzzwords, but what's the "cloud native" story on NixOS? Can I easily create containers and update my orchestrator's deployment? Can I abstract things like AWS Lambdas into this immutable build structure?

bennofs 6y ago
You can build docker images with Nix (https://nixos.org/nixpkgs/manual/#sec-pkgs-dockerTools https://nixos.org/nixpkgs/manual/#sec-pkgs-dockerTools), but right now it wouldn't make much sense to use the NixOS modules (like nginx) for that. The modules in NixOS assume a systemd based environment and are thus not suitable for use in containers (in the end, most service modules generated systemd units). What you can do, though, is use Nix to build a container image with an nginx config. You just can't use the abstractions present in NixOS as-is to generate the nginx config, you'd have to write the nginx config yourself (just as you would if you use a Dockerfile). You could perhaps re-use parts, or modify the NixOS modules, though.
- slobotron 6y ago
  We are using Continix[0] to package up regular NixOS modules in docker [0] https://github.com/notgne2/continix https://github.com/notgne2/continix
jarvuschris 6y ago
Chef Habitat might be more what you're looking for in that regard, it very much feels like an intellectual derivative of NixOS and focuses on the cloud native story
wyager 6y ago
Not having used it, maybe NixOps is the thing you want.
- haolez 6y ago
  I think it's more geared towards creating VM instances. I'm thinking about other resources as well, such as Lambdas.

golergka 6y ago

I'm yet to see a backend app architecture that both is elegant and effective from developer perspective and at the same time doesn't push her to make unneccessary database calls for each request when business logic becomes significantly complex.

yjftsjthsd-h 6y ago
> doesn't push her to make unneccessary database calls for each request when business logic becomes significantly complex. Are you objecting to holding all state in a database, or something else? If so, the only real alternative is to have individual servers hold state, which seems like a poor choice; one way or another you're going to hit the CAP theorem, and databases are well-optimized for getting you the best results from CAP that you're going to.
- golergka 6y ago
  Absolutely not. On the contrary, I'm one of those developers who prefer to do things in SQL rather than application logic.
Zinggi 6y ago
You might be interested in lamdera. It abstracts away database access, data transport and data encoding between client end server. Here is a talk about it: https://www.youtube.com/watch?v=nSrucNcwlA8 https://www.youtube.com/watch?v=nSrucNcwlA8 If you're interested, you can probably get an invite from @supermario on the elm slack, or on: https://lamdera.app/ https://lamdera.app/ Disclaimer: I'm not affiliated with the project, but I've met Mario in person and he's a cool dude with great ideas ;)

gt565k 6y ago

We used their build system Hydra at a previous company and all of our deployments were on NixOS. Check this video out from Rob Vermaas. It's a decent case study of how Nix was applied at LogicBlox https://www.youtube.com/watch?v=nuyuA43q9NE https://www.youtube.com/watch?v=nuyuA43q9NE

exdsq 6y ago

I moved to NixOS the other week and love it. Being able to play about and roll back to previous configurations is honestly amazing once you get into a position that you need it. I tinker with my OS and this happens more often than I’d care to admit! Nix as a build tool is also quite nice, but honestly NixOS is the main attraction for me.

rudolph9 6y ago

I recently switched to NixOS and have essentially configured my OS from scratch in less than a week and now use it as my main system. The thing to remember about NixOS is it’s not a distribution of KDE or Gnome or manager of anything, it’s a declarative way of configuring those things and allows you to easily roll back changes to entire OS. It’s a little bit of investment to get started but one you get rolling it’s such a breath of fresh air to be able to manipulate your whole OS in the similar pragmatic way to you iterate code in a git repo.

darau1 6y ago
> manipulate your whole OS in the similar pragmatic way to you iterate code in a git repo I've been trying to do this for ages with a dotfiles repo and some git aliasing. I really want to try it out, though. Any gotchas or hidden pitfalls I should look out for?
- ymse 6y ago
  One common beginner mistake is attempting to modify files in the immutable store directly. Don't do that. The system is read only for a reason. Also make sure you allocate enough space on your root partition so you don't have to run garbage collection all the time.
  - Shoue 6y ago
    You might want to enable automatic gc either way just so it's cleared out every now and then. https://nixos.org/nixos/options.html#nix.gc https://nixos.org/nixos/options.html#nix.gc
  - therein 6y ago
    I made the switch from Arch about a week ago. So far, great experience. I love the fact that my system state is reproducible and if I use version control on my dotfiles, I basically have a full backup of the look and feel of my workstation. VFIO with GPU passthrough works flawlessly. Setting up FDE with LUKS during and after the install was a breeze as well. Really enjoyed the whole experience. Being able to switch between wildly different possible system configurations like xorg+i3 and wayland+sway by executing a few commands and having version control while doing so is incredible. However one thing I'm struggling with now is "overlays". Simply trying to get "electrum" to install but nixpkgs has 3.3.8, I am looking to build 4.0.0a from HEAD of master. This should be simple to do with something like overlaying this portion from file electrum/default.nix [0] src = fetchurl { url = "https://download.electrum.org/${version}/Electrum-${version}.tar.gz"; sha256 = "1g00cj1pmckd4xis8r032wmraiv3vd3zc803hnyxa2bnhj8z3bg2"; }; with something like: fetchFromGitHub { owner = "spesmilo"; repo = "electrum"; sha256 = "LATESTHASH"; }; But for the life of me, I can't figure out how to do this overlay stuff. ( In fact I'd appreciate any help on this otherwise at this point I'm even jokingly considering an Arch container :) ) Python, NodeJS and Ruby development might also be slightly frustrating if you are used to installing things globally. [0] https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/misc/electrum/default.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/applicatio...

DethNinja 6y ago

Could someone summarise what is the advantage of NixOS compared to something like Ansible or Saltstack + any other Linux distribution?

tbenst 6y ago
I used a Ansible for years before switching to NixOS. The problem with ansible is it is an imperative configuration tool that makes efforts to be declarative, but is not fully. Most runs fail to be declarative, eg even something as basic as “apt update” is irreversible. Ultimately, Ansible requires you to write code that is (State, Code) -> New State, whereas NixOS is truly Code -> State
jordanbeiber 6y ago
NixPkgs amongst other things replace rpm/deb packages - and having a package install declared in a git repo is awesome compared to installing a pre-packaged compressed blob. Nixos keeps the entire system state based on a declaration and lets you move back/forward on whole system configurations super quick. Ansible and salt does not really declare a complete system state but rather try to manipulate the underlying system. Ansible keeps no state at all actually. Nixos+pkg is all about declaring and keeping a state of a machine as much as reasonably possible. It has it’s flaws but the end result is still much more coherent and predictable compared to traditional configuration management.
takeda 6y ago
It's similar n some way, but totally rethinking the problem. Ansible or saltstack are essentially programs that configure your system in specific way. Ansible takes more of a list of things what to change and how, while saltstack tries to be declarative. NixOS is essentially a Linux system described using Nix language. Whenever you make change and run nixos-rebuild, as name suggests it actually rebuilds your entire system from scratch, it is just smart enough to not do work that was already done. Benefits of it is that you will always get to the same state no matter what. Another benefit that is quite annoying with saltstack/ansible if you remove specific application/service/whatever once you rebuild the system, it is gone, like it was never there. You also get Nix benefits, nix never leaves anything in half state changes are atomic, either they are applied successfully or not, if a change broke something, you can easily rollback. Things like for example changing KDE to Gnome or replacing Xorg with Wayland is no harder than replacing emacs with vim (or vim with emacs, if I upset you). The way how Nix works allows different packages using even conflicting libraries. For example you can have two applications using different openssl version etc. If you have one application and you need to apply a custom patch to it or maybe even use a different version. In traditional OS good sysadmins would create a custom RPM package an install it. In Nix you just override the definition, and if a cached build is not available, Nix will be smart enough to compile the code (this means no need for artifactory and uploading custom packages there, though to prevent recompiling every time, you should set up a caching server (there's also caching as a service option if you don't want to manage it) or you can even use S3 bucket. Basically Nix and NixOS is rethinking how building/deploying/packaging does it offers many benefits, CMS like ansible/saltstack/chef/puppet/cfengine etc are no longer needed. It can be used for having comon developement environment, can be used for building, ci/cd etc.

ghuntley 6y ago

Here's my dotfiles for some of my nixos servers and home computers. https://github.com/ghuntley/dotfiles-nixos https://github.com/ghuntley/dotfiles-nixos Steal away and enjoy.

ghuntley 6y ago
Check out the NixOS for existing sysadmins workshop over at — https://github.com/ghuntley/workshops/tree/master/nixos-workshop https://github.com/ghuntley/workshops/tree/master/nixos-work... If you want a TL;DR overview of NixOS then start here — https://github.com/ghuntley/workshops/tree/master/nixos-workshop/modules/01-introduction-to-nixos https://github.com/ghuntley/workshops/tree/master/nixos-work... For an advanced example of overriding nixpkg and usage of pinning/override layers (ie some mandate or reason to run super old version of grpc) — https://github.com/digital-asset/daml/blob/master/nix/nixpkgs.nix#L10 https://github.com/digital-asset/daml/blob/master/nix/nixpkg...

gt565k 6y ago

There's a good write up of how Cardano, the blockchain project, uses Nix. Not surprising, given that Nix was a academic research project, and Cardano has a good network of academic researchers working to solve hard blockchain problems. https://iohk.io/en/blog/posts/2019/02/06/how-we-use-nix-at-iohk/ https://iohk.io/en/blog/posts/2019/02/06/how-we-use-nix-at-i...