Live data from Hacker News

Purely Functional Linux with NixOS [video]

begriffs.com

41–50 of 143 posts

Re: Purely Functional Linux with NixOS [video]

#41
post #29

Earlier quoted context omitted.

How so? You can see the build as a pure function. It consumes a binary blob but it doesn't make it any less deterministic?

The build is a source to binary function. How does one reproduce the binary blob? How does one know that binary hasn't been tampered with?

How does one reproduce a .c file? By copying the file. Either way, you know the bits of both the .c and the .so have not been tampered with because you can verify their hashes. Again, it's a philosophical distinction, not a technical one.

Re: Purely Functional Linux with NixOS [video]

#42

Earlier quoted context omitted.

Like everything else with Gnu, the main difference seems to be philosophical. Guix is fundamentally opposed to pre-compiled binaries. Nix has no issue with them.

>Guix is fundamentally opposed to pre-compiled binaries. Nix has no issue with them. Using pre-compiled binaries means that builds aren't reproducible, a goal of both Nix and Guix.

So, Nix refers to every blob that gets built using an MD5. I should think it would be pretty easy to tell if you have the same binary that somebody else does. And if you can walk a tree of MD5's, you should be able to assert that system A is configured the same as system B.

Re: Purely Functional Linux with NixOS [video]

#43
post #29

Earlier quoted context omitted.

How so? You can see the build as a pure function. It consumes a binary blob but it doesn't make it any less deterministic?

The build is a source to binary function. How does one reproduce the binary blob? How does one know that binary hasn't been tampered with?

And how do you know the source code hasn't been tampered with?

The same way: cryptographic signatures and checksums.

Re: Purely Functional Linux with NixOS [video]

#44
post #29

Earlier quoted context omitted.

How so? You can see the build as a pure function. It consumes a binary blob but it doesn't make it any less deterministic?

The build is a source to binary function. How does one reproduce the binary blob? How does one know that binary hasn't been tampered with?

Can't trust the source either, if you're worried about it being tampered with right? At some point you have to trust something, likely from a central location.. either a checksum, blob, source, or etc.

Re: Purely Functional Linux with NixOS [video]

#45

My Linux experience so far has been limited to ls, cd and vi. From the outside, package management has always seemed to me like a huge mess. But, I've been starting to learn Nix recently and I really like it. I can add, remove, test, screw up, change my mind, whatever without stress.

"From the outside, package management has always seemed to me like a huge mess."

Compared to what?! There's no OS that has historically had better (or even close to as good) package management as Linux, either in the form of apt-get/dpkg or yum/RPM. Nix is probably better, on a couple of dimensions, but to suggest it was a mess before...well, I just wonder what you could be comparing to that would be better?

Re: Purely Functional Linux with NixOS [video]

#46
I love the idea of NixOS, but overall i think i need to wait for it to be a bit more user friendly. The number of times i was completely perplexed when i tried to use this as my home server was.. well, numerous.

Awesome idea, and the rollbacks were great, but i kept having to write my own packages and it was all a bit too confusing to do that constantly.

Re: Purely Functional Linux with NixOS [video]

#47
post #21

Earlier quoted context omitted.

- I think the issue is partly made moot by that not many people know Guile/Scheme in the first place, so they'd need to learn one language anyway. - Guix refuses to integrate proprietary software so its usability is diminished compared to Nix (and Guix has less software packaged than Nix in the first place, AFAIK). - Nix is a pretty good language for the task.

>I think the issue is partly made moot by that not many people know Guile/Scheme in the first place, so they'd need to learn one language anyway. But this language is not a DSL, but a general purpose language that has pattern matchers, HTTP libraries, XML parsers, data structure implementations, etc. >Guix refuses to integrate proprietary software so its usability is diminished compared to Nix (and Guix has less soft…

> But this language is not a DSL, but a general purpose language that has pattern matchers, HTTP libraries, XML parsers, data structure implementations, etc.

I'm not expressing this as a criticism that I have, but for some people what you described is not a feature but a bug. :)

Re: Purely Functional Linux with NixOS [video]

#48

Am I the only one who thought Guix did this better? Maybe it's just my freakish and unnatural love of parenthesis. Or my hatred of learning new configuration syntaxes (I just want to install packges, dammit! Yes, I enjoy learning new languages, but I need to get this machine up and running, and I don't want to learn your new programming language to do that)

IMHO, Nix needs a static type checker far more than it needs parenthesis or syntactic abstraction. The syntax of Nix is a non-issue.

I understand, but guix works well enough, and I don't want to learn another PL just to do package managemnt. Then again, I guess that's why people use nix instead of guix.

Re: Purely Functional Linux with NixOS [video]

#49
post #16

Earlier quoted context omitted.

I suspect that the same binary cannot realistically depend on two different versions of a library. I can imagine that package A may have two binaries, one depending on a library B version 1.1, and another, on B 1.2 Does NixOS allow to have both B-1.1 and B-1.2 installed, and A's different binaries to load the correct different versions of the library from B-1.1 and B-1.2?

As I understand it, Nixos runs their own patched versions of ld and the dynamic loading system calls in libc. The normal lib.so search mechanism is replaced wholesale with "thou shalt link against this dll and no other" on a per-execuatble basis. Multiple versions of .so's don't cause problems, because no executable is depending on a search mechanism it doesn't control.

Actually, I think they use the standard ld.so... it's just that for every executable, the RPATH in the header of the executable is set to a list of directories where the libraries it was built against can be found. ld.so uses the RPATH to find libraries by default.

Re: Purely Functional Linux with NixOS [video]

#50

Am I the only one who thought Guix did this better? Maybe it's just my freakish and unnatural love of parenthesis. Or my hatred of learning new configuration syntaxes (I just want to install packges, dammit! Yes, I enjoy learning new languages, but I need to get this machine up and running, and I don't want to learn your new programming language to do that)

Like everything else with Gnu, the main difference seems to be philosophical. Guix is fundamentally opposed to pre-compiled binaries. Nix has no issue with them.

Which is why, if anything, I'd do what Andy did. (https://wingolog.org/archives/2015/08/04/developing-v8-with-...)
Post reply on HN