Build natively on the development Orin
Two units with different jobs: one builds and runs CI, the other is the deployment target. Building on the target architecture makes the glibc constraint structural rather than configured. The remaining risk is version parity between the two units, not architecture. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013kj58Jugkic783b8ZrtTVZ
This commit is contained in:
@@ -316,6 +316,7 @@ rewriting the document.
|
||||
| 5 | Rust for on-Orin services, Python for off-car tooling, Dart for the display client | Accepted | 2026-09-04 |
|
||||
| 21 | Two clocks per envelope; `monotonic` orders, `timestamp` references | Accepted | 2026-09-05 |
|
||||
| 22 | `signals.json` is the single source for signal name and unit; both are derived, never authored twice | Accepted | 2026-09-05 |
|
||||
| 23 | Services build natively on the development Orin; both units stay on the same L4T release | Accepted | 2026-09-05 |
|
||||
| 6 | Local logging first; off-board LTE telemetry deferred | Accepted | 2026-08-14 |
|
||||
| 7 | Camera/AI inference is a later, separate task | Accepted | 2026-08-14 |
|
||||
| 8 | Self-hosted offline navigation (MapLibre GL + Valhalla + PMTiles) over a cloud maps SDK | Accepted | 2026-09-03 |
|
||||
|
||||
Reference in New Issue
Block a user