Qual seria o Linux ideal para desktops?

Estou iniciando um debate para promover as ideias dos usuários de Linux, não tenho em mente promover esta ou aquela distribuição, mas promover ideias que as distribuições poderiam implementar para melhorar o uso do Linux em desktop.

Infelizmente, eu não acredito que as comunidades das distribuições vão ler estas ideias, muito menos que alguma delas será colocada em prática.

Começarei com a minha opinião sobre o que deveria ser feito para tornar o Linux melhor para desktops:

1. Ter um centro de controle que reúna todas as opções de configurações que possam ser encontradas no sistema. O OpenSuse tem o Yast, o Mandriva tem o MCC, mas a grande maioria das distribuições não tem nada similar. Aliás, um grande erro é cada ambiente gráfico ter o seu próprio Centro de Controle, o que dificulta a integração das coisas em um só lugar.

2. Ter um assistente para compilação seria interessante, este assistente pode fazer o download automático das dependências e dos pacotes de desenvolvimento através de uma ferramenta como o AUTO-APT. Desta forma, a compilação de aplicativos seria mais automática e leigos poderiam baixar o código fonte do aplicativo e compilá-lo facilmente (sem mesmo ter conhecimento).

3. Criar um método de instalação padrão multi-distribuição, permitindo que os desenvolvedores possam criar um instalador para seus aplicativos e distribuí-los independentemente do Linux em que será instalado. Obviamente esta aplicação deve ser estática e ter todas as bibliotecas necessárias acompanhando-a. No Windows, isto existe e não é problema para os usuários, porquê no Linux não poderia ser feito o mesmo?

4. Separar as configurações do usuário de sua pasta pessoal, considerando que as configurações deveriam ser guardadas em local separado dos arquivos pessoais. O ideal é criar uma pasta /home/user_config/nome-de-usuário/ para que as aplicações mantenham os arquivos de configuração pessoal por lá. Claro que isto vai implicar na necessidade de reescrever muitos aplicativos, mas com o tempo se alcança o resultado.

5. Esta é específica para o Ubuntu: lançar uma nova versão em intervalos maiores que 6 meses. Com isto, o Ubuntu seria melhor desenvolvido e testado, além de reduzir os investimentos em manter repositórios, empacotar software e outras tarefas que por ventura venham a ser feitas a cada novo release.

6. Ampliar o tempo de atualizações e suporte. Para as empresas isto é essencial, é garantia de que o software não vai deixar a empresa na mão. Atualmente o tempo de atualizações e suporte é muito pequeno (8 meses para Ubuntu não-LTS, 18 meses para OpenSuse, 5 anos para Ubuntu LTS) e acaba fazendo que a escolha das empresas seja sempre o Windows, pois existem garantias de que o software será atualizado e suportado por 10 anos ou mais.

7. Garantir retrocompatibilidade por pelo menos 2 versões. Para as empresas é um recurso essencial, pois garante-se que o software que a empresa usa continuará a rodar nas próximas duas versões do sistema. Além de garantir retrocompatibilidade com software, é bom garantir retrocompatibilidade com hardware. O Linux não tem nada disto. Amanhã, resolvem tirar o módulo do kernel que faz funcionar aquela placa de rede que tenho nos computadores da minha empresa, então caso eu atualize ficarei sem poder usar a placa de rede. Amanhã resolvem renomear a libtelasco.so.0.2 para libtelasconetcabalocomalucoporra.so.2.3334.54343.55446.7899.112121.5665 e a minha aplicação para de funcionar. Vou ter que manter alguém na empresa só para resolver este tipo de pecuinha, ou seja, criar um link simbólico para fazer minha aplicação voltar a funcionar (e devo torcer para que as chamadas que minha aplicação precisa não tenham sido retiradas na nova versão da biblioteca). Obviamente que o Windows leva uma excelente vantagem, pois a Microsoft garante retrocompatibilidade!

Bem pessoal, por enquanto é isto. Quais são as ideias que vocês teriam para melhorar o Linux no desktop?

Essa discussão é velha... pra ser mais exato, remonta 1994, quando Patrick Volkerding e Ian Murdoch cogitaram fundir suas distros (Slackware e Debian, para ser mais exato) já com essa consideração em mente. O problema em que esbarraram foi justamente na questão do gerenciamento de dependências: o Cara não vê tal gerenciamento como benéfico, mas como uma complexidade desnecessária ao sistema e que mais atrapalha do que ajuda, enquanto o sr. Murdoch parece pensar o contrário.
Com isso quero dizer que não há como aprimorar o uso do GNU / Linux em desktops sem antes resolver essa questão antiga, Rodrigo. Gerenciamento de dependências é algo necessário? Creio que não. Esse recurso acrescenta camadas de complexidade em níveis exponenciais, e combinados a um sistema de distribuição de pacotes significa que o usuário não poderá explorar opções mais intrincadas de uso de um determinado software. Com isso me posiciono contra todo e qualquer sistema de gerenciamento de pacotes e dependências (apt, rpm, não importa), pois eles tornam a coisa toda mais pesada, menos eficiente e mais Windows-like.



