This channel hosts code for integrating QubesOS with Guix. There are short-term goals, a planned pause, a medium-term goal, and a long-term goal.

#Short-term Goals

1. Use QubesOS xen config
2. Create a Guix template
   • Will have partial integration: what is packaged right now.
   • Will NOT have advanced integration such as GUI

For goal 1, I'm not sure how much of the configuration is relevant to the libraries used by guests but I'd expect it's a non-0 amount. The current package uses the default configuration of Xen (aside from flags given to the configure script).

For goal 2, I have started looking at the qubes builder and will use it if appropriate. However, the builder seems designed to control the imperative work of administering a distribution. Guix's declarative model might mean that it does not fit the framework. Guix already has facilities for building images (for example, qemu or docker images). My understanding is that a template is basically just a disk image that gets copied into an LVM volume for use by the system. It might be easier to expand Guix's facilities. Or it might not be.

#Planned Pause

I want to integrate Guix and QubesOS "the right way", which is very opinionated. I'm doing this project in my own time with my own resources so I generally feel comfortable being opinionated. But I still value the opinions of others and seek to incorporate other perspectives and information I have not yet considered. This tends to make things better for everyone.

The relevant point about "the right way" is the difficulty of modularizing operating system declarations in Guix. Currently, the upstream recommendation is to modify a declaration which describes a set of reasonable defaults. However, this does not work well if there is a set of declarations which should be incorporated into a variety of different operating systems. If the set of required declarations changes over time (particularly if the set of fields which contain declarations change), this will disturb the code of every dependent operating system. I previously attempted to create a modularization system, but this turned out to be problematic. The correct way to modularize declarative code is with constraint-oriented programming. However, I have never worked with constraint-oriented programming so I need to study it thoroughly first. Currently, I am working on a paper about function arguments which is helpful because it is a smaller topic and I have never written a disciplined paper before. Once that is finished I will write about constraint-oriented programming and how it applies to Guix.

While working on these papers I will not be doing significant work on this channel. I will still apply version updates for packages which already exist, with the goal of publishing them the weekend after upstream publishes.

#Medium-term Goal

1. Fully supported Guix template

Basically, this template should work out-of-the box just like Debian, Arch, or any other template that is available from the repositories. No big changes here, just adding a new template.

#Long-term Goal

1. Reduce the overhead of maintaining templates for all parties by taking advantage of Guix's package closures.

Basically, Guix's package model means that we can precisely define all inputs and then deploy them onto any arbitrary system without disturbing or relying on anything provided by the native package manager. The notable exception to this is the kernel, which is a necessary environmental dependency. In principle we should be able to create portable service graphs under herd and then start herd using the native service manager, but I don't know if there's currently support for exporting service graphs in Guix. If not it can surely be added.

Put those things together and in principle it will be possible to create a self-contained tarball with everything required for QubesOS support. In principle, adding support should be as simple as unpacking the tarball into the root directory. In practice, there will be conflicts - the native network manager and graphical server/client will need to be disabled, for example. However, this will eliminate the need to maintain package definitions for multiple distributions which will remove some overhead involved in supporting templates.

It should also be possible to have a qube which is dedicated to the store and acts both as a service qube and a pseudo-template. It can be a service qube because it can act as a build server for all other qubes on the machine. The store qube can have significantly more resources (CPUs, RAM) dedicated to it than most user-facing qubes will need. It can also act as a pseudo-template because a Guix-based qubes only needs to receive its profile closure, so that minimum set of files can be copied from the store qube, the the activation logic works and nothing else from the "template" is needed.