10 principais barreiras para o sucesso do desktop Linux

março 29, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Recentemente eu li um artigo muito interessante sobre as principais barreiras que dificultam o sucesso em massa do desktop Linux. Eu já uso Linux em casa desde 2003 e utilizei uma boa variedade de distribuições. Já usei distribuições baseadas em Debian, outras derivadas do Red Hat. Algumas utilizavam Gnome, outras KDE (meu preferido).

Entre as distribuições que me lembro que já usei estão (em ordem mais ou menos cronológica): Conectiva, Red Hat, Knoppix, Mandrake/Mandriva, Suse, Ubuntu/Kubuntu, Mepis e Pc LinuxOS. De uma maneira geral a minha distribuição preferida é o Kubuntu, pois faço questão do KDE e de uma maneira geral o Ubuntu/Kubuntu é a distribuição melhor suportada para a maioria das coisas que você for usar. Após esta experiência em variadas distribuições, pude conhecer o suficiente sobre Linux para saber me virar bem em qualquer versão que eu tenha que usar.

Recentemente a Globo.com migrou os desktops dos desenvolvedores para Linux. Eu já estou usando Linux no trabalho há quase 1 ano, mas as pessoas em geral receberam seus desktops novos com Linux no começo desse ano. Grande parte das pessoas ainda não havia usado Linux como desktop, conhecendo apenas algumas coisas de linha de comando pela experiência de acessar nossos servidores. Com isso, tenho tentado ajudar da melhor forma possível para que a transição deles seja suave. Eu gosto muito de Linux e quero que sua adoção cresça e que as pessoas em geral tenham uma boa experiência de uso.

Apesar de gostar bastante e utilizá-lo quase em tempo integral, não sou do tipo fanático que só vê vantagens. Há algumas coisas que incomodam razoavelmente se você não souber contorná-las, e um novo usuário freqüentemente encontra dificuldades com isso. Como este artigo que mencionei aborda de forma bem interessante estas barreiras comuns, listarei-as aqui e deixarei meus comentários.

1 – Consistência e percepção: com a enorme variedade de distribuições disponíveis, os usuários têm uma enorme liberdade de escolha. Entretanto, isso também traz a característica de que as coisas mudam muito de uma distribuição para a outra. Se você sabe como usar ou configurar alguma coisa em uma determinada distribuição, isto não garante que você conseguirá fazer a mesma coisa em outra distro. A facilidade de uso de uma distribuição para a outra varia bastante. Isto sem dúvida dificulta que um usuário experiente ajude um iniciante, caso a distribuição seja diferente. Como o Windows é uma coisa só, a interface e as configurações não mudam quase nada de um usuário pro outro. Isso facilitou muito a adoção em massa, e usuários novos conseguem rapidamente aprender com usuários experientes. Embora isto possa incomodar os puristas, eu acho que o Linux teria bem mais chances de sucesso se em vez de centenas de distribuições, tivéssemos umas 3 ou 4 no máximo, e os esforços ficassem concentrados nestas.

2 – Fraco suporte a dispositivos móveis: com pouquíssimas exceções, sincronizar dispositivos móveis no Linux é pauleira. Enquanto isto não for tão simples quanto usar um pen drive, esta barreira complicará muito o uso do Linux por usuários comuns. Eu sei que sincronizar um celular ou PDA é bem mais difícil de implementar do que acessar um pen drive, mas o usuário final não quer saber disso quando escolhe um sistema operacional para usar.

3 – Encontrar software compatíveis ao mudar de SO é difícil: é claro que existe muito mais software para Windows do que para Linux. A maioria dos softwares possui equivalentes no Linux, mas a qualidade destes substitutos varia muito. Usuário não-técnicos vão relutar muito em trocar o Office pelo Open Office. Apesar de eu conseguir usar tranqüilamente o Open Office em geral, os formatos amplamente aceitos ainda são os da Microsoft. Tentar usar o Open Office para modificar arquivos do Word ou Excel pode trazer muitas dores de cabeça, especialmente se você precisar salvar no formato Office original. Existe o Crossover Office que suporta muito bem o Office no Linux, mas ele não é gratuito e pouca gente conhece. Ainda temos muito que avançar nesta área.

4 – Problemas com wireless: é vastamente sabido que utilizar dispositivos wireless em geral no Linux é muito complicado ainda, e dependendo do seu hardware e distribuição, isto pode ser muito tranqüilo ou um pesadelo. Os procedimentos de contorno disso variam muito de uma distribuição para a outra, e um usuário comum dificilmente vai saber se virar com isso. Probleminha complicado também.

