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

71–80 of 143 posts

Re: Purely Functional Linux with NixOS [video]

#71

Post by chriswarbo »

Artlav wrote: post #51
SwellJoe wrote: post #45

Earlier quoted context omitted.

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

Perhaps it's about expecting to have program locality? I.e. you download a zip file, you unpack it into a directory, and here is your entire program. Right there, in that directory, not splattered around the filesystem by the package manager. That's the way it's done on Windows, anyway.

Last time I used Windows very little would work unless it was a) installed and b) installed to "C:\Program Files" (some software, can't remember which, would let you choose a different location, but wouldn't work).

It crushed my dreams of a small Windows partition + a large data/programs partition :(

Re: Purely Functional Linux with NixOS [video]

#72

Post by davexunit »

rdtsc wrote: post #40
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.

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.

"Reproducible builds are a set of software development practices which create a verifiable path from human readable source code to the binary code used by computers."

https://reproducible-builds.org/

Re: Purely Functional Linux with NixOS [video]

#73

Post by edude03 »

davexunit wrote: post #66
SwellJoe wrote: post #53

Earlier quoted context omitted.

That doesn't make sense. A reproducible build means that a build done in two different places results in the same binary. It has nothing to do with whether the vendor distributes binaries (with optional source) or source alone. The binary is what matters. i.g., if I build this package myself, will it result in the exact same binary that I download from the vendor? Binaries can be signed to prove that the chain of tru…

The intent of reproducible builds, as defined by the reproducible builds project[0], is to have the entire dependency tree built from the complete, corresponding source code of the many projects in that tree, starting from a minimal set of "bootstrap binaries"[1]. Using precompiled binaries, without a doubt, invalidates that goal. Reproducible builds are an ongoing, unsolved problem. In Guix, some things are reproduc…

I'm pretty sure the goal of reproducible builds is to be able to get the same binary as made somewhere from the source code. Arguably binaries are a form of memoizing / caching if you look at compilation as a pure functional problem. For example, if I have build system that says "with file a hash = 1234 and file b with hash = 4321 I should get a binary with hash = 9876 you can save time compelling that package to check its hash by simply asking the binary repo for a package with hash 9876.

Re: Purely Functional Linux with NixOS [video]

#74

Post by ambrop7 »

vertex-four wrote: post #49
dbcurtis wrote: post #30

Earlier quoted context omitted.

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.

No they definitely use a nonstandard ld.so path. What I showed above is actual output of ldd except there's an actual HASH.

If you think about it makes sense, glibc is still "just" a dependency so it needs to be references from dependant packages by a concrete /nix/store path. You wouldn't want to have a single global libc.so, because you want to be able to upgrade one application using different/newer OS components including libc without possibly breaking existing applications.

The ld.so path is basically the first thing you need to fix when packaging prebuilt software (using patchelf); the second thing are RPATH for other library dependencies.

EDIT: Yes the ld.so probably isn't patched, I failed to completely read your comment. If you want to know really you'd have to look into nixpkgs of course.

Re: Purely Functional Linux with NixOS [video]

#75

Post by vertex-four »

ambrop7 wrote: post #74
vertex-four wrote: post #49

Earlier quoted context omitted.

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.

No they definitely use a nonstandard ld.so path. What I showed above is actual output of ldd except there's an actual HASH. If you think about it makes sense, glibc is still "just" a dependency so it needs to be references from dependant packages by a concrete /nix/store path. You wouldn't want to have a single global libc.so, because you want to be able to upgrade one application using different/newer OS components…

They use a nonstandard ld.so path so that if you build a given binary with a given version of gcc, it uses that gcc's ld.so - but the ld.so isn't patched.

Re: Purely Functional Linux with NixOS [video]

#76

Post by corysama »

davexunit wrote: post #57
corysama wrote: post #41

Earlier quoted context omitted.

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.

It is both a technical and social problem. Please read: https://reproducible-builds.org/

The title of that project is "Reproducible Builds". But, that is only a step towards their goal of "Verifiable Builds". Thus we end up in this frustrating semantic mismatch between the two of us. Guix demands source-verifiable builds. Nix does not. Both enable reproducible builds equally well.

Re: Purely Functional Linux with NixOS [video]

#77

Post by seagreen »

vertex-four wrote: post #67
dbcurtis wrote: post #59

Earlier quoted context omitted.

OK, I replace my naive question above with a different naive question: "Why not just use Haskell?"

Haskell is honestly a larger language, and is a pain in the butt to write. If you're just writing configuration or a very simple package, Nix is basically "JSON with colons, multiline strings, and function calls". Haskell doesn't have a reasonable built-in syntax for dictionaries/maps/whatever you want to call them, which is 95% of Nix.

Well, you would use records, but records are a weak point of the Haskell language. I've discussed "why not Haskell" with some Nix people and they specifically mentioned the lack of row polymorphism.

Re: Purely Functional Linux with NixOS [video]

#78

Post by SwellJoe »

davexunit wrote: post #66
SwellJoe wrote: post #53

Earlier quoted context omitted.

That doesn't make sense. A reproducible build means that a build done in two different places results in the same binary. It has nothing to do with whether the vendor distributes binaries (with optional source) or source alone. The binary is what matters. i.g., if I build this package myself, will it result in the exact same binary that I download from the vendor? Binaries can be signed to prove that the chain of tru…

The intent of reproducible builds, as defined by the reproducible builds project[0], is to have the entire dependency tree built from the complete, corresponding source code of the many projects in that tree, starting from a minimal set of "bootstrap binaries"[1]. Using precompiled binaries, without a doubt, invalidates that goal. Reproducible builds are an ongoing, unsolved problem. In Guix, some things are reproduc…

That's just wrong-headed.

Every binary in the chain can be signed and reproducible (theoretically; we aren't quite there, realistically speaking, and the bootstrap, as you note, is tricky). Forcing every user to build everything from source every time is just a mess, and provides little benefit over signed (reproducible) binaries for the vast majority of users.

It sounds like you (and the guix project) are conflating two orthogonal concepts and making "reproducible builds" into a concept that won't work in widespread use, and maybe even has negative value. We want reproducible builds so that we can be certain that the binary a vendor ships us is built exactly the way they say it was. We don't want it so that everyone is forced to build everything from scratch every time.

Reproducible builds means we can build an identical binary from source to prove that it is what we think it is. It should not mean we must build an identical binary from source every time we install a thing.

Re: Purely Functional Linux with NixOS [video]

#79

Post by SSLy »

SwellJoe wrote: post #45
corysama wrote: post #12

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?

Um, IPS, BSD ports and pkgsrc are a thing.

Re: Purely Functional Linux with NixOS [video]

#80

Post by davexunit »

SwellJoe wrote: post #78
davexunit wrote: post #66

Earlier quoted context omitted.

The intent of reproducible builds, as defined by the reproducible builds project[0], is to have the entire dependency tree built from the complete, corresponding source code of the many projects in that tree, starting from a minimal set of "bootstrap binaries"[1]. Using precompiled binaries, without a doubt, invalidates that goal. Reproducible builds are an ongoing, unsolved problem. In Guix, some things are reproduc…

That's just wrong-headed. Every binary in the chain can be signed and reproducible (theoretically; we aren't quite there, realistically speaking, and the bootstrap, as you note, is tricky). Forcing every user to build everything from source every time is just a mess, and provides little benefit over signed (reproducible) binaries for the vast majority of users. It sounds like you (and the guix project) are conflating…

>Forcing every user to build everything from source every time

>We don't want it so that everyone is forced to build everything from scratch every time.

I believe it is you who is confused. I never suggested this is what reproducible builds are about.

https://www.gnu.org/software/guix/manual/html_node/Substitut...

Post reply on HN