Não Queríamos Esconder o Linux — Queríamos Ensinar Linux

Existe um problema recorrente no ensino de tecnologia que muitos desenvolvedores acabam percebendo com o tempo:

iniciantes não sofrem apenas com programação. eles sofrem com configuração de ambiente.

Especialmente no Windows.

Para muitos estudantes, o primeiro contato com Linux, WSL, terminal, sudo, gerenciadores de pacotes e shell commands acaba se tornando uma barreira frustrante antes mesmo de começarem a desenvolver software.

Esse projeto começou com uma pergunta simples:

e se pudéssemos guiar estudantes durante o onboarding Linux em vez de apenas jogar comandos no terminal?

Essa ideia evoluiu para:

WSL Dev Setup Assistant

Uma aplicação desktop educacional open-source construída com Python e Kivy para ajudar usuários Windows a aprender Linux, WSL e terminal de forma progressiva.

Não escondendo Linux.

Mas ensinando Linux.

O problema real nunca foi o WSL

No início, tudo parecia um problema de tooling:

Instalar WSL
Instalar Ubuntu
Instalar Python
Instalar CLI
Fim

Mas observando estudantes reais em sala de aula, o verdadeiro problema ficou claro rapidamente.

O problema era sobrecarga cognitiva.

Os alunos estavam enfrentando ao mesmo tempo:

• terminal desconhecido
• autenticação Linux
• sudo
• gerenciadores de pacotes
• setup de ambiente
• instalação do Python
• configuração de PATH
• conceitos de WSL
• gerenciamento de distros

…tudo de uma vez.

Mesmo desenvolvedores experientes costumam subestimar o quão intimidador isso pode ser para iniciantes.

A abordagem errada: esconder Linux

Inicialmente pensamos em abstrair tudo atrás de botões:

[Instalar tudo]

Mas rapidamente percebemos que aquilo parecia errado.

Por quê?

Porque inevitavelmente os alunos precisariam usar Linux diretamente em algum momento.

Se a aplicação escondesse completamente:

• terminal
• shell commands
• sudo
• instalação de pacotes
• conceitos de WSL

…estaríamos apenas adiando a curva de aprendizado.

Então mudamos completamente a direção do projeto.

O ponto de virada

O projeto deixou de ser:

launcher de WSL

e começou a se tornar:

assistente educacional de onboarding Linux

Essa mudança alterou praticamente todas as decisões de arquitetura e UX tomadas depois.

A filosofia do projeto

O princípio central passou a ser:

não esconda Linux. reduza o medo do Linux.

Isso levou a uma experiência completamente diferente.

Em vez de executar comandos silenciosamente por trás da interface, a aplicação passou a:

• explicar conceitos
• guiar o estudante
• abrir terminais Linux reais
• contextualizar comandos
• introduzir o terminal progressivamente

O objetivo deixou de ser automação.

O objetivo passou a ser onboarding educacional.

Fluxo atual

Hoje o fluxo da aplicação funciona assim:

Welcome
→ Verificar WSL
→ Escolher distro
→ Instalar distro
→ Primeira execução Linux
→ Terminal assistido

Arquitetura

A aplicação utiliza uma arquitetura em camadas:

UI (Kivy Screens)
        ↓
Services Layer
        ↓
WSL Integration
        ↓
subprocess / wsl.exe

Essa separação ajudou bastante na organização:

• componentes de UI cuidam da experiência
• services orquestram comportamento
• integração WSL encapsula regras de plataforma
• execução de comandos permanece isolada

Por que Kivy?

O Kivy foi escolhido por alguns motivos pragmáticos:

• stack 100% Python
• suporte desktop multiplataforma
• prototipação rápida
• ciclo de iteração simples
• estratégia fácil de empacotamento

O objetivo inicial nunca foi criar uma aplicação desktop visualmente perfeita.

O objetivo era validar rapidamente a experiência de onboarding.

E o Kivy permitiu exatamente isso.

Uma das descobertas mais importantes de UX

No começo tentamos criar um “terminal fake” dentro da aplicação usando áreas de texto.

Funcionava razoavelmente para comandos simples:

