Nix as OS X Package Manager
41–50 of 209 posts
Re: Nix as OS X Package Manager
#42When I first heard about Docker, I thought it did what Nix does. Then someone handed me a docker image saying, "I got this working on my laptop, deploy this. Isn't this great!". I had no idea how they arrived at that configuration. If something happened to them or that image, I wouldn't have known how to reproduce that "working state". So I am happy to see Nix / Guix become popular. It is what I imagined package mana…
> I wouldn't have known how to reproduce that "working state". So what? You don't need to reproduce that working state: The work has already been done! Think about how the interactive approach Lisp and Smalltalk programmers use is superior to the compile/run/rerun approach used by C++ and Java programmers -- by exploring the problem in a nonlinear way, you can find your way to a solution more quickly. Docker package…
Re: Nix as OS X Package Manager
#43I recently set up a new server for a toy project with nixos and it was a pleasurable experience, even if I did have to pull together several sources of somewhat thin documentation. Recommended. Next time I set up a new dev machine I'm going to give nix a try for dev environment management. Using nixops to push a closure from your local system up to ec2 is very pleasing. It feels like the future.
For a toy project this is not a problem of course. But before I'd use nixos in production, it needs a better story for security patches. If you try to look up the word 'security' you get viagra spam on their wiki. and there is no security mailinglist whatsoever iirc.
I'm sure this will improve over time though. And for development, nix is still a saviour.
Re: Nix as OS X Package Manager
#44Earlier quoted context omitted.
> I wouldn't have known how to reproduce that "working state". So what? You don't need to reproduce that working state: The work has already been done! Think about how the interactive approach Lisp and Smalltalk programmers use is superior to the compile/run/rerun approach used by C++ and Java programmers -- by exploring the problem in a nonlinear way, you can find your way to a solution more quickly. Docker package…
Working with Lisp images: it's horrible when you lose track of what runtime change allows your code to continue working. You typically keep a working compilation between code and your intended environment, and use the run time to experiment in between changes.
Re: Nix as OS X Package Manager
#45When I first heard about Docker, I thought it did what Nix does. Then someone handed me a docker image saying, "I got this working on my laptop, deploy this. Isn't this great!". I had no idea how they arrived at that configuration. If something happened to them or that image, I wouldn't have known how to reproduce that "working state". So I am happy to see Nix / Guix become popular. It is what I imagined package mana…
I mean, that's exactly what a Dockerfile is for. I don't know of anyone seriously using Docker that isn't using Dockerfiles exclusively. I only know of a single time when it's valuable to "commit" a new image (recovering logs from a stopped container). None of which is to detract from Nix. Nix+Docker is a powerful combination. It takes Docker's declarative nature all the way down to the compiler used to build the bit…
Are you screwed if you lose a working .git project, or its maintainer? Well, yeah. But we don't actively worry about that happening all that much because we routinely take precautions like distributing it across developer's machines and servers.
Maybe a commit does break, but that's why we didn't just overwrite the previous image.
But also:
> I only know of a single time when it's valuable to
> "commit" a new image (recovering logs from a stopped
> container)
Not everything's open source.Re: Nix as OS X Package Manager
#46The nixos.org website is a bit sparse on the Nix project's history, and same with wikipedia (though separately mentions that NixOS was a research project started by Eelco Dolstra in 2003).
Re: Nix as OS X Package Manager
#47When I first heard about Docker, I thought it did what Nix does. Then someone handed me a docker image saying, "I got this working on my laptop, deploy this. Isn't this great!". I had no idea how they arrived at that configuration. If something happened to them or that image, I wouldn't have known how to reproduce that "working state". So I am happy to see Nix / Guix become popular. It is what I imagined package mana…
> I wouldn't have known how to reproduce that "working state". So what? You don't need to reproduce that working state: The work has already been done! Think about how the interactive approach Lisp and Smalltalk programmers use is superior to the compile/run/rerun approach used by C++ and Java programmers -- by exploring the problem in a nonlinear way, you can find your way to a solution more quickly. Docker package…
My background is physics, and the philosophy there is "If you can't reproduce it, it doesn't exist."
In my experience with software, sharing opaque binary blobs is a Bad Thing. It doesn't matter if the blob is a proprietary firmware image, or a "open source" docker image. It's a magic unreproducible image. And (to me, at least) therefore suspect.
> Docker package management is like that: You make some changes, you commit often, fork your instance and try lots of different things. Eventually you find something that works and you tag it.
Again, the physics philosophy is "If you don't know what you did, you didn't do it".
For software, programming by randomly trying things is one of the worst methods available. You should understand what you're doing, and understand the system you're building.
> You share your tags with other people. This is an extremely productive way to get work done.
Sure. It's a way to quickly create, test, roll back, and share opaque binary blobs. It's "productive" in that you get things done. But you have no real idea what you got done. You just have a magic image that "works".
I would not hire a programmer with that kind of attitude. I've been burnt by that method, and those kind of programmers, too many times.
Re: Nix as OS X Package Manager
#48Since I discovered Nix, I've been using it as a package manager for OS X and Linux. Every project my team is working on now has a default.nix file. Getting started on a project is so easy for a new hire now: just one `nix-env` away from a fully working dev environment! :D
Re: Nix as OS X Package Manager
#49I recently set up a new server for a toy project with nixos and it was a pleasurable experience, even if I did have to pull together several sources of somewhat thin documentation. Recommended. Next time I set up a new dev machine I'm going to give nix a try for dev environment management. Using nixops to push a closure from your local system up to ec2 is very pleasing. It feels like the future.
A big help is IMO to get a solid understanding about how nix itself works[1]. Also check out some existing `configuration.nix` files on GitHub. Just google for "github configuration.nix". This might give you some inspiration what you can do with the `configuration.nix`.
If you have some trouble with customizing vim on NixOS/via nix, checkout this[2] blog post I wrote a month ago. Hope it helps :)
[0] http://blog.tinco.nl/2016/02/05/nixos-on-digital-ocean.html [1] https://nixos.org/nix/about.html [2] https://www.mpscholten.de/nixos/2016/04/11/setting-up-vim-on...
Re: Nix as OS X Package Manager
#50I recently set up a new server for a toy project with nixos and it was a pleasurable experience, even if I did have to pull together several sources of somewhat thin documentation. Recommended. Next time I set up a new dev machine I'm going to give nix a try for dev environment management. Using nixops to push a closure from your local system up to ec2 is very pleasing. It feels like the future.
I did this too until there was a glibc vulnerability. and it took ages for a 'patch' to come out that had to be installed in an obscure way. For a toy project this is not a problem of course. But before I'd use nixos in production, it needs a better story for security patches. If you try to look up the word 'security' you get viagra spam on their wiki. and there is no security mailinglist whatsoever iirc. I'm sure th…
Rather than rebuild everything that depends on the fixed glibc, we build the fixed glibc, then rewrite all references to the old glibc to refer to the new one. That rewriting happens in new copies of the referring packages, of course, since the "store" is immutable.
https://www.gnu.org/software/guix/manual/html_node/Security-... https://savannah.gnu.org/forum/forum.php?forum_id=8470