6 ms·

> Seriously, are we optimizing for the right stuff here? I know Nix is doing package isolation with a programmable environment defined by text files, it's immut

> Seriously, are we optimizing for the right stuff here? I know Nix is doing package isolation with a programmable environment defined by text files, it's immutable and all. I get it. But we have alternatives for these problems. They do a pretty good job overall and we understand them. Setting up a development environment five years ago: here's a Word document that tells you which tools to install. Forget about updating the tools - good luck trying to get everyone to update their systems. Setting up a development environment two years ago: here's a README that tells you which commands to run to build Docker images locally which will build and test your code. OS X users have fun burning RAM to the unnecessary VM gods when they have little to spare to begin with because MacBook Pros. No reproduceability between Dev and CI despite using container images because Dev will have debugging tools made available in the image that will be removed from the final image. Be limited while debugging locally because all debugging must happen over a network connection. Today: Install Nix. Run build.sh. Run test.sh. Run nix-shell if you want more freedom.

acqq 7y ago
> Today: Install Nix I'm missing something here. (Disclaimer: I've just tried to understand the OP, I don't know all the details about what is going on there). The text starts with "In my last post about Nix, I didn’t see the light yet." ... Then it continues with "A popular way to model this is with a Dockerfile." So I have expected that the post will demonstrate how Nix can be used without docker... But then later: "so let’s make docker.nix:" and continues in that way. So there is some dockering involved? To this casual reader, it doesn't seem that using Nix allows one to avoid docker, as a technology, but just that some additional goal is achieved by using Nix over that. I just missed what was actually achieved, other than that the text mentions a few megabytes less here or there, of 100 MB, and that I also miss the information if the megabytes were traded in the build time or, if I understand correctly, in some way even more dependencies (more places from which something has to download something). Can anybody explain? I'm sure that these tradeoffs were obvious to the author, but I as a reader hoped to somehow get the idea of those, and I missed that (yes, it's hard to "see the light" especially indirectly).
- Nullabillity 7y ago
  Nix itself doesn't use Docker, and you can deploy it like that just fine (with NixOS, and NixOps if you have multiple machines). But sometimes your ops team has standardized on Docker, maybe because you're using Kubernetes. In that case, Nix will happily build those images for you.
- marcus_holmes 7y ago
  The big one that I got is that the resulting Nix image has just the Go executable in it, and so the server is safer because if anyone hacks into it they'd need to bring their own copy of any tools they wanted with them. I'm a huge fan of reducing attack surfaces wherever possible, and getting a container that will only run the program required and nothing else is a win for me.
  - acqq 7y ago
    > The big one that I got is that the resulting Nix image has just the Go executable in it Now I miss the point of that one too: if just a Go executable alone can be enough anyway, as it is statically linked, why not just copying it, instead of complicating around?
    - tiew9Vii 7y ago
      A lot of people have standardised on Docker images as the default distribution/packaging format as Kubernetes etc make deploying/running them more standardised across orgs. You can build the binary then have a Dockerfile copy it in from the scratch base image. However if you are using nix for deterministic builds you might as well add the few lines of code to have nix build the docker image to vs a Docker file with a single copy command. If you are not building a static binary you get the advantage nix will copy in only the dependencies needed. You also get the advantage when you are building images you not randomly downloading urls from the internet that may be dead. Artifacts can come from a nix build cache which is cryptographically signed based on the build inputs so you know building the same image every time produces the same output. With typical Dockerfiles that is not true. Docker images are not immutable so fetching the same Docker image may result in a different image being fetched. Likewise a lot of Docker files just wget / yum install random packages from places that may not exist anymore. If you maintain your own nix build cache you will always be able to build, get speedup from hitting the build cache vs compiling and know the build is deterministic. Running the same build multiple times will result in the exact same output.
pjmlp 7y ago
Nix does not set up my Visual Studio and XCode environments, Unity, Unreal, nor OEMs SDKs.
- deleted 7y ago
  [deleted]
- georgyo 7y ago
  Look up nix home manger, you might be able to have nix configure everything in your home directory. Also nix makes it pretty trivial to package and patch propriety binary vendor software. It would take at least one person on the development team feeling comfortable with nix, but they could craft a nix file that does everything.
- lidHanteyk 7y ago
  As well it shouldn't. Proprietary software is trash and should be thrown out. Nix supports unfree software, and has many tools for torturing unfree packages until they yield the desired binaries and filesystem layout; if you want your particular unfree software to be well-supported in nixpkgs, then roll up your sleeves and make the contribution that you want to see.
  - pjmlp 7y ago
    Sadly the supermarket around the corner doesn't take pull requests as payment.
    - lidHanteyk 7y ago
      You think people ought to be paid for writing code. Pathetic. Code is too valuable to be paid for; it ought to be part of a commons, not part of some corporate portfolio. I think that you're just embarrassed that you contribute [0] next to nothing to the community. [0] https://github.com/pjmlp https://github.com/pjmlp
      - pjmlp 7y ago
heavenlyblue 7y ago
You can still re-install all of the dev tools on top of your prod images.
hackworks 7y ago
Well, there is a well defined pattern using configure and make. When very complex builds like GNU Emacs and operating systems have done quite well with this pattern, I wonder what problem we are trying to solve.
- servilio 7y ago
  That's a very apple to oranges comparison, wouldn't you agree? GNU autotools assists in making source code packages portable accross Unix-like systems, while make is for build automation and has fine-level dependencies (inter-files). Nix is a package manager, and though is can build your software for you transparently, it is not tied to and specific software configurationand building toolset, can manage buildtime and runtime dependencies (including downloading the sources), caching build results transparently, etc.
