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 > [<s...@sagegerard.com>](mailto:s...@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
