Mas isso é defeito ou característica?

A versão em inglês desta frase é muito conhecida por quem usa programas de computador: “is it a bug or a feature?”. Ela roda pela área de informática há muito tempo. Pode causar algum espanto o uso da palavra “bug” (inseto) para indicar um defeito. Mas, na computação, há uma base histórica e anedótica para isso. Reza a lenda (e há documentação) que, quando os computadores ainda usavam válvulas eletrônicas e relés eletromecânicos, houve certo dia um mal funcionamento inesperado em uma máquina. Após buscar a causa do problema, verificou-se que um inseto se introduzira entre as lâminas de um relé do computador, causando o mau contato deletério.

O primeiro “bug” foi, assim, literal e um evento mecânico. Com a crescente complexidade da programação, além de eventuais erros físicos em equipamentos, erros de programação passaram a ser muito frequentes. Um programa complexo é de difícil depuração. Mesmo com todo o cuidado do programador, é provável que erros e incoerências tenham escapado. Por extensão do que ocorreu com o relé e o inseto, os erros de programação passaram a ser chamados “bugs”, e o processo de examinar cuidadosamente o programa para livrá-lo dos eventuais erros “debugging” – ou seja, “desinsetização”.

Além dos diversos tipo de erros que podem estar ocultos num programa, ele pode apresentar características inesperadas, introduzidas a propósito no programa, ou, simplesmente, decorrência de alguma inconsistência ou de um “bug”. Um dito irônico afirma que, uma vez detectada a existência de um erro, se ele for convenientemente documentado no sistema, evoluirá e passará a ser considerado uma “característica”. No processador M6800 da Motorola havia uma instrução de máquina não documentada e que, se executada, faria o processador simplesmente desistir de prosseguir e passar a se comportar como um simples contador. O pessoal havia a denominado como “pare e pegue fogo” (HCF,“halt and catch fire” em inglês). Provavelmente esqueceram-se de removê-la após o fim da fase de projeto.

Enfrentamos esse tipo de problema em situações as mais diferentes do nosso dia a dia. Se algo é reconhecido como insuficiente ou gerador de risco, pode-se tentar consertá-lo ou, saindo pela tangente, avisar os usuários que “não é bom” usar determinado recurso, porque pode redundar em dor de cabeça. Nos mapas antigos, por exemplo, as regiões desconhecidas e inexploradas eram marcadas como sendo áreas em que “há dragões”, ou seja, melhor seria não ir para aqueles lados: um erro transformado em característica. Quem quiser prosseguir, que o faça por sua própria conta e risco.

O risco, aliás, é sempre inerente à pesquisa – não se faz investigação sem correr algum risco, mas há que manter em mente a necessidade de não criar riscos adicionais pela simples dificuldade em depurar o que fizemos, ou de não gerar situações que saiam do controle. 

O simples ato de tentar prever tendências e resultados, mesmo que executado com plena isenção, pode envolver metodologias e amostras nem sempre controláveis nas condições disponíveis. 

Mas, como somos todos humanos e falíveis, sempre podemos lançar mão de alguma explicação posterior, que transforme o que pareceria uma falha metodológica ou de aplicação, numa interessante “característica inesperada”. Mas a quem sofreu as consequências, não alivia saber se elas foram devidas a um “bug” ou a uma “feature”.

====
O "bug" do Mark II em pessoa!

https://en.wikipedia.org/wiki/Software_bug

'Há ainda muito a ser feito', Jon Postel

Há versões sobre o ânimo original da Internet. Opto pela que parece-me acomodar dados e fatos. A Internet nasce como sucessora da Arpanet, projeto de rede encomendado à ARPA (Advanced Research Projects Agency) e financiado pelo DoD (Departamento de Defesa Norte-Americano). O recurso que sustentou o projeto é de origem militar. Mas o resultado, almejado pelos líderes do projeto e cientistas envolvidos, no ambiente e mentalidade dominantes nos anos 60 em círculos intelectuais nos EUA, foi uma rede totalmente aberta, sem controle central, sem censura e sem restrições. Leonard Kleinrock, um dos pais do projeto, tem em sua sala na UCLA (Universidade da Califórnia, Los Angeles) placa que marca a inauguração da Arpanet em 29 de outubro de 1969, ano em que também houve Woodstock...

Kleinrock continua ativo na UCLA. Além dele, muitos foram fundamentais no projeto, a começar por J.C.R. Licklider, diretor da ARPA à época, que escreveu textos que anteveem o futuro das redes. Vale a pena uma consulta rápida sobre seus textos e seu perfil.

