11 ms·

20 years of Nix

200 points by domenkozar 4y ago

amelius 4y ago
20 years, is that the compile time now? ;)
- Reventlov 4y ago
  Hold up we're talking about Nix not Rust ! (yeah sorry couldn't resist, I know this is probably misleading)
  - speed_spread 4y ago
    And here I was thinking about Gentoo...
    - mtlmtlmtlmtl 4y ago
      Oh that takes me back to trying to explain to some Gentoo users back in the day that that yea you can optimise stuff better for your slow ass computer. But you now have to spend most of your time compiling code on your slow ass computer. I always found Arch to be a much more reasonable system for this use case because compiling everything from scratch was just pointless, at least back then. But it still maoes it easy to rebuild packages with custom patches etc.
      - CuriousCosmic 4y ago
        > Oh that takes me back to trying to explain to some Gentoo users back in the day that that yea you can optimise stuff better for your slow ass computer. But you now have to spend most of your time compiling code on your slow ass computer. Honestly it depends what your goal is with gentoo. My whole sell with gentoo is that custom packages are just so easy. I can take some garbage toolchain from an embedded manufacturer and wire up an ebuild for it that "just works". Nix is similar once you get it working but the nixpkg and nixos DSLs just kinda suck in their own ways. So it may take me 10-15 min to write and install an ebuild while the nix package may take me an hour or two. Same goes for situations where you need weird kernel configs. It's so easy to just recompile the kernel on gentoo once you have stuff set up. The OS is built expecting a majority of users will want to tweak their kernels so the OS's tooling doesn't fight you when you do. I find this often less well handled in other distros. As for arch, it is pretty close IMHO but (while it may have changed since I used it last) I found that the "bleeding-edge" focus makes dealing with old janky dependencies to be pretty painful. Gentoo certainly isn't the first choice for the majority of people but it IMHO is a really good choice if you are going to be working with funky proprietary toolchains (o/ hi embedded engs).
- mananaysiempre 4y ago
  Sarcasm aside, here’s a Nix manual from 2004: https://releases.nixos.org/nix/nix-0.5/manual/manual.html https://releases.nixos.org/nix/nix-0.5/manual/manual.html. (The compile time of Nix itself is unpleasant, but not exactly exceptional among programs written in the modern C++ style. The eval time even for Nixpkgs even on a ten-year-old i5 is annoying but not a terrible problem the way it’s used now, though even on a recent Android device it’s admittedly measured in minutes.)
  - bpye 4y ago
    With the Hydra binary cache I can quite comfortably update my Avoton C2550 based router or Raspberry Pi 4 AirPlay receiver within a few minutes. It’s only if I need to build a non trivial package that I have to make sure I build on my desktop or in a VM on my MacBook.
    - mananaysiempre 4y ago
      I doubt your setup needed recompiling the Nix binary itself at any point. Even I did that more out of love of adventure than for any practical reasons, it’s just that the scars are still there. (Still less than those from the time when the LibreOffice build was broken on Hydra and a routine system update jumped right into trying to perform it locally, even if that indeed was what I technically asked for...) And you know what, the long evaluation thing might just be a bug. Or at least I don’t see any other reason why (e.g.) `nix-shell -p yt-dlp` works reasonably fast on my Nix-on-Droid[1] installation but `nix shell nixpkgs#yt-dlp` takes minutes. [1] https://github.com/t184256/nix-on-droid https://github.com/t184256/nix-on-droid