5 – Listas de compatibilidade de hardware: alguns fabricantes principais de hardware já suportam muito bem o Linux e isto vem melhorando rapidamente. Para a grande maioria dos componentes já é possível usar tudo perfeitamente no Linux, mas caso você tenha algum modelo não muito comum, pode ter problemas. Além disso, é difícil saber previamente se tudo vai funcionar antes de você tentar. Os CDs bootáveis ajudam muito nisso, permitindo que você teste previamente seu hardware antes de instalar em disco. Este problema eu acredito que muito em breve deixará de ser considerado.

6 – Necessidade de compilar novos módulos de drivers: caso você precise instalar um novo driver no Windows, basicamente você usa um instalador com Next -> Next -> Next. No Linux, você pode precisar compilar o driver, e isto é bem enjoado. Eu lembro que quando comecei a usar Linux em casa, algumas distribuições não vinham nem com módulo de USB ativo. Eu já tive que compilar e configurar módulo de USB para conseguir usar pen drives e câmeras digitais. Isto é muito chato, mas felizmente hoje em dia acontece muito pouco. Exceto em casos muito específicos você nunca precisará mais fazer isso, e acho que já podemos deixar esse problema em segundo plano.

7 – Sério interesse comercial: boa parte das empresas não-técnicas ainda não se importam muito com Linux. Com isso, ainda é freqüente termos que nos virar para conseguirmos reproduzir formatos proprietários de música, vídeo e outras coisas. As empresas em si não disponibilizam codecs pra Linux na maioria dos casos. Eles são desenvolvidos de forma open source, e em alguns casos o suporte ainda é ruim. Acho que daqui a uns 2 ou 3 anos já teremos uma parcela suficiente de usuários não-Windows para que esta postura mude. Enquanto o Windows tem mais de 90% do mercado, financeiramente não é tão fácil convencer diretorias de empresas a investir em outros sistemas operacionais. Se conseguirmos ter algo entre 15 e 20% dos usuários com Linux e Mac, a coisa já muda um pouco de figura, e o suporte melhorará.

8 – Software prontamente disponível: os usuários de Windows estão acostumados a encontrar os softwares para instalar na internet, baixar o instalador e Next -> Next -> Next. No Linux isto é diferente, como já falei previamente. As pessoas estranham inicialmente o conceito de repositórios de pacotes, mas isso na verdade facilita bastante os usuários depois que eles aprendem isso. Este problema será reduzido à medida que mais empresas comecem a adotar Linux. Usuários iniciantes serão capazes de aprender isso rapidamente com usuários experientes, e daqui a algum tempo esta diferença já deve ser vista até como um ponto forte do Linux.

9 – Workarounds vs. correções de bugs: as distribuições variam muito em termos de agilidade de uma para a outra. Algumas oferecem o que há de mais recente em termos de software para os usuários, mas isto os expõe também a mais bugs. Como estas distribuições são mais populares, rapidamente surgem formas conhecidas de contornar os problemas, antes de saírem as correções dos bugs. Outras distribuições (como Debian e Slackware) colocam apenas versões altamente testadas e maduras em seus lançamentos. Os usuários ficam com software defasado, mas muito mais estável. Devido a este fato, algumas distribuições são muito mais usadas em desktops, e outras muito mais comuns em servidores. O kernel do linux e seus princiais módulos são muito, muito estáveis e confiáveis. Já os software gráficos e de uso por usuários finais têm qualidade bem inferior. Temos aplicações de alta qualidade (como as que fazem parte das suites do KDE e Gnome), mas também temos softwares cheios de bugs que podem prejudicar a usabilidade. Ao longo do tempo a qualidade vai melhorando, e para a maioria dos softwares usados por pessoas comuns os bugs são poucos.

10 – Evangelistas e puristas: algumas pessoas têm uma visão pragmática e realista quanto ao Linux, e enxergam claramente suas qualidades, mas também as falhas. Outras simplesmente acham que é a melhor coisa do mundo para todos, sem analisar as dificuldades que pessoas comuns enfrentam. Precisamos ter uma postura madura em relação a software. Não podemos “nos apaixonar cegamente” por nada. Se enxergamos os pontos onde o Linux precisa melhorar e discutirmos eles abertamente, será muito mais fácil progredir. Entrar em flame wars de Linux x Windows é perda de tempo e energia. Cada um tem suas vantagens, e as pessoas podem ter opiniões e gostos diferentes. É ótimo que existam os 2, pois a concorrência ajuda a elevar o nível geral dos sistemas.

Torço muito para que o Linux continue evoluindo bastante e que em breve tenhamos cada vez mais facilidade para usá-lo. Posso dizer que desde 2003 quando comecei a usar, ele já melhorou e muito. Não dá nem pra comparar a situação atual com a de 2003. Estamos num patamar muito superior.