Tive a sorte de poder encontrar três outras personagens fundamentais. Claro que há muitas mais. Centro-me nessas porque constituem o eixo central, o tripé mais conhecido. Vint Cerf, hoje “Evangelista Internet” na Google, que junto com Robert Kahn escreveu o TCP/IP, protocolo que se firmou como o de escolha para redes amplas, Steve Crocker, que serviu até 2018 como Presidente da ICANN e que assina em abril de 1969 o primeiro RFC (Request For Comments), série aberta e acessível que contem toda a documentação sobre a rede, incluindo os padrões definidos e... Jon Postel. Postel nasceu em 1943 e faleceu em 16 de outubro de 1998, há exatos 20 anos. Foi um baluarte técnico e dos conceitos da rede. Batalhou por uma rede aberta, descentralizada, sem controle nem burocracia, baseada em colaboração e confiança. Postel confundia-se com a IANA (Internet Assigned Numbers Authority) na tarefa de distribuir os endereços IP necessários ao funcionamento da rede e era o editor dos RFC, o organizador dos documentos e discussões sobre a Internet. Era ele também quem delegava domínios, como os de código de país. Em abril de 1989 delegou, sem maiores liturgias, o .br ao time técnico e acadêmico que operava a rede brasileira. Bastava-lhe concluir que a rede local estava ancorada onde havia entusiasmo e serviço à comunidade, para fazer a delegação. Era fácil reconhecer Postel: a indefectível mochila às costas, longas barbas e melenas, e sandálias de couro – o arquétipo comum dos técnicos “de raíz” da época. Um sujeito acessível, mas convicto do que pensava, portanto turrão. Manter o que ele defendeu é, em parte, a razão de ser do decálogo do CGI, lançado em 2009. A Internet que Postel queria era uma rede distribuída, com um núcleo sólido mas simples e agnóstico. A ação ocorreria nas bordas, a cargo dos usuários, conteúdos, serviços. Hoje vê-se uma concentração de poder no centro da rede, o que pode afetar sua neutralidade. Se os usuários passarem a ter sua atividade monitorada, ou sugerida pelo centro, isso pode ser ruim e perigoso. Talvez os riscos da atual centralização forcem o pêndulo do poder a voltar de novo para a periferia da rede.

PS. No youtube.com há um vídeo curto, de Vint Cerf, “I remember IANA”. Vale a pena vê-lo.

Material adicional: RFC 2458 - "I Remember IANA", em:
https://tools.ietf.org/html/rfc2468
https://www.youtube.com/watch?v=h2SpygwimA8&t=143s
https://www.internetsociety.org/grants-and-awards/postel-service-award/ten-year-tribute-jon-postel/

http://www.postel.org/remembrances

Boas Maneiras

A forma de convivência mais segura não é, ao contrário do que possa parecer, a existência de leis que nos obriguem à civilidade e à lhaneza, mas algo mais profundo e cultural, que nos constranja a seguir uma etiqueta social de convívio. Mais importante que uma lei que nos mande ceder o lugar a um ancião ou a uma grávida é termos a convicção moral de que isso é o correto a fazer.

O convívio na Internet segue na mesma linha. Sendo uma rede composta de milhares de redes autônomas independentes que aceitam voluntariamente integrar-se num único corpo, a cooperação e colaboração entre todas é vital para que a colcha de retalhos resultante seja operacional, eficiente e segura. 

Apenas como exemplo, lembremos como funciona a descoberta de rotas na Internet: como uma mensagem, que mando de meu computador a um distante alguém, chegará ao seu destino? O “mágico” que opera a proeza é um padrão, com mais de 20 anos de existência, chamado BGP (Border Gateway Protocol), o protocolo de borda. O BGP orienta a uma rede que, numa espécie de confidência vicinal, informe às suas vizinhas o que sabe e o que ela contêm, ao mesmo tempo que recebe esse tipo de informação das vizinhas. A troca de informações é propagada e gera uma tabela de roteamento que define caminhos e, passo a passo, levará a mensagem ao destino. 

Há muitas outras minúcias no roteamento da Internet, mas essa descrição simplista mostra claramente como funciona a colaboração: os dados andam na rede porque seus integrantes cooperam e repassam o que sabem aos vizinhos, criando rotas dinâmicas e eficientes. 

O lado complexo e obscuro fica por conta dos detalhes, tradicional residência do Tinhoso... Sempre os mal-intencionados podem se valer da confiança que receberam de seus pares, para fraudar o bom comportamento da rede toda, seja disseminando informações falsas afetando rotas e topologia, seja fazendo-se passar por outrem para atacar alguém na rede. O dilema dos técnicos e operadores é como resolver (ou minimizar) essas ameaças, sem romper com os princípios fundadores da rede. Afinal, a Internet é conservadora em termos de princípios.

A Internet Society (ISOC), uma das instituições mais tradicionais, foi fundada em 1992 e funciona também como suporte administrativo ao IETF (Internet Engineering Task Force). A ISOC lançou uma iniciativa para, preservando as boas características da rede, diminuir o espaço de ação dos malfeitores: MANRS (Mutually Agreed Norms for Routing Security), algo como “normas mutuamente acordadas para a segurança do roteamento”. Os iniciados na área pronunciarão o acrônimo em inglês como “maners”, ou seja “maneiras”. Boas maneiras. 

Há vasta informação sobre o MANRS na Internet (em www.manrs.org). Se todos os operadores de redes autônomas implementarem as medidas que o MANRS prescreve, é bem provável que o número de ataques de negação de serviço e quetais diminua. E há a boa notícia de que muitos já aderiram e novos continuam a chegar. O NIC.br, que opera os Pontos de Troca de Tráfego no país, assinou com a ISOC um memorando de entendimentos para apoiar a disseminação do MANRS. São tempos em que necessitamos cada vez mais de “boas maneiras”, tanto na rede como na sociedade, para preservar, ainda, alguma esperança.

www.manrs.org