amardeep 4y ago
I have been exploring nix for the past few months and my experience with nix has been both exhilarating and frustrating, simultaneously. On one hand, I find it hard to imagine not using nix now, but on the other hand, I hesitate to recommend it to other colleagues due to its steep learning curve, ux issues and potential for footguns. I sincerely hope that nix community improves the UX to make it more accessible to new users. Though for those willing to invest time in learning it, nix is extremely useful and highly recommended.
- domenkozar 4y ago
  Hey! We've been working at Cachix to address this using https://devenv.sh/ https://devenv.sh/. It's primary targeted to improve DX and on-board users quickly.
  - amardeep 4y ago
    Thanks Domen, devenv.sh is quite nice, and have already started using it.
    - domenkozar 4y ago
      Do you still experience these UX issues and lack of documentation?
  - pbronez 4y ago
    DevEnv looks neat, maybe I’ll try it. I expect my main hurdle will be stuff that isn’t in NicPkgs. Especially for dev stuff, I’m going to want to pull in low-profile GitHub stuff or Python packages. What’s the escape hatch to bring those into the dev environment?
    - rgoulter 4y ago
      > What’s the escape hatch to bring those into the dev environment? One thing you can do is try the Nix package manager on your Linux or macOS system. -- If it's not in nix, you can just do it the way you did things before. If you want to try NixOS: 1. Writing a package is only necessary for sharing code.. you can still just have Python, setup a virtual env, & run the program as you would. 2. You could use a tool like Podman or Docker, to run stuff in containers. I've heard stuff like https://github.com/containers/toolbox https://github.com/containers/toolbox helps this. (Among other solutions).
tmountain 4y ago
I’d like to learn more about the project history, who started it (early contributions), and the context under which the early work was initiated. Wikipedia has exactly two sentences on the history. Is there a better version of the Nix story available?
- nextos 4y ago
  I guess the LISA '04 article and citations / citing work are a good starting point: https://scholar.google.com/scholar?cites=11060877727748937719&as_sdt=2005&sciodt=0,5 https://scholar.google.com/scholar?cites=1106087772774893771...
- domenkozar 4y ago
  The best talk I know about this is https://www.youtube.com/watch?v=t6goF1dM3ag https://www.youtube.com/watch?v=t6goF1dM3ag
shp0ngle 4y ago
nix is one of the things I always think would be neat to try, but I’m always scared away by the complexity.
- rgoulter 4y ago
  You can get quite far without having to be aware of significant complexity. e.g. to take a look at https://devenv.sh/ https://devenv.sh/ or https://www.jetpack.io/devbox/docs/installing_devbox/ https://www.jetpack.io/devbox/docs/installing_devbox/ which aim to leverage nix without requiring nix knowledge.
anarchogeek 4y ago
Doe nix work at all? Or is it just not actually functional on top of MacOS? I've tried a dozen times over the years and I've never gotten it working. Seriously, how is anything so hard to use still around after 20 years!
- dindresto 4y ago
  You might want to give the new installer by Determinate Systems a try: https://determinate.systems/posts/determinate-nix-installer https://determinate.systems/posts/determinate-nix-installer
  - ziml77 4y ago
    I'm definitely going to give that a try. I had issues with the Bash script on macOS and was annoyed that it left me with a system that I had to manually clean up.
  - deleted 4y ago
    [deleted]
- SkyMarshal 4y ago
  Hard to answer your question without info on what the problem is, but lots of people use it on MacOS. Maybe ask about your problem on /r/nixos or https://discourse.nixos.org/ https://discourse.nixos.org/.
- kaba0 4y ago
  It absolutely works and is the best thing since sliced bread within package managers — many UNIX tools are just simply broken on Mac (not always on the packaging side), and in case of more niche tools it is simply not a priority.
- striking 4y ago
  I ship a development environment to a fleet of ~100 engineer laptops based on Nix. If it didn't work, I'd be out of a job
  - 4y ago
haolez 4y ago
What happened to NixOps? It sounded like a great idea when I first read about it.
- bpye 4y ago
  As far as I know, it’s still about [0]. I’ve had a better experience with deploy-rs though [1] - or even just using nixos-rebuild to target the remote machine. [0] - https://github.com/NixOS/nixops https://github.com/NixOS/nixops [1] - https://github.com/serokell/deploy-rs https://github.com/serokell/deploy-rs