Para isso será preciso que essa distribuição ideal desenvolva todos os aplicativos de configuração de maneira independente de ambiente de área de trabalho ou gerenciador de janelas. Ou seja: GUIs bonitinhas para manipular diretamente os arquivos de texto de configuração. De minha parte, tal GUI já existe e é super-eficiente. Ela se chama vim.



Se a pessoa tem preguiça de ler o README e o INSTALL, não sei porquê ela deveria tentar compilar algo... Mas não criticando, a melhor saída seria a disponibilização de um amplo repositório de códigos-fontes e o gerenciador de dependências do instalador de pacotes baixaria e compilaria localmente o pacote e suas dependências. Para isso funcionar, porém, seria necessário uma ferramenta que nem o slacktrack, do Slackware:

(copiado do slack-desc do pacote)


Isso tem um nome: instalar a partir do código-fonte vanilla, isso é, sem personalizações feitas pelos desenvolvedores das distros. Atualmente, das grandes distros só o Slackware tem esse cuidado. Já conversamos sobre nomenclatura antes, Rodrigo, e a culpa é do Debian e derivados que cagam e andam pro FHS. Saia do mundinho das Debian-likes e você vai ver como a coisa funciona ;-)


Nem precisa tanto: basta guardar todas as configurações em ~/.config. Isso facilitaria muita coisa. Não vale a pena criar outro diretório para essa tarefa por conta da questão das permissões e segurança.


Um tempo de suporte maior também seria legal. Citando o caso do Slackware mais uma vez, foi só em 2013 que o suporte gratuito das versões 4 a 9 foi descontinuado (e o 4 era de 1996, se eu não me engano).


Isso vale mais pro Ubuntu do que pras outras distros, mas ainda assim é uma questão importante.


Já conversamos sobre isso antes, Rodrigo. Esse é um problema específico das Debian-like. No Slackware (mais uma vez a comparação) você pode pegar um pacote do Slack 4 e instalar no 14 quase sem problema nenhum (e mais, atendendo as dependências você pode pegar o pacote do 14 e instalar no 4 sem dor de cabeça ;-))


Minha sugestão sincera seria extinguir todas as distros Debian-like, pois os principais problemas que você apontou nascem das idiotias cometidas pela Fundação Debian na hora de manter e administrar os pacotes da distro. Não sendo possível extingui-las, dever-se-ia extinguir o conceito de gerenciador de pacotes e dependências, pois isso acaba criando um sistema inadministrável a longo prazo. Vai que eu preciso de uma flag muito específica de compilação pra fazer aquela minha placa bizarra funcionar? Se compilar na mão posso quebrar o sistema, mas se não compilar a placa não funciona...

Eu já usei Slackware e aprovo o mesmo. Foi difícil configurar tudo quando o instalei, mas uma vez configurado ele ficou excelente. Eu chego a dizer que instalar o Slackware é mais fácil que instalar o Windows 98 ou Me.

Também já fiz uma visita ao Arch Linux, mas achei-o mais amarado que o próprio Ubuntu na questão de dependências. Deu tudo certo na instalação do Arch, foi fácil configurar mas quando comecei a instalar os softwares adicionais acabei desistindo. Mesmo dizendo ao sistema para não instalar os pacotes recomendados, para usar o Mplayer eu teria que instalar o servidor de som Jack inteiro! Foi a primeira vez que eu vi tamanho absurdo: o Mplayer ter dependência do Jack. Até questionei no fórum do Arch Linux e a única resposta que eu tive foi de que o "Mplayer precisa do Jack para funcionar". Onde isto? Só no Arch Linux mesmo, pois nem no Slackware, Mandriva, OpenSuse, Debian e Ubuntu é assim!

O incrível é que compilar software no Slackware era mais fácil do que compilar no Ubuntu, pois o Ubuntu parece dar umas picuinhas pra compilar qualquer coisa. Tem o Auto-apt que é uma mão na roda, mas nunca testei o software que você indicou para o Slackware.

O gerenciamento de pacotes não é algo específico do Debian/Ubuntu, está em todas as distribuições com raras exceções (Slackware, por exemplo). O ideal seria haver um sistema base, com a maioria das bibliotecas populares como parte oficial do sistema, e os desenvolvedores deveriam criar seus aplicativos em cima deste sistema base.

Com relação a GUI para configurações, eu realmente coloquei este item pois é algo que eu creio que falte ao Ubuntu e Debian. O OpenSuse e o Mandriva já tem.

O grande problema dos softwares para Linux é mesmo o gerenciamento de pacotes, se não fosse isto haveriam muitos "instalador.exe" para Linux. No entanto, como os desenvolvedores sabem que as distribuições vão empacotar o seu software e gerenciar as dependências dele, ele não vai sequer se preocupar como que o usuário vai instalar o programa dele.

