Modulo

What is Modulo?

During the late 1970s and through the 80's, LISP Machines were used in academic and research centers for general-purpose computing. The interest in LISP Machines became well-established for the ability of the machine to reflect state changes to the kernel and higher-level components in real-time without the need to reboot. LISP Machines often comprised an amalagam of LISP dialects, tied to a kernel, which featured introspection, hackability, conservative garbage collection, and asynchronous system-level task management. Today, LISP Machines are considered a relic but are still praised by many for their advanced multi-tiered hackable functionality, and their reliance upon the LISP-family of languages. We see iterations of these features in disparate but closely-related utilities: GNU Emacs features a fully-fledged programming language and interpreting environment on top of an efficient C-based kernel, GNU Guix leverages the power of Scheme as a dependable and declarative method to perform package management, development, and configuration at the system and package level, as well as various other projects like StumpWM and the Atlas-Engineer Next browser use Common Lisp for its introspective and flexible object-system, and functional dynamic type system.

Modulo is a distribution and configuration based on the innovations of the old LISP Machines, with the advancements in LISP-based technology of the present. Modulo seeks to synthesize these different facets to provide a default system configuration for GuixSD GNU/Linux-libre, featuring a fully-featured GNU Emacs configuration, custom configuration of StumpWM (or Guile-WM), web browser, and more out-of-the-box! This is done in hope to revive the spirit of the LISP Machine-era, but not necessarily to create a "turtles all the way down" LISP-only machine. Modulo is merely configured using LISP dialects, but should be compatible with all programming languages, environments, and contemporary free (libre) software.

What Modulo is Not

First and foremost, Modulo is NOT a LISP Machine. Despite the caption-line of the project, this is not a project to create an emulation of a LISP Machine. In the current year there are thousands of programming languages, environments, and implementations each with their own set of specifications. Creating Modulo in the strict and principled-style of LISP Machines would be a limiting design concept. The capability of LISP Machines in their rightful glory was unprecedented, and it is those advancements that we seek to implement into a full system configuration. So, in the manner of those features, and using the traditional and contemporary dialects of LISP where they are best fit, Modulo will be best served as a series of "LISP-oriented layers" placed upon your userland, kernel, etc.

Modulo's Design Philosophy

• Fully-introspectable.
• Hackable and fully grokked.
• Opinionated, but flexible.
• Designed for use with free (libre) software.

Modulo's Components

Contributing to Modulo

Where Are the Pull Requests?

There are none! Huzzah! In the past several years there has been a mesmerization of programmers by Git-SCM hosting platforms to reject the built-in functions of Git in favor of their own git-adjacent functionalities. One of these features is the "pull request". There has been some quiet controversy surrounding pull requests as being a more dangerous form of git merge followed by a rebase, which can lead to deleterious consequences in the code base requiring correction by superfluous git pushes and more pull requests. The nice benefit of pull requests is that you can view a diff of your project in your browser, but Git already does this!

The other way to make contributions is by creating a patch (https://git-scm.com/docs/git-format-patch), which creates a Git-derived diff to be sent to the project maintainers and subsequently downloaded, changed, and applied wherever the project maintainers see it most useful. Since the project maintainers are probably using GNU Emacs with the wonderful Magit! extension, patch files are a conveniently painted with their differences highlighted, and can then be applied and pushed.

This is actually a great benefit, because anybody can send changes upstream without having to maintain a public fork of whatever project they are interested in contributing to. Anybody can checkout a local copy of this project, make changes, test them, and then create a patch or patch-series to be sent here with absolutely no need to maintain an online repository for any part of it. You are not required to use NotABug, GitHub, GitLab, or Git-whatever to do any part except open the relevant issue on our issue tracker.

Once you have created your patch or patch-series, the next step is to open an issue on the issue tracker. Start the issue creation process, and indicate in the subject line a small description of what it is pertaining to (usually the commit message is fine), and in the first comment (the original post) describe in some detail what you have changed, and for what reason. Next, copy your patch plain-text and paste it in a new comment enclosed in Markdown Code Block formatting. This formatting is crucial, or else it is likely our ability to apply the patch correctly will be ruined. Please repeat this step if there are multiple patches in a patch-series.

Great! You have opened an issue with a patch. From here, the maintainers (or yourself) will be able to add a tag/label and assignee to the issue to review the patch, engage in further discussion, and hopefully apply your changes to the relevant branch!

I understand this process is different than what you are probably accustomed to, but I hope you will come to find the strong benefits of letting Git do its job with its own tools. It is a less dangerous, and pragmatic way to make contributions to a project. If nothing else, you can have appreciation in knowing your depth-of-knowledge in Git is more than most of your colleagues.