During the 2025/1/21-22 Face-to-Face the members of GEISA met to discuss some foundational aspects of the specification. The group made the following foundational decisions:
The GEISA Execution Environment (EE) will use Linux as the core OS.
It will not use a native hypervisor underneath the OS, though it is possible an implementer might offer this in a transparent way.
GEISA will not specify or provide a specific distribution nor will it provide a specific build recipe at this time.
It is possible a future version of the GEISA EE would be based upon a specific distribution or a specific build recipe for Yocto (or something similar); however, that was seen as a later step, once the specification has more industry support.
As a result apps written for the GEISA EE may need to be compiled for specific targets.
The EE will use containers to provide application isolation.
This decision was based on the application isolation requirements discussed in the meeting.
A future version of the specification may provide guidance on running applications natively within the environment, especially if the overhead of containers is too high for some applications or environments.
The EE containers will be as light-weight as possible.
A sub-team will explore options to minimize container sizes including rootless containers, micro containers, and reusing as much as reasonable from the core OS, while still allowing applications to override core OS provided libraries where necessary.
The sub-team will also explore which container technologies to use. Note: container != Docker. Containers rely on Linux kernel technologies such as cgroups and namespaces. There are a variety of container systems that build on these core technologies including Docker, Podman, LXC, balenaEngine, etc.
GEISA will use a uniform management mechanism such that all GEISA EE will respond to the same set of commands and can be managed by a single management system.
A sub-team will explore possible mechanisms for management including (but not limited to) technologies such as LWM2M and OMA-LW.
The application image transfer mechanism may vary based on the network technology in use.