3. Historico

Sumário

3.1. Observação sobre Subjetividade

O texto desta seção, apesar de conter elementos objetivos, também conta com abudância de elementos subjetivos na forma de exposições sobre a experiência de desenvolver os programas aqui descritos, e a maneira como essas experiências foram progressivamente formando base e fundamento para sustentar o desenvolvimento do projeto Omnitty. Considere-se portanto que esta seção integra, também a Parte Subjetiva da monografia, na medida que lhe concerne, não obstante apresentar-se como seção autônoma para fins de organização.

3.2. A origem do Omnitty

O Omnitty nasceu durante o período em que fui um dos administradores da Rede Linux do IME-USP. Os objetivos do programa surgiram das necessidades que já existiam na Rede Linux desde seus primórdios. O Omnitty também não foi o primeiro programa a tentar atender essas necessidades; teve ele alguns predecessores na administração da Rede Linux, em geral na forma de scripts que se prestavam, em maior ou menor grau, ao mesmo objetivo. Exponho aqui os principais predecessores do Omnitty, como cada um funcionava, e quais as suas deficiências.

3.3. Script "espalha"

Primeiramente utilizava-se um script entitulado espalha para rodar comandos específicos e determinados nas máquinas da Rede. Para utilizá-lo, era necessário elaborar um arquivo contendo os comandos a serem executados (um script), e depois chamar o script espalha com esse arquivo. O espalha, por sua vez, tinha internamente uma lista de máquinas, e iterava por essa lista sequencialmente, logando-se por SSH em cada uma delas e nela rodando o script fornecido pelo administrador.

Havia quatro problemas fundamentais com o espalha:

  1. A necessidade de preparar-se um script de antemão, que implicava no administrador ter que fazer pressuposições sobre a configuração da máquina e ter de prever uma série de casos possíveis.
  2. A falta de interatividade, isto é, os programas a serem executados precisavam ser necessariamente não-interativos, pois o administrador não tinha como interagir com os programas que estavam rodando remotamente, visto que o processo era dirigido por um script. Por isso, o administrador não tinha como lidar com imprevistos. Era necessário prever todos os imprevistos. Ou seja, não obstante ser pouco prático, o espalha também afrontava a lógica.
  3. A falta de robustez, pois quando o script cuidadosamente preparado falhava em alguma das máquinas, seja por algum erro fortuito ou por não produzir os resultados esperados, o administrador não era notificado de maneira cabal. O erro simplesmente aparecia no console em meio ao resto da saída, e rapidamente rolava para fora da área visível da tela, lá sendo perdido para todo o sempre. Ao final da operação, portanto, o administrador não tinha como saber, salvo por posterior intervenção empírica, quais as máquinas onde a operação realmente teve sucesso. A "recomendação", portanto, ao usar-se o espalha era que o administrador observasse ininterruptamente o console, abstendo-se de piscar durante toda a operação, e paralelamente anotasse num pedaço de papel quais as máquinas em que a operação produzira erros para posterior vistoria.
  4. A falta de paralelização. O espalha logava-se seqüencialmente nas máquinas, isto é, não logava numa máquina antes de desconectar da anterior. Por isso, enquanto uma máquina estava processando o script, as demais ficavam inertes; se uma delas demorava excessivamente ou travava completamente, o espalha ficava para sempre à espera do término da operação, não procedendo às demais máquinas que estavam ociosas.

3.4. "Espalha reloaded"

Posteriormente escreveu-se uma nova versão do script espalha, desta vez com gerenciamento assíncrono de conexões: o script fazia conexões a todas as máquinas requisitadas e gerenciava suas respostas, apresentando ao administrador um painel geral de máquinas e os status de saída do script em cada uma.

O problema da falta de paralelização fora resolvido, assim como parcialmente o problema da robustez, já que as falhas ficavam mais evidentes ao administrador mesmo que esse não dedicasse sua atenção integral durante a execução dos comandos, pois a falha do script aparecia destacada em vermelho no painel.

Subsistiam ainda dois dos problemas anteriores: a falta de interatividade e a necessidade de prever imprevistos, pois, assim como o espalha que lhe precedeu, este também orientava-se unicamente a scripts pré-programados.

Em retrospecto, o novo espalha acrescentou muito pouco ao anterior, se levada em consideração a enorme complexidade adicional que se lhe acedeu; escrito num híbrido de Perl e Bash, com tratamento de sinais precário e sujeito a race-conditions, o espalha reloaded, a despeito do título, ainda era substancialmente insatisfatório para os propósitos da Rede Linux.

3.5. GtkEspalha

A busca por soluções melhores para o problema levou-me a cogitar a elaboração de um programa gráfico, isto é, que funcionasse sobre o X Window System ao invés do terminal. A motivação para tal era que o no GNOME já existia, pronta para uso, uma widget de terminal que permitia que programas embutissem um ou mais terminais em suas janelas.

Um dos problemas era que essa widget somente estava disponível para o GTK (Gimp Toolkit) versão 2.0 ou superior; enquanto que na Rede, por virtude de utilizar a distribuição Debian Stable, ainda estava presa à paleozóica e insípida versão 1.2. Uma solução que me ocorreu e que chegou a ser implementada foi modificar o código-fonte do programa xterm para induzí-lo, aparentemente contra sua vontade e ferindo seu orgulho, a embutir-se num controle GTK ao invés de criar uma janela autônoma, fato que logrei com sucesso satisfatório sem desfigurar inteiramente o código do xterm.

Após algum desenvolvimento preliminar, abandonei o projeto por causa de um problema fundamental: na Rede Linux não seria prático para os administradores executarem um programa gráfico nos servidores, já que neles (assim como em boa parte dos servidores Unix e Linux utilizados no mundo), não havia servidor nem as bibliotecas de cliente X. O login indireto, utilizando outras máquinas como servidores X, pareceu-nos demasiado complicado para ser prático; instalar o X nos servidores nos pareceu indesejável, e portanto continuar o desenvolvimento do GtkEspalha tornou-se inútil.

3.6. O Omnitty

A decisão de que "rodar num terminal texto" era um requisito fundamental fez-me procurar alternativas para implementar um programa com a mesma concepção do GtkEspalha, mas que rodasse numa interface ncurses. Assim surgiu a idéia do Omnitty.

Naturalmente, não há uma widget pronta para curses que faça emulação de terminal, nem tampouco um programa como "xterm" que possa ser convencido a rodar embutido numa área da tela. Portanto, foi necessário implementar minha própria biblioteca de emulação de terminal, que denominei ROTE (Our Own Terminal Emulation Library). Forneço mais detalhes sobre essa biblioteca na seção "ROTE".