password4321 4y ago
I tried to install NixOS using the live cd last week in a Hyper-V VM, but it failed to get anywhere due to SquashFS errors. That seemed pretty low-level so I'm putting it back on the back burner. User friendliness doesn't seem to be a top priority, and that's fine.
- CuriousCosmic 4y ago
  > I tried to install NixOS using the live cd last week in a Hyper-V VM, but it failed to get anywher e due to SquashFS errors. I'm curious what happened here because just a few weeks ago I was using a NixOS live-cd to rescue a botched gentoo VM on my windows machine (managed with Hyper-V manager). If you give it another shot, run into the issue again, and document it, the Nix community would almost certainly help you debug it and figure out what went wrong.
  - password4321 4y ago
    Thanks for sharing your counter-anecdata, I'll give it another shot.
- chriswarbo 4y ago
  > I tried to install NixOS using the live cd last week in a Hyper-V VM, but it failed to get anywhere due to SquashFS errors. Heh, that reminds me of installing NixOS back around 2014. I didn't have any way to physically boot off the install CD; so I ran it in qemu, using my real /dev/sda as the "virtual" hard drive (which I'd already partitioned). Thankfully there was no interference with the host system (Trisquel). I'm still using (and evolved version of) the same NixOS config to this day; it still contains the following comment ( https://github.com/Warbo/nix-config/blob/master/nixos/machines/thinkpad.nix https://github.com/Warbo/nix-config/blob/master/nixos/machin... ): trace "FIXME: Which modules are artefacts of using QEMU to install?"
toastal 4y ago
It feels so painful to go back to ‘regular’ Linux now. I'm so concerned about config file entropy and version incompatibility that Nix has solved for me. I'm happy I took the Nix Pill though and completely skipped over Docker and it's often-unnecessary overhead. Nix store is a better solution to reproducible builds, and the syntax is a lot better than LISP for Guix or whatever Skylark is trying to be. Currently I'm setting up a second machine to distribute builds and share a cache on my local network. Overriding C flags Gentoo-style for better optimization is supported, but it can take a while to build--especially with LTO--as Hydra only builds for generic x86_64 so sharing optimized kernels and other software is great. I successfully got a shared znver3 LTO-optimized Linux 6.1.19 kernel with ZFS support yesterday! I just wish I could have built in parallel the kernel on the faster PC and the ZFS stuff on the slower one and resynced the build input derivations when it was finished after running `nixos-rebuild switch --flake ..`. For the future, I hope distributed Nix caches become the norm like BitTorrent and we can all share optimized builds.
- toastal 4y ago
  I resolved by distributed build issues. This works as intended.
Rapzid 4y ago
Nix feels like a dead end.
- miniBill 4y ago
  Can you elaborate? Personally I feel like everything else is a dead end compared to Nix
  - vilunov 4y ago
    I personally would prefer a build and environment tool which uses the modern Linux namespaces to prepare isolated filesystems without needing to reinvent a whole bunch of wheels. A number of problems that I would like to be fixed: - Post-build patches to insure correct shared library paths in artifacts due to requirement to use absolute /nix/store instead of using the traditional Linux filesystem. - Numerous wrappers around existing build tools to move dependencies into nix packages to generate stuff like Cargo.nix. - Not so good handling of content-addressable packages due to historic cruft. - Horrible-horrible way to compute runtime-dependencies of packages [1]. This may be okay as a heuristic to initialize a project, but in the end it must be tweakable manually. I see a future where a package manager builds a fully-isolated environment with only and only required dependencies for my app, using CAS but not forcing it's style of the filesystem on me. Nix is a good step into that direction, but that's not a usable product in my view, just a research project. [1]: https://nixos.org/guides/nix-pills/automatic-runtime-dependencies.html https://nixos.org/guides/nix-pills/automatic-runtime-depende... Edit: Forgot to add, Nix the language is also not good, but I'd like not to discuss that matter. This would be solved by a more modular architecture, where we can manage package with a one tool and build packages with a different tool. Until then, I would be forced to code in Nix, and that's problematic no matter how good the package management is.
    - max-privatevoid 4y ago
      Absolute, immutable store paths are the main reason why Nix is so good in the first place. The key assertion is that FHS sucks. Using complicated and brittle namespace tricks to construct virtual FHS's everywhere is nothing more than shoving the problem under the carpet. It severely limits the places where Nix can be useful. You usually can't create nested namespaces inside a Docker container, so you couldn't use "Namespace-Nix" programs there. You're also destroying the ability to compose packages and environments. Using multiple versions of the same package within one environment - another goal of Nix - becomes impossible. Implementing NixOS in such a paradigm would be a nightmare, and the result would be very limited compared to what NixOS can do now. Yes, having to clean up RPATH after compiling a program sucks. Yes, having to implement workarounds to make build tools that desperately cling to their FHS traditions work sucks. These are effectively bugs and/or design errors in those tools. Packages are supposed to be installable into various different prefixes, Nix or not. That's why ./configure --prefix= exists. The wheel needed to be reinvented because the old one was square.
