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.

the styx project isn't dead!

... but cohost.org is soon going to be.

For one thing, we are probably the first, and will be the last, Linux distro and/or operating system and/or utility software project to use cohost.

Wait. What's a cohost again?

If you've never heard of cohost: It is a rather interesting and independent personal blog/social media site that, unusually for places nowadays, has no third-party cookies, tracking, analytics or network advertising (they had an "artist alley", a sort of classifieds page), and has exhibited a keen and sharp focus on user trust, safety, and creativity.

Currently, our blog at https://styx-os.org/ is a mirror of our cohost blog, at https://cohost.org/styx-os/ - which, with the lovely cohost-blogger software by @oatmealine, has been a fantastic way to put up posts and comments on our own site, in a way that is moderated and minimally-impactful.

We will be moving this blog onto our own servers over the coming month, as cohost's posting deadline (October 1) looms, and the final site shutdown (December 31) nears.

· 5 minute read

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 repositories1; 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.)

Footnotes

  1. 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. ↩

· 2 minute read

styx is a consent-first operating system.

This is perhaps the most important point to cover, because it informs every step of every process we do to produce, promote and develop styx.

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.

(This is going to be a long post, just a heads up.)

· 11 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.

 · 1 minute read
view on cohost · powered by cohost-blogger

styx logo styx copyright 2020 sirocyl / ellie (kymkdd) / ncommander / styx contributors

Use of other names and brands is not intended to reflect a claim of, or right to, use the name or brand. styx is an operating system using the Linux kernel and components, and "styx Linux" as a phrase does not reflect the inclusion of the Linux brand or trademark in the styx project. Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.