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
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