Resumo

  • Xinu era um sistema operacional compacto, mas completo, que os estudantes podiam montar em etapas e iniciar em placas de experimentação.
  • O laboratório da Purdue automatizava a reserva da placa, a transferência da imagem e o acesso ao console serial. Isso tornava o caminho até um sistema em execução mais repetível, sem medir quanto os alunos aprenderam.

Randy Bond guarda uma lembrança específica: na primavera de 1984, no último ano da graduação na Purdue, ele cursou sistemas operacionais com Doug Comer e usou a primeira edição do livro de Xinu. Décadas depois, descreveu a construção de um sistema desde o início como uma experiência marcante para seu trabalho posterior com software embarcado. É o relato retrospectivo de um aluno, não uma avaliação da turma inteira. Ainda assim, ele aponta a aposta pedagógica de Comer: acompanhar a construção e iniciar o resultado pode tornar o sistema mais inteligível do que estudar apenas suas interfaces. O depoimento de Bond publicado pela Purdue registra essa experiência; o material do projeto mostra a estrutura que a sustentava.

O prefácio do livro parte de uma lacuna conhecida. Estudantes podem aprender os serviços de um sistema operacional e continuar imaginando sua parte interna como uma caixa-preta. A resposta de Comer não foi apenas reduzir o assunto, mas oferecer um sistema cujas peças fossem construídas numa hierarquia deliberada, começando numa máquina sem sistema operacional e deixando claras as dependências entre componentes. O prefácio do Xinu percorre processos e memória, sincronização, entrada e saída independente de dispositivo, drivers, protocolos e sistemas de arquivos como partes de um projeto executável, não como uma lista de funcionalidades.

O Xinu era pequeno, mas a Purdue não o apresenta como brinquedo nem como Unix com outro nome. A sigla significa “Xinu Is Not Unix”, e o projeto ressalta que a estrutura interna é diferente. A afirmação didática é mais restrita: um sistema compacto ainda pode expor componentes comuns de um sistema operacional e as abstrações que os conectam. Isso dá à disciplina uma implementação concreta para examinar. Não demonstra que exista uma única arquitetura correta, nem que quem constrói Xinu compreenda todo sistema operacional comercial. A descrição do projeto da Purdue informa seu escopo e seus limites.

O laboratório físico fazia do livro algo além de diagramas e listagens de código. Os alunos compilavam e vinculavam uma imagem em estações Linux comuns. Um conjunto separado de máquinas de retaguarda conectava as placas de experimentação à Ethernet, a dispositivos de reinicialização remota e a um multiplexador de portas seriais. O software reservava uma placa disponível, transferia a imagem, abria uma janela de console e iniciava o sistema. Assim, uma alteração no código podia voltar à execução física sem que o aluno reconstruísse manualmente todo o caminho de hardware a cada tentativa. A descrição do laboratório da Purdue detalha essas etapas.

Essa divisão entre frente e retaguarda é a superfície operacional da aula. A estação de trabalho conserva ferramentas conhecidas; o conjunto de placas transforma a execução física em recurso compartilhado. Automatizar reserva e transferência reduz trabalho repetitivo, mas não automatiza o raciocínio. Uma inicialização bem-sucedida mostra que uma imagem chegou a uma placa e começou a rodar. Não prova, por si só, que o estudante compreendeu escalonamento, memória, interrupções ou acesso a dispositivos. É nessa fronteira entre execução observável e compreensão demonstrada que as alegações precisam parar.

O acesso ao hardware também era uma condição de projeto. O prefácio informa que, quando foi escrito, as placas Galileo e BeagleBone Black escolhidas custavam menos de US$ 50. A linha do tempo do projeto relata que a reformulação de 2014 usou 120 placas Galileo doadas e algumas BeagleBone Black. Esses são valores e quantidades históricos, não preços atuais nem uma conta de custo por aluno. As fontes não publicam ocupação das placas, tempo de espera, taxa de falhas ou custo de suporte. Elas mostram que a Purdue montou um laboratório compartilhado de baixo custo, mas não permitem calcular sua economia completa.

O trabalho também foi colaborativo. Comer escreveu o livro e conduziu o sistema, mas o prefácio agradece a estudantes de pós-graduação pelos ports e drivers, identifica Rajas Karandikar e Jim Lembke pelo desenvolvimento de drivers Galileo e do sistema de transferência em várias etapas, e cita alunos que encontraram problemas e contribuíram com código. A linha do tempo da Purdue também credita a Dave Stevens trabalho com Comer numa implementação completa de TCP/IP. Retratar Xinu como criação individual apagaria o modelo que as fontes mostram: alunos e colaboradores alteravam o sistema enquanto aprendiam a operá-lo.

A máquina virtual oferece outro caminho, mas não é igual à placa. A Purdue diz que a versão para VirtualBox substitui algumas operações de entrada e saída mapeadas em memória por tratamento compatível com I/O mapeado em portas e usa outro driver Ethernet. A VM reduz a barreira do hardware, mas muda a interface que o estudante exercita. Qualquer relato de resultado deve dizer se veio de uma placa física ou de um emulador.

O legado que as fontes sustentam é específico. Xinu combinou uma implementação legível com um caminho repetível do código à máquina, permitindo que estudantes observassem mais do sistema do que uma API revela. O relato de Bond registra a experiência de uma pessoa. Os materiais do projeto documentam código, organização do laboratório e usos relatados, mas não comprovam ganhos de aprendizagem em estudo controlado nem fornecem um levantamento independente das adoções posteriores. Executar o código torna a lição verificável; um registro de inicialização não vira, por isso, uma pesquisa sobre aprendizagem.

Fontes