outro relembrar é viver.
Em outra coluna apresentei Andrew “Bunnie” Huang , um hacker de mão cheia que faz as coisas acontecerem. Ao final daquela coluna perguntei quais eram as histórias brasileiras semelhantes que mereciam ser compartilhadas.
Eu fiquei esperando e continuo esperando contribuições naquele sentido. Temos que mostrar as coisas boas que acontecem aqui, as histórias de engenheiros e técnicos que produzem ou produziram coisas no nosso Brasil. Aproveitando o mote resolvi relembrar uma história pouco conhecida da computação nacional. O Macintosh brasileiro. E resolvi fazer isso entrevistando o Rainer Brockerhoff, hacker de mão cheia que conhece as minúcias do Macintosh como, eu acredito, nenhum outro brasileiro conhece e que participou do desenvolvimento do Macintosh brasileiro. Fiz isso no modelo de 10 perguntas:
1) Qual é a sua história e como você entrou no projeto do Macintosh brasileiro?
Comecei a trabalhar como programador em 1969, na época praticamente só havia computadores em bancos e universidades. Em 1977 comprei um Apple II para uso doméstico e alguns anos depois, quando começaram a surgir os primeiros microcomputadores nacionais, comecei a trabalhar num dos fabricantes, a Quartzil. Lá fui responsável pelo sistema operacional e aprendi projetar hardware também. Quando o Macintosh foi lançado em 1984 me interessei e trouxe um dos primeiros ao Brasil; trouxe também ferramentas de desenvolvimento e comecei a fazer pequenos programas para uso próprio.
Eu já conhecia o pessoal da Unitron dos tempos de Apple II. Quando o hardware do Mac Unitron já estava praticamente pronto, me convidaram a ajudar com o software, e claro que me interessei.
2) Como era composta a equipe e qual era a sua função na equipe?
Creio que eram umas 10 pessoas. Eu era consultor externo, como não moro em São Paulo, e ia para lá uma vez por semana. Fiz boa parte da “Toolbox” – a parte da ROM responsável pela interação com aplicativos e com o usuário. Outras pessoas fizeram os drivers de dispositivos e as rotinas gráficas. Devo ter feito talvez 30% da ROM, é difícil avaliar hoje.
Mais no final também fui responsável pela ROM de inicialização – o equivalente, na época, ao firmware – e também fui convidado pela SEI (Secretaria Especial de Informática) a preparar um parecer técnico detalhando como havia sido feita a engenharia do software Mac Unitron.
3) Como foi realizado o processo da engenharia reversa do software?
Um programador da Califórnia, Steve Jasik , havia desenvolvido um produto chamado MacNosy (“narigudo”) para decodificar a ROM do Mac. Usamos isso bastante, mas também havia outras ferramentas, cujo nome exato não me lembro mais.
4) Como era o processo de desenvolvimento? Quais eram as ferramentas disponíveis? Vocês desenvolviam em qual plataforma?
Era um processo de fazer chamada por chamada do sistema. Para cada uma, eu pegava aquela parte da saída do MacNosy, que era em linguagem Assembler não muito simplificada, e fazia anotações ou alterações para fazer a lógica mais inteligível. Incluia nessa listagem “patches” (alterações) introduzidas pelo disquete de sistema para consertar bugs ou expandir as funções, e comparava isso com a descrição daquela chamada na documentação da Apple. Então eu recodificava aquela função em linguagem C, tínhamos um compilador chamado Aztec C que era bem razoável. Depois, conferia se o código objeto gerado realmente executava as funções desejadas. Tudo isso rodava no meu Mac 512K. A partir de certo ponto tínhamos uma ROM que já podia ser testada.
Isto era possível, também, porque o Mac Unitron tinha o dobro do espaço disponível de ROM do Mac da Apple. Os programadores da Apple tiveram que usar de muitos truques para fazer o software caber, enquanto que tínhamos espaço para absorver as ineficiências do C e ainda consertar vários bugs direto na ROM.
5) Você viveu o período da reserva de mercado, na tua opinião quais foram os prós e contras daquele período?
Acho que foi uma reserva equivocada e inadequada, que não atingiu seus objetivos; especialmente porque pouca gente, na época, entendia os aspectos técnicos ou previa o progresso da globalização. Todos se basearam em indústrias que levaram décadas para se estabelecer e não previram a aceleração da tecnologia digital. Não era viável fabricar chips no Brasil, mas não se podia importar – isso retardou por mais uma década a implantação de carros com motores injetados, por exemplo.
Na empresa onde eu trabalhava, ostensivamente “protegida” pela reserva, precisávamos de um analisador lógico para desenvolver o sistema. O analisador continha um microprocessador, portanto não podia ser importado sem um processo de isenção que levou quase 3 anos! Como toda a indústria estava nessa situação, a reserva foi um grande fomento ao contrabando.
6) O projeto do Macintosh nunca saiu por interferência governamental. Você pode contar um pouco desta história?
Como eu disse, fiz um parecer técnico detalhando que o projeto era legal dentro dos conceitos, da época, de engenharia reversa. Acompanhei o restante só através de informações de terceiros, mas o que me disseram foi que a SEI fez dois laudos técnicos favoráveis – examinando hardware e software separadamente. Durante o processo de aprovação, sob pressão americana, o congresso aprovou a lei 7646 (Lei do Software), que retardou ainda mais as coisas, e o projeto teve que ser refeito e reapresentado. Em 1998 o CONIN rejeitou o projeto. O CONIN era composto de 8 representantes da sociedade civil e 8 ministros do governo. 7 representantes independentes estavam presentes e votaram a favor do projeto. 7 ministros votaram contra e um se absteve. Diante do empate, valeu o voto contrário do ministro da ciência e tecnologia, presidente da comissão.
7) Qual é a tua opinião sobre os limites legais da engenharia reversa?
Não sou advogado, então isso é apenas uma opinião. No caso Unitron, o mercado brasileiro era fechado à Apple, e ela não tinha registrado patentes aqui. E obviamente a Unitron não conseguiria vender no mercado americano; então era uma disputa mais em cima de conceitos de propriedade intelectual. A engenharia reversa foi feito com total acesso ao original, coisa que hoje em dia não seria aceita; mas dentro do conceito de reserva da época era válido.
8 ) E depois do projeto do Macintosh? O que você fez?
Por vários anos, fui diretor técnico de uma empresa que fabricava monitores médicos digitais, que foi até um exemplo de como se poderia desenvolver tecnologia aqui sem copiar ninguém, e concorrer com aparelhos importados. Em paralelo montei um dos primeiros provedores comerciais de Internet no Brasil. E claro, sempre dei consultoria e desenvolvi software para Macintosh. Hoje me considero semi-aposentado mas continuo fazendo shareware para Mac.
9) Você é um dos raros desenvolvedores brasileiros para Macintosh. Como é desenvolver para esta plataforma e como você consegue colocar os teus produtos no mercado?
Acho que o mais importante é visar o mercado global, trabalhar somente pela Internet e ficar em contato com a comunidade de desenvolvedores. É necessário dominar o inglês muito bem, claro. Escolhi um nicho de mercado que facilita isso – shareware para usuários de melhor nível técnico, e para os colegas desenvolvedores. Vou frequentemente a congressos no exterior e publico vários softwares grátis e/ou “open source”. Tudo isso gera publicidade e reconhecimento pela comunidade.
Nada disso adianta se os produtos não forem bem acabados e funcionais. O mercado Mac é muito exigente nesse sentido. A minha tradição familiar é da marcenaria artesanal, meu pai por exemplo era especializado em produzir modelos de madeira para fundição que tinham que ser extremamente precisos. Sou o primeiro não-marceneiro da família, mas herdei a obsessão de polir e aperfeiçoar ao máximo os meus produtos. Se precisasse do shareware para sobreviver, e dedicasse tempo integral a isso, certamente seria possível – especialmente agora, com o mercado da Apple explodindo em várias direções.
10) Você estava no WWDC que a Apple lançou o Intel Inside. Qual foi a tua opinião na época e como você encara hoje? O que você espera da Apple do ponto de vista de software nos próximos anos.
Fiquei surpreso mas, depois de saber detalhes, otimista. Eu sempre disse que não seria possível fazer um bom emulador de PowerPC em Intel, mas uma vez que conseguiram (através do “Rosetta”), foi melhor. A Apple estava muito dependente da Motorola e da IBM que tinham outras idéias sobre a plataforma. Não acho o x86 ideal como arquitetura, mas é que temos hoje em dia. E a história mostra que a conversão foi bem-sucedida, e em menos tempo que anunciado.
O que vimos do Leopard e do iPhone me deixou muito animado quanto ao futuro do software, especialmente do OS X. Ainda não temos dados precisos, porque ambos só vão sair por volta de junho.
Links:
Para saber mais do Macintosh Brasileiro vejam os links abaixo. É interessante que até o nome de Sarney é envolvido na história. Se tiverem mais curiosidade procurem por “Macintosh + Unitron” no Google, vem bastante coisa:
http://inventabrasilnet.t5.com.br/mac512.htm
http://chester.blog.br/mac512.html
http://sts.imv.au.dk/arbejdspapirer/WP1_web.pdf (Referência ao Sarney)
O Steve Jasik também tem uma história interessante relativo a um ícone “Stolen From Apple” que é relatado no site sobre a história do Macintosh Folklore.
Ultimamente está saindo nos blogs uma câmera de vídeo de 360º. No meu mestrado eu fiz exatamente uma câmera desta. Olha o protótipo aí do lado. Ela se conecta ao computador via uma conexão firewire e o computador realiza a fusão das 5 imagens que são capturadas individualmente pela câmera.
Measuring and Managing Performance in Organizations
é um dos melhores livros que já li e deveria ser obrigatório para quem pensa, trabalha ou se relaciona com qualquer um dos assuntos acima. Oriundo de uma tese de doutorado premiada da Carnegie Mellon (berço do CMM) o livro cria um modelo simples com três participantes. Um chefe, um empregado e um cliente. Ele analisa o empregado que realiza um trabalho composto de várias atividades. Algumas são fáceis de serem medidas, outras não. O melhor resultado para o cliente é obtido com uma combinação destas atividades. No caso do chefe medir algumas destas atividades e não medir outras, ocorre uma disfunção, pois o empregado vai privilegiar a atividade que é medida, ignorando ou relegando as outras atividades, neste caso, apesar das mátricas estarem indicando um mar de rosas, o resultado final para o cliente não está. Ocorreu uma disfunção.Normalmente a resposta simplória para lidar com este problema, é criar um novo conjunto de medidas que monitorem todas as atividades. O autor mostra de forma repetitiva a quase impossibilidade de se alcançar este objetivo para trabalhadores criativos. As atividades não são repetitivas e fáceis de serem medidas. Aliás, boa parte do nosso fetiche por medidas é originário da nossa herança do modelo industrial que o trabalho é dividido no formato de Taylor. Taylor dividia o trabalho em pequenas partes que pudessem ser medidas e otimizadas. Funciona no caso dele pois o trabalho é repetitivo, mas alguem acha que o trabalho de design é repetitivo? Como medi-lo?