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.

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