Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nix as OS X Package Manager

ariya.ofilabs.com

Post reply on HN
Print view View original

151–160 of 209 posts

Re: Nix as OS X Package Manager

#151

Post by eridius »

SwellJoe wrote: post #141
lilyball wrote: post #115

Earlier quoted context omitted.

Homebrew is not dangerous. Please don't spread FUD. Your link specifically covers the case of Homebrew on the server . But Homebrew isn't meant to be a server package manager. It's an OS X package manager, and OS X is a desktop operating system, not something that most people choose to use as a server (OS X Server exists but is primarily used for intranet stuff rather than as a production server). The complaints that…

I had no trouble finding people talking about using it on servers during my research. I even found people wanting it and discussing porting it for use on Linux (which is among the most ridiculous suggestions I can imagine, since Linux has an embarrassment of riches in terms of good and great package management options). So, yes, to be clear: The dangers of Homebrew are primarily when considering it for use in a serve…

The people who are trying to use it on servers are misguided. The people who are trying to use it on Linux are just crazy. Homebrew itself has never pretended to be anything other than an OS X package manager aimed at desktop users.

If you want to say "Homebrew is dangerous when used on a public-facing server", that's entirely fair. But that's not what you said. I'm glad that you do recognize this distinction though, and I hope you will think twice before claiming again that Homebrew is dangerous without qualification.

Re: Nix as OS X Package Manager

#152

Post by geocar »

adekok wrote: post #47
geocar wrote: 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…

> In my experience with software, sharing opaque binary blobs is a Bad Thing

And yet you don't know why.

This is called dogma, and dogma is bad: It leads people to make stupid decisions over and over, all the while repeating that the alternative is worse.

Re: Nix as OS X Package Manager

#153

Post by geocar »

Keats wrote: post #69
adekok wrote: post #47

Earlier quoted context omitted.

> 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)

You are assuming "that reproducibility is good".

I believe this assumption needs to be challenged.

Re: Nix as OS X Package Manager

#154

Post by geocar »

falcolas wrote: post #66
geocar wrote: 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…

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?

> How do you recommend applying security updates to the image, short of running (for example) `apt-get dist-upgrade`?

That's exactly how I recommend applying patches.

If it breaks things you can fix it.

You don't do this on a live system: If you're smart and your live systems are ephemeral you can copy your image, get it working, verify it interactively, and once you have a working image, you spin up new instances using the new system, and start shutting down the old systems.

Re: Nix as OS X Package Manager

#155

Post by geocar »

bjt wrote: post #85
falcolas wrote: post #66

Earlier quoted context omitted.

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?

This is the biggie for me. When the next heartbleed comes out, it would REALLY suck to be running a bunch of opaque images that you have no idea how to patch.

That's an unrelated problem. Developing your systems interactively, instead of reimplementing them over and over again produces the same results, just faster. If your servers aren't ephemeral, or you only have "one machine", or if you don't know about heartbleed patching, then you're going to be fucked anyway.

Re: Nix as OS X Package Manager

#157

Post by geocar »

yaowenjiaozi wrote: post #123
oconnore wrote: post #42

Earlier quoted context omitted.

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.

In Smalltalk implementations like Pharo, Squeak etc changes are captured in a changes file. If the image crashes before being saved, it is possible to cherry pick and replay unsaved changes from the changes file.

You can do this with Docker as well: Mount two commits and diff between them, pull bits into a third.

It's also a surprisingly convenient way to build tests.

Re: Nix as OS X Package Manager

#158

Post by geocar »

rdtsc wrote: post #102
bjt wrote: post #85

Earlier quoted context omitted.

This is the biggie for me. When the next heartbleed comes out, it would REALLY suck to be running a bunch of opaque images that you have no idea how to patch.

That's the thing, I surprised how many people were "ok" with that binary imagine that someone built on their laptop. Few saw an issue with it, and instead praised it as a great win. I mean, it was a win, not having to untangle the hairball of rpm/deb dependencies. I like that part too. But not understanding the downside was what shocked me. It was like everyone drank the magic kool-aid potion.

> I surprised how many people were "ok" with that binary imagine that someone built

Really? This surprises you?

The gross majority of the world runs software this way.

The real issues are quality control and release process.

Re: Nix as OS X Package Manager

#159

Post by geocar »

DigitalJack wrote: post #44
oconnore wrote: post #42

Earlier quoted context omitted.

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.

I think this all the time. I have to refresh my clojure repl because I forget what I've eval'd or not and the cognitive load of mentally tracking that state is not something I want to bother with.

Clojure is unusually leaky compared to Unix/Linux or (for example) Erlang.

If we design systems out of a collection of processes, that we can replace at will, then what we actually have is a collection of checkpoints and branches that we can try simultaneously. Replacing individual branches allows us to try out changes there, without having to rebuild (and wait) the entire system.

Another way to think about this, is that Clojure is more like subversion than like git: It might be better than RCS, but you're still stuck with a linear revision history, and new changes can't completely conflict with old objects and old changes that are created.

And yet another way, is to imagine all of those old class definitions that old objects hold onto are actually global variables, because they have global (time) extent, and yet are unreachable, so it's difficult to find out whether your new code is being affected by those old settings.

Smalltalk, and even other (esp. Commercial) Lisps don't have this problem. It has nothing to do with interactivity, but with hidden state.

Re: Nix as OS X Package Manager

#160

Post by Singletoned »

geocar wrote: post #152
adekok wrote: post #47

Earlier quoted context omitted.

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

> In my experience with software, sharing opaque binary blobs is a Bad Thing And yet you don't know why. This is called dogma, and dogma is bad: It leads people to make stupid decisions over and over, all the while repeating that the alternative is worse.

No, this is called learning from experience.

If you put your hand in a fire 5 times and it burns you 5 times, you don't have to understand anything about fire to know that you should probably stop putting your hand in. And if you saw other people about to put their hand in, you would mention to them that everytime you put your hand in, you end up regretting it.

Post reply on HN