pwd
ls
whoami

Mas falhava completamente para fluxos administrativos reais:

sudo apt install

Especialmente porque:

• senhas Linux não aparecem visualmente
• gerenciadores de pacotes são interativos
• comandos longos geravam ansiedade
• subprocessos interativos ficaram frágeis

Isso levou a uma conclusão importante:

um terminal simulado não é um terminal real.

Então redesenhamos completamente a experiência.

A solução melhor

Em vez de tentar emular Linux dentro da aplicação, decidimos abraçar o terminal real.

Hoje a aplicação:

1. explica o que vai acontecer
2. ensina os conceitos
3. abre um terminal Linux real
4. executa comandos Linux reais

Isso melhorou drasticamente:

• confiabilidade
• compatibilidade
• confiança do usuário
• valor educacional

Exemplo: ensinando sudo

Em vez de simplesmente instalar pacotes silenciosamente, a aplicação explica:

Esse comando usa sudo porque instala pacotes
no sistema Linux.

Você precisará informar sua senha Linux.

Depois abre um terminal real executando:

sudo apt update
sudo apt install python3-pip python3-venv pipx

O aluno não apenas “clica em botões”.

Ele começa a entender Linux.

Outro desafio inesperado: Ubuntu moderno e PEP 668

Durante os testes no Ubuntu 24.04 encontramos a nova restrição do Python:

externally-managed-environment

O tradicional:

pip install --user

já não era mais o melhor caminho.

Isso forçou outra decisão arquitetural:

usar pipx em vez de pip

O fluxo evoluiu para:

sudo apt install pipx
pipx install dev-setup-cli-jhonata

E isso acabou alinhando o projeto às práticas modernas de distribuição de CLIs Python.

UX virou o principal desafio de engenharia

Curiosamente, a parte mais difícil não foi implementar integração com WSL.

O mais difícil foi responder:

Como reduzir o medo sem esconder a complexidade?

Esse questionamento mudou completamente a natureza do projeto.

Começamos a desenhar:

• aprendizado progressivo
• explicações contextuais
• terminal guiado
• onboarding educacional
• DevEx assistido

O projeto foi deixando de ser apenas sobre WSL…

…e começou a ser sobre ajudar iniciantes a se sentirem confortáveis dentro de ambientes de desenvolvimento.

Funcionalidades atuais

Hoje a aplicação já possui:

• verificação do WSL
• descoberta de distros
• instalação de distribuições Linux
• orientação para primeira execução Linux
• criação guiada de usuário Linux
• terminal assistido
• execução em terminal Linux real
• instalação guiada do Dev Setup CLI
• mensagens educacionais contextuais
• navegação entre telas
• fluxo progressivo de onboarding

Open-source por design

O projeto foi pensado desde o início como open-source porque:

• ferramentas educacionais devem ser acessíveis
• problemas de onboarding são universais
• experiência do desenvolvedor importa na educação
• outras pessoas podem adaptar a ideia para diferentes contextos

O objetivo nunca foi criar uma plataforma enterprise.

O objetivo é experimentar DevEx educacional.

O que vem pela frente

Alguns dos próximos passos planejados:

• cards educacionais
• histórico de comandos
• terminal mais interativo
• empacotamento com PyInstaller
• modo aula
• testes automatizados
• múltiplos profiles Dev Setup

Considerações finais

Uma das lições mais interessantes desse projeto foi perceber que:

onboarding também é arquitetura de software.

Não apenas infraestrutura.

Não apenas scripts de setup.

Não apenas documentação.

A forma como pessoas entram em um ecossistema técnico influencia:

• aprendizado
• confiança
• retenção
• autonomia

E às vezes…

a melhor ferramenta de desenvolvimento não é a que esconde a complexidade.

É a que ensina a complexidade progressivamente.

Open Source

O projeto está disponível no GitHub e contribuições são bem-vindas.

Se você se interessa por:

• onboarding de desenvolvedores
• DevEx
• tooling educacional
• Linux
• WSL
• aplicações desktop com Kivy

…fique à vontade para explorar o repositório e contribuir. 👉 Repositório