Live data from Hacker News

Purely Functional Linux with NixOS [video]

begriffs.com

21–30 of 143 posts

Re: Purely Functional Linux with NixOS [video]

#21

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.

Re: Purely Functional Linux with NixOS [video]

#22
post #18

Anyone using NixOS as a server in production? We're on FreeBSD now but I think Linux in our stack is inevitable (many servers, like Aerospike, are Linux only). There's always Ubuntu, but this looks lovely. I've had my eye on it for a personal Linux workstation but haven't heard anything about it as a server.

I've used it as a server before and it's quite nice, it just requires getting used to the nix language a bit and possibly dealing with customization work when something you need isn't exposed already in /etc/nixos/configuration.nix. For example, imagine you needed some weird iptables functionality - you might end up writing some shell-ish rules using 'networking.firewall.extraCommands' [ https://github.com/NixOS/nixo…

I should add that there are the obvious benefits to these 'constraints' -- if you can stick with mostly what's exposed already in the default nix packages your configuration will be very clean and your system will be built in a reproducible way from the start.

Re: Purely Functional Linux with NixOS [video]

#23

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.

Re: Purely Functional Linux with NixOS [video]

#24

Anyone using NixOS as a server in production? We're on FreeBSD now but I think Linux in our stack is inevitable (many servers, like Aerospike, are Linux only). There's always Ubuntu, but this looks lovely. I've had my eye on it for a personal Linux workstation but haven't heard anything about it as a server.

I'm using a NixOS server in prod for an application. Works very nicely, makes deployment a breeze. I went from never using NixOS to having a production-ready deployment, including writing a nixpkg for Nignx configuration and my application, all in about a day. I love how an entire server can be configured with a single Nix file (configuration.nix) along with any custom packages, which are again flat-files.

NixOS works best when you're 'all-in' with Nix, including using nixkpkgs over language package managers (or having such package managers be nix-aware). This is not something that's easily done right now, and precludes having a 'pure' Nix experience, especially when using it for dev purposes.

In my case though, where the main application is a binary written in OCaml (which uses the opam package manager), NixOS makes it straightforward to build and distribute binary packages that are patched to the correct library paths on the system. Once that was set up, everything else was a breeze. Server maintenance is almost effortless.

Re: Purely Functional Linux with NixOS [video]

#25

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.

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

Re: Purely Functional Linux with NixOS [video]

#26

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.

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?

Re: Purely Functional Linux with NixOS [video]

#27
post #16
post #11

Earlier quoted context omitted.

Normally you end up only a single version of a library needed in the scope of one application. E.g. application A depends on libraries B and C and both of these depend on the same version of library D. And there is no problem as long as this is the case, the exact same library will be used. If for some reason B and C depend on different versions of a library, then things may go wrong, e.g. one package may end up inad…

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?

Well yes strictly speaking, the same binary. But in practice with Nix's default library resolution logic (the mentioned compiler wrapping) you will probably also have problems trying to build binaries in one package using version of a library (see note [1]). That is, I think you'd have to do some "hacking" to fix the issue, or separate the binaries into different packages (and maybe create a new package that "assembles" all the binaries by creating symlinks to them).

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

Yes, well actually, the thing is that typically you only "install" (into a user environment) final applications (A) that you need not libraries, so the libraries (B) can be considered to not really be installed, just available (somewhere in /nix/store) and referenced correctly (e.g. by RPATH).

[1] When you declare a dependency in a package specification by putting it into buildInputs, the compiler wrapper will automatically add an -L/lib so that linking with just -l will find the library. With multiple versions of a library in buildInputs, that becomes a problem.

Re: Purely Functional Linux with NixOS [video]

#29

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.

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?

Re: Purely Functional Linux with NixOS [video]

#30
post #16
post #11

Earlier quoted context omitted.

Normally you end up only a single version of a library needed in the scope of one application. E.g. application A depends on libraries B and C and both of these depend on the same version of library D. And there is no problem as long as this is the case, the exact same library will be used. If for some reason B and C depend on different versions of a library, then things may go wrong, e.g. one package may end up inad…

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.
Post reply on HN