the styx operating system

styx will be a consent-first, usability-oriented operating system, with a Linux® kernel, and a distribution of self-contained application packages.

styx is a project borne of frustration. some of us on the styx project are 20+ year Linux and UNIX veterans, and newcomers alike; and we all have had our own headaches with the system.

We're working on making Linux less hellish, despite the name - we're going through hell so you don't have to. We've got an RFC track going with ideas as to what makes styx “styx”, and hopefully those ideas … sticks? right ok anyway

We don't force choices on the user to further our own goals, because not doing so is Goal One. Everything else is secondary to this.

The consent and autonomy of an installing user over their system, SHALL NOT be infringed.

styx is a consent-first operating system.

Why? Because those don't exist, in a meaningful way; and it is necessary to enter the field with this rule in mind, lest earlier decisions be used as justification to erode this fact.

styx is built from many free-software components, and in turn, sets out to further enable the use, production and maintenance of free software.

Personally, I see an insurance of software freedom as a goal of styx, but my ideas on what entails “freedom” derive from a basis of consent and autonomy at the systematic level, more so than “freedom” in a contrived libertarian stance, and more so than “source code”, in a reductively technical sense.

styx is an opinionated and inherently political movement in and of itself, I cannot deny that - and decisions need to be made to align with the values of styx, however, said values are also a moving target that we aim to decide, with the decisions we make. This cyclical affair is called “development”, and at the end of it, we want to enable development to be an informed and open process with as many diverse minds as possible, which means that restrictions to software freedom - which restrict the scope of development - may be deleterious to that goal set.

styx takes a pro-“Program”, anti-“App” stance to its own software. We won't forbid “apps”, that's silly, but we won't be making our stuff an “app” for sure.

But on the flip side - I want styx and its own software to be approachable to the common person - as if it were an “app”, where possible, excluding fine technical tunings and things like that.

Ideally, styx does what Mac OS X Server tried to do, when it comes to services and plug-in functionality - making it manageable, visible, and workable from a familiar and discoverable frontend.

styx uses a signed and tamper-evident source of software, which includes full bills-of-materials and source code, where available, with the archive that the software is redistributed by.

styx software archives (which are our packages and components) contain a GUID partition table disk image, with a VHD footer - so that they can be mounted and opened in Windows, macOS, and Linux - including styx.

Package names, and their signatures and authority/authenticity tracking, derives from DNS - either our own, via styx.systems, styx.software and styx.community - or your own repository, or your own internal/intranet library of components.

All packages include all of their minor library dependencies, with the software. They are not statically compiled, but the libraries are commingled in the package, in a special place for library dependencies.

Finally, packages may be partially-fetched, as needed. Since a styx software archive includes _everything_ necessary to build the software, the package size may be larger than necessary to just run the program. Individual partitions in an archive can be fetched independently, and joined with a partial archive file, with sparse ranges of 0's in package locations that are not present. HTTP Range methods, and similar tooling on other protocols, is used to only request what is necessary as it is fetched. Missing components can always be fetched later. Mirrors must and will always include the entire archive file, as a bare minimum, though.

styx is managed by two software components: the styx-installer application, and the styx-daemon service.

styx-installer is what you interact with when installing the OS, and managing packages. It is a cross-platform application with an optional GUI, and a well-defined API. Its task is simple: to fetch/download packages, and put them in the right place. styx-installer does not need to extract, mount, or interact with the system beyond this - reducing its complexity, which is important, as it is an internet-facing program.

The styx-daemon is the background process, which handles all styx package mounting, unmounting, periodic tasks (such as update checking, package expiry and the like) and management (through a local or RPC API). Its main job is to monitor the location where styx packages are placed, check their integrity and applicability, and integrate them into the system after that - instantiating the styx-installer when necessary, to bring in runtime packages or other package components as necessary.

As mentioned before, styx-installer is the software used to download and install both styx packages, and the styx OS. It is a cross-platform program, intended to run on Windows, Linux and macOS.

styx, when installed from an existing OS, does not prompt the user to wipe the partition table, or repartition their drive (except on Mac), or install a bootloader like GRUB. styx doesn't need any of this!

styx's kernel, initial environment and utilities, and the bootloader, are all self-contained in one file - the “styx bootfile” - which is included with, and updated by, the styx installer.

styx packages and the bootfile can coexist, and live with other existing operating systems on a volume, and it can use the existing OS' bootloader (such as Windows Boot Manager or macOS Trusted Boot) to boot styx.

styx will, according to users' configurations, be able to bring in packages from remote sources (including Network Block Devices), removable devices, fixed disk/flash partitions, and even periodic radio datacasts.

The same goes for configuration - the styx installation configuration can exist in firmware/NVRAM, device trees, ACPI tables, or boot blocks on a device's flash or disk - great for embedded systems!

This requires a lot of definition, but essentially: the person, group, administrator or organization, who first installs styx to a given machine, is given a cryptographic key to sign local packages and changes, integrate or exclude DNS names from updates, and modify the system's configuration on a systems level - including kernel changes, trust root changes, and the like. Only that person - and no one else, unless otherwise delegated by the principal user-installer.

We will be doing a lot of UX and UI work to focus on making the daunting tasks of managing a Linux-based system, far easier - as it should be.

When a machine is being managed by someone other than the user actually using the machine (as in a school or enterprise situation), it is made clear to the user what their capabilities and rights are to the system they are using, and who is in charge of supervising or managing it.

A control panel specifically for “Choices” - a collection, with a timeline and chronologically sorted, of every user choice made on that user's system up to that point - all “don't show this again” type dismissals, all questions asked and answered - or not - will be collected on this panel.

Below that, any unmade or unprompted choices can also be made, in the same panel, ahead of being asked.

You always have the option to change your mind later - where that's not possible, it is made explicitly clear that it isn't, but this should be rare.

A managed environment, like an enterprise or school deployment, can also use Choices as points in a decision matrix, to determine the shape and effective layout of a given deployment.

It's up to you to figure out what the “x”-factor is in your styx installation - we empower you with the ability to make your personal computer everything you need, and much of what you want.