O mesmo eu não posso dizer do Windows. Em 2003 o Windows XP já estava amplamente disponível e as pessoas já o conheciam bem. Eu gosto bastante do Windows XP, ele é um ótimo sistema operacional. Já a sua “evolução”, o Windows Vista, pra mim é uma porcaria. Eu não consigo usá-lo. É muito mais pesado que o Windows XP e não me trouxe nenhuma vantagem. Eu já instalei ele em casa e ele veio no meu notebook, mas eu já voltei para o Windows XP em todas as máquinas que tiveram o Vista. Por mim eu simplesmente pulo a atualização pro Vista e espero por uma nova versão do Windows que venha depois. Muita gente compartilha desta opinião, então a Microsoft precisa trabalhar bastante.

Com o crescimento da adoção de open source, acho que aos poucos o Windows terá seu domínio reduzido, embora ainda deva continuar dominando por muitos anos. Acho que o Linux está bem encaminhado e evoluindo bastante na comparação com o Windows. Vamos torcer para que ambos evoluam bastante ao longo do tempo, pois assim todos nós ganhamos. E chega de flame wars, por favor 🙂

Anúncios

mod_rewrite

março 11, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Hoje assisti a um Tech Talk bem interessante na Globo, sobre mod_rewrite. Além de funcionalidades interessantes deste módulo do Apache, as discussões na apresentação me trouxeram vários questionamentos de como incluir de forma mais ativa o Apache em uma arquitetura RESTFul.

Eu já utilizei bastante o Apache na remota época em que eu desenvolvia algumas coisas em Php. Na verdade não fazia nada de muito sofisticado, mas tinha boa familiaridade com os módulos, com a configuração, essas coisas. Depois que foquei mais no uso de servidores de aplicação Java, deixei o Apache em segundo plano. Praticamente só vinha usando o Apache para servir conteúdo estático, e claro, nele também ficam configurados os conectores para comunicação com os servidores de aplicação.

Como tenho trabalhado bastante com web services REST, venho tentando explorar ao máximo os recursos do HTTP para elaborar protocolos de comunicação concisos e intuitivos. Neste sentido, o Apache oferece recursos muito interessantes. Por exemplo, quando utilizamos URIs no formato /usuario/123456/item/25 para representar um determinado item de um determinado usuário, a resposta a esta requisição é cacheável pelo Apache. Entretanto, ao utilizar URIs neste formato você precisa definir uma forma de fazer o parsing da URI para pegar os parâmetros relevantes.

No meu artigo de REST da Java Magazine de Abril eu usei o StringTokenizer do JDK para fazer a quebra da URI e pegar os valores que me interessavam. A JSR-311 define uma forma bem interessante de fazer isso com annotations também. E hoje fui descobrir que o mod_rewrite também pode fazer facilmente a quebra de URIs neste formato em URIs com parâmetros em query string por exemplo.

Uma utilização inteligente do cache do servidor web e de módulos de proxy também pode tornar a arquitetura da aplicação bem eficiente e reduzir bastante a carga sobre os servidores de aplicação. Se eu posso utilizar diretamente o cache do Apache para várias URIs, não vale a pena deixar as requisições chegarem ao container de servlets, mesmo que ele responda também com dados em cache.

Vendo o poder e a facilidade de uso de alguns módulos do Apache, me sinto obrigado a ter total familiaridade com ele novamente. Aos poucos irei estudando e integrando os módulos do Apache à arquitetura das minhas aplicações REST, pois isto pode trazer um belo ganho de performance e escalabilidade. Afinal de contas, quem quer explorar a fundo os recursos do HTTP não pode abrir mão de explorar a fundo um servidor tão confiável e maduro como o Apache, não é mesmo?

OBS: uns anos atrás eu dizia pra mim mesmo que o dia que eu conhecesse pelo menos vagamente metade dos projetos na home da Apache Software Foundation eu já teria uma boa bagagem. Hoje em dia já conheço mais da metade do projetos da home, e admiro cada vez mais esta fundação. O mundo open source não chegaria aos pés do que é hoje sem a existência da ASF. Um belo exemplo de qualidade em software!


Jersey meets Abdera

fevereiro 6, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Talvez os dois mais promissores projetos atualmente sendo desenvolvidos na área de web services Rest são o Apache Abdera e o Jersey. O Apache Abdera oferece uma API para manipulação de conteúdo no formato Atom, e é bastante útil para implementações baseadas no Atom Publishing Protocol. Já o Jersey é a implementação de referência da JSR-311, que mencionei num post recente aqui no blog.

Os 2 projetos são complementares, já que as funcionalidades de ambos não tem muitas interseções. Ontem o Marc Hadley, um dos principais desenvolvedores do Jersey postou sobre um desenvolvimento que ele está fazendo, usando o Jersey e o Abdera em um projeto de web services Restful. No post do Marc Hadley ele menciona que utilizou os recursos HTTP do Jersey (como mapeamento de URIs em classes e métodos e a capacidade de manipular diversos content-types) juntamente com as funcionalidades do Abdera de manipulação de recursos Atom.

