23 ms·

NixOS 21.05

310 points by jiehong 5y ago

bfrog 5y ago
Time to update!
grumpyprole 5y ago
This excellent Linux distribution has the honour of not needing to recommend a clean install. It deserves to be far more popular. I've run it since 2014 with so few problems, that I can't really claim to "know" Linux anymore.
- kaba0 5y ago
  That’s my only problem with it, I will forget what this random file in /etc does or how to configure this and that because it is so simple to do decleratively and never breaks :D
  - agumonkey 5y ago
    Maybe it's like disk usage. You'll always find new stuff to brain on
- xemoka 5y ago
  I still can’t quite figure out why it’s not more popular... then again, I don’t use it either, sadly, because it’s not as popular as I feel it deserves; I feel like there must be some reason it’s not used more, so in turn haven’t dedicated the time to learn it. Perhaps that’s cyclic...
  - Filligree 5y ago
    Software that isn't already packaged is hard to use at all. Often possible -- steam-run is handy; despite the name it basically provides a Ubuntu env -- but many forms of software development are difficult-to-impossible without first learning about Nix internals. It can be a superb experience after you go through that trouble. Or it might not be. It depends on what you're trying to do, exactly, but you have to first spend a lot of effort learning before you'll have your answer. Personally, I found it worth my while.
    - gugagore 5y ago
      Could you briefly mention an example of something that is difficult/impossible without first learning about Nix internals, and allude to what kind of internals need to be learned?
      - mason55 5y ago
        For starters, the recommended way for really understanding how to setup any package or option is to read the source in nixpkgs. Depends what you mean by "Nix internals" but for me that qualifies.
      - rgoulter 5y ago
        As one example, IIRC, I can run "npm install -g" on other Linux distributions, but can't with Nixpkgs (since npm will try to install the package to the nix store). Yarn would install it to the home folder.
        0xCMP 5y ago
        Yea this can be very annoying when a package is not already in nixpkgs or it's out of date. There was a similar issue if you didn't use Python virtualenvs properly, which was an early source of frustration for me personally.
        pxc 5y ago
        Fwiw you can use `npm install -g` if you configure NPM to use your homedir for globally installed packages, as well. It's just not the default behavior.
      - kaba0 5y ago
        As another example, binary blobs are usually hard to get them to run. But steam-run (a base debian chroot, but you can even specifically build custom ones with only specific libraries available), or in the worst case just running a docker container can solve everything.
  - rkangel 5y ago
    It is great, but a bit painful to learn and get working for you. I like to use Nix to provide my development environments but that's often painful due to conflicts between the Nix approach and how the language package manager wants to work.
    - larusso 5y ago
      Yes this. I tried this a few times but always ended in me banging against some esoteric issue. For example I tried to nixify a project I had which needs ruby and node. If you think you can spin up any version of ruby you are mistaken. The project removes older versions from time to time. The wrapper to fetch the correct gems from nix to setup the nix-env had really hard problems when gems or npm packages started their own native builds. I’m a huge fan of the project and will give it a try again at one point. But I decided for now to go fully manual with arch to get a better understanding of most components involved in Linux before using the automatic that is nix.
      - _huayra_ 5y ago
        > But I decided for now to go fully manual with arch to get a better understanding of most components involved in Linux before using the automatic that is nix. I think one can do this separately, e.g. run NixOS for the host OS and then do LFS or Gentoo or Arch in a VM where you can easily blow things up and revert to a prior snapshot. Also, flakes takes care of the channels shenanigans by pinning input package versions. The hardest thing about Nix is that there is very little in the way of "beginner to intermediate" documentation. There is a huge gap between tutorials about just tweaking configuration.nix and a bit a people who have insanely abstract / modularized configs. The key insight for me was that although they sell the "it's a lazily-evaluated language" thing really hard, at the end of the day there are a few things forcing side effects: - There are certain key attributes that nix will call forceAttrs on (in the interpreter). You can think of these as the "roots" that will act as a starting point for evaluating all other attributes as needed. This is the stuff you usually see like nixosConfigurations, shell, etc. The sad part is that you really have to read the C++ source to understand this it seems. - At the "bottom", there are a bunch of things built in to write to files in the sandboxed result/ directory, but there are also these monstrous bash scripts to do a lot of the heavy lifting, e.g. the mkDerivation one. It's important to read over these scripts to understand what's being written. I've found this youtube series [0] to be a good way to figure out how to go from beginner to intermediate. [0] https://www.youtube.com/playlist?list=PL-saUBvIJzOkjAw_vOac75v-x6EzNzZq- https://www.youtube.com/playlist?list=PL-saUBvIJzOkjAw_vOac7...
  - mason55 5y ago
    IMO the biggest blocker is documentation. The best way to figure out how to do something is typically to search around in the nixpkgs/NixOS options for what you're trying to do, then go read the code. There's very little in the way of "here's a common task that new users want to do and here's the blessed way to do it." Even something that should be Nix's MAJOR selling point, like "create a single repo that configures a bunch of machines, including some NixOS and some other OS" doesn't have a recommended way to do it. Another challenge with the docs is the fact that Nix is * An OS * A package manager * A way to manage dev environments A lot of times I find someone who solves my problem but they solve it in the context of building a dev environment and I want to do it in the context of setting up an OS package. It means that even with all the good tutorials and blog posts out there, you might still have a bunch of work to do to get things to work how you want. This translates into tons & tons of opportunities for users to give up. Also, for some reason, so many examples are done in the imperative manner, and it's not always super clear how to translate them to a declarative setup. Again, just defeating the strengths of Nix and clouding the benefits. If a new user sees a bunch of examples that involve starting nix-shell and installing some dependencies it's both hard to understand the benefits and hard to translate that to a declarative setup.
    - gugagore 5y ago
      It sounds like nix provides an escape hatch [1] out of the declarative framework into something imperative, e.g. running `apt install $package`. And that seems like it would really ease adoption, since I would assume that it would allow a gradual adoption of the declarative mindset. [1] https://wiki.c2.com/?EscapeHatch https://wiki.c2.com/?EscapeHatch
      - mason55 5y ago
        IMO the escape hatch doesn't get you any real benefits. It's not like you can install packages from apt/yum/aur so you don't get access to any new software (plus nixpkgs is bigger than all those). All it does is result in confusing tutorials that hide the benefits of declarative management and make it difficult for new users who just want to get things working.
  - rgoulter 5y ago
    For the use case of developer machines, NixOS is much more friction compared to other OSs. It's not about how nice Nix stuff is when it works. It's about how much of a pain it is to get things working when things aren't nice and you don't know what to do. With other popular distributions, you can rely on being able to find a StackOverflow answer with whatever your error message is. Most other OSs and package managers are malleable enough that you can easily beat them into shape should anything go wrong. It's also usually easy enough to adapt how things are done in one Linux distribution to another, but Nix is weird and takes a long time to figure out. (Nix stuff itself being expressive enough that there's often more than one way to do things).
    - gugagore 5y ago
      > It's about how much of a pain it is to get things working when things aren't nice and you don't know what to do. Thank you for highlighting this. I love elegance, safety, reproducibility, declarative specifications, etc. But the minute I get the sense of "this philosophy is getting in the way. I am stuck, even though I know exactly what to do below this layer of abstraction", I get very annoyed. That's why I asked about "escape hatches" in a sibling comment.
      - kaba0 5y ago
        Worst case just run chroots, or docker for the rare case something really don’t want to run under Nix. But it rarely happens anymore, it has a huge ecosystem with almost everything packaged so depending on how niche is the thing you work on, it can be a really comfortable environment.
    - toastal 5y ago
      There would be less friction if say NPM and package managers like these weren't installing files in random places, assuming locations of files/binaries instead of querying, let libraries and binaries be configurable, and/or not following the XDG spec. This is probably what developers should be doing, but many can't be asked to understand Ubuntu isn't the only Linux distro.
  - mekster 5y ago
    Maybe figure out why none of the cloud providers provide Nix as their install OS image. If that happens, users will easily double and maybe more hands might fix the docs or perhaps it's a chicken egg problem but if it's the doc, it's easily solvable.
    - kevincox 5y ago
      That is easy. It is unpoplar and not compatible with popular images. The default image for a cloud provider is going to target the common use case and easiest way for a novice to get started. If you already know what you are doing you will select a custom image anyways.
    - scintill76 5y ago
      Running something like nixos-infect to convert an Ubuntu machine into NixOS is going to be a new user’s easiest part of using NixOS. After that, it’s a pretty steep learning curve (or a tutorial) to do anything interesting. I’m doubtful that deleting that first step would bring more users.
