Linus Torvalds afirma: o Linux está 'inchado'

Linus Torvalds, o criador do Linux, fez um comentário interessante na LinuxCon nesta segunda-feira: "O Linux está inchado". Para os afoitos em achar que o Linux 'pegou' uma rota evolutiva sem saída, acalmem-se. Torvalds apenas informou que, devido ao sucesso, o Linux continua crescendo a medida que sua adoção aumenta. E que esse é o 'problema' do sucesso: tentar abraçar cada vez mais, um número maior de tarefas.


O interessante é que essa característica de 'inchaço' sempre foi utilizada, pela própria comunidade Linux, como adjetivo rotulante para o sistema operacional Windows da Microsoft. E Torvalds diz que esse mesmo crescimento no Linux, o torna "enorme e assustador".

Torvalds tem reclamado que as idéias iniciais dele, sobre um kernel hiper-eficiente, não se tornaram realidade. Mas o Linux está presente em quase tudo: desde data centers corporativos até mais da metade dos smartphones produzidos no mundo. Mesmo assim ele levanta uma questão: "Será que o Linux vai se tornar cada vez mais parecido com o Windows, a medida que for aumentando seu sucesso?".

Sabemos que é errado pensar no Linux (principalmente a nível de kernel) como algo monolítico. O Linux é modular. Mas será que ele é modular o suficiente para garantir seu crescimento de forma sustentável e sadia, no mundo atual?


Modularidade

Dizem que a fonte de todo o mau está na sua raiz. Então vamos ao kernel do problema: analisemos primeiro o quão modular o kernel Linux realmente é. E a primeira análise que podemos pensar em fazer é no hardware.

Analisando o Hardware

Como afirmado nos primeiros parágrafos desse texto, o Linux pode ser encontrado em praticamente todo o tipo de hardware, desde servidores em data centers corporativos, até diferentes tipos de smartphones de dezenas de fabricantes em todo o mundo. Mas o que conheço do kernel Linux, posso dizer isso não é modularidade, isso é pluralidade.

O kernel Linux é capaz de 'estar presente' em todo o tipo de dispositivo, mas não da forma modular como você pensa. Levando-se em conta que o kernel é todo o projeto relacionado ao mesmo (seu núcleo principal e todos os 'módulos' existentes), por que não é simplesmente fácil de se instalar 'um mesmo kernel customizado' em qualquer dispositivo? Um kernel para smartphone é altamente customizado (no sentido de customização manual e horas de programação à parte) para esse tipo de hardware. Não a toa vemos várias empresas de telefonia, investindo em seus Linux modificados para smartphones. Se você tentasse instalar o mesmo kernel de um smartphone em um servidor de produção localizado num data center, você não conseguiria algo funcionalmente viável. Para ser mais realista, esse mesmo kernel não funcionaria em um smartphone concorrente.

E onde está a modularidade do kernel, se você precisa perder meses de programação para 'criar' uma versão customizada do mesmo para funcionamento em um hardware altamente especializado? E até onde o projeto de modularização do kernel pode ir, para poder atender a todos os hardware sem esbarrar em problemas legais?


Acredito que o kernel Linux ainda precisa passar por muitas reconstruções (ou uma verdadeira reescrita do zero) para que ele possa ser um projeto verdadeiramente modular, e poder crescer e se desenvolver com o tempo, sempre atendendo as necessidades da evolução econômica e social da utilização dos inúmeros hardware 'presentes' e 'futuros'. Mas será que isso é o que Linus Torvalds desejava inicialmente para seu projeto?

Reescrita do projeto

O ideal seria ter um kernel Linux que gerenciasse de forma altamente modular e customizada, os diferentes tipos de suporte a drivers e hardware como um todo, a ponto de você poder escolher em sua configuração (apenas um kernel) para qual tipo de hardware/produto você quer usar o mesmo.

Atualmente você tem uma série de escolhas de configuração do kernel, mas elas envolvem funcionalidades gerais (um nível acima) e não funcionalidades aplicadas (um nível abaixo, especificando o tipo de hardware/produto). E essas mesmas escolhas são, em sua maioria, voltadas para atender uma gama limitada de produtos/hardware. Não acho que isso seja suficiente para chamar o kernel de modular, tendo em vista os diversos tipos de hardware existentes no mercado. Uma idéia: Por que não ter um kernel mais 'inteligente' que pudesse fazer uma 'varredura' no produto e escolher as configurações ideais para que todas as funcionalidades básicas do novo dispositivo pudessem funcionar? E isso utilizando apenas um kernel, e não precisando perder horas em escovação de bits (com direito a reprogramação de partes) para se atender ao novo produto?

Claro que isso esbarra em outros problemas maiores, que seria a 'padronização', não de hardware, mas de estrutura funcional dos componentes de hardware de um fabricante (e liberação desses mesmos specs para os desenvolvedores). O desenvolvimento do kernel Linux até poderia suprir essa necessidade mesmo sem a colaboração dos fabricantes. Mas haja tempo, pessoal, e horas de engenharia reversa a seguir...

