I need to design a strategy which allows me to maintain Slack9 without too much time. This will necesarily involve cloud services and automated builds and test.


The most important thing in order to keep Slack9 maintained is automation. This is key to keep up with all the updates done to the open source project Slack9 wil be based on.

But automation has a huge cost in tooling which can make Slack9 fail due to the maintenance of the automation itself.

Because Slack9 will be based on Slackware, using the same tooling Slackware uses is to some extent a requirement. But it also has virtues which makes it a good candidate to work on automation, and those virtues have allowed Patrick Volkerding to maintaing Slackware for more than 25 years.

There are other big projects which follow simmilar approaches, like Arch Linux, which also proves that the approach works well at scale.

The main characteristic of these automation systems is that they are based on mostly autocontained shell scripts. This allows these projects to deal with any kind of software build and installation process.

A note about current approaches

There are other approaches being explored by modern Linux distributions about software management: - user focused - system focused

In the first category we can find AppImage, Flatpak and Snap as their most prominent examples, while at the second category we can find GNU Guix, NixOS and Fedora Atomic.

The first category focus on user applications, tipically desktop applications like word processors, chat clients, web browsers, photo editing, etc. and the second category covers that, but focus on system components like compilers, web servers, database systems, utility libraries, etc.

It is seductive to view the system as a collection of little pieces which can be managed separately, but such a thing leads to hard problems which are often solved by heavily patching software to make it work in an environment its creators didn’t support. Or even faking the environment altogether with heavily customized configurations, symlinks, etc.

The transactional-like software upgrades are a very desirable feature, which promises long stability to the system with the ability to undo the wrong doings. But these update might be obtainable regardless of the approach used by leveraging tools like Snapper.

In Slack9 I think I am going to focus on getting Snapper for the system updates, and use Flatpak for the user applications whenever possible. Also nothing will prevent an user to use Nix or Guix as a package manager for itself.

Anyway, Slack9 will be a system as a whole, there will be a set of packages which are going to be designed to be installed together, without any dependency resolution, just like Slackware is.


A huge part of the success of many projects is their documentation. It allows users to make a mental model of the project, fully understanding the aim of the creators, so they can contribute to the project in many ways.

This is a personal project, with a low probability of public engagement, but documentation will be essential. It will allow me to remember why and how decisions were made, and how a particular piece fit into the system as a whole. Also it will allow others to read and apply the same methods, or improve them, and if I am lucky, they will share the improvements with me.

The current documentation pipeline is based on pandoc. The source is written in [markdown] and then translated to HTML using pandoc and a custom CSS template based on Tufte CSS and Practical Typography by M. Butterick. This is all glued toghether in a Makefile which is executed automatically in a Sourcehut build task, which builds and published the web.