nitsky 5y ago
I recently moved my laptop, desktop, and a few servers from Arch Linux to NixOS with flakes and home-manager. It is amazing! The complete configuration for all machines is in a single git repository, I can share configuration between them, and a `flake.lock` file guarantees all machines are using the same version of everything. No more trying to remember what command I need to run to install and configure software and no more copying files from `/etc` between machines. Best of all, if I need to rebuild a computer from scratch or buy a new one, just running `nixos-install --flake myrepo#mymachine` configures everything so I can pick up right where I left off with an identical setup. I also appreciate that a lot of frequently used configuration is easy to enable. For example, to install podman, the Arch wiki details a number of files in /etc you need to edit. On NixOS, just add `podman.enable = true;` to your configuration and you're done. At this point, I think NixOS is hugely underrated and I strongly encourage anyone who is an advanced linux user to try it.
- CloselyChunky 5y ago
  Could you share a link to your repo? This setup sounds interesting. Currently I have two separate repos for NixOS and home-manager.
  - nitsky 5y ago
    https://github.com/nitsky/config https://github.com/nitsky/config
  - res0nat0r 5y ago
    I use nixpkgs on my osx laptop for most everything over homebrew these days, I've upgraded nix to 2.4, but home-manager isn't compatible. Hopefully that will change soon.
    - mekster 5y ago
      Good thing about nix package manager is that you can have same path using it on macOS and on Linux, so your shell config files are easier to maintain without if's. Linuxbrew installing at /home/linuxbrew/.linuxbrew/ is a bit of a joke too.
