+## Function outline
+
+### OS Image
+The Makefile uses `debootstrap` to set up a Raspbian environment. Package signatures will be verified. Operations within the Raspbian environment are performed using `qemu`. Thus building on a x86 host platform is possible. The environment is then copied to an image file using loopback mounting. The `files` directory contains an overlay of Raspbian config files, which are copied into the image file at this stage. Since this happens at _image_ creation, the debootstrapped root _directory_ is modified as little as possible.
+
+The list of raspbian packages which are installed in the chroot environmant can be extended in `config.mk`.
+
+### Bluetooth and Wifi Networking
+DHCP and DNS services on Oktopus are provided by `dnsmasq`. Bluetooth networking is provided by the regular Linux Bluetooth stack using hci, bridge, and ip/ifup utilities. All attempts to connect to the Bluetooth network ap are trusted automatically, this is facilitated by a shell loop in (`files/`)`etc/rc.local` (autotrust is not otherwise provided by the Bluetooth stack).
+As a matter of convenience during testing and debugging the sensor computer can also join an existing Wifi network. Wifi credentials can be provided in `config.mk`. Because Oktopus will not provide DHCP and DNS on Wifi, the name resolution for Oktopus services will not work on Wifi and the sensor webapp may not be usable. Only Bluetooth networking is intended for this kind of operation.
+
+### Sensor readout and Webapp
+
+ The sensor application is currently under development. The `gummikraken` submodule provides virtual sensors with simulation data. Gummikraken will be gradually replaced by working sensor drivers.
+
+ The display application (oktopus_frontend) is developed as a separate project. See its respective repository for a detailed documentation.
+
+Also see git submodules:
+ * gummikraken (to be removed)
+ * teesock
+ * gummikraken/oktopus_frontend (submodule to be moved to the main repo)
+
+The sensor application resides under `/srv/` in the generated system image. Each sensor is read periodically by a distinct program. Each sensor program provides sensor readout on stdout in a short time interval of its own choosing. All sensor programs are launched in parallel by `hatch.sh`. The sensor data is accumulated and provided on a Unix socket (`/tmp/oktopus.sock`) by the program `teesock`. Each connection to this socket will yield a copy of the current sensor stream.
+
+The display application is served over HTTP by the busybox httpd, which is launched from inetd. The display reads the sensor data as an HTTP Event Stream from port 8200 (Okt-Two-pus ;-). The Event Stream is generated from the sensor stream on the aforementioned Unix socket. Conversion of the seonsor readout to the HTTP Event Stream format is done by `tentacles.sh`, which is also launched via inetd.
+