Xiden/Guix design comparison

Xiden/Guix design comparison

[Sage Gerard]

[-- Attachment #1: Type: text/plain, Size: 14454 bytes --]

This is an offshoot Q&A based off Devos' questions in the "How did you handle making a GNU/Linux distribution?" thread. It pertains to how Guix compares to Xiden on some points.

Given the length of both of our emails, I don't expect everyone to read this. Guix is mentioned for discussion purposes, but I use the -devel list only because the questions did. Apologies to the mods if that's not an excuse, since I'm not trying to distract from the purpose of the list.

Read on only if you care.

--

> Packages in Guix can specify which version of a package they use. [...] Is something missing from Guix here?

In Xiden, package versions and the notations used to express them are user-defined. If you use semver and I use dates, we can still map our dependency lists to the same package definitions. Xiden leaves it to us to agree on a scheme for some set of packages.

> SHA-384 and Keccak are separate things? [...] By definition, implementations of SHA-384 have no reason to use Keccak.

Correct. I'm just saying that Alice's decision to prefer a SHA-384 implementation for using Keccak is not our business. Ditto for Bob and SHA-1. Alice can force use of Keccak for software arriving on her system with Xiden, without needing to discuss that with anyone.

She's in charge of how a package manager works on her system, and we aren't. Xiden approaches CHFs similarly to OpenSSL in that implementations are selected by providers, except in Xiden a knowledgeable user may assume the role of a CHF implementation provider for their own system. I suspect we'd agree that is a terrible idea, which is why I use zero-trust defaults for everything to mitigate risks.

I allow for danger because most software distribution problems I've seen in the field boil down to smart people dealing with the lasting consequences of outdated or rushed decisions. I'm not assuming competency, but I am assuming that even those with bad practices still need to solve their distribution problems.

>> unconditionally prefers cached installations, such that every defined artifact
>> has exactly one stored copy on disk.
>
> Coming from Guix, I don't know what this means. Does this mean only one version
> of a package can be in the store at the same time, and building a newer version
> deletes the older version? How does this compare with ‘content deduplication’?

Xiden has a cache for package inputs, and a cache for installed outputs. The user has more control over the latter. Depending on the configuration you use in a launcher, you can map all inputs to the same content-addressable filesystem, implying deduplication. However, you can also decide to defeat the installed output cache for the sake of how SxS installations in Xiden. That way you can store any number of any revision of any package in one store (Although I use the word "state" in the docs).

>> but only for artifacts from services authenticated by his operating system's certificates
>
> This is rather vague to me, unless you're referring to substitutes.
> What does this mean for origin specifications?
>
> (source (origin
> (method url-fetch)
> (uri (string-append ["mirror://gnu/hello/hello-"](mirror://gnu/hello/hello-) version
> ".tar.gz"))
> (sha256 ; imagine this was SHA-1 instead.
> (base32
> "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
>
> Bob got the origin specification from Xiden (or something like a Guix channel
> but for Xiden). How would this ‘artifact’ authenticated by ‘operating system
> certificates’? I mean, when you let your operating system build that origin
> (via guix (or Xiden?), which you could consider part of the OS), it will check
> that hash, and it will be considered valid (‘authenticated?’) if the hash matches.
> There are no certificates at play here.
>
> I suppose the OS (guix or Xiden?) could then ‘sign’ it, but what value does that
> provide to Bob? (Unless Bob runs a substitute server on their computer.)

Xiden distinguishes authenticating an artifact and authenticating a service from which an artifact is specified. I mentioned the latter, so I was talking about SSL or TLS authentication.

The word "source" means something different in Xiden. It refers to a structure instance that implements a titular Racket generic. When "tapped", a Xiden source yields an input port and an estimated number of bytes available for the port, or +inf.0 if no estimate is available. The user would tell a launcher what budgets it would allow, if any, and Xiden will only read bytes when the budget is in agreement with the estimate.

When I say "artifact", I mean one of two things.

- An (artifact) expression in a Xiden package input, which consists of a Xiden source, integrity information, and signature information (where available).
-  Some blob of data that I can verify after a download. Definition #1 is just a more restricted form of the same idea.

So to help us discuss this point I'd have translate your expression to a package input in Xiden as follows. I swapped the server and added a signature expression to clarify something.

(input "hello"
(artifact (http-source (string-append ["https://packages.example.com/hello/"](https://packages.example.com/hello/) version ".tar.gz"))
(integrity 'sha1 (base32 "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))
(signature (http-source ["https://packages.example.com/public-key.pem"](https://packages.example.com/public-key.pem))
(http-source (string-append ["https://packages.example.com/hello/"](https://packages.example.com/hello/) version ".tar.gz.sha1.sig")))))

I was saying that Bob can trust the CA that signed the certificates for packages.example.com, but handwaved over that because I was already writing such a long email.

The content of the .tar.gz file is authenticated separately. You can see that I happened to use a PEM-encoded public key and a remote signature file. The end-user's launcher would have to be compatible. If a user prefers to use GPG and not allow for signatures that sit outside of a package definition, their launcher would say so.

There's an example in Xiden's source that shows how to swap out cryptographic backends, so if you don't want to use OpenSSL or GPG, or if you want to automate conversions of formats between the two, the option is available.

And if some of this sounds vague, that's because it is. Semantics of some forms are not fully defined without a launcher. e.g. Xiden only understands the (signature) form to authenticate data using assymetric cryprography, without caring about how exactly you'd do it.

>> trusts digest creation and signature verification as implemented by his host's dynamically--linked `libcrypto` library for use in the same process.
>> downloads content from GitHub packages
>
> AFAIK there is no such thing a ‘GitHub packages’. What is a ‘GitHub package’,
> precisely?

I was referring to the output of the packages feature Microsoft rolled out for GitHub. It integrates with the GitHub Actions feature for CI/CD.

I am actually going to prepare an example where I use a GitHub repository as a catalog of sorts, such that pushing to the repository adds a valid target for a launcher.

>> such that packages cannot conflict in a shared namespace
>
> ‘packages cannot conflict in a shared namespace’ is a bit vague.
> Are you referring to ‘profile collisions’? About having multiple versions
> of the same package on the same system? Guix (and nix) can handle the latter.
> When the ‘propagated-inputs’ are limited, installing multiple packages each using
> a different version of a package is possible.
>
> Is something missing from Guix here (please be very concrete)? [...] I'm not sure what you mean here, can you illustrate this very concretely? And is something missing in Guix here?

I am not in a position to speak for others on what technical aspects are missing or inferior in Guix. That's not what I'm trying to do here.

I only care about how easily a human being can switch between concrete details in this problem domain, which means Xiden leaves some details for the user to define. I'll give you concrete details on how I try to enable this, and I'm not trying to say Guix is missing anything by doing so.

One detail to note is that Xiden does not have profiles. With an unprivileged user, Xiden launchers all act like `ln -s <totally-made-up-notation> link-name`. I didn't think it needed to be more complicated than that.

>> prefers Semantic Versions
>
> If upstream doesn't do ‘semver’, and instead uses a versioning system like
> used by TeX (3.14, 3.141, 3.1415, 3.14159, ...), then Xiden cannot somehow
> let the package use ‘semver’ instead. Unless you want to teach Xiden to
> convince upstream to change their versioning system?

A Xiden launcher may translate your preferred version notation to an upstream scheme.

>> These preferences are valid in Xiden's DSL for writing launchers.
>
> What is a launcher (compared to packages in Guix), and why would I want one?

The docs say what a launcher is.

You want one if you want to adapt to social and technical differences between package management systems. Xiden does not know what you want without clarification from you, for similar reasons to why Vulkan ended up more explicit than OpenGL.

> Why shouldn't I just install packages and run them ("guix package -i texmacs",
> start texmacs from some application chooser menu of the desktop environment).

Your question assumes `guix` is the command you want to run, which is fine, but not everyone is you. I suspect that's why you are struggling to understand how Xiden works, because Xiden does not prescribe itself as the sole option for how you put things on your system. It can also serve as a bridge between your existing options.

I think the pattern of everybody and their cat making a GNU/Linux distribution with a new package manager raises questions about interoperability. I'm trying to address that by saying that Xiden is to package managers what Racket is to programming languages. The white paper covers this.

>> The invariants for each launcher can differ as much as Cargo and Vortex differ.
>> What I wanted to do was allow users to declare their own invariants explicitly,
>> but only when those invariants are wanted for subjective reasons.
>
> What are these invariants you're speaking of? I don't think you're referring
> to, say, translation invariance (‘the laws of physics remain the same under a
> translation of the coordinate system’).
>
> Or do you mean something like ‘Invariant (computer science), an expression whose
> value doesn't change during program execution’ ([<https://en.wikipedia.org/wiki/Invariant>](https://en.wikipedia.org/wiki/Invariant))?

https://stackoverflow.com/a/112088

> But what are the ‘expressions’ in this case?

If I don't mean S-expressions, I am probably referring to a string of arbitrary content with a meaning made up by the user.

>> Xiden launchers have advantages over shell scripts in that we can both still download
>> and install dependencies from the same servers, and create reproducible builds in terms
>> of the same (bit-identical) state on disk. We just differ on details that shouldn't impact
>> how we work. It also helps us patch holes faster, since if (say) a catalog maintainer tells
>
> What is a ‘catalog maintainer’ (maybe it's like someone with commit access to a ‘guix channel’?)

A catch-all term I use for a person with a server that responds with artifacts, by definition #2 of "artifact."

> Also, what ‘shell scripts’ are you referring to.

Doesn't matter. That bit was me anticipating questions like "Why go this abstract when I could just write a shell script?"

>> us that a CHF was compromised, we can immediately revoke trust in the CHF independently
>
> Maybe guix could gain a command "guix style transition-hash OLD NEW" to automagically
> rewrite package definitions to use the new hash algorithm instead of the old. It will
> need to download plenty of source code however, and it will entail a world-rebuild.

Xiden doesn't have that problem. Or, more accurately, it doesn't take responsibility for that problem. I think the real world is too messy to try that.

>> in our own clients.
>
> What are these ‘clients’ you're speaking of? I haven't been needing any ‘clients’ lately.

In the context of Xiden, "client" may be a synonym for "launcher" if the launcher uses the network.

>> The package definitions are all expressed in terms of what the launchers allow.
>
> If 'package definition' = (package definition as in Guix), then this is false,
> Guix doesn't have a notion of ‘launchers’ and doesn't depend on ‘Xiden’.
> What are you meaning, exactly? Also, I haven't found any package definitions in Xiden,
> could you point me to any?

The guide shows a command that prints where you can find examples. I have spent over an hour typing before getting to this question, so I ask that you please read the docs more.

If you are looking for a definition for something like GNU coreutils, then you won't find one without an associated launcher. I'll get to launcher details in your other questions. I am not currently hosting any system-level packages, so you won't get definitions from me.

> Why would I want to ‘escape to a new distribution model’? Writing something like Guix
> from scratch seems a lot of work to me, I would rather fork Guix (with a few
> likewise-minded collaborators) than to start over again. Or move to Debian maybe.
> I don't see what ‘Xiden’ could offer here.

The details that would prompt one to fork a package manager source tree can be trivially changed in a Xiden launcher.

> I would rather not have to ‘adapt to problems’, I would rather that upstream has something
> that works (though I can understand if occasionally mistakes are made).

We differ here. I need the ability to make my own decisions that may contradict upstream decisions at any time. That's a freedom I value and aim to protect.

--

I didn't bother with the rest of the email because I don't have time to repeat answers found elsewhere, or define every other word. There are enough contextual clues to help your own research. I'm happy to take further questions, but please ask with the understanding that I've already been generous with my time here. If there's a problem with Xiden's approach, please open a GitHub issue against zyrolasting/xiden.

Thanks.

[-- Attachment #2: Type: text/html, Size: 23566 bytes --]

Re: Xiden/Guix design comparison

[Ryan Sundberg]

[-- Attachment #1: Type: text/plain, Size: 16428 bytes --]

Hello Sage,

Why start yet another package manager from scratch? Are there any features that couldn't just be implemented in Guix itself? I prefer development in Racket over guile too, but Guile with it's low level system call/c compatibility plays to its strengths for the use cases involved in systems programming a package manager.

Did you discover guix after writing Xiden? I'm not understanding the use cases Xiden proposes that would be difficult to implement in Guix (for example, GPG signature verification for package sources). I don't think Racket as a platform is compelling enough to justify the effort.

You also compare Xiden to Racket as if it is a package manager to write other package managers with. But you can also just call into Guix modules directly and integrate guix into any other guile program and build a new package manager on top of it. I personally have used Racket to generate guile code to call guix modules to spawn processes for deterministic/generated virtual machines. It is turtles all the way down. I could demo this in private if you are interested.

Anyways it sounds like there is some valuable research in Xiden, but I think it would be most beneficial at large to integrate some of the most useful elements of your research into Guix, rather than try to reproduce the work to bootstrap the world and also redefine or translate the thousands of package definitions. The maintenance alone on the myriad package definitions is enough to keep up with for all of us put together.

My $0.02! Thanks for sharing.

Sincerely,

Ryan Sundberg


-------- Original Message --------
From: Sage Gerard <sage@sagegerard.com>
Sent: August 24, 2021 1:33:55 PM PDT
To: guix-devel@gnu.org
Subject: Xiden/Guix design comparison

This is an offshoot Q&A based off Devos' questions in the "How did you handle making a GNU/Linux distribution?" thread. It pertains to how Guix compares to Xiden on some points.

Given the length of both of our emails, I don't expect everyone to read this. Guix is mentioned for discussion purposes, but I use the -devel list only because the questions did. Apologies to the mods if that's not an excuse, since I'm not trying to distract from the purpose of the list.

Read on only if you care.

--

> Packages in Guix can specify which version of a package they use. [...] Is something missing from Guix here?

In Xiden, package versions and the notations used to express them are user-defined. If you use semver and I use dates, we can still map our dependency lists to the same package definitions. Xiden leaves it to us to agree on a scheme for some set of packages.

> SHA-384 and Keccak are separate things? [...] By definition, implementations of SHA-384 have no reason to use Keccak.

Correct. I'm just saying that Alice's decision to prefer a SHA-384 implementation for using Keccak is not our business. Ditto for Bob and SHA-1. Alice can force use of Keccak for software arriving on her system with Xiden, without needing to discuss that with anyone.

She's in charge of how a package manager works on her system, and we aren't. Xiden approaches CHFs similarly to OpenSSL in that implementations are selected by providers, except in Xiden a knowledgeable user may assume the role of a CHF implementation provider for their own system. I suspect we'd agree that is a terrible idea, which is why I use zero-trust defaults for everything to mitigate risks.

I allow for danger because most software distribution problems I've seen in the field boil down to smart people dealing with the lasting consequences of outdated or rushed decisions. I'm not assuming competency, but I am assuming that even those with bad practices still need to solve their distribution problems.

>> unconditionally prefers cached installations, such that every defined artifact
>> has exactly one stored copy on disk.
>
> Coming from Guix, I don't know what this means. Does this mean only one version
> of a package can be in the store at the same time, and building a newer version
> deletes the older version? How does this compare with ‘content deduplication’?

Xiden has a cache for package inputs, and a cache for installed outputs. The user has more control over the latter. Depending on the configuration you use in a launcher, you can map all inputs to the same content-addressable filesystem, implying deduplication. However, you can also decide to defeat the installed output cache for the sake of how SxS installations in Xiden. That way you can store any number of any revision of any package in one store (Although I use the word "state" in the docs).

>> but only for artifacts from services authenticated by his operating system's certificates
>
> This is rather vague to me, unless you're referring to substitutes.
> What does this mean for origin specifications?
>
> (source (origin
> (method url-fetch)
> (uri (string-append ["mirror://gnu/hello/hello-"](mirror://gnu/hello/hello-) version
> ".tar.gz"))
> (sha256 ; imagine this was SHA-1 instead.
> (base32
> "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
>
> Bob got the origin specification from Xiden (or something like a Guix channel
> but for Xiden). How would this ‘artifact’ authenticated by ‘operating system
> certificates’? I mean, when you let your operating system build that origin
> (via guix (or Xiden?), which you could consider part of the OS), it will check
> that hash, and it will be considered valid (‘authenticated?’) if the hash matches.
> There are no certificates at play here.
>
> I suppose the OS (guix or Xiden?) could then ‘sign’ it, but what value does that
> provide to Bob? (Unless Bob runs a substitute server on their computer.)

Xiden distinguishes authenticating an artifact and authenticating a service from which an artifact is specified. I mentioned the latter, so I was talking about SSL or TLS authentication.

The word "source" means something different in Xiden. It refers to a structure instance that implements a titular Racket generic. When "tapped", a Xiden source yields an input port and an estimated number of bytes available for the port, or +inf.0 if no estimate is available. The user would tell a launcher what budgets it would allow, if any, and Xiden will only read bytes when the budget is in agreement with the estimate.

When I say "artifact", I mean one of two things.

- An (artifact) expression in a Xiden package input, which consists of a Xiden source, integrity information, and signature information (where available).
-  Some blob of data that I can verify after a download. Definition #1 is just a more restricted form of the same idea.

So to help us discuss this point I'd have translate your expression to a package input in Xiden as follows. I swapped the server and added a signature expression to clarify something.

(input "hello"
(artifact (http-source (string-append ["https://packages.example.com/hello/"](https://packages.example.com/hello/) version ".tar.gz"))
(integrity 'sha1 (base32 "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))
(signature (http-source ["https://packages.example.com/public-key.pem"](https://packages.example.com/public-key.pem))
(http-source (string-append ["https://packages.example.com/hello/"](https://packages.example.com/hello/) version ".tar.gz.sha1.sig")))))

I was saying that Bob can trust the CA that signed the certificates for packages.example.com, but handwaved over that because I was already writing such a long email.

The content of the .tar.gz file is authenticated separately. You can see that I happened to use a PEM-encoded public key and a remote signature file. The end-user's launcher would have to be compatible. If a user prefers to use GPG and not allow for signatures that sit outside of a package definition, their launcher would say so.

There's an example in Xiden's source that shows how to swap out cryptographic backends, so if you don't want to use OpenSSL or GPG, or if you want to automate conversions of formats between the two, the option is available.

And if some of this sounds vague, that's because it is. Semantics of some forms are not fully defined without a launcher. e.g. Xiden only understands the (signature) form to authenticate data using assymetric cryprography, without caring about how exactly you'd do it.

>> trusts digest creation and signature verification as implemented by his host's dynamically--linked `libcrypto` library for use in the same process.
>> downloads content from GitHub packages
>
> AFAIK there is no such thing a ‘GitHub packages’. What is a ‘GitHub package’,
> precisely?

I was referring to the output of the packages feature Microsoft rolled out for GitHub. It integrates with the GitHub Actions feature for CI/CD.

I am actually going to prepare an example where I use a GitHub repository as a catalog of sorts, such that pushing to the repository adds a valid target for a launcher.

>> such that packages cannot conflict in a shared namespace
>
> ‘packages cannot conflict in a shared namespace’ is a bit vague.
> Are you referring to ‘profile collisions’? About having multiple versions
> of the same package on the same system? Guix (and nix) can handle the latter.
> When the ‘propagated-inputs’ are limited, installing multiple packages each using
> a different version of a package is possible.
>
> Is something missing from Guix here (please be very concrete)? [...] I'm not sure what you mean here, can you illustrate this very concretely? And is something missing in Guix here?

I am not in a position to speak for others on what technical aspects are missing or inferior in Guix. That's not what I'm trying to do here.

I only care about how easily a human being can switch between concrete details in this problem domain, which means Xiden leaves some details for the user to define. I'll give you concrete details on how I try to enable this, and I'm not trying to say Guix is missing anything by doing so.

One detail to note is that Xiden does not have profiles. With an unprivileged user, Xiden launchers all act like `ln -s <totally-made-up-notation> link-name`. I didn't think it needed to be more complicated than that.

>> prefers Semantic Versions
>
> If upstream doesn't do ‘semver’, and instead uses a versioning system like
> used by TeX (3.14, 3.141, 3.1415, 3.14159, ...), then Xiden cannot somehow
> let the package use ‘semver’ instead. Unless you want to teach Xiden to
> convince upstream to change their versioning system?

A Xiden launcher may translate your preferred version notation to an upstream scheme.

>> These preferences are valid in Xiden's DSL for writing launchers.
>
> What is a launcher (compared to packages in Guix), and why would I want one?

The docs say what a launcher is.

You want one if you want to adapt to social and technical differences between package management systems. Xiden does not know what you want without clarification from you, for similar reasons to why Vulkan ended up more explicit than OpenGL.

> Why shouldn't I just install packages and run them ("guix package -i texmacs",
> start texmacs from some application chooser menu of the desktop environment).

Your question assumes `guix` is the command you want to run, which is fine, but not everyone is you. I suspect that's why you are struggling to understand how Xiden works, because Xiden does not prescribe itself as the sole option for how you put things on your system. It can also serve as a bridge between your existing options.

I think the pattern of everybody and their cat making a GNU/Linux distribution with a new package manager raises questions about interoperability. I'm trying to address that by saying that Xiden is to package managers what Racket is to programming languages. The white paper covers this.

>> The invariants for each launcher can differ as much as Cargo and Vortex differ.
>> What I wanted to do was allow users to declare their own invariants explicitly,
>> but only when those invariants are wanted for subjective reasons.
>
> What are these invariants you're speaking of? I don't think you're referring
> to, say, translation invariance (‘the laws of physics remain the same under a
> translation of the coordinate system’).
>
> Or do you mean something like ‘Invariant (computer science), an expression whose
> value doesn't change during program execution’ ([<https://en.wikipedia.org/wiki/Invariant>](https://en.wikipedia.org/wiki/Invariant))?

https://stackoverflow.com/a/112088

> But what are the ‘expressions’ in this case?

If I don't mean S-expressions, I am probably referring to a string of arbitrary content with a meaning made up by the user.

>> Xiden launchers have advantages over shell scripts in that we can both still download
>> and install dependencies from the same servers, and create reproducible builds in terms
>> of the same (bit-identical) state on disk. We just differ on details that shouldn't impact
>> how we work. It also helps us patch holes faster, since if (say) a catalog maintainer tells
>
> What is a ‘catalog maintainer’ (maybe it's like someone with commit access to a ‘guix channel’?)

A catch-all term I use for a person with a server that responds with artifacts, by definition #2 of "artifact."

> Also, what ‘shell scripts’ are you referring to.

Doesn't matter. That bit was me anticipating questions like "Why go this abstract when I could just write a shell script?"

>> us that a CHF was compromised, we can immediately revoke trust in the CHF independently
>
> Maybe guix could gain a command "guix style transition-hash OLD NEW" to automagically
> rewrite package definitions to use the new hash algorithm instead of the old. It will
> need to download plenty of source code however, and it will entail a world-rebuild.

Xiden doesn't have that problem. Or, more accurately, it doesn't take responsibility for that problem. I think the real world is too messy to try that.

>> in our own clients.
>
> What are these ‘clients’ you're speaking of? I haven't been needing any ‘clients’ lately.

In the context of Xiden, "client" may be a synonym for "launcher" if the launcher uses the network.

>> The package definitions are all expressed in terms of what the launchers allow.
>
> If 'package definition' = (package definition as in Guix), then this is false,
> Guix doesn't have a notion of ‘launchers’ and doesn't depend on ‘Xiden’.
> What are you meaning, exactly? Also, I haven't found any package definitions in Xiden,
> could you point me to any?

The guide shows a command that prints where you can find examples. I have spent over an hour typing before getting to this question, so I ask that you please read the docs more.

If you are looking for a definition for something like GNU coreutils, then you won't find one without an associated launcher. I'll get to launcher details in your other questions. I am not currently hosting any system-level packages, so you won't get definitions from me.

> Why would I want to ‘escape to a new distribution model’? Writing something like Guix
> from scratch seems a lot of work to me, I would rather fork Guix (with a few
> likewise-minded collaborators) than to start over again. Or move to Debian maybe.
> I don't see what ‘Xiden’ could offer here.

The details that would prompt one to fork a package manager source tree can be trivially changed in a Xiden launcher.

> I would rather not have to ‘adapt to problems’, I would rather that upstream has something
> that works (though I can understand if occasionally mistakes are made).

We differ here. I need the ability to make my own decisions that may contradict upstream decisions at any time. That's a freedom I value and aim to protect.

--

I didn't bother with the rest of the email because I don't have time to repeat answers found elsewhere, or define every other word. There are enough contextual clues to help your own research. I'm happy to take further questions, but please ask with the understanding that I've already been generous with my time here. If there's a problem with Xiden's approach, please open a GitHub issue against zyrolasting/xiden.

Thanks.

[-- Attachment #2: Type: text/html, Size: 25165 bytes --]

Re: Xiden/Guix design comparison

[zimoun]

Hi Sage,

On Tue, 24 Aug 2021 at 20:33, Sage Gerard <sage@sagegerard.com> wrote:

> This is an offshoot Q&A based off Devos' questions in the "How did you
> handle making a GNU/Linux distribution?" thread. It pertains to how
> Guix compares to Xiden on some points. 
>
> Given the length of both of our emails, I don't expect everyone to
> read this. Guix is mentioned for discussion purposes, but I use the
> -devel list only because the questions did. Apologies to the mods if
> that's not an excuse, since I'm not trying to distract from the
> purpose of the list. 
>
> Read on only if you care.

I have read your emails and your Reddit post, and also watched your
presentation at RacketCon, in addition to the White Paper and some docs.
Well, I must admit that I lack context, probably from Racket ecosystem,
to get all the points of what Xiden is.  To answer to your first email,
IIUC, as I said earlier, you should use the Guix binaries––probably via
the Ryan’s proposal––to explore your ideas behind Xiden.

Because it is guix-devel, my attempt here is to explain what Guix is and
maybe you will find how to use it with Xiden. ;-)

From my understanding, Xiden seems like a workflow engine; see for
example:

  <https://guixwl.org/>

Evil is in details but GWL is somehow less strict than Guix itself.  GWL
defines ’process’es which do whatever stuff using programs and then
’workflow’ which is a graph of processes.  On the other hand, Guix
defines ’package’s which do more or less “only”: ’fetch-from-Internet &&
./configure && make && make check && make install’, so a lot of things
have to be strict, for instance version, method for fetching, etc.

And, again, from my understanding, the launcher looks like a flexible
and declarative way to describe how the content flows.  Maybe give a
look at Common Workflow Language [0] or if you have not yet to Dataflow
[1] stuff.  I do not know if it is relevant, for sure I miss a lot of
stuff with Xiden. :-) In Guix, nothing really flows but things are just
built.  All the other stuff Guix does come from the nice properties that
these builds have.

0: <https://www.commonwl.org/>
1: <https://en.wikipedia.org/wiki/Dataflow_architecture>

Reading your piece of writings, I thought to topics you might be
interested in.  Speaking about build systems, a good framework to
compare them is exposed in “Build à la carte“ [2]; it is a really good
reading, IMHO.

Guix is now a lot of things, but, from my point of view, at first, Guix
is somehow a (glue of) build system: it transforms a graph of
dependencies into binaries items; vertexes are package definitions and
edges are inputs.  Note that Guix consider 2 kind of inputs: explicit
and implicit.  Roughly speaking and to stay short, the implicit inputs
are compilers and various utilities.  For instance, the Guix package
’racket-minimal’ [3] requires a C compiler which is not listed in the
’inputs’ field but is implicit by ’gnu-build-system’.

2:
<https://www.microsoft.com/en-us/research/publication/build-systems-a-la-carte/>
3: <https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/racket.scm?id=ae3e6ba506f57a4353f491242a3f5e4d419f9aa9#n128>

Now, I would like to point issues about trust.  Today, when you build
Racket from source (milk), you need compilers (yogourt).  These
compilers come from source (other milk) compiled by compilers (other
yogourt).  And so on.  The question is the size of the initial yogourt
you are ready to eat (trust).  In case you missed the pedestrian
explanations of Trusting Trust by Carl, please watch [4].  I do not know
about Microsoft, and about Mac the initial yogourt is really a huge
piece. :-) The initial yogourt used by Guix is detailed here [5,6].

4: <https://youtu.be/I2iShmUTEl8>
5: <https://guix.gnu.org/manual/devel/en/guix.html#Bootstrapping>
6: <https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/>

My point here is if Xiden works on Mac and the launcher is zero-trust,
it could be worth to specify against which attack Xiden is trying to
protect.  IIUC, not against a Trusting Trust attack. ;-)

Guix tries to get a straight path from a minimal set of binaries to
modern compilers.  The aim [7] is to have human-auditable binaries,
somehow.  That’s said, this path is running using a (binary) kernel on
the top of hardware, so still a chicken-egg problem. ;-) The question,
as always, is against what we protect.  Note that another path is tried:
formal verification. Somehow, the audit is done by proof-assistant
[8,9]; another long story. :-)

7: <https://bootstrappable.org/>
8: <https://cakeml.org/>
9: <https://compcert.org/>

Last, about preserving semantics, i.e., do not rebuild, it is a
difficult task.  For instance, I remember the idea exposed in this blog
post [10].  And about functional principles applied to deployment,
’propellor’ [11,12] by Joey Hess might be interesting.  Or not. :-)

10:
<https://www.joachim-breitner.de/blog/743-Build_tool_semantic_aware_build_systems>
11: <https://youtu.be/kzXXcr8TyJY>
12: <https://lwn.net/Articles/713653/>

Well, all in all, I am off-topic about your questions.  Maybe you will
find your way.  Feel free to expose your ideas.  If Guix can help to
have better tools. :-)

All the best,
simon

Re: Xiden/Guix design comparison

[Sage Gerard]

[-- Attachment #1: Type: text/plain, Size: 18124 bytes --]

> Did you discover guix after writing Xiden?

I did, although when I did discover Guix, I incorporated what I learned from Guix with the limitations in Racket's approach to package management.

> Why start yet another package manager from scratch?

Do I need a reason? I like programming, I do it to relax, and I think this domain is interesting and fun.

Normally when I duplicate an existing effort, it is because I wish to learn how it works well enough to be self-sufficient within the domain. This adds more effort on my part, but that's the path that led me from scripting web front ends to maintaining a homelab, and hopefully write an operating system from scratch. I like learning by doing, and that necessarily leads to duplication of existing efforts somewhere.

> Are there any features that couldn't just be implemented in Guix itself?

Of course not. This is all FOSS. I could just as easily ask if there are any missing features that couldn't just be implemented in Xiden. Ditto for low-level system call/cc and Racket. We all eventually deal with C with the same audiences, so I see our journeys as equifinal.

The only difference I see is that if we both start from an new user, I hypothesize I can teach them to use Xiden faster than you can teach them to use Guix. A race could be fun! That would help us both identify usability pain points.

Finding things I'm missing is actually part of why I'm here, because I already know Xiden is not bootstrapped and is necessarily missing a sufficiently tall tower of turtles. But I don't see that as sufficient reason to use Guix, because I'm here to learn by doing, not to stop just because I'm given an opportunity to stop thinking.

> It is turtles all the way down. I could demo this in private if you are interested. [...] it would be most beneficial at large to integrate some of the most useful elements of your research into Guix, rather than try to reproduce the work to bootstrap the world and also redefine or translate the thousands of package definitions.

I believe you, and I agree. Ryan Prior's email showed me a nice way to layer Xiden on top of one of said turtles, and I'm satisfied with that for now. If Xiden grows enough to feasibly bootstrap with volunteers, then I'd rather it be on its own than dependent on a middleman. I'm not too worried about interoperability problems, because that's something I require Xiden to solve early on.

And if I may: I think I see one thing that is missing from Guix as an ecosystem as opposed to just a tool. Technical superiority can never address the subjective (and sometimes silly) reasons that help users pick a tool. Even if I acknowledge Guix as technically superior, that doesn't mean I want to use it. The time it takes for me to learn Guix well is lower than the time it takes for me to replicate the functionality I want at the time using Xiden (see The Lisp Curse).

Now, I also want Xiden to be adaptable enough to simplify for laypersons, without forcing them to depend on me as a middleman. To me, that's the main difference between the user's experience with Guix, and with Xiden.

I don't know how well that will play out yet. Time will tell.

> ---------------------------------------------------------------
> From: Sage Gerard [<sage@sagegerard.com>](mailto:sage@sagegerard.com)
> Sent: August 24, 2021 1:33:55 PM PDT
> To: guix-devel@gnu.org
> Subject: Xiden/Guix design comparison
>
> This is an offshoot Q&A based off Devos' questions in the "How did you handle making a GNU/Linux distribution?" thread. It pertains to how Guix compares to Xiden on some points.
>
> Given the length of both of our emails, I don't expect everyone to read this. Guix is mentioned for discussion purposes, but I use the -devel list only because the questions did. Apologies to the mods if that's not an excuse, since I'm not trying to distract from the purpose of the list.
>
> Read on only if you care.
>
> --
>
>> Packages in Guix can specify which version of a package they use. [...] Is something missing from Guix here?
>
> In Xiden, package versions and the notations used to express them are user-defined. If you use semver and I use dates, we can still map our dependency lists to the same package definitions. Xiden leaves it to us to agree on a scheme for some set of packages.
>
>> SHA-384 and Keccak are separate things? [...] By definition, implementations of SHA-384 have no reason to use Keccak.
>
> Correct. I'm just saying that Alice's decision to prefer a SHA-384 implementation for using Keccak is not our business. Ditto for Bob and SHA-1. Alice can force use of Keccak for software arriving on her system with Xiden, without needing to discuss that with anyone.
>
> She's in charge of how a package manager works on her system, and we aren't. Xiden approaches CHFs similarly to OpenSSL in that implementations are selected by providers, except in Xiden a knowledgeable user may assume the role of a CHF implementation provider for their own system. I suspect we'd agree that is a terrible idea, which is why I use zero-trust defaults for everything to mitigate risks.
>
> I allow for danger because most software distribution problems I've seen in the field boil down to smart people dealing with the lasting consequences of outdated or rushed decisions. I'm not assuming competency, but I am assuming that even those with bad practices still need to solve their distribution problems.
>
>>> unconditionally prefers cached installations, such that every defined artifact
>>> has exactly one stored copy on disk.
>>
>> Coming from Guix, I don't know what this means. Does this mean only one version
>> of a package can be in the store at the same time, and building a newer version
>> deletes the older version? How does this compare with ‘content deduplication’?
>
> Xiden has a cache for package inputs, and a cache for installed outputs. The user has more control over the latter. Depending on the configuration you use in a launcher, you can map all inputs to the same content-addressable filesystem, implying deduplication. However, you can also decide to defeat the installed output cache for the sake of how SxS installations in Xiden. That way you can store any number of any revision of any package in one store (Although I use the word "state" in the docs).
>
>>> but only for artifacts from services authenticated by his operating system's certificates
>>
>> This is rather vague to me, unless you're referring to substitutes.
>> What does this mean for origin specifications?
>>
>> (source (origin
>> (method url-fetch)
>> (uri (string-append ["mirror://gnu/hello/hello-"](mirror://gnu/hello/hello-) version
>> ".tar.gz"))
>> (sha256 ; imagine this was SHA-1 instead.
>> (base32
>> "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))))
>>
>> Bob got the origin specification from Xiden (or something like a Guix channel
>> but for Xiden). How would this ‘artifact’ authenticated by ‘operating system
>> certificates’? I mean, when you let your operating system build that origin
>> (via guix (or Xiden?), which you could consider part of the OS), it will check
>> that hash, and it will be considered valid (‘authenticated?’) if the hash matches.
>> There are no certificates at play here.
>>
>> I suppose the OS (guix or Xiden?) could then ‘sign’ it, but what value does that
>> provide to Bob? (Unless Bob runs a substitute server on their computer.)
>
> Xiden distinguishes authenticating an artifact and authenticating a service from which an artifact is specified. I mentioned the latter, so I was talking about SSL or TLS authentication.
>
> The word "source" means something different in Xiden. It refers to a structure instance that implements a titular Racket generic. When "tapped", a Xiden source yields an input port and an estimated number of bytes available for the port, or +inf.0 if no estimate is available. The user would tell a launcher what budgets it would allow, if any, and Xiden will only read bytes when the budget is in agreement with the estimate.
>
> When I say "artifact", I mean one of two things.
>
> - An (artifact) expression in a Xiden package input, which consists of a Xiden source, integrity information, and signature information (where available).
> -  Some blob of data that I can verify after a download. Definition #1 is just a more restricted form of the same idea.
>
> So to help us discuss this point I'd have translate your expression to a package input in Xiden as follows. I swapped the server and added a signature expression to clarify something.
>
> (input "hello"
> (artifact (http-source (string-append ["https://packages.example.com/hello/"](https://packages.example.com/hello/) version ".tar.gz"))
> (integrity 'sha1 (base32 "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i"))
> (signature (http-source ["https://packages.example.com/public-key.pem"](https://packages.example.com/public-key.pem))
> (http-source (string-append ["https://packages.example.com/hello/"](https://packages.example.com/hello/) version ".tar.gz.sha1.sig")))))
>
> I was saying that Bob can trust the CA that signed the certificates for packages.example.com, but handwaved over that because I was already writing such a long email.
>
> The content of the .tar.gz file is authenticated separately. You can see that I happened to use a PEM-encoded public key and a remote signature file. The end-user's launcher would have to be compatible. If a user prefers to use GPG and not allow for signatures that sit outside of a package definition, their launcher would say so.
>
> There's an example in Xiden's source that shows how to swap out cryptographic backends, so if you don't want to use OpenSSL or GPG, or if you want to automate conversions of formats between the two, the option is available.
>
> And if some of this sounds vague, that's because it is. Semantics of some forms are not fully defined without a launcher. e.g. Xiden only understands the (signature) form to authenticate data using assymetric cryprography, without caring about how exactly you'd do it.
>
>>> trusts digest creation and signature verification as implemented by his host's dynamically--linked `libcrypto` library for use in the same process.
>>> downloads content from GitHub packages
>>
>> AFAIK there is no such thing a ‘GitHub packages’. What is a ‘GitHub package’,
>> precisely?
>
> I was referring to the output of the packages feature Microsoft rolled out for GitHub. It integrates with the GitHub Actions feature for CI/CD.
>
> I am actually going to prepare an example where I use a GitHub repository as a catalog of sorts, such that pushing to the repository adds a valid target for a launcher.
>
>>> such that packages cannot conflict in a shared namespace
>>
>> ‘packages cannot conflict in a shared namespace’ is a bit vague.
>> Are you referring to ‘profile collisions’? About having multiple versions
>> of the same package on the same system? Guix (and nix) can handle the latter.
>> When the ‘propagated-inputs’ are limited, installing multiple packages each using
>> a different version of a package is possible.
>>
>> Is something missing from Guix here (please be very concrete)? [...] I'm not sure what you mean here, can you illustrate this very concretely? And is something missing in Guix here?
>
> I am not in a position to speak for others on what technical aspects are missing or inferior in Guix. That's not what I'm trying to do here.
>
> I only care about how easily a human being can switch between concrete details in this problem domain, which means Xiden leaves some details for the user to define. I'll give you concrete details on how I try to enable this, and I'm not trying to say Guix is missing anything by doing so.
>
> One detail to note is that Xiden does not have profiles. With an unprivileged user, Xiden launchers all act like `ln -s <totally-made-up-notation> link-name`. I didn't think it needed to be more complicated than that.
>
>>> prefers Semantic Versions
>>
>> If upstream doesn't do ‘semver’, and instead uses a versioning system like
>> used by TeX (3.14, 3.141, 3.1415, 3.14159, ...), then Xiden cannot somehow
>> let the package use ‘semver’ instead. Unless you want to teach Xiden to
>> convince upstream to change their versioning system?
>
> A Xiden launcher may translate your preferred version notation to an upstream scheme.
>
>>> These preferences are valid in Xiden's DSL for writing launchers.
>>
>> What is a launcher (compared to packages in Guix), and why would I want one?
>
> The docs say what a launcher is.
>
> You want one if you want to adapt to social and technical differences between package management systems. Xiden does not know what you want without clarification from you, for similar reasons to why Vulkan ended up more explicit than OpenGL.
>
>> Why shouldn't I just install packages and run them ("guix package -i texmacs",
>> start texmacs from some application chooser menu of the desktop environment).
>
> Your question assumes `guix` is the command you want to run, which is fine, but not everyone is you. I suspect that's why you are struggling to understand how Xiden works, because Xiden does not prescribe itself as the sole option for how you put things on your system. It can also serve as a bridge between your existing options.
>
> I think the pattern of everybody and their cat making a GNU/Linux distribution with a new package manager raises questions about interoperability. I'm trying to address that by saying that Xiden is to package managers what Racket is to programming languages. The white paper covers this.
>
>>> The invariants for each launcher can differ as much as Cargo and Vortex differ.
>>> What I wanted to do was allow users to declare their own invariants explicitly,
>>> but only when those invariants are wanted for subjective reasons.
>>
>> What are these invariants you're speaking of? I don't think you're referring
>> to, say, translation invariance (‘the laws of physics remain the same under a
>> translation of the coordinate system’).
>>
>> Or do you mean something like ‘Invariant (computer science), an expression whose
>> value doesn't change during program execution’ ([<https://en.wikipedia.org/wiki/Invariant>](https://en.wikipedia.org/wiki/Invariant))?
>
> https://stackoverflow.com/a/112088
>
>> But what are the ‘expressions’ in this case?
>
> If I don't mean S-expressions, I am probably referring to a string of arbitrary content with a meaning made up by the user.
>
>>> Xiden launchers have advantages over shell scripts in that we can both still download
>>> and install dependencies from the same servers, and create reproducible builds in terms
>>> of the same (bit-identical) state on disk. We just differ on details that shouldn't impact
>>> how we work. It also helps us patch holes faster, since if (say) a catalog maintainer tells
>>
>> What is a ‘catalog maintainer’ (maybe it's like someone with commit access to a ‘guix channel’?)
>
> A catch-all term I use for a person with a server that responds with artifacts, by definition #2 of "artifact."
>
>> Also, what ‘shell scripts’ are you referring to.
>
> Doesn't matter. That bit was me anticipating questions like "Why go this abstract when I could just write a shell script?"
>
>>> us that a CHF was compromised, we can immediately revoke trust in the CHF independently
>>
>> Maybe guix could gain a command "guix style transition-hash OLD NEW" to automagically
>> rewrite package definitions to use the new hash algorithm instead of the old. It will
>> need to download plenty of source code however, and it will entail a world-rebuild.
>
> Xiden doesn't have that problem. Or, more accurately, it doesn't take responsibility for that problem. I think the real world is too messy to try that.
>
>>> in our own clients.
>>
>> What are these ‘clients’ you're speaking of? I haven't been needing any ‘clients’ lately.
>
> In the context of Xiden, "client" may be a synonym for "launcher" if the launcher uses the network.
>
>>> The package definitions are all expressed in terms of what the launchers allow.
>>
>> If 'package definition' = (package definition as in Guix), then this is false,
>> Guix doesn't have a notion of ‘launchers’ and doesn't depend on ‘Xiden’.
>> What are you meaning, exactly? Also, I haven't found any package definitions in Xiden,
>> could you point me to any?
>
> The guide shows a command that prints where you can find examples. I have spent over an hour typing before getting to this question, so I ask that you please read the docs more.
>
> If you are looking for a definition for something like GNU coreutils, then you won't find one without an associated launcher. I'll get to launcher details in your other questions. I am not currently hosting any system-level packages, so you won't get definitions from me.
>
>> Why would I want to ‘escape to a new distribution model’? Writing something like Guix
>> from scratch seems a lot of work to me, I would rather fork Guix (with a few
>> likewise-minded collaborators) than to start over again. Or move to Debian maybe.
>> I don't see what ‘Xiden’ could offer here.
>
> The details that would prompt one to fork a package manager source tree can be trivially changed in a Xiden launcher.
>
>> I would rather not have to ‘adapt to problems’, I would rather that upstream has something
>> that works (though I can understand if occasionally mistakes are made).
>
> We differ here. I need the ability to make my own decisions that may contradict upstream decisions at any time. That's a freedom I value and aim to protect.
>
> --
>
> I didn't bother with the rest of the email because I don't have time to repeat answers found elsewhere, or define every other word. There are enough contextual clues to help your own research. I'm happy to take further questions, but please ask with the understanding that I've already been generous with my time here. If there's a problem with Xiden's approach, please open a GitHub issue against zyrolasting/xiden.
>
> Thanks.

[-- Attachment #2: Type: text/html, Size: 29533 bytes --]

Re: Xiden/Guix design comparison

[Sage Gerard]

[-- Attachment #1: Type: text/plain, Size: 7221 bytes --]

Thank you so much for the wealth of resources, and for reading the materials!

I see how you got the workflow aspect, although I hesitate to sum up Xiden as a workflow engine. When I wrote Polyglot (a static site generator), it also included an abstraction for arbitrary workflows. In my mind, Xiden and Polyglot have workflow engines, because I always hated it when I used a library or framework, only for it to pressure me into doing things the "____ way." I strongly believe that tools don't get opinions, so whenever I write anything over 1000 lines of code, I tend to add on a way to override my design-level decisions within my project.

I'm aware of what you're saying re: yogurt, and since Xiden is cross-platform it necessarily requests different levels of your trust in system binaries. I'd want the best possible scenario on GNU/Linux, hence my other thread. But for Windows, I think Xiden's development is basically done.

On 8/25/21 6:50 AM, zimoun wrote:

> Hi Sage,
>
> On Tue, 24 Aug 2021 at 20:33, Sage Gerard
> [<sage@sagegerard.com>](mailto:sage@sagegerard.com)
> wrote:
>
>> This is an offshoot Q&A based off Devos' questions in the "How did you
>> handle making a GNU/Linux distribution?" thread. It pertains to how
>> Guix compares to Xiden on some points.
>>
>> Given the length of both of our emails, I don't expect everyone to
>> read this. Guix is mentioned for discussion purposes, but I use the
>> -devel list only because the questions did. Apologies to the mods if
>> that's not an excuse, since I'm not trying to distract from the
>> purpose of the list.
>>
>> Read on only if you care.
>
> I have read your emails and your Reddit post, and also watched your
> presentation at RacketCon, in addition to the White Paper and some docs.
> Well, I must admit that I lack context, probably from Racket ecosystem,
> to get all the points of what Xiden is.  To answer to your first email,
> IIUC, as I said earlier, you should use the Guix binaries––probably via
> the Ryan’s proposal––to explore your ideas behind Xiden.
>
> Because it is guix-devel, my attempt here is to explain what Guix is and
> maybe you will find how to use it with Xiden. ;-)
>
> From my understanding, Xiden seems like a workflow engine; see for
> example:
> [<https://guixwl.org/>](https://guixwl.org/)
> Evil is in details but GWL is somehow less strict than Guix itself.  GWL
> defines ’process’es which do whatever stuff using programs and then
> ’workflow’ which is a graph of processes.  On the other hand, Guix
> defines ’package’s which do more or less “only”: ’fetch-from-Internet &&
> ./configure && make && make check && make install’, so a lot of things
> have to be strict, for instance version, method for fetching, etc.
>
> And, again, from my understanding, the launcher looks like a flexible
> and declarative way to describe how the content flows.  Maybe give a
> look at Common Workflow Language [0] or if you have not yet to Dataflow
> [1] stuff.  I do not know if it is relevant, for sure I miss a lot of
> stuff with Xiden. :-) In Guix, nothing really flows but things are just
> built.  All the other stuff Guix does come from the nice properties that
> these builds have.
>
> 0:
> [<https://www.commonwl.org/>](https://www.commonwl.org/)
> 1:
> [<https://en.wikipedia.org/wiki/Dataflow_architecture>](https://en.wikipedia.org/wiki/Dataflow_architecture)
> Reading your piece of writings, I thought to topics you might be
> interested in.  Speaking about build systems, a good framework to
> compare them is exposed in “Build à la carte“ [2]; it is a really good
> reading, IMHO.
>
> Guix is now a lot of things, but, from my point of view, at first, Guix
> is somehow a (glue of) build system: it transforms a graph of
> dependencies into binaries items; vertexes are package definitions and
> edges are inputs.  Note that Guix consider 2 kind of inputs: explicit
> and implicit.  Roughly speaking and to stay short, the implicit inputs
> are compilers and various utilities.  For instance, the Guix package
> ’racket-minimal’ [3] requires a C compiler which is not listed in the
> ’inputs’ field but is implicit by ’gnu-build-system’.
>
> 2:
> [<https://www.microsoft.com/en-us/research/publication/build-systems-a-la-carte/>](https://www.microsoft.com/en-us/research/publication/build-systems-a-la-carte/)
> 3:
> [<https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/racket.scm?id=ae3e6ba506f57a4353f491242a3f5e4d419f9aa9#n128>](https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/racket.scm?id=ae3e6ba506f57a4353f491242a3f5e4d419f9aa9#n128)
> Now, I would like to point issues about trust.  Today, when you build
> Racket from source (milk), you need compilers (yogourt).  These
> compilers come from source (other milk) compiled by compilers (other
> yogourt).  And so on.  The question is the size of the initial yogourt
> you are ready to eat (trust).  In case you missed the pedestrian
> explanations of Trusting Trust by Carl, please watch [4].  I do not know
> about Microsoft, and about Mac the initial yogourt is really a huge
> piece. :-) The initial yogourt used by Guix is detailed here [5,6].
>
> 4:
> [<https://youtu.be/I2iShmUTEl8>](https://youtu.be/I2iShmUTEl8)
> 5:
> [<https://guix.gnu.org/manual/devel/en/guix.html#Bootstrapping>](https://guix.gnu.org/manual/devel/en/guix.html#Bootstrapping)
> 6:
> [<https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/>](https://guix.gnu.org/en/blog/2020/guix-further-reduces-bootstrap-seed-to-25/)
> My point here is if Xiden works on Mac and the launcher is zero-trust,
> it could be worth to specify against which attack Xiden is trying to
> protect.  IIUC, not against a Trusting Trust attack. ;-)
>
> Guix tries to get a straight path from a minimal set of binaries to
> modern compilers.  The aim [7] is to have human-auditable binaries,
> somehow.  That’s said, this path is running using a (binary) kernel on
> the top of hardware, so still a chicken-egg problem. ;-) The question,
> as always, is against what we protect.  Note that another path is tried:
> formal verification. Somehow, the audit is done by proof-assistant
> [8,9]; another long story. :-)
>
> 7:
> [<https://bootstrappable.org/>](https://bootstrappable.org/)
> 8:
> [<https://cakeml.org/>](https://cakeml.org/)
> 9:
> [<https://compcert.org/>](https://compcert.org/)
> Last, about preserving semantics, i.e., do not rebuild, it is a
> difficult task.  For instance, I remember the idea exposed in this blog
> post [10].  And about functional principles applied to deployment,
> ’propellor’ [11,12] by Joey Hess might be interesting.  Or not. :-)
>
> 10:
> [<https://www.joachim-breitner.de/blog/743-Build_tool_semantic_aware_build_systems>](https://www.joachim-breitner.de/blog/743-Build_tool_semantic_aware_build_systems)
> 11:
> [<https://youtu.be/kzXXcr8TyJY>](https://youtu.be/kzXXcr8TyJY)
> 12:
> [<https://lwn.net/Articles/713653/>](https://lwn.net/Articles/713653/)
> Well, all in all, I am off-topic about your questions.  Maybe you will
> find your way.  Feel free to expose your ideas.  If Guix can help to
> have better tools. :-)
>
> All the best,
> simon

[-- Attachment #2: Type: text/html, Size: 8523 bytes --]