https://github.com/stal-ix/ix
ix package manager, statically build packages, for darwin/linux, with clang
https://github.com/stal-ix/ix
bootstrap distribution hermetcity linking reproducibility static
Last synced: 19 days ago
JSON representation
ix package manager, statically build packages, for darwin/linux, with clang
- Host: GitHub
- URL: https://github.com/stal-ix/ix
- Owner: stal-ix
- License: mit
- Created: 2022-05-26T00:38:32.000Z (about 4 years ago)
- Default Branch: main
- Last Pushed: 2026-04-26T01:47:19.000Z (about 2 months ago)
- Last Synced: 2026-04-26T03:32:35.055Z (about 2 months ago)
- Topics: bootstrap, distribution, hermetcity, linking, reproducibility, static
- Language: Shell
- Homepage: https://stal-ix.github.io/
- Size: 31.8 MB
- Stars: 188
- Watchers: 3
- Forks: 21
- Open Issues: 3
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
**This repository is a stable branch. All development activities are carried out on https://github.com/pg83/ix.
Kindly submit all PRs there.**
# stal/ix
**stal/ix** is a Linux distribution (**Stalix**) built around a custom, source-based package/build system (**IX**).
This repository documents and hosts the tooling and package set used to build a complete OS image, while the core idea is the same everywhere:
- treat “the OS” as a **content-addressed store** of build artifacts
- keep builds **deterministic and debuggable**
- make it possible to build large systems without turning the build language into a Turing-complete nightmare
- minimize “runtime surprises” (dynamic loader, random `.so`/plugins, SUID binaries, etc.)
> If you are looking for “another distro”, Stalix is closer to “a laboratory for building a *correct* Linux” than a mainstream desktop distribution.
## Projects
### 1) IX — the package manager / build system
IX is a package manager in the “Nix/Guix family”, but with different trade-offs:
- **Content-addressed store** (think `/ix/store/...`) with immutable build outputs.
- **Source-first**: packages are built from sources using explicit recipes.
- **Non–Turing-complete(ish) package definitions**: the system is designed so that describing packages doesn’t turn dependency resolution/build planning into an unbounded computation.
- **Templated package recipes**: packages are generated from templates (Jinja-style), which makes “do the same, but with a tiny change” actually practical.
- **Hermetic builds / isolation**: build steps are intended to run in an isolated environment (no “oops, my build tool touched `/bin` on the host”).
- **Cross-target support** (work in progress, but used in practice): build artifacts can target other OS/ABIs.
- **Aggressive focus on static linking** and reproducibility where it makes sense for the system.
Typical concepts you will see:
- `/ix/store/-` — immutable outputs
- “realms” / “system realm” — an assembled environment composed from store entries
- wrappers around toolchains/linkers to enforce policies and reduce per-package boilerplate
### 2) Stalix — a distro built on IX
Stalix is “what happens when IX builds the whole OS”.
Core ideas:
- **No systemd**.
- **No SUID binaries by default** (security model is built to avoid the classic “SUID + plugins = boom” story).
- **A minimal, explicit userspace**: fewer implicit runtime dependencies, fewer “magic” daemons.
- A strong preference for **static binaries** and **explicit composition** over “shared library soup”.
- A “build it like you mean it” approach: toolchain updates, graphics stack experiments, hermetic build fixes, etc. are treated as first-class engineering work.
Stalix is also published to external indexes (e.g. Repology) to make package freshness visible and to enable automated update workflows.
## Why does this exist?
Because the typical Linux distro model tends to accumulate properties that are hard to reason about:
- dynamic linking everywhere (ABI constraints, loader complexity, startup overhead, dependency fragility)
- plugins loaded from the filesystem at runtime
- build systems that assume `host == target`
- “supply chain by default” (random prebuilt blobs inside source trees)
- implicit host environment leakage into builds
IX/Stalix is an attempt to push in the opposite direction: **make the system boring and explicit**.
## Repository layout (high level)
This repo typically contains:
- the IX entrypoint and supporting tools (executors, wrappers, helpers)
- the package set (“ports tree”)
- distro assembly logic (images/rootfs, init, base system composition)
- CI helpers and metadata dumps (e.g. for Repology)
Exact layout evolves; use the top-level directories as the source of truth.
## Getting started
### Build a package
Examples from real usage:
```sh
# Build a single package
./ix build bin/b64
# Cross-target build example
./ix build bin/b64 --target=freebsd-x86_64
```
### Mutate / assemble the system realm
```sh
# Apply system composition changes (think “assemble/refresh the system realm”)
./ix mut system
```
### Run a tool from the store (convenience)
```sh
# Resolve a binary name to the package and run it
./ix run zstd --help
```
> Notes:
> - The exact CLI and the available targets/features depend on the current state of the repo.
> - This project is intentionally not “one command to install on any machine”. It’s a build system and a distro lab.
## Security model (high-level)
Stalix tries to avoid entire classes of problems instead of “patching around them”:
- avoid SUID binaries where possible
- avoid loading untrusted native code at runtime (classic .so plugin model)
- prefer hermetic builds and explicit inputs
- make “what is in the system” auditable via the store and build graph
This does not magically make the system secure. It’s a set of engineering choices that try to reduce attack surface and reduce complexity.
## Contributing
Contributions are welcome, especially in areas that scale poorly for a single maintainer:
- package updates and fixes
- build isolation fixes (removing implicit host dependencies)
- bootstrap work (reducing circular toolchain requirements)
- CI improvements and reproducibility checks
- documentation (yes, really)
If you send PRs:
- keep changes minimal and scoped
- include rationale (what broke, why this fixes it)
- prefer deterministic fixes over “works on my machine”
## Status / disclaimer
This is an active engineering project, not a polished consumer OS.
Expect:
- breakage during large toolchain transitions
- experiments (graphics stack, init, build isolation)
- non-mainstream decisions (by design)
If you want a stable, boring workstation today — use a mainstream distro.
If you want to explore how a “correct-by-construction-ish” Linux could be built — welcome.