julianeon 4y ago
Surprising to me that there's 0 Nix meetups in the Bay Area, as listed on that page. There should be one!
- ronef 4y ago
  Just announced the bay area meetup -> https://www.eventbrite.com/e/nixos-20th-bay-area-meet-tickets-594999107347 https://www.eventbrite.com/e/nixos-20th-bay-area-meet-ticket... Hope to see you all soon :)
- tomberek 4y ago
  I’m looking to put one together in Bay Area for next week or so. DM me if interested or if you know more people in the area.
  - ronef 4y ago
    +1 we should have more info tomorrow :)
SirensOfTitan 4y ago
What I would like is to replace both Docker and docker compose for prod images and local dev, respectively for my team. Is this possible with nix today? It’s mostly a macOS box team. I use nix flakes to manage my own configuration, but last time I played with building docker images on macOS I had to stand up a builder image on qemu or inside docker. Further, I’ve historically run into friction between other package managers and nix. The poetry2nix and pnpm2nix kind of tools have a lot of friction [for example, private registry support for poetry is poor]. My current project has a dependency on xmlsec and it’s a bit cumbersome to handle building non wheels on M1.
EntrePrescott 4y ago
I like the principle of Nix that one can simultaneously install different versions of the same software and make layered choices of what version to use with what or depending on the use case. Nix has spearheaded that principle and that's great. That being said, that fine-grained layering selection is done via symlinks in Nix afaik, whereas a couple newer packaging systems (e.g. OCI containers or flatpak) can do such layering with newer stuff like bind mounts and namespaces+sandboxing (and I don't just mean sandbox for build time but for run time) and thus increase the security by selectively choosing what a package is supposed to have access to. I wonder how fast Nix will adapt to such new possibilities. I think it should do so quickly (e.g. switch to OCI as the underlying layering system; I hear that the Tvix project is experimenting with that?), as that could establish Nix as the dominant system/distribution in that field whereas otherwise it would be overtaken and left behind by whatever OCI-container-based distribution manages to come out as the dominant one. There is currently (temporarily) a unique window of opportunity in that: * Docker is totally ruining their position in the OCI world, and had never really put effort into building a comprehensive quality curated distribution. That is: their registry may be "comprehensive" as in large choice, but apart from a small set of base images, it's mostly a hotchpotch of low-quality uncurated images with uncertain security… and often found to be of severely lacking in the security domain. * Redhat has a much too closed policy for their OCI registries and has made the mistake of restricting their OCI stuff to the server side while fedora pushes flatpak/flathub which is too restricted to the desktop. That artificial chasm between a server-only and a desktop-only system sucks. * Ubuntu has completely borked their attempts at new sandboxed/layered package formats, snap sucks. And Debian and the other remaining big distros have nothing in that category Nix has the advantage of already having a large, comprehensive and curated set of packages. All it needs is to adopt OCI as its underlying layering system (instead of symlinks), make its large package base trivially accessible to OCI, and make an effort on UX (a little more accessible and easier) and it could come out as the dominant distribution.
- anon291 4y ago
  No. The nix store is a graph. Oci images are a tree. This is terrible for code ruse. Nix is superior. Oci should adopt a nix based approach.
Ferret7446 4y ago
Realistically speaking, Nix will never become widespread. Instead, I foresee immutable OSes like Steam OS, Chrome OS and Fedora Silverblue combined with something like flatpak for installing applications. The evolutionary strategy of reproducible snapshots of state has historically been far more successful than "pure" functional approaches; see Docker for example, or reproduction of DNA based lifeforms.

