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

NixOS Reproducible Builds: minimal ISO successfully independently rebuilt

discourse.nixos.org

Post reply on HN
Print view View original

51–60 of 179 posts

Re: NixOS Reproducible Builds: minimal ISO successfully independently rebuilt

#51

Post by flkiwi »

Aerbil313 wrote: post #31
mihalycsaba wrote: post #3

Sorry for being dense, but I thought one of the main reason for nixos's existence is reproducibilty. I thought they have these kinds of things solved already. I have only ~2 hours experience with Nixos, wanted to try hyprland, I thought it would be easier on Nixos since hyprland needs a bit of setup and maybe it's easier to use someone else's config on nixos, than on some other distro. Finding a config was hard too,…

Check out https://github.com/donovanglover/nix-config . Flake based config with hyprland and cool stuff. > at that point I gave up. NixOS is not for the weak or time constrained, currently. Hopefully it will be one day. Still if you push through, you reap the benefits.

Another good option: https://github.com/Misterio77/nix-starter-configs

I started with this one, the minimal version, then moved on to something more like the standard version, and now I'm moving on to something based on his much more complicated and flexible build in a different repo. I had been flailing, then this repo made it click.

Re: NixOS Reproducible Builds: minimal ISO successfully independently rebuilt

#52

Post by cpuguy83 »

ahmedfromtunis wrote: post #32

Stupid question as I never worked on something like this before: why isn't reproducibility the default behavior? I mean if 2 copies of a piece of software were compiled from the same source, what stops them from being identical each and every time? I know there are so many moving parts, but I still can't understand how discrepancies can manifest themselves.

Here is a very recent post from the Go team on things they had to do to make the Go toolchain fully reproducible.

https://go.dev/blog/rebuild

Re: NixOS Reproducible Builds: minimal ISO successfully independently rebuilt

#53

Post by t0astbread »

ParetoOptimal wrote: post #14
mihalycsaba wrote: post #12

Earlier quoted context omitted.

I don't remember, some of them needed some other tools installed(like flakes whatever it is), I looked for configs, that looked like they don't need a few more hours to learn and to setup some other tools for them to work. I just wanted to take a quick look at hyprland, I imagined I just use an existing config, I never thought it would need hours of research. Later I installed an arch vm and managed to install hyprla…

> I just wanted to take a quick look at hyprland, I imagined I just use an existing config, I never thought it would need hours of research. It shouldn't. You'd want a simple flake to start with that has home-manager (for higher chance of finding declarative vest practice configs and modules) and to add small things to that. I imagine you tried grabbing someone's complex config, modifying it, and ran into issues?

Flakes will hopefully be that soon but I wouldn't recommend starting with flakes when learning Nix in 2023. They're experimental and you still need to learn most of flake-less Nix (except channels and NIX_PATH) anyways.

When I started learning/using NixOS about two years ago I found it useful to start out with just Nixpkgs (i.e. what you get out of the box) and only add libraries when I felt they would help me. My first configs where ugly as hell and full of bad practice but the cool thing about Nix is that it gives you a lot of safety nets to enable experimentation and refactoring.

Re: NixOS Reproducible Builds: minimal ISO successfully independently rebuilt

#54

Post by mbakke »

mgaunard wrote: post #43

Don't you have to fake the system time to do this? The time often ends up inside the binaries one way or another.

Indeed time stamps are probably the most common sources of indeterminism. So common that a de-facto standard variable to fake a timestamp has been implemented in many compilers:

https://reproducible-builds.org/docs/source-date-epoch/

Re: NixOS Reproducible Builds: minimal ISO successfully independently rebuilt

#56

Post by chpatrick »

dicytea wrote: post #9
Reventlov wrote: post #4

For those wondering : it should be remembered that the reproducibility of Nix / NixOS / Nixpkgs is only a reproducibility of the sources: if the sources change, one is warned, but it is not a question of the reproducibility of the binaries (which can change at each build). This binary reproducibility of Nix / NixOS / Nixpkgs is indeed not really tested, at least not systematically. Guix, Archlinux, Debian do the bina…

> Guix, Archlinux, Debian do the binary reproducibility better than Nix / NixOS / Nixpkgs. Huh, didn't know that Arch Linux tests reproducibility. It's apparently 85.6% reproducible: https://reproducible.archlinux.org I wonder how much work would be needed for NixOS, considering it has more than 80k packages in the official repository.

I think that's also a bit of an unfair comparison given the number of AUR packages you usually use on Arch. With nixpkgs there isn't a distinction between official and community packages.

Re: NixOS Reproducible Builds: minimal ISO successfully independently rebuilt

#57

Post by rssoconnor »

Thrir94994i wrote: post #11
onedognight wrote: post #7

Rebuilding the minimal ISO from source is an impressive milestone on the journey to a system that builds from source reproducibly. Guix had an orthogonal but equally impressive milestone on the same journey recently[0], bootstrapping a full compiler toolchain from a single reproducible 357 byte binary without any other binary compiler blobs. These two features may one day soon be combined to reproducibly build a full…

357 bytes for bootstrap compiler binary is VERY impressive!

To be fair, it is 357 bytes ... plus a POSIX operating system.

Still, that POSIX operating system bit is also being worked on.

Re: NixOS Reproducible Builds: minimal ISO successfully independently rebuilt

#58

Post by WhyNotHugo »

chpatrick wrote: post #23
mihalycsaba wrote: post #3

Sorry for being dense, but I thought one of the main reason for nixos's existence is reproducibilty. I thought they have these kinds of things solved already. I have only ~2 hours experience with Nixos, wanted to try hyprland, I thought it would be easier on Nixos since hyprland needs a bit of setup and maybe it's easier to use someone else's config on nixos, than on some other distro. Finding a config was hard too,…

> Sorry for being dense, but I thought one of the main reason for nixos's existence is reproducibilty. I thought they have these kinds of things solved already. Nixos has the advantage that everything is built in its own sandbox with only its explicitly declared (and hashed) dependencies available, unlike in mainstream distros where it's the full system environment, so in many cases you already get the same binary ev…

> unlike in mainstream distros where it's the full system environment

Usually packages are built in an environment which has only a minimal base system plus the package's explicitly dependencies. They don't have random unnecessary packages installed.

Re: NixOS Reproducible Builds: minimal ISO successfully independently rebuilt

#59

Post by mbakke »

amelius wrote: post #55
mgaunard wrote: post #43

Don't you have to fake the system time to do this? The time often ends up inside the binaries one way or another.

Could you name an example of how (and for what reason) this might happen?

Typically part of a "version string":

    $ python3
    Python 3.10.7 (main, Jan  1 1970, 00:00:01) [GCC 11.3.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>>
Perhaps a relic from when software had to be manually updated?

Re: NixOS Reproducible Builds: minimal ISO successfully independently rebuilt

#60

Post by WhyNotHugo »

somat wrote: post #15

I find it funny(ironic) that the OpenBSD project is trying hard to go the other way, every single install has unique and randomized address offsets. While I understand that these two goals, reproducible builds and unique installs, are orthogonal to each other, both can be had at the same time, the duality of the situation still makes me laugh.

OpenBSD does randomised linking at boot time. Packages themselves can still be reproducible. All the randomisation is done locally after the packages are downloaded and their checksums validated.
Post reply on HN