Legogris 7y ago
You skipped the "spend 3 hours figuring out why libgcc_s.so.1 won't link when trying to compile that one protobuf tool you need right now" step. Seriously, I dread every time I have to compile C++ in NixOS and there's no existing derivation already. Oh, and when the Omnisharp guys start requiring a new version of mono that won't build the same way for whatever reason, so you're stuck on old versions of your IDE plugins if you want C# support until someone else figure out what broke.

acqq 7y ago

> Today: Install Nix I'm missing something here. (Disclaimer: I've just tried to understand the OP, I don't know all the details about what is going on there). The text starts with "In my last post about Nix, I didn’t see the light yet." ... Then it continues with "A popular way to model this is with a Dockerfile." So I have expected that the post will demonstrate how Nix can be used without docker... But then later: "so let’s make docker.nix:" and continues in that way. So there is some dockering involved? To this casual reader, it doesn't seem that using Nix allows one to avoid docker, as a technology, but just that some additional goal is achieved by using Nix over that. I just missed what was actually achieved, other than that the text mentions a few megabytes less here or there, of 100 MB, and that I also miss the information if the megabytes were traded in the build time or, if I understand correctly, in some way even more dependencies (more places from which something has to download something). Can anybody explain? I'm sure that these tradeoffs were obvious to the author, but I as a reader hoped to somehow get the idea of those, and I missed that (yes, it's hard to "see the light" especially indirectly).

Nullabillity 7y ago
Nix itself doesn't use Docker, and you can deploy it like that just fine (with NixOS, and NixOps if you have multiple machines). But sometimes your ops team has standardized on Docker, maybe because you're using Kubernetes. In that case, Nix will happily build those images for you.
marcus_holmes 7y ago
The big one that I got is that the resulting Nix image has just the Go executable in it, and so the server is safer because if anyone hacks into it they'd need to bring their own copy of any tools they wanted with them. I'm a huge fan of reducing attack surfaces wherever possible, and getting a container that will only run the program required and nothing else is a win for me.
- acqq 7y ago
  > The big one that I got is that the resulting Nix image has just the Go executable in it Now I miss the point of that one too: if just a Go executable alone can be enough anyway, as it is statically linked, why not just copying it, instead of complicating around?
  - tiew9Vii 7y ago
    A lot of people have standardised on Docker images as the default distribution/packaging format as Kubernetes etc make deploying/running them more standardised across orgs. You can build the binary then have a Dockerfile copy it in from the scratch base image. However if you are using nix for deterministic builds you might as well add the few lines of code to have nix build the docker image to vs a Docker file with a single copy command. If you are not building a static binary you get the advantage nix will copy in only the dependencies needed. You also get the advantage when you are building images you not randomly downloading urls from the internet that may be dead. Artifacts can come from a nix build cache which is cryptographically signed based on the build inputs so you know building the same image every time produces the same output. With typical Dockerfiles that is not true. Docker images are not immutable so fetching the same Docker image may result in a different image being fetched. Likewise a lot of Docker files just wget / yum install random packages from places that may not exist anymore. If you maintain your own nix build cache you will always be able to build, get speedup from hitting the build cache vs compiling and know the build is deterministic. Running the same build multiple times will result in the exact same output.

pjmlp 7y ago

Nix does not set up my Visual Studio and XCode environments, Unity, Unreal, nor OEMs SDKs.

deleted 7y ago
[deleted]
georgyo 7y ago
Look up nix home manger, you might be able to have nix configure everything in your home directory. Also nix makes it pretty trivial to package and patch propriety binary vendor software. It would take at least one person on the development team feeling comfortable with nix, but they could craft a nix file that does everything.
lidHanteyk 7y ago
As well it shouldn't. Proprietary software is trash and should be thrown out. Nix supports unfree software, and has many tools for torturing unfree packages until they yield the desired binaries and filesystem layout; if you want your particular unfree software to be well-supported in nixpkgs, then roll up your sleeves and make the contribution that you want to see.
- pjmlp 7y ago
  Sadly the supermarket around the corner doesn't take pull requests as payment.
  - lidHanteyk 7y ago
    You think people ought to be paid for writing code. Pathetic. Code is too valuable to be paid for; it ought to be part of a commons, not part of some corporate portfolio. I think that you're just embarrassed that you contribute [0] next to nothing to the community. [0] https://github.com/pjmlp https://github.com/pjmlp
    - pjmlp 7y ago

heavenlyblue 7y ago

You can still re-install all of the dev tools on top of your prod images.

hackworks 7y ago

Well, there is a well defined pattern using configure and make. When very complex builds like GNU Emacs and operating systems have done quite well with this pattern, I wonder what problem we are trying to solve.

servilio 7y ago
That's a very apple to oranges comparison, wouldn't you agree? GNU autotools assists in making source code packages portable accross Unix-like systems, while make is for build automation and has fine-level dependencies (inter-files). Nix is a package manager, and though is can build your software for you transparently, it is not tied to and specific software configurationand building toolset, can manage buildtime and runtime dependencies (including downloading the sources), caching build results transparently, etc.

Legogris 7y ago

You skipped the "spend 3 hours figuring out why libgcc_s.so.1 won't link when trying to compile that one protobuf tool you need right now" step. Seriously, I dread every time I have to compile C++ in NixOS and there's no existing derivation already. Oh, and when the Omnisharp guys start requiring a new version of mono that won't build the same way for whatever reason, so you're stuck on old versions of your IDE plugins if you want C# support until someone else figure out what broke.