20 years of Nix

200 points by domenkozar 4y ago

amelius 4y ago

20 years, is that the compile time now? ;)

Reventlov 4y ago
Hold up we're talking about Nix not Rust ! (yeah sorry couldn't resist, I know this is probably misleading)
- speed_spread 4y ago
  And here I was thinking about Gentoo...
  - mtlmtlmtlmtl 4y ago
    Oh that takes me back to trying to explain to some Gentoo users back in the day that that yea you can optimise stuff better for your slow ass computer. But you now have to spend most of your time compiling code on your slow ass computer. I always found Arch to be a much more reasonable system for this use case because compiling everything from scratch was just pointless, at least back then. But it still maoes it easy to rebuild packages with custom patches etc.
    - CuriousCosmic 4y ago
      > Oh that takes me back to trying to explain to some Gentoo users back in the day that that yea you can optimise stuff better for your slow ass computer. But you now have to spend most of your time compiling code on your slow ass computer. Honestly it depends what your goal is with gentoo. My whole sell with gentoo is that custom packages are just so easy. I can take some garbage toolchain from an embedded manufacturer and wire up an ebuild for it that "just works". Nix is similar once you get it working but the nixpkg and nixos DSLs just kinda suck in their own ways. So it may take me 10-15 min to write and install an ebuild while the nix package may take me an hour or two. Same goes for situations where you need weird kernel configs. It's so easy to just recompile the kernel on gentoo once you have stuff set up. The OS is built expecting a majority of users will want to tweak their kernels so the OS's tooling doesn't fight you when you do. I find this often less well handled in other distros. As for arch, it is pretty close IMHO but (while it may have changed since I used it last) I found that the "bleeding-edge" focus makes dealing with old janky dependencies to be pretty painful. Gentoo certainly isn't the first choice for the majority of people but it IMHO is a really good choice if you are going to be working with funky proprietary toolchains (o/ hi embedded engs).
mananaysiempre 4y ago
Sarcasm aside, here’s a Nix manual from 2004: https://releases.nixos.org/nix/nix-0.5/manual/manual.html https://releases.nixos.org/nix/nix-0.5/manual/manual.html. (The compile time of Nix itself is unpleasant, but not exactly exceptional among programs written in the modern C++ style. The eval time even for Nixpkgs even on a ten-year-old i5 is annoying but not a terrible problem the way it’s used now, though even on a recent Android device it’s admittedly measured in minutes.)
- bpye 4y ago
  With the Hydra binary cache I can quite comfortably update my Avoton C2550 based router or Raspberry Pi 4 AirPlay receiver within a few minutes. It’s only if I need to build a non trivial package that I have to make sure I build on my desktop or in a VM on my MacBook.
  - mananaysiempre 4y ago
    I doubt your setup needed recompiling the Nix binary itself at any point. Even I did that more out of love of adventure than for any practical reasons, it’s just that the scars are still there. (Still less than those from the time when the LibreOffice build was broken on Hydra and a routine system update jumped right into trying to perform it locally, even if that indeed was what I technically asked for...) And you know what, the long evaluation thing might just be a bug. Or at least I don’t see any other reason why (e.g.) `nix-shell -p yt-dlp` works reasonably fast on my Nix-on-Droid[1] installation but `nix shell nixpkgs#yt-dlp` takes minutes. [1] https://github.com/t184256/nix-on-droid https://github.com/t184256/nix-on-droid

amardeep 4y ago

I have been exploring nix for the past few months and my experience with nix has been both exhilarating and frustrating, simultaneously. On one hand, I find it hard to imagine not using nix now, but on the other hand, I hesitate to recommend it to other colleagues due to its steep learning curve, ux issues and potential for footguns. I sincerely hope that nix community improves the UX to make it more accessible to new users. Though for those willing to invest time in learning it, nix is extremely useful and highly recommended.