Esta iniciativa foi muito bem recebida pelo James Snell e pelo Dan Diephouse (fundador do XFire), que são os principais desenvolvedores do Apache Abdera. O desenvolvimento destes dois projetos vem trazendo enorme amadurecimento aos web services REST e hoje já é possível desenvolver web services neste formato com grande produtividade e poder.

Claro que os projetos ainda estão em um estágio intermediário de desenvolvimento, mas é deles que virá a adoção mainstream com maturidade desta linha de serviços. Estou acompanhando continuamente o que está sendo feito nesta área, e o que já pude ver até agora é fascinante.

A propósito, os dois projetos são open source e os principais envolvidos fazem parte de empresas como a IBM, Sun, Mulesource, entre outras. O desenvolvimento de software open source é hoje em dia a principal forma de desenvolvimento da vanguarda da tecnologia mundial. As empresas já perceberam o sucesso do movimento e estão apoiando firmemente o mesmo. Não posso deixar de registrar minha profunda satisfação com isso. 🙂


Google Android: será que vai vingar?

novembro 20, 2007

Atenção, este blog foi migrado para: http://brunopereira.org

Há 1 semana foi anunciado o lançamento do ambiente de desenvolvimento para o Google Android.O projeto é extremamente ousado e inovador e tem um potencial revolucionário no mercado de software para dispositivos móveis. Bom, você não esperava nada de menor impacto vindo deles, certo?

Se tiver sucesso, o Android virá para tomar conta de um mercado ainda meio indefinido, sem uma presença soberana. Ok, sabemos que existe o Symbian e o Windows Mobile, que são belos sistemas operacionais para dispositivos móveis, mas e quanto a todo o resto? Sony Ericsson, Motorola, Samsung, LG, etc etc etc…

Eu já tive a oportunidade de trabalhar com J2ME durante pouco mais de 1 ano e meio. Na época a aplicação em questão era J2ME sobre Windows Mobile 2002 e inicialmente utilizava o DB2 Everyplace como ferramenta de sincronização com o servidor. Posteriormente esta aplicação foi migrada para o Oracle Lite 10g, o que funcionou muito melhor para as nossas necessidades. Nossa aplicação era um sistema de automação de força de vendas, e integrava-se ao JDEdwards e ao Siebel (respectivamente ERP e CRM do cliente).

Gostei bastante de ter tido esta experiência e lembro-me que uma das maiores frustrações era o desenvolvimento focado em uma plataforma específica, no nosso caso, Windows Mobile.

“Ah, mas o Palm OS também suporta J2ME e os PDAs são tão robustos como os do Windows Mobile. Não podemos utilizá-lo?”. Esta pergunta é de fato pertinente, porém na prática a implementação para Palm OS seria um outro projeto, pois os sistemas operacionais são muito diferentes. No Palm OS você não consegue nem colocar um arquivo texto avulso, criado em seu desktop para dentro dele. Tudo tem que ser através de aplicações que se registrem no processo de sincronização com o desktop.

Na época isto foi bastante frustrante, pois cada smartphone com Windows Mobile custava quase R$ 3000. O fato de não poder usar um Palm de R$ 600 ou até mesmo um celular que suportasse J2ME limitou um pouco a escala do projeto.

Neste contexto, a chegada do Android (que busca ser uma camada de software comum sobre a variada gama de aparelhos disponível) é muito bem-vinda. Poder desenvolver um software único compatível com centenas de modelos diferentes era algo antes inimaginável, e sem dúvida uma necessidade real.

O Android será um sistema operacional desenvolvido sobre um kernel customizado do Linux. Serão oferecidas bibliotecas para acesso aos diversos recursos de hardware dos celulares e também aplicações para os usuários finais. O desenvolvimento de software para o Android será totalmente em Java e o ambiente de desenvolvimento baseia-se na plataforma do Eclipse.

Um claro problema para o sucesso do Android é que as operadores de telefonia teriam que adequar seus modelos de negócio com a chegada desta nova plataforma. A venda de serviços utilizando esta plataforma é algo ainda não vislumbrado claramente. Além disso, apesar de um grupo grande e significativo de empresas terem aderido inicialmente à iniciativa, alguns gigantes do setor como Nokia e Sony Ericsson ainda não aderiram ao movimento, então temos ainda muita estrada pela frente até saber que caminhos o Android irá traçar.

Podemos ter certeza de que o Google tem poder, inovação e qualidade suficientes para revolucionar este mercado, e que eles não entraram nesta para brincar com a Microsoft. Se eles serão capazes de emplacar mais um sucesso avassalador com o Android, só o futuro nos dirá. Mas que eu torço muito pelo sucesso do Android, não restam dúvidas!