Re: Xiden/Guix design comparison

[Sage Gerard <sage@sagegerard.com>]

[-- 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 --]