Hacker News Reader

Comment by sa1 | Hacker News Reader

For the kind of reproducibility nix needs, ./configure && make && make install is not enough. It needs to track and manage the artefacts created by the build system, not just run a script.

View on HN

Except, most of a nixos system is built by simple Autoconf scripts and some env cars being set correctly.

I mean I built a whole nix distribution for embedded devices with runit as init and cross compiling and everything and nix made it easy and fun. And I learned that it's just Autoconf and shell all the way down. There's no magic to nix. The most voodoo non standard thing they do is patchelf stuff, but most of the nixos specific stuff is just setting paths to configure scripts or in the environment.

The builds are not guaranteed to be reproducible.

Nix doesn't guarantee reproducible builds. That's why there's a whole signing framework

There is no disagreement there. Reproducibility is definitely a goal though.

I don't really understand your line of argument.

It's a goal but not a fundamental design requirement for nix packages. It seemed like you were implying that you had to make nix builds reproducible in order to get them working with nixpkgs, which wluld greatly complicate things.

Yeah, if every language had their build systems in order, we wouldn't have needed nix as much, so definitely grateful for what nix does. But some problems can only be elegantly solved a level below nix.

I'm interested in your work (nix for embedded). Do you happen to have some blog posts or repos somewhere about this?

I'm building a small personal server device that lets you self-host services in containers and then access them via proxy over WebRTC (so you don't even need a dedicated IP).

I'm in the process of moving my website over from AWS to my own infrastructure (I was using S3 and their CDN for my blog, but unfortunately, the Parler debacle made me rethink my association with them), but the repositories (which are old and need to be updated... this is my hobby project) are on github.

This is my nixos extension to use musl and runit instead of glibc and systemd: https://github.com/intrustd/appliance

built off of my own fork of nixpkgs: https://github.com/intrustd/nixpkgs (forked from a the 19.* releases I think... some changes need to be merged upstream).

Currently, I have it running on an O-Droid HC2 and have used it to share my photos with family. Unfortunately, most home internet connections just don't have enough bandwidth even for modest photo and video sharing, so I'm exploring other means of data transfer rather than a strict client/server thing (maybe using BitTorrent over WebRTC to share larger files). In either case, all the data remains owned by my and physically with me. The system can generate URLs that can be used to access the device for limited amounts of time. So, for example, I can ask my photos app to generate URL I can send to my aunts to show them pictures of my daughter, and this URL will last for X many days until the token expires.

Very cool and ambitious project! Props to you for standing your ground for Freedom of Expression.

I know this is a non-issue for your case but I wonder how much more expensive would self-hosting a blog (+ a few web-services) on a SBC be w.r.t cloud solutions? Have you calculated the numbers (electricity usage, traffic, etc).

This isn't really 'designed' for public blogs, more for sharing content with close friends. It's still in an exploratory phase. The apps (which are just containerized nix expressions) can share content with one another, and with apps on devices that you've paired with your server. Then your friends can see the content you've posted and you can see theirs. That's the intended use case. It's not really intended to host a super traffic heavy blog.

My Odroid HC2 takes very little electricity. Haven't run the numbers on it.

I think I might be misunderstanding you, but that's completely false. Nix sandboxes things and every single C project I've used with "./configure && make && make install" works with zero boilerplate.

Yeah, it definitely works, and nix works around the problem, and lets you, the user, install the packages, but the builds are not guaranteed to be reproducible.

They are as reproducible as you can get with C builds and far more reproducible than most other build systems across many different languages.

https://r13y.com/

Yeah, that's the point, as far as you can get with C builds isn't far enough. We're criticizing C build systems here, not nix.

I mean is there a build system not named "bazel" that does a better job of making reproducible builds than a C autoconf project built with Nix?

There's a lot of wiggle room in "better", but there are a decent number of distros for which ~95% of the packages are built in a reproducible way, including Debian, Arch, and Yocto: https://reproducible-builds.org/citests/

And a lot of those packages use autotools; I don't see the C build system as being particularly hostile to reproducible builds.

Yep, and those distributions function just fine without nix. The point is that that's despite the build system rather than assisted by it.

Reply on news.ycombinator.com