nixpacks VS stage0

Example with Nixpacks:

We have an upcoming nixpacks builder that should work on ARM/ARM64, but there are issues in the nixpacks codebase I'm still trying to sort out before that lands.

I think this is something the writer of the article would be delighted to find: https://github.com/railwayapp/nixpacks

Yes, it builds the Dockerfile if it exists otherwise it uses nixpacks to create an image from source files for any language/framework. This image is then run using docker run .

I think this is true for Nix in the deployment/ops space, where debugging a broken build can be very frustrating. Language improvements are going to be less useful for app developers, the Flake learning curve is not going to get better with a type system.

Perhaps something like heroku buildpaks (https://github.com/railwayapp/nixpacks ?) would help devs get on the Nix train.

Hey! Any plans on integrating nixpacks? I'm one of the core maintainers & would love to help you out. No worries if not.

Uses NixPacks to build the images;

Somewhat tangential, but I'm curious how big the bootstrap seed for Nix is. That is, if you wanted to build the entire world, what's a minimum set of binaries you'd need?

Guix has put quite a bit of work into this, AFAIU, and it's getting close to being bootstrappable all the way from stage0 [0]. Curious if some group is also working on similar things for Nix.

[0]:https://github.com/oriansj/stage0

https://www.bootstrappable.org/ has some good info. Reading the source of https://github.com/oriansj/stage0 is also very enlightening. It's set its goal to be understandable by 70% of programmers.

Even if they aren't, people absolutely should be able to bootstrap new platforms from scratch. It's important to have confidence in our tools, in our ability to rebuild from scratch, and to be safe against the "trusting trust" attack among other things.

Lately I've been catching up on the state of the art in bootstrapping. Check out the live-bootstrap project. stage0 starts with a seed "compiler" of a couple hundred bytes that basically turns hex codes into bytes while stripping comments. A series of such text files per architecture work their way up to a full macro assembler, which is then used to write a mostly architecture-independent minimal C compiler, which then builds a larger compiler written in this subset of C. This then bootstraps a Scheme in which a full C compiler (mescc) is written, which then builds TinyCC, which then builds GCC 4, which works its way up to modern GCC for C++... It's a fascinating read:

https://github.com/oriansj/stage0

https://github.com/fosslinux/live-bootstrap/blob/master/part...

Even if no one is "using" this it should still be a primary motivator for keeping C simple.

One countermeasure not mentioned here is bootstrapping a compiler with a program small enough to be manually verified. The stage0 project is under 1KB (small enough that the binary can be, and has been, manually checked against the hand written assembly), and GNU Guix (a system for reproducible, isolated builds) is currently working on moving it's bootstrap speed to stage0. That means that, fairly soon, there will be a large set of software that doesn't have a connection to an original C compiler.