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 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
-
Mutiny
-
praxis
- a source-based package manager -
synonym
- a utility for managing alternatives -
commune
- utilities for working with thes6
ands6-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
-
Kernel: Linux, long-term releases only
-
Standard C library:
musl
-
Core system utilities:
toybox
-
busybox
to fill in the cracks, temporarily
-
-
Default shell: OpenBSD
ksh
-
The Oil shell is also being looked at.
-
-
Job scheduling:
snooze
-
System automation:
execline
-
System-management scripts that are not invoked by a user will be written in execline whenever possible. See skarnet’s explanation for reasons why.
-
-
Device handling, firmware loading:
mdevd
-
SSL library:
libressl
-
-
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.
-
-
- 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.
-
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.
-
There seems to be some good criticism to be had that it is reinventing the wheel.
-
I think that some of its features, such as service activation, have no place in a system bus.
-
All this aside: it’s still required if you use Bluetooth on Linux.
-
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
-
-
A bit worryingly complex.
-
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.
-
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
-
Exherbo Linux - My former distribution of choice, helped me realize the potential of source-based distributions; ultimately our interests diverged.
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)
-
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.