Tecnologia, Arte e Cultura
Cada vez mais os sistemas Open Source vem encontrando utilização prática em tecnologias das mais variadas. Dentro dessa filosofia de utilização de softs de código aberto foi lançado o Katana, um braço robótica baseado em Linux, de baixo custo e alto desempenho, voltado para uso na indústria, na automação de laboratórios e em pesquisas.
Para mais detalhes sobre o invento leia em Inovação Tenológica.
Em entrevista para a Linux Magazine o presidente do Serpro, Marcos Mazoni, fala sobre a adoção do software livre nas empresas públicas. O Serpro é um dos principais fornecedores de soluções de tecnologia da informação para o governo federal e seus órgãos e empresas. Marcos Mazoni, presidente do órgão e do Comitê de Implantação de Software Livre do governo federal, falou a respeito de seu primeiro ano à frente da instituição, os desafios enfrentados e o que podemos esperar do próximo ano.
Transcrevemos a seguir a entrevista na integra.
Linux Magazine» No final de 2007, você previu uma economia de R$100 milhões em 2008 com a substituição de software proprietário por Software Livre no governo federal. Isso se concretizou?
Marcos Mazoni» Tivemos muitas substituições de software proprietário por Software Livre. Porém, o governo federal possui sistemas de informação construídos nos últimos 40 anos que ainda estão em operação. Por isso, as substituições ocorreram em grau muito maior em nossa infra-estrutura do que propriamente nos novos sistemas.
A adoção de Software Livre em nossas ferramentas de desenvolvimento e nossa infra-estrutura de rede, além da nossa gestão da infra-estrutura, promoveram uma economia talvez até maior do que R$ 100 milhões.
Diversos componentes de Software Livre, como nosso framework de desenvolvimento e nossa ferramenta de correio, agenda e catálogo (Expresso), entraram em importantes empresas, como Dataprev, Caixa Econômica Federal,Banco do Brasil e Petrobras, o que deu uma economia muito grande a todas as empresas do governo e, portanto, também para o orçamento.
LM» No momento, quais são os maiores clientes do Serpro?
MM» A Receita Federal corresponde a 70% da nossa atividade, enquanto o Ministério da Fazenda responde por 80%, ao Ministério do Planejamento cabem 10% e outros 30 órgãos compõem os 10% restantes do nosso trabalho.
Na prática, somos praticamente um órgão interno do Ministério da Fazenda.
LM» Como anda a migração do governo federal para o BrOffice.org?
MM» Após a adesão ao protocolo que orienta a utilização do ODF, estamos com todos os órgãos em processo de migração ou em planejamento com o PDTI para 2009. Isso inclui grandes estruturas, como o Exército, a Aeronáutica, Banco do Brasil, Caixa Econômica e outras.
LM» O episódio da aprovação na ISO do padrão concorrente do ODF, o OOXML, teve alguma repercussão negativa sobre os trabalhos de adoção do ODF no governo?
MM» Não, pois isso teve pouca influência sobre a adesão ao protocolo. Com os órgãos aderindo ao protocolo, eles fazem a opção natural pelo BrOffice.org.
LM» Você afirmou recentemente que em 2009 o Serpro iria promover treinamentos em ferramentas livres no governo, e que para isso seriam necessárias redes. Quais dessas redes já existem?
MM» Algumas já existem. Por exemplo, no BrOffice.org nós trabalhamos muito com o BrOffice Brasil. Outras estão em construção: estamos atuando nesse momento em parceria com cinco universidades federais com foco em ferramentas específicas. Com a Universidade Federal do Paraná estamos montando todo um processo de suporte e treinamento para bancos de dados livres; com a Universidade Federal de Pernambuco estamos trabalhando com ferramentas de reutilização de código e maturidade (desde análise de requisitos até a reutilização propriamente dita); estamos também trabalhando com mineração de dados com a Universidade Federal de Minas Gerais (Tamanduá); na Universidade Federal do Rio de Janeiro estamos trabalhando com a modelagem de dados. Estamos ampliando nossa rede para obtermos mais conhecimentos no mundo do Software Livre, pois o suporte depende cada vez mais de nós.
LM» Existe também interação com empresas privadas?
MM» Em dezembro, num evento no Rio de Janeiro, vamos colocar nossas ferramentas de desenvolvimento à disposição de comunidades externas. Nosso framework de geração de código Java, por exemplo, chamado 14 bis e derivado doPinhão da Celepar. O nome é uma homenagem a Santos Dumont, cuja obra (o Demoiselle) foi disponibilizada em 1909 para quem desejasse alterar e utilizar para qualquer outro fim.
Vamos fazer o mesmo com nossa ferramenta de gestão de projetos, o E-Car, que hoje tem comunidades de governo e será aberta também a empresas privadas. A idéia é que o governo federal tenha mais ferramentas de TI para controle de custos e processos principalmente com a crise financeira mundial que terá conseqüências importantes no próximo ano.
Nossa lógica não é sempre termos que gerar o código, mas gerar renda dentro do país.
LM» Quais foram as maiores conquistas e dificuldades do Serpro e do Comitê de Implantação de Software Livre ao longo de 2008?
MM» No caso do Serpro, foi a opção que tínhamos de não trabalhar com software básico. Fomos obrigados a reverter essa opção, pois não tínhamos na empresa pessoas especialistas em sistemas operacionais, bancos de dados etc. O maior desafio, então, foi desenvolver a capacidade para que nossos funcionários voltassem a trabalhar com software básico. Descobrir aqueles que se encontravam em outros projetos para trazê-los ao desenvolvimento de software básico foi um desafio. Por último, construir essas ferramentas também foi difícil, mas conseguimos fazê-lo em um ano.
Entre as conquistas, a nova ferramenta de declaração do imposto de renda usada em 2008 foi marcante, assim como a criação de um modelo de governança dos softwares que desenvolvemos junto a órgãos públicos de outras esferas. Tudo isso foi feito sem qualquer prejuízo ao processo que já estava em andamento.
LM» Em relação à ferramenta de declaração do imposto de renda, existe alguma previsão para transformá-lo em Software Livre?
MM» Como ele é uma mistura de diversas ferramentas, há a questão legal dos códigos. Tão logo isso esteja resolvido, não há dificuldades para disponibilizá-lo.
LM» Após o intenso planejamento em 2008, quais dificuldades você prevê nas ações do próximo ano?
MM» Prevejo as dificuldades naturais a uma mudança de cultura. Na realidade, eu assumo parte da culpa, pois sempre mostramos bastante a questão da economia, debatemos muito sobre a questão da qualidade técnica dos produtos, mas acho que a principal chave foi pouco abordada: é a mudança de postura, de produtos adquiridos (software proprietário) para algo que vamos compartilhar e construir juntos (Software Livre).
Nesse sentido, mesmo dentro do universo do Software Livre, é muito comum nos vermos em comparações que pertencem, na realidade, ao modelo de software proprietário, como afirmar que um software “não faz algo”, em vez de “ainda não faz isso”. Por conta dessa postura, muitas vezes são iniciados projetos a partir do zero simplesmente porque não há alternativa livre que realize uma das funções desejadas para o software. Temos um exemplo disso, que foi o desenvolvimento de uma solução (Carteiro) de email, calendário, agenda e catálogo de endereços. Já existia o Expresso, que também era um software livre, e que realizava as mesmas tarefas.
Colaborar e participar de uma comunidade seria a melhor opção, pois teríamos uma evolução muito mais rápida e um salto de qualidade. Essa mudança de postura é o grande diferencial.
Santos Dumont, usando idéias de vários especialistas da sua época, precisou de apenas um ano para desenvolver o 14 bis, enquanto os irmãos Wright — que não permitiram o uso de suas idéias — levaram dez. Por isso, o brasileiro liberou também os conhecimentos sobre sua criação.
LM» Em caso de mudanças políticas na esfera federal, é possível que mude também a estratégia do governo para o Software Livre. Nesse caso, existem medidas no sentido de coibir um possível retorno ao favorecimento do software proprietário?
MM» Muitas pessoas falam isso, mas acho que nada na sociedade é “sem retorno”. Acredito que, se esse grupo político toma atitudes que beneficiam a sociedade, os outros grupos utilizarão essa estratégia tanto quanto nós — mas talvez falando menos. Ninguém trocaria o Apache por uma ferramenta proprietária.
Não acredito que existam situações sem retorno.
LM» Uma das maiores carências do Software Livre no Brasil, hoje, é o ecossistema em torno das soluções. Porém, com órgãos públicos desenvolvendo softwares internamente, eles talvez não ajudem a solucionar isso. Como o Serpro pode promover melhorias nesse quadro?
MM» Acredito que a demanda atual por tecnologia é tão grande que nem todos os órgãos federais juntos conseguiriam supri-la. Então, teremos muitas contratações em 2009. Vamos nos integrar também à iniciativa privada através de uma maior abertura e facilitação do processo de contratação de serviços externos em Software Livre.
O que queremos evitar é a dependência de soluções. Acho que veremos importantes mudanças no ecossistema no próximo ano.
LM» Qual o impacto da crise financeira mundial sobre a indústria de software, especificamente sobre a indústria brasileira de Software Livre?
MM» Creio que teremos uma pressão de demanda, pois os gastos precisarão de mais controle — refletindo-se em investimentos em tecnologia —, a geração de receita terá de ser aumentada e os processos precisarão ser acelerados. Tudo isso deverá ser feito de forma equilibrada, ou seja, será necessário gastar menos com soluções que vão gerar mais renda.
Por isso, será importante para a nossa indústria local produzir Software Livre e ser referência nessa área.
Fonte Linux Magazine
Andrew S.Tanenbaum, criador do sistema operacional Minix fala sobre a disponibilidade dos computadores em matéria publicada na Linux Magazine e que transcrevemos a seguir na íntegra.
Tanenbaum: Por que os computadores não funcionam sem parar?
Por Andrew S. Tanenbaum
Os usuários de computadores estão mudando. Há dez anos, a maioria dos usuários de computadores eram pessoas ou profissionais jovens com amplo conhecimento técnico. Quando algo saía errado – o que ocorria com freqüência –, eles sabia consertá-las. A maioria deles consegue consertar computadores tão bem quanto um nerd de computador padrão sabe consertar seu carro. O que eles querem mais do que qualquer outra coisa é que o computador funcione o tempo todo, sem interrupções ou falhas.
Muitos usuários comparam automaticamente seus computadores a suas televisões. Ambos estão repletos de componentes eletrônicos mágicos e possuem telas grandes. A maioria dos usuários tem um modelo implícito de uma televisão: (1) você compra a TV; (2) você a liga na tomada; (3) ela funciona perfeitamente sem qualquer falha durante os próximos dez anos. Eles esperam isso do computador e, quando não é o que obtêm, ficam frustrados. Quando os especialistas em computadores lhes dizem: “Se Deus quisesse que os computadores funcionassem o tempo todo, Ele não teria inventado o botão de RESET”, eles não se convencem.
Por falta de uma melhor definição de disponibilidade, adotemos a seguinte: um dispositivo é dito disponível (isto é, podemos dispor dele) se 99% dos usuários jamais experimenta qualquer falha durante todo o período em que o possuem. Por essa definição, virtualmente nenhum computador é disponível, enquanto a maioria das TVs, iPods, câmeras digitais etc. são. Usuários técnicos de computador estão dispostos a perdoar um computador que trave uma ou duas vezes por ano; usuários comuns, não.
Usuários domésticos não são os únicos incomodados com a baixa disponibilidade dos computadores. Até mesmo em ambientes altamente técnicos, a baixa disponibilidade dos computadores é um problema. Empresas como Google e Amazon, com centenas de milhares de servidores, experimentam várias falhas todo dia. Elas aprenderam a conviver com isso, mas prefeririam sistemas que simplesmente funcionassem sem parar. Infelizmente, os softwares atuais falham nesse aspecto.
O problema básico é que softwares contêm bugs, e quanto mais software, mais bugs. Vários estudos já mostraram que o número de bugs por mil linhas de código (KLoC) varia de um a dez em grandes sistemas de produção. Um software muito bem escrito talvez tenha dois bugs por KLoC ao longo do tempo, mas não menos. Um sistema operacional com, digamos, 4 milhões de linhas de código, portanto, deve ter pelo menos 8 mil bugs. Nem todos são fatais, mas alguns serão. Um estudo da Universidade Stanford mostrou que drivers de dispositivos – que compõem até 70% da base de código de um sistema operacional típico – possuem taxas de bugs 3x a 7x mais altas que o resto do sistema. Drivers de dispositivos têm taxas mais altas porque (1) são mais complicados e (2) são menos inspecionados. Enquanto muitas pessoas estudam o escalonador, poucas verificam os drivers de impressoras.
A solução: kernels menores
A solução para esse problema é retirar código do kernel, no qual o dano pode ser máximo, e colocá-lo em processos do espaço do usuário, onde bugs não conseguem causar falhas de sistema. É assim que o MINIX 3 é projetado. O sistema MINIX atual é o (segundo) sucessor do MINIX original, que foi lançado originalmente em 1987 como sistema operacional educativo, mas desde então foi radicalmente revisado para se tornar um sistema altamente disponível e auto-recuperável. Segue uma breve descrição da arquitetura do MINIX; há mais informações em www.minix3.org.
O MINIX 3 é projetado para rodar o mínimo de código possível no modo do kernel, em que bugs podem facilmente ser fatais. Em vez de 3-4 milhões de linhas de código no kernel, o MINIX 3 tem aproximadamente 5.000 linhas de código no kernel. Às vezes, kernels desse tamanho são chamados de microkernels. Eles lidam com gerenciamento de processos no baixo nível, escalonamento, interrupções e o relógio, e fornecem alguns serviços de baixo nível para componentes do espaço do usuário.
A maior parte do sistema operacional roda como uma coleção de drivers de dispositivos e servidores, cada um rodando como processo comum do espaço do usuário com privilégios restritos. Nenhum desses drives e servidores roda como superusuário ou equivalente. Eles não conseguem nem acessar dispositivos de I/O ou o hardware MMU diretamente; precisam usar serviços do kernel para ler e escrever no hardware. A camada de processos rodando diretamente no modo de usuário acima do kernel consiste em drivers de dispositivos, com o driver de disco, o de Ethernet e todos os outros rodando como processos separados protegidos pelo hardware MMU, para não conseguirem executar qualquer instrução privilegiada e nem lerem ou escreverem em locais de memória além dos seus próprios.
Acima da camada de drivers vem a de servidores, com um servidor de arquivos, um servidor de processos e outros. Os servidores fazem uso dos drivers assim como de serviço do kernel. Por exemplo, para ler um arquivo, um processo do usuário envia uma mensagem ao servidor de arquivos, que então envia uma mensagem para o driver de disco para buscar os blocos necessários. Quando o sistema de arquivos os tem em seu cache, ele chama o kernel para movê-los para o espaço de endereços do usuário.
Além desses servidores, há um outro servidor chamado “servidor de reencarnação”. Ele é o pai de todos os processos de drivers e servidores e monitora seu comportamento. Se ele descobrir um processo que não esteja respondendo a pings, ele inicia uma nova cópia a partir do disco (exceto pelo driver do disco, que fica oculto na RAM). O sistema foi projetado para que muitos (mas não todos) os drivers e servidores críticos sejam automaticamente substituídos enquanto o sistema funciona, sem perturbar os processos de usuário em execução e sem nem notificar o usuário. Dessa forma, o sistema é auto recuperável.
Para testar se essas idéias funcionam na prática, conduzimos os seguintes experimentos. Iniciamos um processo de injeção de falhas que sobrescreveu 100 instruções de máquina no binário do driver Ethernet em execução para ver o que ocorreria caso um deles fosse executado. Se nada acontecesse em poucos segundos, outras 100 eram injetadas e assim por diante. No total, injetamos 800.000 falhas em cada um dos três diferentes drivers Ethernet e causamos 18.000 travamentos do driver. Em todos os casos, o driver foi automaticamente substituído pelo servidor de reincarnação. Apesar de injetar 2,4 milhões de falhas no sistema, o servidor não parou uma vez sequer. Nem é preciso dizer que se ocorrer um erro fatal num driver do Windows ou do Linux rodando no kernel, todo o sistema operacional travará imediatamente.
Existe alguma desvantagem nessa técnica? Sim. Há uma redução de desempenho. Não a medimos extensivamente, mas o grupo de pesquisa em Karlsruhe, Alemanha, que desenvolveu seu próprio microkernel (o L4) e depois rodou o Linux como um de seus processos de usuário, conseguiu uma perda de desempenho de apenas 5%. Acreditamos que se dedicarmos um pouco de atenção a esse típico, também conseguiremos reduzir a perda para a faixa entre 5 e 10%. Desempenho não é uma prioridade para nós, já que a maioria dos usuários que lêem email ou navegam pelo Facebook não são limitados pelo desempenho da CPU. O que eles querem, no entanto, é um sistema que simplesmente funcione o tempo todo.
Se microkernels são tão disponíveis, por que ninguém os usa?
Na verdade, usam, sim. Provavelmente você roda vários deles. Seu telefone celular, por exemplo, é um computador pequeno, mas comum em todos os outros aspectos, e há uma boa chance de ele rodar o L4 ou o Symbian, outro microkernel. O roteador de alta performance da Cisco também usa um microkernel. Nos mercados militar e aeroespacial, em que disponibilidade é fundamental, o Green Hills Integrity, outro microkernel, é amplamente usado. O PikeOS e o QNX também são microkernels amplamente usados em sistemas industriais e embarcados. Em outras palavras, quando é realmente importante que o sistema “simplesmente funcione o tempo todo”, as pessoas usam microkernels. Para mais informações sobre esse tópico, veja www.cs.vu.nl/~ast/reliable-os/.
Concluindo, é nossa crença, baseada em várias conversas com usuários não técnicos, que o que eles mais desejam é um sistema que funcione perfeitamente todo o tempo. Eles têm uma baixa tolerância a sistemas pouco confiáveis, mas atualmente não têm escolha. Acreditamos que sistemas baseados em microkernels podem nos levar a sistemas mais disponíveis.
Confira também o texto original (em inglês) deste editorial.
Um Grupo de Hackers acaba de portar o Kernel 2.6 do Linux para iPhone. Embora com muitas limitações de suas funções, eles conseguiram fazer o sistema inicializar no iPhone, primeira e segunda geração da Apple e, também no iPod touch primeira geração. Para maiores informações você pode visitar o site oficial Linux on the iPhone.
Blog sobre cultura e tecnologia.
