Linux na universidade: da curiosidade para ferramenta de trabalho real
Eu já usava Linux no trabalho antes de entrar na faculdade. Na universidade, aprendi o que eu não sabia que não sabia — e por que o terminal é onde a produtividade de verdade acontece.
Antes de entrar na faculdade, eu já usava Linux no trabalho.
Administrava servidor de email Postfix no Debian. Configurava máquinas Ubuntu para uso em escritório. Sabia o suficiente para manter as coisas funcionando.
Quando entrei no curso de Ciência da Computação e a maioria dos laboratórios rodava Linux, achei que tinha vantagem. Estava certo — mas por razões diferentes das que eu imaginava. E havia partes de Linux que eu usava todos os dias sem entender.
O que eu sabia usar: os comandos que resolvia problema.
ls, cd, cp, mv, rm, chmod, chown, grep, tail -f, systemctl. O conjunto prático de quem mantém servidor. Quando algo quebrava, eu sabia os comandos para investigar e resolver.
O que eu não sabia: o que estava acontecendo embaixo.
Por que chmod 755 funcionava mas chmod 777 era problema? Eu aplicava as permissões corretas por convenção — mas não tinha internalizado o modelo de usuário/grupo/outros e o que cada bit representava. Sabia que funcionava, não por que funcionava.
A matéria de Sistemas Operacionais foi onde isso mudou.
Não porque o professor ensinou permissões de arquivo especificamente — mas porque ele ensinou o modelo que as permissões expressam. Processo tem usuário. Arquivo tem dono. O kernel verifica se o processo tem permissão antes de abrir o arquivo.
Quando isso conectou, eu parei de decorar permissões e comecei a raciocinar sobre elas. Se o processo roda como www-data e o arquivo é do root sem leitura para outros — sem precisar testar, eu sabia que ia falhar.
Entender o modelo é diferente de saber os comandos.
O que a faculdade adicionou ao meu Linux:
Shell scripting com lógica real. No trabalho, meus scripts eram lineares. Um comando, depois outro, com pouco tratamento de erro. Na faculdade, projetos exigiam scripts que tomavam decisões: liam argumentos, verificavam condições, falhavam de forma informativa. Aprendi $? para checar exit code. Aprendi set -e para falhar cedo. Aprendi que script que silencia erros é script que esconde problema.
Pipes como composição. grep "ERROR" /var/log/app.log | awk '{print $5}' | sort | uniq -c | sort -rn — a ideia de que você compõe ferramentas pequenas para fazer análise complexa sem escrever programa. Eu tinha usado pipes antes, mas sem perceber que era filosofia de design, não só atalho.
Man pages como documentação real. Antes, quando eu não sabia como um comando funcionava, procurava no Google. Na faculdade, aprendi a ler man pages — e descobri que a documentação estava ali o tempo todo, completa, com exemplos. A capacidade de ler documentação primária é habilidade diferente de saber usar ferramenta.
O que a experiência de trabalho me deu que os colegas não tinham:
Intuição de quando algo está errado. Um processo consumindo CPU alta, disco cheio, porta que não deveria estar aberta — eu reconhecia sinais antes de ter vocabulário formal para eles. Os colegas aprendiam a detectar os problemas depois de aprender a classificar. Eu classificava depois de já ter detectado.
Isso não é superioridade — é diferença de trajetória. Cada caminho tem pontos cegos e vantagens. O da prática tem o contexto. O da teoria tem o modelo.
Passei 2017 com dois Linux diferentes na cabeça: o que eu operava e o que eu entendia. Ao longo do ano eles foram convergindo.
Quando os dois se encontraram — quando o modelo formal explicava o comportamento que eu via na prática — a compreensão ficou sólida de um jeito que nenhum dos dois caminhos daria sozinho.
Essa semana: qual ferramenta você usa todos os dias mas nunca entendeu o modelo por baixo?