We just want you to be able to use the computer without fighting it. That's all.

styx will be a consent-first, usability-oriented operating system, with a Linux® kernel, and a distribution of packages built from nixpkgs.

More information:

What makes styx different?

We're going for a modular, system-agnostic linux environment optimized for quick setup and teardown, and built to work with existing system software where possible.

In our RFC pipeline, a few ideas shine through. As a rule, styx is a consent-first operating system. We don't force choices on the user to further our own goals, because not doing so is Goal One.

Our methodology follows a strict documentation before implementation policy, meaning that the prose written is the target — and sets the requirements for our code.

styx's strength is in its versatility. it will run where it needs to, how it needs to, and usecases can be defined as sets of styx configurations.

Quality is the building problem.

All software on styx, even third-party FOSS, goes through quality assurance steps. Higher-quality software is promoted better.

Warnings while building will be treated as errors first (-Werror), then built again with that disabled. Any build stoppage automatically registers as a bug with us.

Finally, with the help of nix, styx packages will aim for reproducible builds.

How secure is styx?

Package names and IDs are canonicalized to DNS records. Packages and repos are identified by their domain name, or FQDN, and metadata and package repositories are provided via DNS infrastructure. This ensures an authoritative, federated and decentralized registry of package ownership, and importantly, one we don't need to maintain a global registry for.

A repository of packages is simply the part of the domain name in front of the package title itself. The entire repository is versioned, rather than individual packages. The version is committed to DNS as a TXT record.

Packages will be signed. The identity of the maintainership signature is backed by DNS, by way of DNSSEC. In cases where that is not possible, HTTPS certificates, or a public keychain or keyserver can also contribute to the styx PKI.

To further ensure an authoritative, tamper-resistent and tamper-evident root of trust, we will provide authoritative DNS nameservers, and employ DNS over HTTPS (DoH), for any DNS question which can be answered with styx's own group of authoritative nameservers.

This blog mirrors posts from the styx cohost page.

Open comments: On software freedom and styx.

I'm not making a hard decision yet on this front, but I do want to request comments to inform our decision-making process regarding the rules defining "software freedom" - associating only Free Software with the styx "systems" and "software" maintainership and repositories, where possible, and whether to prohibit "nonfree" software in styx and its core repositories 1; to what scope, if so; and what impact that will have on the maintainability and usability of a styx system, moving forward.

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.

(This post corresponds to RFC 26 in the styx standards track.)

This mainly applies to software we develop and maintain, in the "systems" and "software" repositories, either as our own software, as adopted projects, or as forks and patches for other software, that are considered core and integral to styx itself - things like the kernel, the init system, the package manager, the desktop environment, and drivers with first-tier support (e.g., excluding some GPU drivers which insist on proprietary or non-distributable software.) Things outside of that, which would live in the "community" repository, will clearly and strongly indicate the nature of their license, or that they communicate with proprietary or commercial services, but in a non-condescending and non-alarmist way. ↩

Oct 27, 2023 · 2 minute read

debut post!

hi. This is styx. (@sirocyl here!)

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

I'll be opening a blog here, and mirroring it to our not-very-secret website in the coming whenevers, to host RFCs, progress reports, poll for ideas and the like.

styx is a project borne of frustration. the parent post, is only the tip of the iceberg; 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 just want you to be able to use the computer without fighting it. That's all.