Como o Gnome e o KDE se destruíram mutuamente

Tem muita gente terrivelmente intrigada com o Google Chrome OS. Não vou mentir, eu também estou. O Google está prometendo uma mudança para lá de necessária na forma como computadores pequenos trabalham. Problemas como atualizações de software, backups, instalações, manutenção e vírus vêm atormentando o mundo há muito tempo; já passou da hora das coisas mudarem. Mas para mim, essa mudança que está prestes a acontecer só mostra o que muita gente passou um bom tempo tentando negar: o KDE e o GNOME se destruíram mutuamente. Escrevo isso sabendo que vou deixar muita gente com raiva. Talvez seja a primeira vez em que alguém escreve um artigo e recebe respostas furiosas dos dois lados: dos usuários do KDE e do GNOME, que podem acabar (finalmente?) unindo forças para mostrar para todo mundo que eu não tenho razão!

Vamos voltar um pouco no tempo – não muito, mais ou menos um ano. Você é o Google e que oferecer o sistema operacional para a próxima geração de usuários, aqueles que não começaram com o Excel e o Word, mas sim com o Facebook e o Flickr. A escolha óbvia para o kernel é o GNU/Linux – o Google sabe disso, e inclusive trabalha para melhorá-lo. A pergunta é: qual ambiente de desktop você vai oferecer a esses novos usuários? O KDE? O GNOME? Os dois? Mas os programas dos dois não têm visuais diferentes? E o sistema de áudio falido deles? Alguém falou em Pulseaudio?

Pergunta difícil. A resposta foi simples e dolorosa: nenhum dos dois. Dolorosa, porque intimamente eu tenho certeza (embora não possa provar) de que se o GNU/Linux tivesse um único conjunto de bibliotecas de desktop, um único ambiente de desktop, um único conjunto de padrões para a reprodução de áudio e assim por diante, essas bibliotecas estariam no Google Chrome OS. O Google acabaria lançando um conjunto de ferramentas para instalação de software no Chrome OS, sem os problemas absurdos encontrados hoje na instalação de software no GNU/Linux.

Só que essa coisa de ter duas opções para tudo no mundo dos desktops GNU/Linux significava que a quebra com o passado no Google Chrome OS teria que ser mais definitiva e certamente mais radical. Ao menos a princípio, o Google Chrome OS não vai permitir a instalação de software de terceiros. Mais cedo ou mais tarde, tenho certeza quase absoluta de que eles vão ceder – e quando essa hora chegar, eles vão ter que lidar com a divisão entre KDE e GNOME, e o resultado será a bagunça de sempre.

Você disse que o Chrome OS vai permitir a instalação de software?

As primeiras prévias do Chrome OS mostram claramente que não será possível instalar software de terceiros no sistema operacional. Só para garantir, o sistema de arquivos raiz é montado somente para leitura! Esse é um recado claro do Google (e eu gosto disso): o sistema de arquivos principal é para o núcleo do sistema. Não há razão para se instalar programas para usuários ali, isso só gera um monte de problemas. Um aplicativo para usuários finais deve ser uma pasta autossuficiente, cheia de todas as tranqueiras que o aplicativo trouxer.

Obviamente, se houvesse apenas um ambiente de desktop no GNU/Linux, seria trivial fazer uma lista de bibliotecas mínimas para cada versão oficial do sistema. Nesse caso, seria possível: arrastar o ícone daquele programa velho de contabilidade que estava no seu backup há dois anos e usar o programa sem cair no inferno das dependências. Só que o GNU/Linux tem dois ambientes de desktop diferentes, e ter um conjunto organizado de bibliotecas não é algo tão trivial quanto deveria ser.

Por outro lado, permitir apenas o uso de aplicativos web vai dificultar muito a transição. Cada vez mais gente vai reclamar disso. Muitos usuários vão ter aquele programinha que querem rodar no laptop com o Chrome OS (eu, pessoalmente, tenho o GNUCash, e não, não existe um equivalente “web”). O risco é o Google deixar uma questão importante dessas nas mãos de desenvolvedores independentes. O Google vai se sentir tentado a fazer isso: os desenvolvedores independentes vão bolar mods para facilitar a inclusão de repositórios e poluir o sistema principal com coisas que nunca deveriam aparecer por lá. Um dia o Google vai ter que bolar um jeito organizado de instalar programas, como aconteceu com o próprio Android (uma pasta com tudo dentro) ou com a Apple (uma pasta com tudo dentro) ou com qualquer outro sistema onde a instalação de software funcione bem mesmo.

Com o Android as coisas foram fáceis, porque o Google podia ditar exatamente quais bibliotecas um determinado software deveria esperar e como os aplicativos deveriam reproduzir áudio e afins (sem o pesadelo de OSS/Alsa/Pulseaudio/KDE/GNOME/sei-lá-mais-o-quê). Eles usaram Java (ou Dalvik) para evitar a confusão e tornar tudo mais seguro. No Google Chrome OS, o Google vai ter que fazer algumas escolhas, desagradando uma parte considerável da base de usuários do GNU/Linux, seja qual for a opção escolhida. A decisão que o Google tomou agora foi muito útil para chamar a atenção, mas não acho que vá durar. Ou melhor, eu espero que não dure.

Uma solução possível (e parcial) para o problema GNOME/KDE seria criar “pacotes de bibliotecas”, de modo que bastasse o “pacote do GNOME” para rodar aplicativos do GNOME. Note que isso não é o mesmo que dizer que o usuário precisa da libmultipoderosa.so.3.4.2 – estamos falando de “super pacotes”, com tudo o que um aplicativo feito para o GNOME pode esperar encontrar. Se um aplicativo precisasse de bibliotecas específicas, só precisaria tê-las em um diretório “lib” próprio. Algo parecido com o que a Apple faz. Isso também não seria bom em termos visuais (os aplicativos teriam aparência divergente, problemas com o som e afins), mas pelo menos pode ser que funcione.

De volta ao GNOME e ao KDE

Quem diz que a concorrência é positiva, e que é bom o GNU/Linux ter dois ambientes de desktop competindo, está louco. Os prejuízos que essa concorrência causou ao GNU/Linux são imensos. Quando o Google decidiu criar um sistema operacional voltado para a web, abriu mão dos dois ambientes. Com o Google Chrome OS, tanto o KDE quanto o GNOME subitamente se tornaram irrelevantes – e vão se tornar cada vez mais irrelevantes com o passar do tempo.

Adeus, desktop. Olá, aplicativos web. Vamos cruzar os dedos para que o período de transição seja tranquilo.