simonpoole1 / rachel-build

Build process for RACHEL installations
2 stars 1 forks source link

Goal: store materials in a separate partition, which may be on another physical drive #2

Open julianharty opened 10 years ago

julianharty commented 10 years ago

We have been experimenting with scripts that copy across selected materials from an existing RACHEL image into an expanded image that includes the root filesystem, OS, etc. This work is useful, now we've decided having the data in a separate partition would improve the design, deployment portability and scalability of the project.

Design: Separate the data (the RACHEL materials) from the OS. They can then be updated and stored separately. Also the RACHEL materials (and possibly the OS) can be stored in read-only partitions which can help improve performance, security, caching, and extend the life of underlying SD-cards and flash storage.

Deployment: We can deploy RACHEL more easily to various OS's and hardware devices, for instance we can use RACHEL-on-a-stick. A relatively small OS image is easier to transfer and write to cost-effective and available SD-Cards globally. (large cards are seldom available in rural areas).

Portability: Data (the materials) is OS agnostic. The running software (ka-lite, kiwix, etc) are tiny and easy to install and run on most OS's, including Windows, OSX and Linux, including ARM devices such as Raspberry Pi's.

Scalability: smaller, less expensive SD-Cards, data on USB memory, etc. are slightly easier manage and take from location to location. Less technical staff can update data separately from the OS, etc. so we can scale in terms of deployments and managing existing installations (once they use the separate partition for data).