Assim, podemos dizer que o kernel Linux, mesmo com seu 'núcleo' e seus 'módulos', não é um projeto modularizado. Eu diria até que o mesmo está se tornando um verdadeiro macrófago. Outro ponto que renderia um livro inteiro, é o problema de relacionamento, criação, reescrita e aceitação de código entre os integrantes da 'equipe' de desenvolvimento do kernel Linux. Vamos deixar isso para futuros posts.


Analisando o Software

Considerando que, para o mercado e para os usuários, o Linux não é mais somente o kernel, vamos falar também do software. E acredite se quiser, esse é um campo minado maior que o problema da modularização do kernel. Aqui há muito mais gente e programas (de todas as camadas), que no caso do hardware. Até onde o Linux se aproxima da Microsoft quando o chamamos de 'inchado'?

No começo...

No começo se criava funcionalidades 'semelhantes' e 'suportáveis'. Se queríamos participação em um mercado/mundo crescente em tecnologia, mas retraído em aceitação de inovações, precisaríamos desenvolver produtos com a mesma cara e mesma funcionalidade, que fossem compatíveis com os diferentes tipos de arquivos do concorrente. Mas tudo isso sem todos os problemas do mesmo, e que continuassem abertos e livres. Essa foi a primeira onda.

Com os projetos aumentando em número, funcionalidades e facilidades de uso, num mercado/mundo também crescente em novas e variadas tecnologias, o problema aumentou. Mediante a estagnação em novidades do concorrente, a comunidade Linux se viu obrigada a inovar e não ter mais a quem copiar. Essa foi a segunda onda.

Atualmente

Hoje em dia temos centenas de projetos em Software Livre e de Código Aberto (SL/CA), desde os poderosos ambientes de desktops, até aplicativos de escritório, som e imagem, passando por programas de gerenciamento de médio e baixo-níveis, linguagens de programação, etc. Nós realmente abraçamos o mundo com o SL/CA para Linux. Mas, por que não dominamos esse mercado ainda? O que estamos fazendo de errado?

Eu diria que 'parcialmente' a culpa é nossa. Claro que boa parte da culpa reside na resistência do usuário (corporativo ou não) ao novo. A querer re-aprender.

Nós, no mundo Linux, temos uma variedade enorme de softwares que fazem tudo. E temos milhares de softwares que fazem (ou se propõem a fazer) a mesma coisa. Vários editores de texto, vários reprodutores de áudio e/ou vídeo, e por ai vai. Todos esse projetos são bons e eu realmente sou a favor da possibilidade de escolha por parte do usuário. Mas acho que os projetos correlacionados esquecem que eles estão no mesmo lado da disputa - a disputa contra o software proprietário. E em vez de seguirem seus caminhos isolados e com a torcida (leia-se usuários) de cada um disputando quem é o melhor, acho que esses projetos deveriam ampliar sua integração com seus semelhantes.


Muitos podem até questionar que uma integração acabaria com a individualidade. Mas existem vários níveis de integração. Estou falando apenas do básico. Por exemplo, programas similares deveriam ser compatíveis com todos os formatos de arquivos e serviços que disponibilizam, além da possibilidade COMPLETA de interconversão de padrões de arquivos. E isso vale para todos os softwares, sejam eles, clientes de e-mail, editores de texto ou mesmo manipuladores de imagem, áudio e vídeo. A interconverção, claro, não se limitaria ao tipo de arquivo, mas também as bases de dados, ponto de grande importância em nosso atual mundo digital globalizado, onde a Internet e a Web 2.0 estão 'a disposição'.

Essa integração, sempre modularizada e padronizada, conquistaria para os projetos relacionados maior força e melhor poder de disputa com os programas proprietários equivalentes. Também apoio a participação oficial e explícita de desenvolvedores de projetos similares, entre seus 'iguais'. E o principal, que está subliminarmente dito aqui. As boas idéias DEVEM SEMPRE ser copiadas entre os projetos semelhantes.

Conclusão

Acredito que, com esses focos bem definidos, o Linux só tem a ganhar em seu crescimento, sem acabar ficando pior que o Windows no inchaço. Afinal, somos uma comunidade sem precedentes em números de desenvolvedores. Nenhuma empresa (ou mesmo a soma delas) poderia se igualar no número de 'mentes brilhantes' a favor do desenvolvimento de software. Ainda mais quando falamos de Linux e SL/CA para Linux. Porém, quanto maior o número de pessoas, sem o controle ou diretrizes bem definidos, pior será o desenvolvimento dos mesmos. E esse problema, se não resolvido, criará um inchaço (com direito a rupturas) muito maior no futuro.

Interatividade

Agora é a vez de vocês. Gostaria que dessem suas opiniões, sugestões, críticas e/ou reclamações sobre o texto acima. Também gostaria de saber de casos relacionados vivenciados por vocês, seja em casa ou no trabalho, com relação a ausência (ou existência) da modularidade no Linux (seja ele somente o Kernel, ou todas as camadas dessa cebola digital).

Links de Interesse

Esse texto e minhas opiniões foram baseadas nesses dois links.

- InternetNews.COM: http://www.internetnews.com/software...e.php/3840236/

- CNet News: http://news.cnet.com/8301-13505_3-10358024-16.html