domenkozar 4y ago
Hey! We've been working at Cachix to address this using https://devenv.sh/ https://devenv.sh/. It's primary targeted to improve DX and on-board users quickly.
- amardeep 4y ago
  Thanks Domen, devenv.sh is quite nice, and have already started using it.
  - domenkozar 4y ago
    Do you still experience these UX issues and lack of documentation?
- pbronez 4y ago
  DevEnv looks neat, maybe I’ll try it. I expect my main hurdle will be stuff that isn’t in NicPkgs. Especially for dev stuff, I’m going to want to pull in low-profile GitHub stuff or Python packages. What’s the escape hatch to bring those into the dev environment?
  - rgoulter 4y ago
    > What’s the escape hatch to bring those into the dev environment? One thing you can do is try the Nix package manager on your Linux or macOS system. -- If it's not in nix, you can just do it the way you did things before. If you want to try NixOS: 1. Writing a package is only necessary for sharing code.. you can still just have Python, setup a virtual env, & run the program as you would. 2. You could use a tool like Podman or Docker, to run stuff in containers. I've heard stuff like https://github.com/containers/toolbox https://github.com/containers/toolbox helps this. (Among other solutions).

tmountain 4y ago

I’d like to learn more about the project history, who started it (early contributions), and the context under which the early work was initiated. Wikipedia has exactly two sentences on the history. Is there a better version of the Nix story available?

nextos 4y ago
I guess the LISA '04 article and citations / citing work are a good starting point: https://scholar.google.com/scholar?cites=11060877727748937719&as_sdt=2005&sciodt=0,5 https://scholar.google.com/scholar?cites=1106087772774893771...
domenkozar 4y ago
The best talk I know about this is https://www.youtube.com/watch?v=t6goF1dM3ag https://www.youtube.com/watch?v=t6goF1dM3ag

shp0ngle 4y ago

nix is one of the things I always think would be neat to try, but I’m always scared away by the complexity.

rgoulter 4y ago
You can get quite far without having to be aware of significant complexity. e.g. to take a look at https://devenv.sh/ https://devenv.sh/ or https://www.jetpack.io/devbox/docs/installing_devbox/ https://www.jetpack.io/devbox/docs/installing_devbox/ which aim to leverage nix without requiring nix knowledge.

anarchogeek 4y ago

Doe nix work at all? Or is it just not actually functional on top of MacOS? I've tried a dozen times over the years and I've never gotten it working. Seriously, how is anything so hard to use still around after 20 years!

dindresto 4y ago
You might want to give the new installer by Determinate Systems a try: https://determinate.systems/posts/determinate-nix-installer https://determinate.systems/posts/determinate-nix-installer
- ziml77 4y ago
  I'm definitely going to give that a try. I had issues with the Bash script on macOS and was annoyed that it left me with a system that I had to manually clean up.
- deleted 4y ago
  [deleted]
SkyMarshal 4y ago
Hard to answer your question without info on what the problem is, but lots of people use it on MacOS. Maybe ask about your problem on /r/nixos or https://discourse.nixos.org/ https://discourse.nixos.org/.
kaba0 4y ago
It absolutely works and is the best thing since sliced bread within package managers — many UNIX tools are just simply broken on Mac (not always on the packaging side), and in case of more niche tools it is simply not a priority.
striking 4y ago
I ship a development environment to a fleet of ~100 engineer laptops based on Nix. If it didn't work, I'd be out of a job
- 4y ago

haolez 4y ago

What happened to NixOps? It sounded like a great idea when I first read about it.

bpye 4y ago
As far as I know, it’s still about [0]. I’ve had a better experience with deploy-rs though [1] - or even just using nixos-rebuild to target the remote machine. [0] - https://github.com/NixOS/nixops https://github.com/NixOS/nixops [1] - https://github.com/serokell/deploy-rs https://github.com/serokell/deploy-rs

password4321 4y ago

I tried to install NixOS using the live cd last week in a Hyper-V VM, but it failed to get anywhere due to SquashFS errors. That seemed pretty low-level so I'm putting it back on the back burner. User friendliness doesn't seem to be a top priority, and that's fine.

