Microsoft abre ThreadX como código abierto

ThreadX de Eclipse: código abierto y licencias

• Muchos ven abrir el código de ThreadX como una victoria clara frente a mantenerlo como propietario, especialmente dado su enorme base de despliegue.
• A algunos les preocupa que la gobernanza de la Eclipse Foundation sea lenta/burocrática y pueda dejar que los proyectos se estanquen, pero otros señalan que cualquiera puede hacer un fork si el progreso se detiene.
• Hay confusión sobre la licencia: el repositorio de GitHub existente aún muestra una licencia de evaluación/uso limitado en hardware, pero los anuncios dicen que está migrando a MIT. Varios comentaristas toman MIT como el estado final previsto y esperan actualizaciones en el repositorio.

Contexto estratégico: Microsoft, AWS, FreeRTOS

• ThreadX (rebautizado como Azure RTOS) fue adquirido después de que Amazon comprara FreeRTOS; los comentaristas ven el movimiento de Microsoft hacia Eclipse como un paso atrás en esa estrategia de RTOS para IoT.
• Varios mensajes sostienen que Amazon compró FreeRTOS para impulsar el bloqueo en AWS IoT y las cargas de trabajo automotrices/de “vehículo definido por software”; se percibe que Microsoft siguió la corriente más que lideró.
• A algunos les inquieta el control de las grandes nubes sobre los RTOS centrales, pero otros creen que el principal beneficio son SDK y herramientas más maduros.

Certificación de seguridad e impacto en la industria

• Un tema importante es que ThreadX ya cuenta con certificaciones de seguridad (por ejemplo, automotriz y ferroviaria). Mantenerlas bajo un modelo abierto se considera costoso, pero potencialmente “cambiador de la industria”.
• La certificación se describe como un proceso pesado, con costes continuos y recertificación para los cambios; aun así, partir de una base ya certificada se considera una gran ventaja.
• Hay debate sobre si la certificación actúa como punto de control: puedes modificar libremente el código, pero pierdes el estado certificado salvo que recertifiques. El consenso: esto constriñe a todos por igual, incluida Microsoft, pero Microsoft probablemente tenga vías de recertificación más baratas.

Comparaciones con otros RTOS

• ThreadX se caracteriza como muy pequeño y centrado: esencialmente un planificador más primitivas de threading/memoria/IPC.
• Zephyr se ve como más rico en funcionalidades (mejor soporte de placas, infraestructura de pruebas), pero más complejo y todavía trabajando hacia la certificación de seguridad.
• FreeRTOS se usa ampliamente, pero no está certificado para seguridad por sí mismo; existe un derivado comercial (SAFERTOS) para ese espacio.
• Otros RTOS mencionados como ahora abiertos incluyen µC/OS-II/III; QNX se señala como algo aparte (propiedad de BlackBerry) y no afectado.

Raspberry Pi, VideoCore y firmware de GPU

• Hay gran interés en ThreadX porque sustenta el firmware de arranque VideoCore de Raspberry Pi, que controla el hardware y trata a los núcleos ARM como “esclavos”.
• Algunos esperan que esto conduzca a una publicación como código abierto del firmware de GPU de la Pi; otros argumentan que es poco probable debido a IP separada de Broadcom, DRM y riesgos de patentes.
• Ya existe un firmware abierto en clean-room para Pi; los comentaristas dicen que el código fuente de ThreadX es en gran parte irrelevante para ese esfuerzo.

Notas embebidas e históricas

• Varios mensajes recuerdan el uso prolongado de ThreadX en impresoras, cámaras, motores de gestión y otros sistemas profundamente embebidos.
• Se discute cuánto ha avanzado la tooling FOSS embebida y que los RTOS suelen ser minimalistas y a menudo ya no son propietarios.
• Un debate lateral cubre la historia de Linux frente a MINIX y qué cuenta como un “fork”, ilustrando cierta confusión pero sin afectar el tema de ThreadX.