Guix

[deutschbitte]

Closes #10

[Sjors]

Thanks, I'll add some feedback today. Get well soon!

[Sjors]

I don't entirely buy the idea that Stallman's arguments were purely philosophical whereas Raymond's were practical. Not running malware and not being dependent on one vendor for bug fixes seems plenty pragmatic to me. But I do agree that "many eyes make bugs shallow" is a unique perspective that adds even more value. I also haven't read either their works in any detail. So I edited this section to make these ideas less conflicting and focus more on the history of the "FOSS" abbreviation.

[Sjors]

Ok, I've edited a bunch of things up to "The Solution" where you left off.

This chapter / episode is much longer than I remember it :-) Let's cut it off before the part about walletscrutiny.com. It's a very useful project, and but I think we should explain Guix and then end there.

Big picture wise: Guix doesn't solve the problem of dependencies much better than Gitian. At least not "dependencies" in the sense of libraries that the chapter describes. The main problem Guix solves is that of trusting the build system (virtual machine, compiler, etc). Arguably those are "dependencies" too, but that's perhaps too confusing.

So perhaps we should move the section on dependencies up or down, moving Gitian and Guix closer together.

Guix also aims to be more developer friendly than Gitian, which it probably succeeded at, given that it already supports 20K packages: https://guix.gnu.org/en/packages/

The episode is from some time ago; Guix has replaced Gitian since Bitcoin Core v22 (mid 2021)

[deutschbitte]

Ok, I've edited a bunch of things up to "The Solution" where you left off.

This chapter / episode is much longer than I remember it :-) Let's cut it off before the part about walletscrutiny.com. It's a very useful project, and but I think we should explain Guix and then end there.

Big picture wise: Guix doesn't solve the problem of dependencies much better than Gitian. At least not "dependencies" in the sense of libraries that the chapter describes. The main problem Guix solves is that of trusting the build system (virtual machine, compiler, etc). Arguably those are "dependencies" too, but that's perhaps too confusing.

So perhaps we should move the section on dependencies up or down, moving Gitian and Guix closer together.

Guix also aims to be more developer friendly than Gitian, which it probably succeeded at, given that it already supports 20K packages: https://guix.gnu.org/en/packages/

The episode is from some time ago; Guix has replaced Gitian since Bitcoin Core v22 (mid 2021)

I'm a bit torn on this. I kind of like the dependencies section in the middle because it gives a bit of context and theory and then we're like TADA HERE'S THE SOLUTION... kind of. But we can move it around if you think it would flow better the other way or make for a better ending to talk about dependencies in general.

[deutschbitte]

Back to you

[Sjors]

But we can move it around

Let's keep the current sequence. I agree it has a nice cadence.

do you want to "insert yourself" as the author into the text using I/we? Is one or the other preferable to you

Let's try "we". Closer to finishing the first edition I'll give the whole thing a read, at which point I might switch to "I".

I added reference to Log4j in the chapter on dependencies: f7ea0480f8846653e07dd3da9ce9b1a63536f40e

I changed "Can Gitian Be Corrupted?" to "Who builds the builder?" (or some other variation on "Who watches the watcher?"). The problem of untrustworthy compilers isn't specific to Gitian. And "building the builder" is what Guix does.

Back to you for final tweaks.

[Sjors]

Back to you