Em que você está logado, de fato

Quem opera rede passa o dia em interfaces de fabricante: um console web, uma linha de comando proprietária, uma plataforma de gerência. Por baixo de quase tudo isso está a mesma coisa. O balanceador de carga tem um sistema de arquivos com /var/log dentro. O firewall roda tarefas do cron. O ponto de acesso tem um shell. Quando a documentação de um fabricante manda rodar tcpdump no appliance, não é analogia - é o tcpdump, lendo um filtro BPF, escrevendo um arquivo pcap, exatamente como o artigo sobre captura descreve.

Isso vale saber por uma razão prática antes de uma histórica: no momento em que você reconhece o appliance como um host vestindo um produto, uma quantidade grande de instinto de diagnóstico se transfere. Disco cheio é disco cheio. Um processo que não morre é um processo que não morre. Rotação de logs, permissões de arquivo, sincronia de horário, resolução de nomes, uma tabela de inodes esgotada - falham num firewall pelas mesmas razões e com os mesmos sintomas que em qualquer outro lugar, e a documentação do fabricante muitas vezes descreve o sintoma sem nomear a causa.

1969, e o jogo

A origem é famosamente modesta. Os Bell Labs saíram do Multics, um ambicioso projeto de tempo compartilhado que construíam com o MIT e a General Electric, em 1969. Várias das pessoas que trabalharam nele - , , Rudd Canaday, Doug McIlroy - acharam que o projeto lhes ensinara algo que valia guardar, e Thompson tinha um jogo chamado Space Travel que queria rodar. Escreveram um sistema pequeno para um PDP-7 descartado, começando pelo sistema de arquivos. Brian Kernighan é creditado com o nome: Unics, um trocadilho com Multics, depois grafado Unix.

Em 1971 quiseram uma máquina maior, e o jeito de conseguir orçamento para um PDP-11 foi prometer escrever software de composição tipográfica para o departamento de patentes dos Bell Labs. O primeiro uso em produção do Unix foi formatar pedidos de patente.

A decisão que o tornou portátil

Em 1973 Ritchie reescreveu a maior parte do núcleo numa linguagem que projetara em boa medida para isso: o C. Na época aquilo beirava a heresia. Sistemas operacionais eram escritos em assembly porque desempenho importava e supunha-se que linguagens de alto nível fossem desperdício demais.

O retorno foi que o Unix deixou de estar preso a uma máquina. Portá-lo para hardware novo passou a significar portar um compilador C e recompilar, em vez de reescrever tudo, e em meados da década a mesma árvore de código rodava em equipamentos de vários fabricantes. Todo sistema operacional que um profissional toca hoje descende dessa decisão - inclusive o que está dentro do appliance no rack.

O acidente de licenciamento

Aqui está a parte que explica o formato da indústria, e não é uma decisão técnica de jeito nenhum.

Em 1956 a AT&T encerrara um processo antitruste por acordo, comprometendo-se a se restringir a comunicações de operadora - telefone e telégrafo. Seus advogados leram aquilo como significando nenhum negócio além de telefones. Então, quando os Bell Labs tiveram um sistema operacional, não podiam vendê-lo. Uma cláusula separada do mesmo acordo obrigava a AT&T a licenciar suas patentes a preços simbólicos, e o Unix foi licenciado do mesmo jeito: barato, a universidades, com o código-fonte.

E, decisivamente, as licenças eram mínimas. O software vinha como estava, sem royalties e sem suporte e sem correções de erro. Essa omissão é a importante. Usuários que não podiam ligar para um fabricante consertavam as coisas eles mesmos e mandavam as correções uns aos outros, e uma cultura de correções, ferramentas e código compartilhados se formou em torno de um produto cujo dono estava legalmente impedido de dar assistência. O artigo de 1974 na Communications of the ACM tornou o sistema famoso; a versão 6, em 1975, foi a primeira amplamente distribuída fora dos Bell Labs.

Um remédio antitruste dirigido a um monopólio telefônico produziu, como efeito colateral, o modelo de distribuição que a indústria de software passou os cinquenta anos seguintes redescobrindo.

Berkeley, e por que todo programa de rede se parece

O mais consequente dos licenciados universitários foi a Universidade da Califórnia em Berkeley, cuja Berkeley Software Distribution virou uma linha paralela de desenvolvimento. O trabalho de Berkeley é onde nasceu boa parte do que quem opera rede usa todo dia - sobretudo a interface que um programa usa para abrir uma conexão de rede, projetada ali, e que é a razão de código escrito para um Unix compilar em outro.

É a segunda metade da história das guerras de protocolo, vista pelo lado do software. O venceu em parte por ser livre de implementar e já estar rodando; já estava rodando em boa medida porque vinha no Unix que as universidades já tinham.

Fragmentação, litígio, e o momento que importou

O Unix comercial então se fragmentou. Todo grande fabricante lançou o seu - Sun, IBM, HP, DEC, SGI - cada um incompatível o bastante para irritar e parecido o bastante para frustrar, que é o que o foi escrito para conter. Enquanto isso a propriedade do código original mudou de mãos e virou objeto de litígio: os Unix System Laboratories processaram o braço comercial da distribuição de Berkeley no começo dos anos 1990, e uma década depois outra rodada de litígio tentou sustentar reivindicações contra o Linux.

O momento é a parte historicamente decisiva. O Unix livre com a posição jurídica mais clara estava preso num tribunal exatamente quando um estudante finlandês anunciou, em 1991, um núcleo que escrevera sozinho. O Linux chegou sem o ônus, e organizações que teriam hesitado diante de um processo não precisaram hesitar. É por isso que o appliance no seu rack tem muito mais chance de ser Linux que - embora a linha BSD esteja bem viva, e alguns sistemas operacionais de rede sejam construídos sobre ela.

O que isso significa quando algo quebra

A interface do fabricante é um filtro, não o sistema. Um console de gerência mostra o que o fabricante decidiu expor. Quando a resposta não está lá, ela em geral continua existindo num arquivo de log, numa tabela de processos ou numa captura de pacotes por baixo.

Saiba onde está a fronteira do suporte, e respeite-a. A maioria dos fabricantes de rede distingue com clareza entre uma linha de comando suportada e um shell subjacente, e o faz por boas razões: mudanças não suportadas não sobrevivem a atualizações, não são cobertas pelo suporte e não são visíveis à gestão de configuração de que a plataforma depende. Ler pelo shell para diagnosticar é prática normal; escrever por ele para consertar coisas é como parques se tornam insustentáveis. O uso correto deste conhecimento é entender o diagnóstico e então aplicar a correção pelo caminho suportado.

E as habilidades genéricas são as duráveis. Certificações de fabricante expiram e linhas de produto são descontinuadas - este catálogo é em boa parte um registro disso. A capacidade de ler um log, seguir um processo, filtrar uma captura e raciocinar sobre um sistema de arquivos não expira, porque é o mesmo trabalho desde que um grupo de pessoas nos Bell Labs quis rodar um jogo sobre voar até os planetas.

Fontes