About

I believe that software works best when it is developed with an academic rigor in its design and industrial robustness in its implementation. I do not believe that it is effective to consider academic rigor and industrial robustness as separate specializations handled by different people. Both factors must be considered simultaneously (not in parallel) at every step of the software construction and maintenance processes.

A line of work might start with a practical desire or with a theoretical interest. For example, my interest in combining Guix with QubesOS comes from practical (if vague) desires. However, my interest in programming languages comes from theoretical interest. Nevertheless, combining Guix and QubesOS will require interesting theoretical work and my research into programming languages will create practical benefits. Both of these lines have a premise and a set of short-/medium-/long-term goals.

¶ Guix and QubesOS

¶ Premise

Guix and QubesOS provide different kinds of benefits for computing, and both can enhance the other.

Guix provides a declarative interface to the Nix build system embedded in Guile Scheme. Embedded DSLs are useful because they minimize the cognitive overhead required to use the technology, assuming that the host language is useful for other purposes. The more purposes the host language can serve the lower the overhead for all purposes.

QubesOS provides a desktop-oriented Xen distribution. This is useful for security by compartmentalization, as discussed by the QubesOS team. It is also beneficial for developers who want to tinker with core components of the operating system or otherwise engage in risky behavior while still wanting to access their bank account reliably and confidentially.

¶ Short-term

Support a Guix machine running in PVH mode installable from an RPM. Running in PVH mode is beneficial because it enables features like dynamic memory allocation and is considered more secure for a generic use-case. Being installable from an RPM will make it easier for interested parties to try it out, as the biggest stumbling block tends to be initial installation.

My initial plan was to support this by running a Xephyr service, because the main challenge is that PVH machines don't get a root window to draw in. However, it turns out that debugging "my window never appears even though Xephyr launched successfully and printed no errors" is really difficult for someone who has no experience debugging X servers. I could spend a bunch of time learning how X servers work, but it makes more sense to spend that time packaging the GUI agent since I'll need to do that either way, and X might be replaced with wayland anyway.

¶ Medium-term

Support all of the core QubesOS infrastructure required to run a fully integrated AppVM. This will be acceptable to submit as a community template. It will make it easier to support arbitrary distributions on QubesOS because a guix pack can provide all of the required software regardless of the host environment.

The main unknown is how to support launching arbitrary services. Guix creates a shepherd configuration file to run all services, but that file doesn't seem easily accessible right now.

It will also make it easier for people to define templates for specific purposes, because the set of required software will be precisely defined. To that end, I will also look at better support for combining multiple fragments of operating system configurations, so that community members can define and share their own configurations independently of the core infrastructure. I expect that this will be accomplished by creating a constraint processing system to generate Guix configurations. I will study and describe the state of the art in constraint processing and apply the most relevant techniques to Guix.

¶ Long-term

Support a complete declaration of a QubesOS system in Guix, including using Guix for dom0. It will still be possible to use other distributions in this system, but the interface for declaring them will likely be less expressive.

Identify ways to describe the structure of software projects that is not explicitly stated in the code. Maintain descriptions of Xen, QubesOS, and Guix.

¶ Programming Languages

¶ Premise

There are a wide variety of programming languages available for use today. This diversity has been created by practical needs: different languages address the needs of different communities in ways that are suitable for them. However, each of these languages contains a large number of arbitrary decisions and duplicated work. It will be interesting to examine the languages that exist today and categorize their features into the essential features which truly support their communities and arbitrary decisions which may be changed without undermining the language's purpose.

¶ Short-term

Finish my paper about function arguments. This paper is the prototype for what papers in this series will be: comparative analyses of features provided by various languages, a generalization of those features, and examples of how more specific and concise versions of those features can be built on top in an interoperable way.

¶ Medium-term

Write more papers in this line.

¶ Long-term

Maintain a project which provides the generalizations as a set of extensions to Guile Scheme. It would be nice to maintain it as pure R7RS, but I expect I will want at least some things to be native extensions which requires being tied to a specific implementation. The lack of custom callable objects in R7RS is already a significant barrier to generalizing function arguments ergonomically.