To any device
One binary. Any platform. No toolchain to install.
The strategic promise is deliberately blunt: one small command — harb — does everything, and it is a single file you drop onto any laptop. No SDK, no build environment to assemble, no dependency to resolve. If you can copy one file, you can develop, boot and ship a machine.
You write the .machine file in any editor. harb check and harb plan need nothing else. Booting runs the whole machine in QEMU — on Linux, or on Windows through WSL — on that same laptop, with no board required to see it work. When it is right, the same build produces the image for the real device; writing it to a card is a command you run yourself, and the tooling prints it rather than running it, because a wrong letter there can erase a disk.
The same file, projected to four kinds of device
A normal PC
x86_64. Boots the image directly, or in an emulator first. The everyday server or counter box.
A Raspberry Pi
arm64. Written to an SD card with two slots, so an update is tried once and rolled back by the board itself.
A tablet or phone
The device's kernel kept; everything above it is your declaration. One world, no app drawer.
A sensor or MCU
No kernel at all — the program is the device. The same file, projected down to a microcontroller.
Getting it onto a device you already have
You do not upgrade an existing OS into Harobanda — you replace it, the way you install any operating system, with a whole image. On a PC or laptop, write the image to a USB stick or a spare disk and boot from it; it can sit beside the old system or take the machine over entirely. On a Raspberry Pi, flash the SD card and slot it in. The box then boots your declaration instead of whatever ran before.
Phones are the honest exception, and the reason is the whole argument of this site: most consumer phones weld the software to the hardware and lock the bootloader, so no operating system but the vendor's may boot on them. The touch shape targets hardware where that lock can be opened; otherwise the vendor's weld is the wall. Sovereignty, or its absence, is decided at the bootloader.
The strategic requirement
Same file, same command, every target. You do not learn a new toolchain per device — you change one word in the declaration, the board, and re-derive the image. Then the image goes onto the device — a PC's disk, a Pi's SD card, a microcontroller's memory — by a command you run yourself. Two copies of the system and a hardware watchdog (a timer that restarts the board unless the system keeps resetting it) make the first boot a trial, so a bad deploy returns to the version that worked, with no one on site.