Name

mutiny - BSD-inspired Linux system and research project aiming to be a testbed for interesting system design, forward thinking design choices, minimalism, and fun computing

Synopsis

Mutiny is a project aiming to deliver a Linux distribution that prioritizes a consistent, interesting, and fun to use system. Influenced heavily by BSD system design, minimalist software, and an interest in forward-thinking system design, Mutiny aims to explore alternatives to the hegemony that makes up most Linux distributions.

Mutiny logo

Mutiny is young! If you find the ideas here interesting, please reach out at irc://irc.libera.chat/#mutiny.

There’s a set of git repositories. No bootable system yet, this OS mostly exists as a pile of documents and some broken chroots for now.

This is the main document, here’s a few other documents written currently:

  • A design document about praxis, the package manager.

  • A longer but unfinished document about the package API, theory.

  • A running list of software that might be of interest for Mutiny.

Goals

Grokkability

(grok: verb. "to understand profoundly and intuitively")
Do you think you could ever come to understand what you run on your computer day in and day out? There’s something to be said for being able to. While some things in a system can usually be overlooked, on Mutiny we want to promote an understandable, conceptualizable system. You don’t have to understand what everything does as an end—​but it should be encouraged to learn how the pieces fit together, to learn the philosophy, and really become infatuated with some of the unique ideas being brought forth.

Consistency

Linux systems have suffered from a large amount of inconsistencies in maintenance and style. This is part due to the bazaar model of development, but it doesn’t have to be this way. Software should be bent to conform, and users should come to expect things are going to be a certain way on a Mutiny system.

Uniqueness

There are advantages that come with many sorts of systems acting all alike. But, if you aren’t a fan of the similarities, it means there’s not much of an alternative for you to look out for. We don’t all want Windows, or GNOME, or a Mac, and that’s okay, just like the people that do. Keeping in line with the testbed attitude, Mutiny will always try to make a unique system that people can learn to appreciate for the differences.

Alternatives

In the Linux world there is often an acceptance that some of the system just sucks, but that’s just what we’re stuck with. And that’s reasonable in some cases where alternatives don’t exist. However, Mutiny should aim to thoroughly explore alternatives when they do exist.

Documentation

The system should be thoroughly documented so that you never need to reference external websites in order to learn about it. Documentation should be consistent, too. On Mutiny, all documentation should be accessible through man or /share/doc.
Manual pages will be required for any package that installs a program to /bin, and in all files in /etc will also require manual pages to exist for them.

System

Software

  • Mutiny

    • praxis - a source-based package manager

    • synonym - a utility for managing alternatives

    • commune - utilities for working with the s6 and s6-rc state manager/supervisor

      • commune-snooze - manages scheduled jobs at the system and user scope

      • commune-user - manages the user’s services and states (cf. systemd --user)

      • commune-xinit - manages the user’s Xorg session

  • Base

  • Toolchain

  • Minutiae

    • Manual page reader: mandoc

    • Default framebuffer terminal font: Spleen

      • Spleen is actually the default used on OpenBSD as of 2019, and it contains a good set of sizes, which makes it a good default font for larger, more recent high pixel density displays. It also looks nice.

    • Line editing library: libedit

      • Provides a mostly readline-compatible API.

Software being avoided
Most GNU software

It’s a bit played out. I’d just like to see what more there is out there.

GnuPG

PGP kinda really sucks and we all need to give up the ghost. And it has a bunch of dependencies, and it’s horrendously bloated in terms of features.

dbus

I’m interested in seeking out alternatives to it for a few reasons.

  1. There’s only two real implementations of it: the reference implementation, which is what most people use and apparently has enough performances issues that people are working to shove it into the kernel instead of userspace, and dbus-broker, which seems to have some level of dependency on systemd. While it might not necessarily be the case, this to me signifies some level of complexity in implementation that I’m not interested in accepting as the norm, and possibly as a system component if enough things want to use it.

  2. There seems to be some good criticism to be had that it is reinventing the wheel.

  3. I think that some of its features, such as service activation, have no place in a system bus.

  4. All this aside: it’s still required if you use Bluetooth on Linux.

  5. Alternative: skabus. Heavily a work in progress, but it looks interesting. For now though, the plan is just to stay away from dbus as much as possible.

PulseAudio

  1. A bit worryingly complex.

  2. The main appeal of it is in multiplexing sound sources on one sound card. This can already be done with ALSA, it’s just not pretty to configure.

  3. The alternative: sndio. It’s from OpenBSD, it seems to be a lot simpler, and fits in well with the philosophy we’re going for because of this.

Nonessential but otherwise interesting software that would be a good fit to the philosophy can be found on the software page.

Filesystem layout

In the Mutiny layout, there are a few goals:

  • Accomodate some common paths; #!/bin/sh, etc.

  • Embrace the good innovations that have occurred, like /run and the /sbin+/bin merge.

  • Remove redundancy. No more /media or /usr, /tmp points to /run/tmp.

See hier(7) for a full explanation of the layout.

Prior art

Notes

(ideally these will disappear and turn into their own sections or pages or what have you)

On languages and internationalization

The insistance of English being "the default language of computing" as a rationale to justify not replacing gettext is rather stupid, when not a bit xenophobic. Asserting default languages of entire fields has real world implications when it gets down to the people using them. There’s a really interesting tendency in the Unix development crowds that have minimalist design tendencies to just ignore this.

Mutiny packages should allow for options to only install whatever languages are going to be used. We can set en_US as the default language that is enabled in packages, but only if we are going to provide complete support to those who speak other languages. There’s an obvious question here as to documentation and support through things like IRC though, and I’m only one person.

Documentation

A goal should be to ensure that most documentation is mdoc format. s6 is a notable example of a project that doesn’t currently have manpages, though I believe that’s something many people in the community have been wanting, and in fact something I plan to contribute upstream.

There’s a few tools written by the main mandoc dev that convert other formats to mdoc, they might be worth looking at.

s6 based stuff

In Mutiny, a goal should be to have the same software powering many scopes of the system. This promotes the ability to have an intimate familiarity with the foundation of your system, and thus an easier introduction to administrating it and doing cool stuff with it. A really good point in which this can be carried out is in s6 and s6-rc.

I have a work in progress implementation of doing this at the xinit level, since it’s definitely possible to do a supervisor as your session manager for Xorg sessions. Furthermore, this should be able to be carried up to the login level. (call it commune-user) This could mean user services for users on the system, akin to systemd’s user scope…​

Open questions

XDG standards

In line with the consistency goal, we should really closely follow organizational standards like the XDG Base directory specification. (which is the origin of things like ~/.config, ~/.local, ~/.cache, and so on)

  1. TODO: Should software distributed by Mutiny be patched to use XDG?

License

Mutiny is in the public domain.

To the extent possible under law, Kylie McClain <kylie@somas.is> has waived all copyright and related or neighboring rights to this work.

http://creativecommons.org/publicdomain/zero/1.0/