__jem 5y ago
I recently moved back to Arch from NixOS. I really love the idea, and the execution isn't necessarily bad, but it didn't make sense for me on the desktop. Straying off the beaten path quickly led to the sense that I was going to have to learn way more about Nix than I wanted to. I hope the documentation and community grows, because I definitely got the sense that it is the future arriving early!
- 1_player 5y ago
  The documentation and the nix language are the worst things about the project IMO. I really hope Guix succeeds because Scheme is, in my opinion, a better DSL and language than this weird, not very well documented, Haskell-like derivative. Unless you've drank the kool-aid, you have to learn a completely new operating system and way of doing things, a weird language that's lacking on documentation, and a ton of system or package-specific options that are even less documented, and requires you to spend too much time reading the source to understand what's going on and how to achieve something a little off the beaten path. Feels a bit cultish IMO, and that only the illuminated ones are able to grok it. That it's my fault I'm not prepared to do the work and see for myself why NixOS is better than any other distro.
  - e3bc54b2 5y ago
    I agree on every single point. I'd love to make GuixSD my permanent home. But, Guix is not just Nix with better language. It comes with its own baggage elsewhere. Guix repository has way wayy fewer packages. Some of the most common ones like the plasma-desktop are absent. Proprietary applications are a no-go. Even if I set up nonguix, I'm warned that that cuts off my support in official channels. As an Optimus laptop owner (because my Master's required running Cuda and pytorch) I'm simply left hanging on Guix. I understand and often appreciate Guix's stand on everything above. No. of packages is because of strong stance on bootstrapping, proprietary package unavailability is self a explanatory. But, that doesn't solve my problems, and creates few new ones. Even Debian allows using proprietary firmware blobs with some fiddling and doesn't turn people away for asking. These barriers are so much that I bit the bullet and (mostly) learned the weird Nix DSL. As much as I'd like to go for Guix, for my personal use case, it is a nonstarter.
candiddevmike 5y ago
If you currently use something like Ansible to orchestrate changes (such as failover of a PostgreSQL node), how would you do this with Nix? Do you still use Ansible, or can you use NixOps for this?
- kevincox 5y ago
  In general Nix is a huge step above Ansible for config management. They aren't even playing the same game. Ansible is an awkward syntax to generate a shell script, NixOps is a declarative deployment tool. (I wrote more about this in [1] if you are interested). However one place that NixOps doesn't handle well is state. So for example if you want to run state mutating commands such as boot read-only, kill replication, then start replication on the other node it is a bit tedious. You could do this with multiple states. For example generate the "readonly" state and deploy it, then generate the "failed over" state. However there isn't great support sequencing these types of things as far as I am aware. But also a disclaimer that I haven't actually been in the situation where I needed to manage PostgreSQL with Nix so I haven't looked too closely at the options. I would love to hear someone with experience to share what they do. [1] https://kevincox.ca/2015/12/13/nixos-managed-system/ https://kevincox.ca/2015/12/13/nixos-managed-system/
e3bc54b2 5y ago
I've been smitten by NixOS ever since I first tried it 2 years ago. Its the first carefree experience I've had with my system. As a side note, this result includes first tiny contributions of mine! That said, I really hope the community gets their stuff together on Flakes. They're designated as experimental and official document doesn't recommend them, but all the cool kids are already using them everywhere and it is fracturing the efforts and alienating newcomers.
- _huayra_ 5y ago
  I really can't believe they didn't finalize Flakes in this release. The difference between it and the "standard" way of doing things is night-and-day. these sort of "secret better ways of doing things" that are not the default really frustrate and drive away new users
  - mikepurvis 5y ago
    As another learner, I'm pretty upset about this as well. Standard install gets you nix 2.3.12 (https://nixos.org/download.html https://nixos.org/download.html), but to get flakes, you have to be on nix-2.4pre20210503_6d2553a: https://nixos.wiki/wiki/Flakes#Non-NixOS https://nixos.wiki/wiki/Flakes#Non-NixOS (And yeah, obviously all the docs are non-flake too, which leads to confusion about flake.nix vs default.nix...)
  - e3bc54b2 5y ago
    By the way things are, I doubt they'll be stable in next release either. There were some pretty fancy things in last year's NixCon so devs might just push on that. But the problem is, many many new shiny things are so comingles with flakes that they are now stuck in limbo, thanks to the one amazing feature that was showcased back in 2019 and then rotted away in implementation hell. Initial RFC was rushed, barely discussed (there are lots of comments, but very little progress, as is the way with flakes) and then simply merged as experimental akin to pushing mess under the carpet. Well the mess was useful, but now the carpet is uneven and the first timers can barely walk straight. I just want a conclusion on flakes, any conclusion would be better than this stupid silent march.
kovek 5y ago
How is managing python packages or ruby gems on NixOS? I remember the experience was not polished a few years ago.
- kevincox 5y ago
  In general it is very nice. A common method is you create a `default.nix` file in the project you are working on and use tools that manage the deps for you. For example: Rust+Cargo: https://gitlab.com/kevincox/watchlog/-/blob/22c877065f763b3d191dbea2e6ff06104e8720c3/default.nix#L8-10 https://gitlab.com/kevincox/watchlog/-/blob/22c877065f763b3d... Node+NPM: https://gitlab.com/kevincox/kevincox-web-compiler/-/blob/9faccec9f145a1815f2ab57570976fd32c5e8ccc/default.nix#L8-19 https://gitlab.com/kevincox/kevincox-web-compiler/-/blob/9fa... My only Ruby project is private but I just rolled my own with: export "GEM_HOME=$out" bundle install --jobs $NIX_BUILD_CORES Then I can set the resulting derivation as $GEM_HOME in the build step. And sorry, but I don't do much Python. For development you then use nix-shell to build the environment with all of the dependencies available. The downside is that you either need to commit the default.nix to the project, or configure it to be ignored. But the advantage is that it handles everything for you. For example you can configure native libraries such as PostgreSQL client or openssl without worrying if they are installed on your system. This means that the entire dev environment is tested in CI (assuming that you run nix-build in CI). This is also nicer than docker/VM based dev environments as it just prefixes your usual environment with the deps, so you still have your regular commands and development tools available.
  - reasonabl_human 5y ago
    Are you up for explaining these gists? We use nix extensively at work and yet I’m having trouble wrapping my head around these. Node dependencies have been a thorn in our nixification of some packages, C / C++ has come easily.
    - kevincox 5y ago
      Sure. NPM is the easy case because the package-lock.json file can easily be read by Nix and contains hashes for all of the packages. This means that simply be importing the file into Nix you can have a reproducible build. No Nix-specific maintenance required. In the linked case I use this library to manage that https://github.com/nmattia/napalm https://github.com/nmattia/napalm (in that example I use master but for production I would pin a version). It simply parses the package-lock.json, downloads the packages and uses npm to build the node_modules folder. It also provides some convenient functions for building packages with "bin" files or just linking node_modules inside a build. Note that this is more for project development. It doesn't use the "system" packages (intentionally) for Node, it fetches whatever versions you have specified from NPM. Nix will only provide the "native" stuff like Node and NPM themselves and any native libraries.
jcgoette 5y ago
Would love to see an official Docker image.
- kevincox 5y ago
  You mean https://hub.docker.com/r/nixos/nix https://hub.docker.com/r/nixos/nix?
- ris 5y ago
  There is one: https://github.com/NixOS/docker https://github.com/NixOS/docker But it's more of a Nix docker image than a NixOS one, because half of the things that NixOS gives you don't really make much sense in a docker image (systemd in a container?).
  - jcgoette 5y ago
    > it's more of a Nix docker image
jpe90 5y ago
What do experienced nix-ers tend to do when they need to use software that's not up to date or available in nixpkgs? Are you guys knowledgeable enough to package everything yourselves, or do you just use buildFHSUserEnv until someone else works out the kinks? I didn't get a chance to figure out how to do the latter, but I'm curious because I've struggled as a new user.
- reasonabl_human 5y ago
  We nixify all in-house development packages at work, it isn’t that bad once you get the hang of it, and comes with an awesome amount of ‘just works’ when integrating packages on custom devices down the road.
- pimeys 5y ago
  I fork the repo, update the package in my fork, add the fork as a flake to my inputs and test my changes. When I'm happy, I create a pull request to the main repo. I started using NixOS in all my machines last winter, and slowly decided it is for me when I understood the basics. It was a rough start for me, but I have a few decades of linux knowledge, that helped me past the starting point. You can read my config and see how to create overlays from different sources. E.g. if your fork updates vim, your overlay overwrites vim in the definition. Then referring to pkgs.vim points to your fork. See flake.nix in the repo. https://github.com/pimeys/nixos https://github.com/pimeys/nixos
  - kaba0 5y ago
    I would just add that more often than not it is as easy as changing the version string in the somePackage/default.nix file and changing the corresponding hash of the source. Of course if the build changes in the new version or it depends on some new lib it can become a bit more difficult, but with a bit of experience it is not that hard to solve.
    - pimeys 5y ago
      And to get the hash of some file you download, you can do `nix-prefetch-url https://us.download.nvidia.com/XFree86/Linux-x86_64/460.80/NVIDIA-Linux-x86_64-460.80.run https://us.download.nvidia.com/XFree86/Linux-x86_64/460.80/N...` that'll cache the file for you and give the sha256. Remember to add `--unpack` if the file is an archive.
hollerith 5y ago
I ran Nixos for a few months from Dec 25 to Mar 12 of this year. During that time there were 2 zero-day exploits published for Chrome that went unpatched for weeks on Nixos. (Specifically the package named google-chrome went unpatched.) This was on the "unstable" branch of Nixos, the branch that became the stable branch today, which is the occasion of this story on HN we are commenting on. Digression: the reason I chose the unstable branch instead of the then-stable branch (named Nixos-20.09) was that I wanted to achieve an "all-Wayland" environment as quickly as practical (and in fact all of the apps running on my machine right now and for the past few weeks talk directly to Wayland without the interposition of Xwayland). And the reason I wanted to jump ahead to an all-Wayland system is that although I knew Linux pretty well, I knew very little about X11, and I reasoned that since X11 is slowly going away anyways, I would prefer to avoid spending any time learning about it and would prefer to avoid having to get used to its quirks. (End of digression.) You cannot just install Chrome from Google's web site on Nixos: unless someone has compiled it for you, you have to compile it from source and more distressingly you have to configure the compilation extensively to have any hope of the resulting binary actually running. For example, glibc on Nixos is not in a standard location, but rather all of the files in the glibc package are under a directory with a name like /nix/store/8f9f6724fd2341d9f2bc758cf9e43830d23d37a3-glibc. Well, of course the code that compiles Chrome needs to be informed of that location and of the locations of all of the other packages it relies on, e.g., the system's libraries for drawing GUIs on the screen. This job of configuring the compilation is mostly easily done by writing something similar to a declarative build script in the Nix language, so of course that means I would've had to learn a new programming language in order to patch the zero-day exploit in Chrome before the maintainer of the google-chrome package got around to it (which I never did). Sadly, I did not have time back then in early March to install the stable version of Nixos to determine whether these zero-day exploits had remained unpatched there, too. (I did verify that the package "chromium" was at the same vulnerable version as the package "google-chrome" was.) So I guess the purpose of this comment is that there are preliminary signs (namely, the fact that nowhere was I warned that the unstable branch might have gaping security holes) that Nixos does not get as much attention from security-knowledgeable maintainers as some of the other Linux distros do -- or at least that the security attention it gets is concentrated on server use cases with desktop use cases being relatively neglected.
dividedbyzero 5y ago
If I wanted to use nixpkgs on macOS instead of my dotfiles manager (yadm) and Brewfile – I hear you can do that – would I have to expect missing software (vs. homebrew)? Just about how much pain should I expect, being completely new to NixOS?
- YuukiRey 5y ago
  I do that for my work machine which is a MacBook Pro. You still need to install most GUI apps through the normal non-Nix procedure. You also won't be able to use the Git module in home manager since that will use a version of Git that doesn't understand some MacOS specific customizations, mostly surrounding Keychain if i recall correctly. Most packages just work on MacOS but it's not a first class citizen and there are always more packages broken for Darwin than Linux. But I'll say it again, I tend to dabble in plenty of programming languages and often run software that's a bit off the beaten path and Home Manager and Nix on MacOS work 95% of the time for me.
- jdelStrother 5y ago
  There’s a couple of absent macOS-specific packages, compared to homebrew. So I have `trash` and `pngpaste` declaratively compiled-from-github in my nix config, but that's the only two I'm missing compared to brew. (That said, I never dealt much with brew-cask, so if you have a host of GUI packages from that, you may be missing more) If you're on an M1 Mac it will use x86 binaries by default, running under Rosetta. The situation is improving - I use almost all of my packages in native aarm64-darwin - but it still requires using bleeding-edge code. The learning curve has been pretty brutal, but I really like it for both managing my system-wide (well, user-wide) software, and for pinning to explicit package versions in a large ruby/javascript project.
- SkyMarshal 5y ago
  Nix has over 80k packages now, so odds are what you need is there. But you should verify everything you need is available before switching. Make a list of everything you need and search the package repository for it: https://search.nixos.org/packages https://search.nixos.org/packages
earksiinni 5y ago
Ahhhh, Nix/NixOS. The package manager/OS that I so desperately wanted to love. I stuck with Nix for about six months. I even became a package maintainer. In the end, I gave up for three reasons: 1. Documentation is really bad. It's often confusing, incomplete or just plain wrong. What drove me crazy is the extreme imprecision with which certain fundamental concepts are referred to. For example, "derivations" are among the basic building blocks of Nix's package management system, yet I counted at least three unrelated ways in which they're referred to within different parts of the documentation. There were also many times when the only way to solve routine problems was to get in contact with Nix's developers. 2. I never appreciated how much package management is intertwined with individual ecosystems' cultures until I tried using a "universal" package manager like Nix. Take Node packages. The norm is to install in a project's node_packages directory, and many packages rely on that idiom just to function (e.g., hardwired to import modules with that particular directory structure in mind). Nix attempts to translate each ecosystem's idioms into its own system by introducing many helper functions (all written in the Nix language, very few of which are documented) for each ecosystem. The problem is more fundamental than the fact that this approach is only partially successful and many packages remain subtly broken. The real problem is that there's no unified meta-approach or design language to rationalize how each ecosystem's idiosyncrasies are assimilated. The API's for each ecosystem's Nix helper functions are totally different. You end up as a "Nix Node package developer" just to do your job as a web developer, and then a "Nix Python package developer" just to add a Python package, and so on. 3. The developers don't seem to have any interest in solving these UX problems. They are quick to respond and welcoming people, but the impression I was left with is that they're mostly academics or just interested in whatever subsystem they're working on. For example, when I was working on Nix, the canonical mechanism for updating a single Node package in the Nix repository was to run a script that updated all (yes, all) Node packages in the repo. When I pointed out all the ways that this was an impractical approach, the response was that it's actually a good thing because that way the Node packages in the repo don't get get stale (!) This was one of a few examples I encountered where the devs didn't seem to be aware of how unusable Nix was in real world cases. My mini-review is from the perspective of someone who was willing to put in the time to jump through all the hoops. I've left out obvious issues that would be a showstopper for many (e.g., obscurity of the Nix language, poor support on macOS). The issues that I've listed are "fit and finish" issues that at a glance may appear superficial, but having worked in the community for a while, I came to believe are more fundamental. They're about governance and what the community wants from the project. I don't believe that their goals are aligned with those of most devs who probably want a system that solves one of the biggest pains in tooling, package management. It's a pity because Nix's design is really ingenious. Making a "functional" package manager in and of itself is a huge achievement. What I didn't appreciate when I started using Nix is how it normalizes the act of programming your package manager. It's like shifting from Heroku to CloudFront except with much worse docs. The idea is brilliant, the promise is there, but the team doesn't seem interested in turning the whole package from a project into a cohesive product.
deckard1 5y ago
I must admit, I'm curious about the idea but I don't yet "get" it. Reproducible builds sound like a great idea at first, but this has the same problem as Docker containers: you inadvertently become a package/distro maintainer. How does one update the system regularly with security updates? Are we locking by semver somehow (like node, etc.)? And who decides which version ranges to lock to, etc. etc.? Honestly, I'd probably much rather just take an existing Debian/Redhat/etc. LTS distro and do a custom install script, which isn't that hard in the first place. And, in case of cloud server environments, you can just take a snapshot of your VM with a simple click of a button. You can't get much more reproducible than an actual snapshot of your entire system.
- kaba0 5y ago
  Usually you have a declarative package/system config file that is seldom changes and you point it to a nixpkgs repository, which has definitions for other packages. So an update is as easy as changing that repo to a newer/modified branch. Of course you can even depend on multiple such repos, or override them in any way so you can use a specific lib with an older shared library while use everything else with the latest. As for versioning, it is hash-based. Packages specify a source (eg github repo and a specific commit) and the hash of the downloaded source files, and build instructions inside the nixpkgs repo. The resulting program will depend on each listed property. And since they are referenced by hash, a program can use any possible version of another program. Hope it answers your questions!
- Mic92 5y ago
  Within a release there are no version bumps, only if you live on unstable or switch to a new release you would get them. The problem of an actual snapshot of your entire system is that you don't really now what should be in there and it collects a lot of cruft/state. With NixOS you can write little modules for services and move those between VM/Machines, whatever floats your boat. IMHO this type of config management sucks less than ansible/chef etc because you are not fighting against the package manager. The configuration holds the ground truth on what is installed on the system.
- takeda 5y ago
  It's like an OS that has builtin salt/ansible/chef/puppet. Because Nix language describe the OS instead of what to change/configure it's superior to these tools, and solves the problem that supposedly same machines are drifting apart. For example if in the CM you tell it to install a package, then change your mind and remove the entry that does it. The package will remain installed. With NixOS if you remove the package from configuration, it's gone. I personally really like Nix's building capability. For example I can use it to generate a minimal docker container. It requires some knowledge, but I can also modify compilation options in dependencies (like remove unneeded functionality). It looks like there's also an option to similarly build lightweight OS images[1]. I haven't tried it yet but looks cool. [1] https://github.com/cleverca22/not-os https://github.com/cleverca22/not-os
pxc 5y ago
A teeny-tiny orientation for (prospective?) Nix newcomers: Having spent years on Arch and Gentoo, imo the NixOS community is outstanding even among 'advanced' Linux distros in terms of expertise and kindness. I'll never forget one time I was having problems with a Python package generation tool and when I mentioned it on IRC, and one of its authors (Rok Garbas, who is so quite active in the community) just hopped on a call to debug the issue I was having right then and there. If you're on the fence about Nix and that kind of community is valuable to you, make sure to check out the forums [1] and realtime chat [2] (the latter of which is unfortunately still in the process [3] of migrating away from Freenode). If personal assistance/mentorship of the kind I described at the beginning of this post is appealing to you, several generous and knowledgeable community members host Nix ‘office hours’ [4]. I'm not sure who all are still running them, but I know tomberek is for sure [5] and you can find a link in the footnotes. There is one serious problem with NixOS and the wider ecosystem right now, namely that the best experience available depends on Nix features that are unreleased. Nix makes it very easy to run bleeding edge builds of Nix and enable these features, but the unofficial status of it all has slowed adoption, integration, and documentation of these tools in the wider community. That aside— i.e., if you're willing to be a little bit of a pioneer— the community is on the whole pretty rich with good documentation of everything but the bleeding edge, unreleased bits at this point. Those pieces mostly impact the CLI and specifying inputs to the expressions you use to define your system. Everything in the NixOS and Nixpkgs manuals is still accurate. The unreleased components are also fairly mature despite their unofficial status: many folks in the community have been using them for a year or two now. Finally: if you're interested in dipping your toes in without committing to a system fully managed by Nix and you're a macOS user, nix-darwin [6] provides a pretty NixOS-like experience using a module system and CLI based on NixOS'. There's nothing equally complete in terms of managing system services in a declarative fashion on non-NixOS Linux, but home-manager [7] provides some functionality for enabling user-mode services in a declarative style. You can check whether your favorite software is packaged for Nix here [8], and additionally NixOS does support several other forms of cross-distro packaging/deployment, including Flatpak, AppImage, and Docker. Steam support is native and works without much fuss, too. --------- 1: https://discourse.nixos.org/ https://discourse.nixos.org/ 2: https://matrix.to/#/!MKvhXlSTLGJUXpYuWF:nixos.org https://matrix.to/#/!MKvhXlSTLGJUXpYuWF:nixos.org 3: https://github.com/NixOS/rfcs/pull/94 https://github.com/NixOS/rfcs/pull/94 4: https://discourse.nixos.org/search?q=office%20hours https://discourse.nixos.org/search?q=office%20hours 5: https://discourse.nixos.org/t/nix-office-hours/11945 https://discourse.nixos.org/t/nix-office-hours/11945 6: https://github.com/LnL7/nix-darwin https://github.com/LnL7/nix-darwin 7: https://github.com/nix-community/home-manager https://github.com/nix-community/home-manager 8: https://search.nixos.org/packages https://search.nixos.org/packages
mrobot 5y ago
I found the nix pills to be a good starting point for learning about how to use nixpkgs/nixos https://nixos.org/guides/nix-pills/index.html https://nixos.org/guides/nix-pills/index.html
nuker 5y ago
I tried. I stopped at ‘pip install whatever’ in nix.
- seniorivn 5y ago
  did you stop at trying linux at launching whatever.exe file as well?
balves 5y ago
What are people's thoughts on running nix without nixos, using a base system such as Debian or Arch? It seems like it might be a nice way to get reproducible dev environments, without some of the headaches being discussed here. Is this a common use, or do people typically just do all-or-nothing?
- joepie91_ 5y ago
  That's how I started out with openSUSE + Nix, but I quickly found that I still had to learn about most of Nix's quirks, while only getting a small part of the benefits (namely, not the system configuration). It may be worth it if you care a lot about having imperative escape hatches, but if you're willing to invest upfront work in getting past the learning curve and want to maximize the benefit you get from it, I would just recommend diving into NixOS directly.
- danieldk 5y ago
  I would say that it is a good gateway drug. I used Nix + home-manager on macOS for a while. It was really nice for replacing the broken macOS userland plus having reproducible dev environments. I liked it so much that I tried NixOS on a Dell Workstation that I still had. Configuring a full machine declaratively was so powerful that I slowly moved from macOS to NixOS pretty much full-time.

310 points by jiehong 5y ago

Time to update!

This excellent Linux distribution has the honour of not needing to recommend a clean install. It deserves to be far more popular. I've run it since 2014 with so few problems, that I can't really claim to "know" Linux anymore.

kaba0 5y ago
That’s my only problem with it, I will forget what this random file in /etc does or how to configure this and that because it is so simple to do decleratively and never breaks :D
- agumonkey 5y ago
  Maybe it's like disk usage. You'll always find new stuff to brain on
xemoka 5y ago
I still can’t quite figure out why it’s not more popular... then again, I don’t use it either, sadly, because it’s not as popular as I feel it deserves; I feel like there must be some reason it’s not used more, so in turn haven’t dedicated the time to learn it. Perhaps that’s cyclic...
- Filligree 5y ago
  Software that isn't already packaged is hard to use at all. Often possible -- steam-run is handy; despite the name it basically provides a Ubuntu env -- but many forms of software development are difficult-to-impossible without first learning about Nix internals. It can be a superb experience after you go through that trouble. Or it might not be. It depends on what you're trying to do, exactly, but you have to first spend a lot of effort learning before you'll have your answer. Personally, I found it worth my while.
  - gugagore 5y ago
    Could you briefly mention an example of something that is difficult/impossible without first learning about Nix internals, and allude to what kind of internals need to be learned?
    - mason55 5y ago
      For starters, the recommended way for really understanding how to setup any package or option is to read the source in nixpkgs. Depends what you mean by "Nix internals" but for me that qualifies.
    - rgoulter 5y ago
      As one example, IIRC, I can run "npm install -g" on other Linux distributions, but can't with Nixpkgs (since npm will try to install the package to the nix store). Yarn would install it to the home folder.
      - 0xCMP 5y ago
        Yea this can be very annoying when a package is not already in nixpkgs or it's out of date. There was a similar issue if you didn't use Python virtualenvs properly, which was an early source of frustration for me personally.
      - pxc 5y ago
        Fwiw you can use `npm install -g` if you configure NPM to use your homedir for globally installed packages, as well. It's just not the default behavior.
    - kaba0 5y ago
      As another example, binary blobs are usually hard to get them to run. But steam-run (a base debian chroot, but you can even specifically build custom ones with only specific libraries available), or in the worst case just running a docker container can solve everything.
- rkangel 5y ago
  It is great, but a bit painful to learn and get working for you. I like to use Nix to provide my development environments but that's often painful due to conflicts between the Nix approach and how the language package manager wants to work.
  - larusso 5y ago
    Yes this. I tried this a few times but always ended in me banging against some esoteric issue. For example I tried to nixify a project I had which needs ruby and node. If you think you can spin up any version of ruby you are mistaken. The project removes older versions from time to time. The wrapper to fetch the correct gems from nix to setup the nix-env had really hard problems when gems or npm packages started their own native builds. I’m a huge fan of the project and will give it a try again at one point. But I decided for now to go fully manual with arch to get a better understanding of most components involved in Linux before using the automatic that is nix.
    - _huayra_ 5y ago
      > But I decided for now to go fully manual with arch to get a better understanding of most components involved in Linux before using the automatic that is nix. I think one can do this separately, e.g. run NixOS for the host OS and then do LFS or Gentoo or Arch in a VM where you can easily blow things up and revert to a prior snapshot. Also, flakes takes care of the channels shenanigans by pinning input package versions. The hardest thing about Nix is that there is very little in the way of "beginner to intermediate" documentation. There is a huge gap between tutorials about just tweaking configuration.nix and a bit a people who have insanely abstract / modularized configs. The key insight for me was that although they sell the "it's a lazily-evaluated language" thing really hard, at the end of the day there are a few things forcing side effects: - There are certain key attributes that nix will call forceAttrs on (in the interpreter). You can think of these as the "roots" that will act as a starting point for evaluating all other attributes as needed. This is the stuff you usually see like nixosConfigurations, shell, etc. The sad part is that you really have to read the C++ source to understand this it seems. - At the "bottom", there are a bunch of things built in to write to files in the sandboxed result/ directory, but there are also these monstrous bash scripts to do a lot of the heavy lifting, e.g. the mkDerivation one. It's important to read over these scripts to understand what's being written. I've found this youtube series [0] to be a good way to figure out how to go from beginner to intermediate. [0] https://www.youtube.com/playlist?list=PL-saUBvIJzOkjAw_vOac75v-x6EzNzZq- https://www.youtube.com/playlist?list=PL-saUBvIJzOkjAw_vOac7...
- mason55 5y ago
  IMO the biggest blocker is documentation. The best way to figure out how to do something is typically to search around in the nixpkgs/NixOS options for what you're trying to do, then go read the code. There's very little in the way of "here's a common task that new users want to do and here's the blessed way to do it." Even something that should be Nix's MAJOR selling point, like "create a single repo that configures a bunch of machines, including some NixOS and some other OS" doesn't have a recommended way to do it. Another challenge with the docs is the fact that Nix is * An OS * A package manager * A way to manage dev environments A lot of times I find someone who solves my problem but they solve it in the context of building a dev environment and I want to do it in the context of setting up an OS package. It means that even with all the good tutorials and blog posts out there, you might still have a bunch of work to do to get things to work how you want. This translates into tons & tons of opportunities for users to give up. Also, for some reason, so many examples are done in the imperative manner, and it's not always super clear how to translate them to a declarative setup. Again, just defeating the strengths of Nix and clouding the benefits. If a new user sees a bunch of examples that involve starting nix-shell and installing some dependencies it's both hard to understand the benefits and hard to translate that to a declarative setup.
  - gugagore 5y ago
    It sounds like nix provides an escape hatch [1] out of the declarative framework into something imperative, e.g. running `apt install $package`. And that seems like it would really ease adoption, since I would assume that it would allow a gradual adoption of the declarative mindset. [1] https://wiki.c2.com/?EscapeHatch https://wiki.c2.com/?EscapeHatch
    - mason55 5y ago
      IMO the escape hatch doesn't get you any real benefits. It's not like you can install packages from apt/yum/aur so you don't get access to any new software (plus nixpkgs is bigger than all those). All it does is result in confusing tutorials that hide the benefits of declarative management and make it difficult for new users who just want to get things working.
- rgoulter 5y ago
  For the use case of developer machines, NixOS is much more friction compared to other OSs. It's not about how nice Nix stuff is when it works. It's about how much of a pain it is to get things working when things aren't nice and you don't know what to do. With other popular distributions, you can rely on being able to find a StackOverflow answer with whatever your error message is. Most other OSs and package managers are malleable enough that you can easily beat them into shape should anything go wrong. It's also usually easy enough to adapt how things are done in one Linux distribution to another, but Nix is weird and takes a long time to figure out. (Nix stuff itself being expressive enough that there's often more than one way to do things).
  - gugagore 5y ago
    > It's about how much of a pain it is to get things working when things aren't nice and you don't know what to do. Thank you for highlighting this. I love elegance, safety, reproducibility, declarative specifications, etc. But the minute I get the sense of "this philosophy is getting in the way. I am stuck, even though I know exactly what to do below this layer of abstraction", I get very annoyed. That's why I asked about "escape hatches" in a sibling comment.
    - kaba0 5y ago
      Worst case just run chroots, or docker for the rare case something really don’t want to run under Nix. But it rarely happens anymore, it has a huge ecosystem with almost everything packaged so depending on how niche is the thing you work on, it can be a really comfortable environment.
  - toastal 5y ago
    There would be less friction if say NPM and package managers like these weren't installing files in random places, assuming locations of files/binaries instead of querying, let libraries and binaries be configurable, and/or not following the XDG spec. This is probably what developers should be doing, but many can't be asked to understand Ubuntu isn't the only Linux distro.