Do outro lado, o desenvolvedor que não teve seu programa incluso em uma grande distribuição tem dificuldade para explicar ao usuário como instalar o programa. Ele cai na desgraça do gerenciamento de dependências, pois antes de instalar o usuário vai ter que resolver esta questão!

Vejam o exemplo do Windows: um sistema operacional com a maioria das bibliotecas necessárias para os desenvolvedores criarem suas aplicações, caso necessário uma biblioteca diferente o desenvolvedor vai ter que disponibilizar a biblioteca na instalação do software. Simples, e perfeito. Em tese, isto funcionaria também no Linux, mas o desenvolvedor nunca sabe quais bibliotecas vai encontrar no sistema alvo.

Com todo respeito às opiniões contrárias, eu encaro o gerenciamento de pacotes e dependências como um avanço.
Mas sou contra a fragmentação de pacotes, como ocorre com os rpm, deb , etc. Manter os pacotes sem alteração de código e sem fragmentação facilitaria até a manutenção da distro e empacotamento dos programas.

É sério isso?! nossa, eu realmente não sabia dessa!
Eu sempre pensei que essa questão da retrocompatibilidade fosse um problema do Linux (todas as distribuições), onde se você instalasse um pacote do Debian 3.1/4 (por exemplo) no 7.x não daria certo (a menos que você instale uma "tijolada" de dependências, para depois várias delas serem atualizadas impedindo o uso do pacote);

Eu tenho o Slackware instalado em uma VM para "brincar" com ele de vez em quando e, depois dessa, penso em torná-lo no meu sistema principal! (eu "acredito" na retrocompatibilidade e na simplicidade, instalei o Slack na VM justamente por ser um sistema simples; juntamente com o Slack, instalei também um gerenciador de janelas simples [o Window Maker, para ser mais exato - adorei ter descoberto um gerenciador de janelas "com a cara" do NeXTSTEP], já que o KDE ficaria pesado demais em uma VM [pelo menos ficou nas outras] e, eu acho que essa "dupla" ficou incrível - um sistema simples com um gerenciador de janelas simples - perfeito, ótimo desempenho e tudo funciona perfeitamente);

Quanto aos gerenciadores de pacotes/instalação de programas, eu acho que uma boa ideia seria criar um formato "universal" (ao invés de .deb, .rpm, .tgz e etc, criar um formato onde todas as distrubuições reconheceriam) e que, antes do pacote ser instalado, o próprio gerenciador se encarregasse de instalar as dependências necessárias (no pacote poderia existir uma "lista" com todas as dependências necessárias e então, o gerenciador faria uma "checagem" entre a lista e o sistema do usuário, instalando automaticamente todas as dependências que estariam faltando) - isso não seria a fórmula de todos os problemas porém, existiria um gerenciador simples, fácil (e personalizável, claro), compatível e que certamente ajudaria muito nessa questão (a simplicidade é tudo - como "disseram" uma vez: "A perfeição não é alcançada quando não existir mais nada para acrescentar, mas sim quando não existir mais nada para eliminar")

Se for para haver um gerenciador de pacotes com gerenciamento de dependências, o mais prático seria disponibilizar os códigos-fontes inalterados nos repositórios da distro e compilar localmente. Código-fonte é universal, pra toda distro é igual. Uma ferramenta que nem o slacktrack e fica tudo lindo.

Instalador Universal já tem, basta ver o instalar oficial do VMWare WorkStation, entre outos. O grande problema é que ninguém usa!

A maioria das empresas (como o Google e a Steam) e desenvolvedores prefere empacotar os softwares em .deb e .rpm (esse nem sempre), e deixa o resto do trabalho para a comunidade.

Por mais que essa discussão seja antiga, a solução não é tão complexa, basta ver como é a instalação de pacotes/programas no Apple Mac OS X; os softwares são disponibilizados em .dmg, que nada mais é que uma imagem de disco semelhante ao .iso, e nessa imagem contém uma pasta com a extensão .app (sim, os aplicativos do Mac OS X são pastas com extensão .app), e a única coisa que o instalador faz é copiar essa pasta .app para a pasta global do sistema, a /Applications, podendo ser feito até via Terminal:
$ sudo cp -R /Volumes/Software/Software.app /Applications

Simples, e fácil. Todo o conteúdo do software fica dentro da pasta /Applicatios/Software.app/Contents.

E para excluir o Aplicativo é muito mais fácil, basta arrastar essa pasta /Applications/Software.app para a Lixeira!
Ou: rm -rf /Applications/Software.app no Terminal. Na minha opinião, o Linux deveria seguir esse modelo para instalação Universal de pacotes.

Sim, isto seria muito bom.

Meus filhos, não pensem nessas merdas de pacotes. Isso é o que estraga a coisa... Padronizar pela compilação direta resolveria de uma maneira muito mais simples a questão.