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

Purely Functional Linux with NixOS [video]

begriffs.com

Post reply on HN
Print view View original

31–40 of 143 posts

Re: Purely Functional Linux with NixOS [video]

#31

Post by davexunit »

ambrop7 wrote: post #21
qwertyuiop924 wrote: post #15

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)

- 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 software packaged than Nix in the first place, AFAIK).

Guix is younger, thus has less software packaged, but the number of new packages introduced with each Guix release continues to increase. I have all the packages most important to me and have been using GuixSD exclusively for at least a year now.

>Nix is a pretty good language for the task.

The problem with any DSL is that is not very extensible and developers must spend time maintaining parsers, compilers, etc. for a one-off language. Guix is achieving its velocity in good part thanks to using an existing general purpose language that new languages can be embedded within.

Re: Purely Functional Linux with NixOS [video]

#32

Post by davexunit »

dbcurtis wrote: post #26
grumpyprole wrote: post #17

Earlier quoted context omitted.

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

After a quick look at Nix syntax, it seems to me that it is almost JSON but different enough to required all new parsers. Maybe I'm wrong about that. But... why not just use JSON?

JSON isn't a programming language.

Re: Purely Functional Linux with NixOS [video]

#33

Post by davexunit »

tener wrote: post #29
davexunit wrote: post #25

Earlier quoted context omitted.

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

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?

Re: Purely Functional Linux with NixOS [video]

#34

Post by vertex-four »

dbcurtis wrote: post #26
grumpyprole wrote: post #17

Earlier quoted context omitted.

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

After a quick look at Nix syntax, it seems to me that it is almost JSON but different enough to required all new parsers. Maybe I'm wrong about that. But... why not just use JSON?

Nix is actually a purely function programming language - you can embed function calls in it. This is used to great effect in various parts of nixpkgs - the entire thing is actually a program which returns the Nix package tree (but is not fully evaluated unless you explicitly ask for it).

Re: Purely Functional Linux with NixOS [video]

#35

Post by dbcurtis »

davexunit wrote: post #32
dbcurtis wrote: post #26

Earlier quoted context omitted.

After a quick look at Nix syntax, it seems to me that it is almost JSON but different enough to required all new parsers. Maybe I'm wrong about that. But... why not just use JSON?

JSON isn't a programming language.

True enough. Maybe I've not seen enough of what is in a Nix packaging script.

Re: Purely Functional Linux with NixOS [video]

#36

Post by qwertyuiop924 »

davexunit wrote: post #33
tener wrote: 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?

Checksums!

Re: Purely Functional Linux with NixOS [video]

#37

Post by ambrop7 »

dbcurtis wrote: post #30
nine_k wrote: 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.

I think that they don't do too drastic changes. There are certainly checks in the compilation process to not accidentally link to /usr/lib/ libraries, but I think the main problem of finding libraries works with a simple compiler wrapper adding needed -Lflags (for finding libs at compile time) and RPATH entries to binaries (for finding libs at run time). There of course may be "hacks" made to gcc/libc but I don't see a reason they would be essential for functioning.

One notable thing Nix does is hardcode a path to a specific dynamic linker (e.g. /nix/store/HASH-glibc-2.23/lib/ld-linux-x86-64.so.2). All other dynamic libraries should be referenced through soname+RPATH.

Re: Purely Functional Linux with NixOS [video]

#38

Post by chriswarbo »

dbcurtis wrote: post #26
grumpyprole wrote: post #17

Earlier quoted context omitted.

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

After a quick look at Nix syntax, it seems to me that it is almost JSON but different enough to required all new parsers. Maybe I'm wrong about that. But... why not just use JSON?

You can use `builtins.toJSON` and `builtins.fromJSON` to inter-operate with JSON.

They don't handle functions or infinite datastructures though.

Re: Purely Functional Linux with NixOS [video]

#40

Post by rdtsc »

davexunit wrote: post #25
corysama wrote: post #23

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.

Not knowing the practicalities and details of how either one works, and talking in general, I don't see how binaries would make things not-reproducible. One can take a hash of firmware blob just as well as a hash of a source file.
Post reply on HN