lcavalheiro
(usa Slackware)
Enviado em 23/01/2014 - 14:12h
bilufe escreveu:
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.
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.
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.
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.
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).
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:
slacktrack: slacktrack (Slackware package building utilities)
slacktrack:
slacktrack: slacktrack tracks the installation of a 'make install' (or similar)
slacktrack: and produces a Slackware compliant package from the results.
slacktrack:
slacktrack: slacktrack can be used to build packages from Slackware's '.build'
slacktrack: scripts or your own.
slacktrack:
slacktrack: slacktrack tracks installations directly on the host's filesystem.
slacktrack:
slacktrack:
(copiado do slack-desc do pacote)
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?
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 ;-)
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.
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.
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.
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).
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.
Isso vale mais pro Ubuntu do que pras outras distros, mas ainda assim é uma questão importante.
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!
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 ;-))
Bem pessoal, por enquanto é isto. Quais são as ideias que vocês teriam para melhorar o Linux no desktop?
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...
