Live data from Hacker News

Nix as OS X Package Manager

ariya.ofilabs.com

61–70 of 209 posts

Re: Nix as OS X Package Manager

#61
post #56

Earlier quoted context omitted.

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…

The big difference is that nothing about Dockerfiles implies that the processes they perform to build an image are deterministic or repeatable. Will a build step that runs `curl https://github.com/something/whatever` do the same thing in six months that it does today? Docker doesn't help with that at all. Nix improves determinism by (almost) guaranteeing that if you build the same nix expression six months from now,…

In practice, one can check the Dockerfile lineage of a given Docker image and assess the quality of the commands. Good practices are to use package managers with explicit versions, for example "apt-get install subversion-tools=1.3.2-5~bpo1". Or, if you so desire, just pipe NixOS outputs into Docker, as somebody else in this thread mentioned.

Re: Nix as OS X Package Manager

#62

I was forcefully relocated from my comfortable decade-old Debian home into OS X, and the package management here in unsatisfying. I'm looking forward to future posts that show how Nix is better than Homebrew or MacPorts, because that hasn't been demonstrated so far. And as a bikeshed nitpick, I was always unhappy with the meaningless rpm options, preferring apt's clearer options (rpm -qa vs aptitude search). I'm a bi…

Try pkgsrc. It's much more like apt than nix, macports, or homebrew.

Re: Nix as OS X Package Manager

#63

I was forcefully relocated from my comfortable decade-old Debian home into OS X, and the package management here in unsatisfying. I'm looking forward to future posts that show how Nix is better than Homebrew or MacPorts, because that hasn't been demonstrated so far. And as a bikeshed nitpick, I was always unhappy with the meaningless rpm options, preferring apt's clearer options (rpm -qa vs aptitude search). I'm a bi…

apt-cache search aptitude isn't necessarily installed.

The new apt, if you have it, now combines apt-get with apt-cache plus a bunch of UI improvements.

    apt search ...
    apt install ...
If you've got it, it's well worth a look.

Re: Nix as OS X Package Manager

#64
post #60

Why use nix when pkg-src has been available on Darwin for over 15 years, boasts more packages, and has decades of support (plus Jonathan Perkin and the guys over at Joyent)? Why people assume the gross project known as homebrew (and the better macports, where homebrew gets all of their real package patches) are the only two package managers on OS X/Darwin is perplexing to me... Not to say nix is not interesting, but…

Both of your links are broken.

Re: Nix as OS X Package Manager

#65
post #33

Earlier 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.

This reminds me of one of the good things APL has. You can interactively change anything in your workspace, and all the things (array, function, operators) can be serialized, programmatically within the language.

Re: Nix as OS X Package Manager

#66
post #33
post #15

When 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…

How do you recommend applying security updates to the image, short of running (for example) `apt-get dist-upgrade`? What if that breaks? Do you just continue with the out-of-date image?

Re: Nix as OS X Package Manager

#67
What happens when packages need to store data?

For example, installing Datomic via Brew will result in databases being stored in:

/usr/local/Cellar/datomic/0.9.5206/libexec/data

How would that work with Nix? Would the data live under /nix?

And most importantly, would that data get squashed because of some kind of idempotency assumptions that Nix might make?

Re: Nix as OS X Package Manager

#68
post #15

When 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…

Also people forget that the Nix philosophy doesn't end in the package manager Nix, there's also NixOS which takes a functional approach to configuration management of the whole OS. And many other things.

Re: Nix as OS X Package Manager

#69
post #47
post #33

Earlier 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…

> You don't need to reproduce that working state: The work has already been done! 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) therefor…

We wrote an article about the same thing https://blog.wearewizards.io/why-docker-is-not-the-answer-to... (Tom has a background in physics as well)

Re: Nix as OS X Package Manager

#70
post #60

Why use nix when pkg-src has been available on Darwin for over 15 years, boasts more packages, and has decades of support (plus Jonathan Perkin and the guys over at Joyent)? Why people assume the gross project known as homebrew (and the better macports, where homebrew gets all of their real package patches) are the only two package managers on OS X/Darwin is perplexing to me... Not to say nix is not interesting, but…

Hmm.. I've never tried pkg-src before. I'll give it a try.

Step 1: I have to download a gig of stuff before I can install any packages? Even though my drive is big nowadays, that still seems like a bit of a waste...

Step 2: Let's try building a package, the last thing I installed with homebrew.

    > cd math/minisat
    > make install clean
    Makefile:27: *** missing separator.  Stop.
    > make
    Makefile:27: *** missing separator.  Stop.
Hmm.. this isn't the most user-friendly system...

UPDATE: I have to use the bmake I bootstrapped, didn't realise (and the quick-start docs didn't mention it). Now building begins, but the executable doesn't link.

Post reply on HN