- mekster 5y ago
  Maybe figure out why none of the cloud providers provide Nix as their install OS image. If that happens, users will easily double and maybe more hands might fix the docs or perhaps it's a chicken egg problem but if it's the doc, it's easily solvable.
  - kevincox 5y ago
    That is easy. It is unpoplar and not compatible with popular images. The default image for a cloud provider is going to target the common use case and easiest way for a novice to get started. If you already know what you are doing you will select a custom image anyways.
  - scintill76 5y ago
    Running something like nixos-infect to convert an Ubuntu machine into NixOS is going to be a new user’s easiest part of using NixOS. After that, it’s a pretty steep learning curve (or a tutorial) to do anything interesting. I’m doubtful that deleting that first step would bring more users.

nitsky 5y ago

I recently moved my laptop, desktop, and a few servers from Arch Linux to NixOS with flakes and home-manager. It is amazing! The complete configuration for all machines is in a single git repository, I can share configuration between them, and a `flake.lock` file guarantees all machines are using the same version of everything. No more trying to remember what command I need to run to install and configure software and no more copying files from `/etc` between machines. Best of all, if I need to rebuild a computer from scratch or buy a new one, just running `nixos-install --flake myrepo#mymachine` configures everything so I can pick up right where I left off with an identical setup. I also appreciate that a lot of frequently used configuration is easy to enable. For example, to install podman, the Arch wiki details a number of files in /etc you need to edit. On NixOS, just add `podman.enable = true;` to your configuration and you're done. At this point, I think NixOS is hugely underrated and I strongly encourage anyone who is an advanced linux user to try it.