CuriousCosmic 4y ago
> I tried to install NixOS using the live cd last week in a Hyper-V VM, but it failed to get anywher e due to SquashFS errors. I'm curious what happened here because just a few weeks ago I was using a NixOS live-cd to rescue a botched gentoo VM on my windows machine (managed with Hyper-V manager). If you give it another shot, run into the issue again, and document it, the Nix community would almost certainly help you debug it and figure out what went wrong.
- password4321 4y ago
  Thanks for sharing your counter-anecdata, I'll give it another shot.
chriswarbo 4y ago
> I tried to install NixOS using the live cd last week in a Hyper-V VM, but it failed to get anywhere due to SquashFS errors. Heh, that reminds me of installing NixOS back around 2014. I didn't have any way to physically boot off the install CD; so I ran it in qemu, using my real /dev/sda as the "virtual" hard drive (which I'd already partitioned). Thankfully there was no interference with the host system (Trisquel). I'm still using (and evolved version of) the same NixOS config to this day; it still contains the following comment ( https://github.com/Warbo/nix-config/blob/master/nixos/machines/thinkpad.nix https://github.com/Warbo/nix-config/blob/master/nixos/machin... ): trace "FIXME: Which modules are artefacts of using QEMU to install?"

toastal 4y ago

It feels so painful to go back to ‘regular’ Linux now. I'm so concerned about config file entropy and version incompatibility that Nix has solved for me. I'm happy I took the Nix Pill though and completely skipped over Docker and it's often-unnecessary overhead. Nix store is a better solution to reproducible builds, and the syntax is a lot better than LISP for Guix or whatever Skylark is trying to be. Currently I'm setting up a second machine to distribute builds and share a cache on my local network. Overriding C flags Gentoo-style for better optimization is supported, but it can take a while to build--especially with LTO--as Hydra only builds for generic x86_64 so sharing optimized kernels and other software is great. I successfully got a shared znver3 LTO-optimized Linux 6.1.19 kernel with ZFS support yesterday! I just wish I could have built in parallel the kernel on the faster PC and the ZFS stuff on the slower one and resynced the build input derivations when it was finished after running `nixos-rebuild switch --flake ..`. For the future, I hope distributed Nix caches become the norm like BitTorrent and we can all share optimized builds.

toastal 4y ago
I resolved by distributed build issues. This works as intended.

Rapzid 4y ago

Nix feels like a dead end.

miniBill 4y ago
Can you elaborate? Personally I feel like everything else is a dead end compared to Nix
- vilunov 4y ago
  I personally would prefer a build and environment tool which uses the modern Linux namespaces to prepare isolated filesystems without needing to reinvent a whole bunch of wheels. A number of problems that I would like to be fixed: - Post-build patches to insure correct shared library paths in artifacts due to requirement to use absolute /nix/store instead of using the traditional Linux filesystem. - Numerous wrappers around existing build tools to move dependencies into nix packages to generate stuff like Cargo.nix. - Not so good handling of content-addressable packages due to historic cruft. - Horrible-horrible way to compute runtime-dependencies of packages [1]. This may be okay as a heuristic to initialize a project, but in the end it must be tweakable manually. I see a future where a package manager builds a fully-isolated environment with only and only required dependencies for my app, using CAS but not forcing it's style of the filesystem on me. Nix is a good step into that direction, but that's not a usable product in my view, just a research project. [1]: https://nixos.org/guides/nix-pills/automatic-runtime-dependencies.html https://nixos.org/guides/nix-pills/automatic-runtime-depende... Edit: Forgot to add, Nix the language is also not good, but I'd like not to discuss that matter. This would be solved by a more modular architecture, where we can manage package with a one tool and build packages with a different tool. Until then, I would be forced to code in Nix, and that's problematic no matter how good the package management is.
  - max-privatevoid 4y ago
    Absolute, immutable store paths are the main reason why Nix is so good in the first place. The key assertion is that FHS sucks. Using complicated and brittle namespace tricks to construct virtual FHS's everywhere is nothing more than shoving the problem under the carpet. It severely limits the places where Nix can be useful. You usually can't create nested namespaces inside a Docker container, so you couldn't use "Namespace-Nix" programs there. You're also destroying the ability to compose packages and environments. Using multiple versions of the same package within one environment - another goal of Nix - becomes impossible. Implementing NixOS in such a paradigm would be a nightmare, and the result would be very limited compared to what NixOS can do now. Yes, having to clean up RPATH after compiling a program sucks. Yes, having to implement workarounds to make build tools that desperately cling to their FHS traditions work sucks. These are effectively bugs and/or design errors in those tools. Packages are supposed to be installable into various different prefixes, Nix or not. That's why ./configure --prefix= exists. The wheel needed to be reinvented because the old one was square.

