Microsoft abre o código-fonte do ThreadX

Eclipse ThreadX: Código Aberto e Licenciamento

• Muitos veem a abertura do ThreadX como uma vitória clara em vez de mantê-lo proprietário, especialmente dada sua enorme base de implantação.
• Alguns temem que a governança da Eclipse Foundation seja lenta/burocrática e possa deixar projetos estagnados, mas outros observam que qualquer pessoa pode fazer um fork se o progresso travar.
• Há confusão sobre o licenciamento: o repositório existente no GitHub ainda mostra uma licença de avaliação/uso limitado a determinado hardware, mas anúncios dizem que a migração será para MIT. Vários კომენტadores tratam MIT como o estado final pretendido e esperam atualizações no repositório.

Contexto Estratégico: Microsoft, AWS, FreeRTOS

• O ThreadX (rebatizado como Azure RTOS) foi adquirido depois que a Amazon comprou o FreeRTOS; os comentaristas veem a mudança da Microsoft para a Eclipse como, na prática, um recuo dessa estratégia de IoT-RTOS.
• Várias postagens argumentam que a Amazon comprou o FreeRTOS para impulsionar o lock-in do AWS IoT e cargas de trabalho automotivas/“software-defined vehicle”; a Microsoft é vista como tendo seguido, e não liderado.
• Alguns se incomodam com o controle das grandes nuvens sobre RTOSes centrais, mas outros acham que o principal benefício são SDKs e ferramentas mais maduros.

Certificação de Segurança e Impacto na Indústria

• Um tema importante é que o ThreadX já possui certificações de segurança (por exemplo, automotiva, ferroviária). Manter isso sob um modelo aberto é visto como caro, mas potencialmente “transformador para a indústria”.
• A certificação é descrita como um processo pesado, com custos contínuos e recertificação para mudanças; ainda assim, começar a partir de uma base certificada é considerado uma grande vantagem.
• Há debate sobre se a certificação atua como um ponto de controle: você pode modificar livremente o código, mas perde o status certificado a menos que recertifique. O consenso: isso restringe todos igualmente, inclusive a Microsoft, mas a Microsoft provavelmente tem caminhos de recertificação mais baratos.

Comparações com Outros RTOSes

• O ThreadX é caracterizado como muito pequeno e focado: essencialmente um escalonador mais primitivas de threading/memória/IPC.
• O Zephyr é visto como mais rico em recursos (melhor suporte a placas, infraestrutura de testes), mas mais complexo e ainda trabalhando para obter certificação de segurança.
• O FreeRTOS é amplamente usado, mas não é por si só certificado para segurança; existe uma derivação comercial (SAFERTOS) para esse espaço.
• Outros RTOSes mencionados como agora abertos incluem µC/OS-II/III; o QNX é apontado como algo separado (de propriedade da BlackBerry) e não afetado.

Raspberry Pi, VideoCore e Firmware da GPU

• Há grande interesse no ThreadX porque ele está na base do firmware de boot VideoCore do Raspberry Pi, que controla o hardware e trata os núcleos ARM como “escravos”.
• Alguns esperam que isso leve a um lançamento de código aberto do firmware da GPU do Pi; outros argumentam que isso é improvável devido a IP separado da Broadcom, DRM e riscos de patentes.
• Já existe um firmware aberto em sala limpa para o Pi; comentaristas dizem que o código-fonte do ThreadX é em grande parte irrelevante para esse esforço.

Notas Embutidas e Históricas

• Várias postagens relembram o uso antigo do ThreadX em impressoras, câmeras, management engines e outros sistemas profundamente embarcados.
• Há discussão sobre o quanto as ferramentas FOSS para embedded evoluíram, e sobre como RTOSes normalmente são minimalistas e muitas vezes já não são mais proprietários.
• Um debate lateral cobre a história de Linux vs MINIX e o que conta como um “fork”, ilustrando alguma confusão, mas sem impactar o tema ThreadX.