CloselyChunky 5y ago
Could you share a link to your repo? This setup sounds interesting. Currently I have two separate repos for NixOS and home-manager.
- nitsky 5y ago
  https://github.com/nitsky/config https://github.com/nitsky/config
- res0nat0r 5y ago
  I use nixpkgs on my osx laptop for most everything over homebrew these days, I've upgraded nix to 2.4, but home-manager isn't compatible. Hopefully that will change soon.
  - mekster 5y ago
    Good thing about nix package manager is that you can have same path using it on macOS and on Linux, so your shell config files are easier to maintain without if's. Linuxbrew installing at /home/linuxbrew/.linuxbrew/ is a bit of a joke too.

__jem 5y ago

I recently moved back to Arch from NixOS. I really love the idea, and the execution isn't necessarily bad, but it didn't make sense for me on the desktop. Straying off the beaten path quickly led to the sense that I was going to have to learn way more about Nix than I wanted to. I hope the documentation and community grows, because I definitely got the sense that it is the future arriving early!

1_player 5y ago
The documentation and the nix language are the worst things about the project IMO. I really hope Guix succeeds because Scheme is, in my opinion, a better DSL and language than this weird, not very well documented, Haskell-like derivative. Unless you've drank the kool-aid, you have to learn a completely new operating system and way of doing things, a weird language that's lacking on documentation, and a ton of system or package-specific options that are even less documented, and requires you to spend too much time reading the source to understand what's going on and how to achieve something a little off the beaten path. Feels a bit cultish IMO, and that only the illuminated ones are able to grok it. That it's my fault I'm not prepared to do the work and see for myself why NixOS is better than any other distro.
- e3bc54b2 5y ago
  I agree on every single point. I'd love to make GuixSD my permanent home. But, Guix is not just Nix with better language. It comes with its own baggage elsewhere. Guix repository has way wayy fewer packages. Some of the most common ones like the plasma-desktop are absent. Proprietary applications are a no-go. Even if I set up nonguix, I'm warned that that cuts off my support in official channels. As an Optimus laptop owner (because my Master's required running Cuda and pytorch) I'm simply left hanging on Guix. I understand and often appreciate Guix's stand on everything above. No. of packages is because of strong stance on bootstrapping, proprietary package unavailability is self a explanatory. But, that doesn't solve my problems, and creates few new ones. Even Debian allows using proprietary firmware blobs with some fiddling and doesn't turn people away for asking. These barriers are so much that I bit the bullet and (mostly) learned the weird Nix DSL. As much as I'd like to go for Guix, for my personal use case, it is a nonstarter.

candiddevmike 5y ago

If you currently use something like Ansible to orchestrate changes (such as failover of a PostgreSQL node), how would you do this with Nix? Do you still use Ansible, or can you use NixOps for this?

kevincox 5y ago
In general Nix is a huge step above Ansible for config management. They aren't even playing the same game. Ansible is an awkward syntax to generate a shell script, NixOps is a declarative deployment tool. (I wrote more about this in [1] if you are interested). However one place that NixOps doesn't handle well is state. So for example if you want to run state mutating commands such as boot read-only, kill replication, then start replication on the other node it is a bit tedious. You could do this with multiple states. For example generate the "readonly" state and deploy it, then generate the "failed over" state. However there isn't great support sequencing these types of things as far as I am aware. But also a disclaimer that I haven't actually been in the situation where I needed to manage PostgreSQL with Nix so I haven't looked too closely at the options. I would love to hear someone with experience to share what they do. [1] https://kevincox.ca/2015/12/13/nixos-managed-system/ https://kevincox.ca/2015/12/13/nixos-managed-system/

e3bc54b2 5y ago

I've been smitten by NixOS ever since I first tried it 2 years ago. Its the first carefree experience I've had with my system. As a side note, this result includes first tiny contributions of mine! That said, I really hope the community gets their stuff together on Flakes. They're designated as experimental and official document doesn't recommend them, but all the cool kids are already using them everywhere and it is fracturing the efforts and alienating newcomers.

_huayra_ 5y ago
I really can't believe they didn't finalize Flakes in this release. The difference between it and the "standard" way of doing things is night-and-day. these sort of "secret better ways of doing things" that are not the default really frustrate and drive away new users
- mikepurvis 5y ago
  As another learner, I'm pretty upset about this as well. Standard install gets you nix 2.3.12 (https://nixos.org/download.html https://nixos.org/download.html), but to get flakes, you have to be on nix-2.4pre20210503_6d2553a: https://nixos.wiki/wiki/Flakes#Non-NixOS https://nixos.wiki/wiki/Flakes#Non-NixOS (And yeah, obviously all the docs are non-flake too, which leads to confusion about flake.nix vs default.nix...)
- e3bc54b2 5y ago
  By the way things are, I doubt they'll be stable in next release either. There were some pretty fancy things in last year's NixCon so devs might just push on that. But the problem is, many many new shiny things are so comingles with flakes that they are now stuck in limbo, thanks to the one amazing feature that was showcased back in 2019 and then rotted away in implementation hell. Initial RFC was rushed, barely discussed (there are lots of comments, but very little progress, as is the way with flakes) and then simply merged as experimental akin to pushing mess under the carpet. Well the mess was useful, but now the carpet is uneven and the first timers can barely walk straight. I just want a conclusion on flakes, any conclusion would be better than this stupid silent march.

kovek 5y ago

How is managing python packages or ruby gems on NixOS? I remember the experience was not polished a few years ago.

kevincox 5y ago
In general it is very nice. A common method is you create a `default.nix` file in the project you are working on and use tools that manage the deps for you. For example: Rust+Cargo: https://gitlab.com/kevincox/watchlog/-/blob/22c877065f763b3d191dbea2e6ff06104e8720c3/default.nix#L8-10 https://gitlab.com/kevincox/watchlog/-/blob/22c877065f763b3d... Node+NPM: https://gitlab.com/kevincox/kevincox-web-compiler/-/blob/9faccec9f145a1815f2ab57570976fd32c5e8ccc/default.nix#L8-19 https://gitlab.com/kevincox/kevincox-web-compiler/-/blob/9fa... My only Ruby project is private but I just rolled my own with: export "GEM_HOME=$out" bundle install --jobs $NIX_BUILD_CORES Then I can set the resulting derivation as $GEM_HOME in the build step. And sorry, but I don't do much Python. For development you then use nix-shell to build the environment with all of the dependencies available. The downside is that you either need to commit the default.nix to the project, or configure it to be ignored. But the advantage is that it handles everything for you. For example you can configure native libraries such as PostgreSQL client or openssl without worrying if they are installed on your system. This means that the entire dev environment is tested in CI (assuming that you run nix-build in CI). This is also nicer than docker/VM based dev environments as it just prefixes your usual environment with the deps, so you still have your regular commands and development tools available.
- reasonabl_human 5y ago
  Are you up for explaining these gists? We use nix extensively at work and yet I’m having trouble wrapping my head around these. Node dependencies have been a thorn in our nixification of some packages, C / C++ has come easily.
  - kevincox 5y ago
    Sure. NPM is the easy case because the package-lock.json file can easily be read by Nix and contains hashes for all of the packages. This means that simply be importing the file into Nix you can have a reproducible build. No Nix-specific maintenance required. In the linked case I use this library to manage that https://github.com/nmattia/napalm https://github.com/nmattia/napalm (in that example I use master but for production I would pin a version). It simply parses the package-lock.json, downloads the packages and uses npm to build the node_modules folder. It also provides some convenient functions for building packages with "bin" files or just linking node_modules inside a build. Note that this is more for project development. It doesn't use the "system" packages (intentionally) for Node, it fetches whatever versions you have specified from NPM. Nix will only provide the "native" stuff like Node and NPM themselves and any native libraries.

jcgoette 5y ago

Would love to see an official Docker image.

kevincox 5y ago
You mean https://hub.docker.com/r/nixos/nix https://hub.docker.com/r/nixos/nix?
ris 5y ago
There is one: https://github.com/NixOS/docker https://github.com/NixOS/docker But it's more of a Nix docker image than a NixOS one, because half of the things that NixOS gives you don't really make much sense in a docker image (systemd in a container?).
- jcgoette 5y ago
  > it's more of a Nix docker image

jpe90 5y ago

What do experienced nix-ers tend to do when they need to use software that's not up to date or available in nixpkgs? Are you guys knowledgeable enough to package everything yourselves, or do you just use buildFHSUserEnv until someone else works out the kinks? I didn't get a chance to figure out how to do the latter, but I'm curious because I've struggled as a new user.

reasonabl_human 5y ago
We nixify all in-house development packages at work, it isn’t that bad once you get the hang of it, and comes with an awesome amount of ‘just works’ when integrating packages on custom devices down the road.
pimeys 5y ago
I fork the repo, update the package in my fork, add the fork as a flake to my inputs and test my changes. When I'm happy, I create a pull request to the main repo. I started using NixOS in all my machines last winter, and slowly decided it is for me when I understood the basics. It was a rough start for me, but I have a few decades of linux knowledge, that helped me past the starting point. You can read my config and see how to create overlays from different sources. E.g. if your fork updates vim, your overlay overwrites vim in the definition. Then referring to pkgs.vim points to your fork. See flake.nix in the repo. https://github.com/pimeys/nixos https://github.com/pimeys/nixos
- kaba0 5y ago
  I would just add that more often than not it is as easy as changing the version string in the somePackage/default.nix file and changing the corresponding hash of the source. Of course if the build changes in the new version or it depends on some new lib it can become a bit more difficult, but with a bit of experience it is not that hard to solve.
  - pimeys 5y ago
    And to get the hash of some file you download, you can do `nix-prefetch-url https://us.download.nvidia.com/XFree86/Linux-x86_64/460.80/NVIDIA-Linux-x86_64-460.80.run https://us.download.nvidia.com/XFree86/Linux-x86_64/460.80/N...` that'll cache the file for you and give the sha256. Remember to add `--unpack` if the file is an archive.

hollerith 5y ago

I ran Nixos for a few months from Dec 25 to Mar 12 of this year. During that time there were 2 zero-day exploits published for Chrome that went unpatched for weeks on Nixos. (Specifically the package named google-chrome went unpatched.) This was on the "unstable" branch of Nixos, the branch that became the stable branch today, which is the occasion of this story on HN we are commenting on. Digression: the reason I chose the unstable branch instead of the then-stable branch (named Nixos-20.09) was that I wanted to achieve an "all-Wayland" environment as quickly as practical (and in fact all of the apps running on my machine right now and for the past few weeks talk directly to Wayland without the interposition of Xwayland). And the reason I wanted to jump ahead to an all-Wayland system is that although I knew Linux pretty well, I knew very little about X11, and I reasoned that since X11 is slowly going away anyways, I would prefer to avoid spending any time learning about it and would prefer to avoid having to get used to its quirks. (End of digression.) You cannot just install Chrome from Google's web site on Nixos: unless someone has compiled it for you, you have to compile it from source and more distressingly you have to configure the compilation extensively to have any hope of the resulting binary actually running. For example, glibc on Nixos is not in a standard location, but rather all of the files in the glibc package are under a directory with a name like /nix/store/8f9f6724fd2341d9f2bc758cf9e43830d23d37a3-glibc. Well, of course the code that compiles Chrome needs to be informed of that location and of the locations of all of the other packages it relies on, e.g., the system's libraries for drawing GUIs on the screen. This job of configuring the compilation is mostly easily done by writing something similar to a declarative build script in the Nix language, so of course that means I would've had to learn a new programming language in order to patch the zero-day exploit in Chrome before the maintainer of the google-chrome package got around to it (which I never did). Sadly, I did not have time back then in early March to install the stable version of Nixos to determine whether these zero-day exploits had remained unpatched there, too. (I did verify that the package "chromium" was at the same vulnerable version as the package "google-chrome" was.) So I guess the purpose of this comment is that there are preliminary signs (namely, the fact that nowhere was I warned that the unstable branch might have gaping security holes) that Nixos does not get as much attention from security-knowledgeable maintainers as some of the other Linux distros do -- or at least that the security attention it gets is concentrated on server use cases with desktop use cases being relatively neglected.

dividedbyzero 5y ago

If I wanted to use nixpkgs on macOS instead of my dotfiles manager (yadm) and Brewfile – I hear you can do that – would I have to expect missing software (vs. homebrew)? Just about how much pain should I expect, being completely new to NixOS?

YuukiRey 5y ago
I do that for my work machine which is a MacBook Pro. You still need to install most GUI apps through the normal non-Nix procedure. You also won't be able to use the Git module in home manager since that will use a version of Git that doesn't understand some MacOS specific customizations, mostly surrounding Keychain if i recall correctly. Most packages just work on MacOS but it's not a first class citizen and there are always more packages broken for Darwin than Linux. But I'll say it again, I tend to dabble in plenty of programming languages and often run software that's a bit off the beaten path and Home Manager and Nix on MacOS work 95% of the time for me.
jdelStrother 5y ago
There’s a couple of absent macOS-specific packages, compared to homebrew. So I have `trash` and `pngpaste` declaratively compiled-from-github in my nix config, but that's the only two I'm missing compared to brew. (That said, I never dealt much with brew-cask, so if you have a host of GUI packages from that, you may be missing more) If you're on an M1 Mac it will use x86 binaries by default, running under Rosetta. The situation is improving - I use almost all of my packages in native aarm64-darwin - but it still requires using bleeding-edge code. The learning curve has been pretty brutal, but I really like it for both managing my system-wide (well, user-wide) software, and for pinning to explicit package versions in a large ruby/javascript project.
SkyMarshal 5y ago
Nix has over 80k packages now, so odds are what you need is there. But you should verify everything you need is available before switching. Make a list of everything you need and search the package repository for it: https://search.nixos.org/packages https://search.nixos.org/packages

earksiinni 5y ago

Ahhhh, Nix/NixOS. The package manager/OS that I so desperately wanted to love. I stuck with Nix for about six months. I even became a package maintainer. In the end, I gave up for three reasons: 1. Documentation is really bad. It's often confusing, incomplete or just plain wrong. What drove me crazy is the extreme imprecision with which certain fundamental concepts are referred to. For example, "derivations" are among the basic building blocks of Nix's package management system, yet I counted at least three unrelated ways in which they're referred to within different parts of the documentation. There were also many times when the only way to solve routine problems was to get in contact with Nix's developers. 2. I never appreciated how much package management is intertwined with individual ecosystems' cultures until I tried using a "universal" package manager like Nix. Take Node packages. The norm is to install in a project's node_packages directory, and many packages rely on that idiom just to function (e.g., hardwired to import modules with that particular directory structure in mind). Nix attempts to translate each ecosystem's idioms into its own system by introducing many helper functions (all written in the Nix language, very few of which are documented) for each ecosystem. The problem is more fundamental than the fact that this approach is only partially successful and many packages remain subtly broken. The real problem is that there's no unified meta-approach or design language to rationalize how each ecosystem's idiosyncrasies are assimilated. The API's for each ecosystem's Nix helper functions are totally different. You end up as a "Nix Node package developer" just to do your job as a web developer, and then a "Nix Python package developer" just to add a Python package, and so on. 3. The developers don't seem to have any interest in solving these UX problems. They are quick to respond and welcoming people, but the impression I was left with is that they're mostly academics or just interested in whatever subsystem they're working on. For example, when I was working on Nix, the canonical mechanism for updating a single Node package in the Nix repository was to run a script that updated all (yes, all) Node packages in the repo. When I pointed out all the ways that this was an impractical approach, the response was that it's actually a good thing because that way the Node packages in the repo don't get get stale (!) This was one of a few examples I encountered where the devs didn't seem to be aware of how unusable Nix was in real world cases. My mini-review is from the perspective of someone who was willing to put in the time to jump through all the hoops. I've left out obvious issues that would be a showstopper for many (e.g., obscurity of the Nix language, poor support on macOS). The issues that I've listed are "fit and finish" issues that at a glance may appear superficial, but having worked in the community for a while, I came to believe are more fundamental. They're about governance and what the community wants from the project. I don't believe that their goals are aligned with those of most devs who probably want a system that solves one of the biggest pains in tooling, package management. It's a pity because Nix's design is really ingenious. Making a "functional" package manager in and of itself is a huge achievement. What I didn't appreciate when I started using Nix is how it normalizes the act of programming your package manager. It's like shifting from Heroku to CloudFront except with much worse docs. The idea is brilliant, the promise is there, but the team doesn't seem interested in turning the whole package from a project into a cohesive product.

deckard1 5y ago

I must admit, I'm curious about the idea but I don't yet "get" it. Reproducible builds sound like a great idea at first, but this has the same problem as Docker containers: you inadvertently become a package/distro maintainer. How does one update the system regularly with security updates? Are we locking by semver somehow (like node, etc.)? And who decides which version ranges to lock to, etc. etc.? Honestly, I'd probably much rather just take an existing Debian/Redhat/etc. LTS distro and do a custom install script, which isn't that hard in the first place. And, in case of cloud server environments, you can just take a snapshot of your VM with a simple click of a button. You can't get much more reproducible than an actual snapshot of your entire system.

kaba0 5y ago
Usually you have a declarative package/system config file that is seldom changes and you point it to a nixpkgs repository, which has definitions for other packages. So an update is as easy as changing that repo to a newer/modified branch. Of course you can even depend on multiple such repos, or override them in any way so you can use a specific lib with an older shared library while use everything else with the latest. As for versioning, it is hash-based. Packages specify a source (eg github repo and a specific commit) and the hash of the downloaded source files, and build instructions inside the nixpkgs repo. The resulting program will depend on each listed property. And since they are referenced by hash, a program can use any possible version of another program. Hope it answers your questions!
Mic92 5y ago
Within a release there are no version bumps, only if you live on unstable or switch to a new release you would get them. The problem of an actual snapshot of your entire system is that you don't really now what should be in there and it collects a lot of cruft/state. With NixOS you can write little modules for services and move those between VM/Machines, whatever floats your boat. IMHO this type of config management sucks less than ansible/chef etc because you are not fighting against the package manager. The configuration holds the ground truth on what is installed on the system.
takeda 5y ago
It's like an OS that has builtin salt/ansible/chef/puppet. Because Nix language describe the OS instead of what to change/configure it's superior to these tools, and solves the problem that supposedly same machines are drifting apart. For example if in the CM you tell it to install a package, then change your mind and remove the entry that does it. The package will remain installed. With NixOS if you remove the package from configuration, it's gone. I personally really like Nix's building capability. For example I can use it to generate a minimal docker container. It requires some knowledge, but I can also modify compilation options in dependencies (like remove unneeded functionality). It looks like there's also an option to similarly build lightweight OS images[1]. I haven't tried it yet but looks cool. [1] https://github.com/cleverca22/not-os https://github.com/cleverca22/not-os

pxc 5y ago

A teeny-tiny orientation for (prospective?) Nix newcomers: Having spent years on Arch and Gentoo, imo the NixOS community is outstanding even among 'advanced' Linux distros in terms of expertise and kindness. I'll never forget one time I was having problems with a Python package generation tool and when I mentioned it on IRC, and one of its authors (Rok Garbas, who is so quite active in the community) just hopped on a call to debug the issue I was having right then and there. If you're on the fence about Nix and that kind of community is valuable to you, make sure to check out the forums [1] and realtime chat [2] (the latter of which is unfortunately still in the process [3] of migrating away from Freenode). If personal assistance/mentorship of the kind I described at the beginning of this post is appealing to you, several generous and knowledgeable community members host Nix ‘office hours’ [4]. I'm not sure who all are still running them, but I know tomberek is for sure [5] and you can find a link in the footnotes. There is one serious problem with NixOS and the wider ecosystem right now, namely that the best experience available depends on Nix features that are unreleased. Nix makes it very easy to run bleeding edge builds of Nix and enable these features, but the unofficial status of it all has slowed adoption, integration, and documentation of these tools in the wider community. That aside— i.e., if you're willing to be a little bit of a pioneer— the community is on the whole pretty rich with good documentation of everything but the bleeding edge, unreleased bits at this point. Those pieces mostly impact the CLI and specifying inputs to the expressions you use to define your system. Everything in the NixOS and Nixpkgs manuals is still accurate. The unreleased components are also fairly mature despite their unofficial status: many folks in the community have been using them for a year or two now. Finally: if you're interested in dipping your toes in without committing to a system fully managed by Nix and you're a macOS user, nix-darwin [6] provides a pretty NixOS-like experience using a module system and CLI based on NixOS'. There's nothing equally complete in terms of managing system services in a declarative fashion on non-NixOS Linux, but home-manager [7] provides some functionality for enabling user-mode services in a declarative style. You can check whether your favorite software is packaged for Nix here [8], and additionally NixOS does support several other forms of cross-distro packaging/deployment, including Flatpak, AppImage, and Docker. Steam support is native and works without much fuss, too. --------- 1: https://discourse.nixos.org/ https://discourse.nixos.org/ 2: https://matrix.to/#/!MKvhXlSTLGJUXpYuWF:nixos.org https://matrix.to/#/!MKvhXlSTLGJUXpYuWF:nixos.org 3: https://github.com/NixOS/rfcs/pull/94 https://github.com/NixOS/rfcs/pull/94 4: https://discourse.nixos.org/search?q=office%20hours https://discourse.nixos.org/search?q=office%20hours 5: https://discourse.nixos.org/t/nix-office-hours/11945 https://discourse.nixos.org/t/nix-office-hours/11945 6: https://github.com/LnL7/nix-darwin https://github.com/LnL7/nix-darwin 7: https://github.com/nix-community/home-manager https://github.com/nix-community/home-manager 8: https://search.nixos.org/packages https://search.nixos.org/packages

mrobot 5y ago

I found the nix pills to be a good starting point for learning about how to use nixpkgs/nixos https://nixos.org/guides/nix-pills/index.html https://nixos.org/guides/nix-pills/index.html

nuker 5y ago

I tried. I stopped at ‘pip install whatever’ in nix.

seniorivn 5y ago
did you stop at trying linux at launching whatever.exe file as well?

balves 5y ago

What are people's thoughts on running nix without nixos, using a base system such as Debian or Arch? It seems like it might be a nice way to get reproducible dev environments, without some of the headaches being discussed here. Is this a common use, or do people typically just do all-or-nothing?

joepie91_ 5y ago
That's how I started out with openSUSE + Nix, but I quickly found that I still had to learn about most of Nix's quirks, while only getting a small part of the benefits (namely, not the system configuration). It may be worth it if you care a lot about having imperative escape hatches, but if you're willing to invest upfront work in getting past the learning curve and want to maximize the benefit you get from it, I would just recommend diving into NixOS directly.
danieldk 5y ago
I would say that it is a good gateway drug. I used Nix + home-manager on macOS for a while. It was really nice for replacing the broken macOS userland plus having reproducible dev environments. I liked it so much that I tried NixOS on a Dell Workstation that I still had. Configuring a full machine declaratively was so powerful that I slowly moved from macOS to NixOS pretty much full-time.