julianeon 4y ago

Surprising to me that there's 0 Nix meetups in the Bay Area, as listed on that page. There should be one!

ronef 4y ago
Just announced the bay area meetup -> https://www.eventbrite.com/e/nixos-20th-bay-area-meet-tickets-594999107347 https://www.eventbrite.com/e/nixos-20th-bay-area-meet-ticket... Hope to see you all soon :)
tomberek 4y ago
I’m looking to put one together in Bay Area for next week or so. DM me if interested or if you know more people in the area.
- ronef 4y ago
  +1 we should have more info tomorrow :)

SirensOfTitan 4y ago

What I would like is to replace both Docker and docker compose for prod images and local dev, respectively for my team. Is this possible with nix today? It’s mostly a macOS box team. I use nix flakes to manage my own configuration, but last time I played with building docker images on macOS I had to stand up a builder image on qemu or inside docker. Further, I’ve historically run into friction between other package managers and nix. The poetry2nix and pnpm2nix kind of tools have a lot of friction [for example, private registry support for poetry is poor]. My current project has a dependency on xmlsec and it’s a bit cumbersome to handle building non wheels on M1.

EntrePrescott 4y ago

I like the principle of Nix that one can simultaneously install different versions of the same software and make layered choices of what version to use with what or depending on the use case. Nix has spearheaded that principle and that's great. That being said, that fine-grained layering selection is done via symlinks in Nix afaik, whereas a couple newer packaging systems (e.g. OCI containers or flatpak) can do such layering with newer stuff like bind mounts and namespaces+sandboxing (and I don't just mean sandbox for build time but for run time) and thus increase the security by selectively choosing what a package is supposed to have access to. I wonder how fast Nix will adapt to such new possibilities. I think it should do so quickly (e.g. switch to OCI as the underlying layering system; I hear that the Tvix project is experimenting with that?), as that could establish Nix as the dominant system/distribution in that field whereas otherwise it would be overtaken and left behind by whatever OCI-container-based distribution manages to come out as the dominant one. There is currently (temporarily) a unique window of opportunity in that: * Docker is totally ruining their position in the OCI world, and had never really put effort into building a comprehensive quality curated distribution. That is: their registry may be "comprehensive" as in large choice, but apart from a small set of base images, it's mostly a hotchpotch of low-quality uncurated images with uncertain security… and often found to be of severely lacking in the security domain. * Redhat has a much too closed policy for their OCI registries and has made the mistake of restricting their OCI stuff to the server side while fedora pushes flatpak/flathub which is too restricted to the desktop. That artificial chasm between a server-only and a desktop-only system sucks. * Ubuntu has completely borked their attempts at new sandboxed/layered package formats, snap sucks. And Debian and the other remaining big distros have nothing in that category Nix has the advantage of already having a large, comprehensive and curated set of packages. All it needs is to adopt OCI as its underlying layering system (instead of symlinks), make its large package base trivially accessible to OCI, and make an effort on UX (a little more accessible and easier) and it could come out as the dominant distribution.

anon291 4y ago
No. The nix store is a graph. Oci images are a tree. This is terrible for code ruse. Nix is superior. Oci should adopt a nix based approach.

Ferret7446 4y ago

Realistically speaking, Nix will never become widespread. Instead, I foresee immutable OSes like Steam OS, Chrome OS and Fedora Silverblue combined with something like flatpak for installing applications. The evolutionary strategy of reproducible snapshots of state has historically been far more successful than "pure" functional approaches; see Docker for example, or reproduction of DNA based lifeforms.