Developer notes
This is the engineering side of FDS: how the pieces are built, why choices were made, and what we actually measured. The user manual describes how to use the current interfaces without the milestone history.
Start with the active cartridge/desktop revision. Its acceptance is separate from the frozen 0.1.0 release. Old test reports describe the inputs named in those reports; a changed source tree needs fresh checks.
Design and build references
- Master plan
- Build host and dependencies
- Development workflow
- Workstation tooling plan
- Architecture, packages, rootfs, init, services
- Reproducible builds and frozen releases
- Dasung integration and physical monitor procedure
- Physical bay calibration and stress procedures
- Implementation ledger and roadmap
Acceptance history
- clap-validation
- dasung-validation
- m0-validation
- m1-validation
- m10-validation
- m11-validation
- m12-validation
- m2-validation
- m3-validation
- m4-validation
- m5-validation
- m6-validation
- m7-validation
- m8-validation
- m9-validation
- workstation-validation
Earlier guides and working notes
These retain useful implementation details and the historical interfaces that went with them. Use the user manual for current commands, especially software cartridge creation: new payloads contain installed Void package trees.
- architecture
- boot
- build-host
- cartridges
- cleanup
- dasung
- data
- desktop
- development
- eeprom
- getting-started
- glossary
- implementation-status
- init
- internal-storage
- m4-work
- master-plan
- media-tools
- packages
- performance
- power
- recovery
- releases
- reproducible-builds
- roadmap
- rootfs
- services
- software-format
- stress-testing
- tooling
- troubleshooting
- workstation-tooling-plan
- workstation