Problemas graves no Linux

Olá

Há muito tempo testo distribuições GNU /Linux e tenho visto que elas sempre possuem os mesmos problemas .Eles não são tão fáceis de se encontrar e podem ser confundidos com outros problemas .
Embora eu goste muito do GNU/Linux e do software livre , é necessário que esses problemas sejam corrigidos para que assim conquistem um bom pedaço da área do desktop.

Enfim vou começar a citar os problemas:

1° Não há separação entre software que é do sistema e software que não é.

Por exemplo no Windows nenhum programa que se instala pode remover o botão iniciar ou o windows explorer . No Linux ou outro sistema Unix Livre ,isso pode acontecer . Na maioria das vezes , o individuo instala um programa p2p por exemplo ,mas ai o sistema de pacotes insiste em atualizar algum pacote do gnome ou uma dependencia do sistema.

Issso é errado .Deveria existir uma lista de pacotes do sistema que não podem ser manipulados a qualquer mudança que aconteça .O que eu quero dizer é que deveria existir uma lista de pacotes do sistema que nunca seriam modificadas pelos aplicativos que o usuário instala .Exceto somente pelo o desenvolvedor da distro que então entregaria atualizações de segurança.

Nesta lista proibida deveria existir :

Gnome (ou outro ambiente de trabalho)
Kernel
X ( e todos os seus aparatos)
Glibc
E alguns outros importantes para o sistema.

Desculpem falar ,mas devemos fazer igual ao Windows .Não devemos misturar aplicativos com os pacotes do sistema. No win por exemplo , o indivíduo pode remover todos os seus aplicativos e continuar com o Windows intacto .No linux isso não acontece .O usuário instala um programa que não tem nada a ver ,mas ai o linux mistura com os pacotes do sistema , tenta atualizar o gnome , tenta remover conflitos e tudo.

O que se propõe então ?
Criar uma lista de pacotes do sistema que nunca seriam modificados por alguma aplicação que o usuário instala.Exceto para atualização de segurança e que não quebrem a API..

O que seria pacote do sistema?
São aqueles pacotes essenciais para o funcionamente adequado para o usuário.Exemplos são :
Gnome -(se modificar esse ambiente de trabalho é a mesma coisa que remover o botão "Iniciar" do usuário).
Kernel,- Não preciso dizer nada
X - Essencial
Glibc

Agora , o que não fazem parte do sistema?
Editores de texto
Navegadores
Jogos
Emuladores

Esses aplicativos opcionais e dependem de usuário para usuário .Não podemos misturar com o que é essencial para o usuário (pacotes do sistema) , com o que não é (pacotes de aplicativos - jogos, editores de texto e etc..).

Uma analogia simples pra entender : O Windows não cola a casa com seus móveis.Ele não quebra a parede da casa pra instalar um armário.Se precisar de uma parede nova pra por o armário , o Windows constroi outra parede ,mas não quebra a anterior. O windows é capaz de fazer algo que o gentoo linux faz , manter varios aplicativos funcionando ao mesmo tempo sem que nenhuma remova a outra .E isso é uma coisa boa

O Unix quebra o piso da casa pra por uma cadeira no chão .


2° Sistema de pacotes
O sistema "Sistema de pacotes" é muito problemático e complexo. Além de tratar todos os aplicativos como "pacotes" ele é muito preocupado em compartilhar TODAS as dependencias e prover uma segurança EXTREMAMENTE ALTA que é desnecessária.
Isso acontece porque isso é uma herança velha dos profissionais do Unix.Antigamente ,espaço em disco era pequeno e manter duas bibliotecas iguais traria um risco na segurança do sistema.

MAS atualmente esses problemas não são tão preocupantes assim .Espaco em disco se tornou muito barato e expansivo.O Linux é heterogeneo demais pra se preocupar em compartilhar todas essas bibliotecas.Talvez isso seja bom pra profissionais ,mas para usuários isso não é.
Pra falar a verdade ,isso faz muito mal pro usuário. Por exemplo , o usuário se perde todo em uma montanha de pacotes para somente instalar um único aplicativo .Vive instalando pacotes mínimos muito pequenos, pois se não instalar , nada de aplicativo instalado .Pra falar a verdade o usuário nem mesmo sabe qual pacote começar .Sem contar que pela falta de uma API estável, ele provavelmente vai ter que puxar todos os pacotes novamente quando instalar uma versão nova da distribuiçao.

Isso é muito diferente do Windows , onde o usuário instala o programa desejado através de um único instalador (ou dois no máximo) e fica com o programa pronto.E o instalador é bonito e informal , não usa frontends e não fico dando avisos de "conflito " "falta de dependencia" e outras coisas complexas para o usuário.
O windows não se preocupa em compartilhar todas as bibliotecas e gastar um pouco mais de espaço pra manter duas bibliotecas iguais .
Vocês podem falar que isso aumenta o risco de falhas .Sim ,pode aumentar, mas não é um risco elevado e por fim é muito melhor o usuário ter o programa funcionando do que viver num ambiente seguro e não ter programa nenhum funcionando.
E na realidade , os crackers não exploram os aplicativos tanto assim .Eles na realide ,exploram falhas do sistema .Pois aplicativos são muito diferentes ,mas o sistema não.

Mais um problema :.
Vocês já viram que trancaram a instalação de aplicativos dentro do sistema. O usuário só pode instalar programas de forma fácil através do adicionar e remover programas ?
Ele deveria também poder acessar a internet e puxar da pagina oficial do desenvolvedor um instalador bonito e prático

Mais outro problema.:"Baixar a lista de pacotes"
Isso é horrivel e deixa o sistema dependente de internet ,pois o usuário tem que gastar banda só pra ter aplicativos instalados.
Isso também é uma herança velha dos profissionais de Unix , onde deveriam puxar pacotes de repositórios "seguros" e de confiança.Isso é um extremo formalismo e trata os Sistemas Linux como se fossem os mais inseguros do mundo.


O que deve ser feito ?
Primeira coisa : largar esse "sistema de pacotes" .É muito modular e parece uma pilha de lego.Recomendado para profissionais .Para usuários nao.
Esquecer a paranoia de compartilhar todas as bibliotecas .Mas não ha necessidade também de clonar toda a bibliteca para cada aplicativo.
Por exemplo , Se um aplicativo exige o python então faça o usuário instalar o aplicativo python atraves de uma mensagem simples "Erro python não foi encontrado , instale em www.python.org" . Python é um aplicativo grande e que muitos aplicativos dependem dele.
Agora nunca peça ao usuário pra instalar a libblablabla.so .Isso já deveria ser incluido com o aplicativo.

A diferença que devem notar é que se um aplicativo necessita de outro aplicativo pra instalar ,então o faça instalar o aplicativo .
Se for o caso de depender de uma biblioteca ou uma DLL ,então ja inclua no aplicativo mesmo que já exista no sistema ou não. Pois na realidade você não sabe se há ou não no sistema ,pois você sabe que o usuário tem somente o sistema.Você não sabe se ele tem a libblablabla incluida ou não pois isso não faz parte do sistema . (Lembre-se do primeiro problema citado acima).


Isso é importante , por mais que seja tolo manter duas ou mais bibliotecas iguais .Mas ainda acima de tudo é melhor manter duas ou mais bibliotecas ,pois mesmo sendo iguais ,elas são compiladas de forma diferente . E se um programa for desinstalado , o outro programa não sofre o risco de parar de funcionar pois tem a sua propria biblioteca

Isso além de tudo facilitaria muito para o usuário .E diminuira a extrema modularidade danosa ao usuário que chega ao ponto de instalar pacotes de tamanho de 30k para um app enorme funcionar.E a palavra pacote é feia .Isso é coisa de profissional de segurança.

Melhorar também a interface de instalação.Devemos usar instaladores e não frontends de apt-get ou outra coisa parecida.São muito simplórios, não dão uma explicação exata do que usuário instala . E são muito formais, jogam na cara do usuário que a libblablabla.so não está instalada.
Compare com os instaldores do PC-BSD, Lzpack e msi.

Tudo isso seria evitado se o sistema usasse instaladores com dependencias banais já incluídas e através de um unico instalador.E isso só funciona se seguirmos a solução do primeiro problema citado lá em cima.Pois ainda infelizmente o Linux não sabe o que é do sistema e o que não é.

Uma analogia fácil: O windows já te da uns kits prontos .O Linux dá um lego .Mas o usuário não quer montar , o usuário quer usar. E se queremos conquistar o usuario devemos para de montar pilhas de lego.


3° Dependencia da Linha de comando

Infelizmente o sistemas Unix Livre ainda tem muita dependencia da linha de comando escondida nas interfaces gráficas. Muitos aplicativos usam ainda o conceito de backend-frontend onde existem duas interfaces rodando ao mesmo tempo. A GUI que manda comandos de texto para a interface terminal do backend que então é processado.
Além de gastar mais recursos pra manter duas interfaces rodando e criar uma dependencia da linha de comando, o sistema pode entrar numa situação que eu chamo de dissonância.
Dissonancia:

É aquela situação exemplar onde você clica na GUI frontend e não acontece nada , pois na realidade aconteceu um erro feio na cli backend ,mas a GUI- não sabe tratar o erro de forma adequada.
Ou pode ser também que você fechou uma GUI-frontend travada ,mas a cli-backend continua a funcionar e gastando recursos.Parece aquele efeito de fechar o explorer ,mas não te deixar ejetar o cdrom.
Isso é dissonancia (nesse caso) ,ou seja ,é a falta de harmonia onde as duas interfaces não se comunicam junto ao mesmo tempo.

Isso não é de todo mal ?Não muito , isso não é tão prejudicial se o programa for bem feito .Pode se tornar até imperceptível. Mas isso acontece muito na área adminsitrativa. Tem melhorado ,mas isso é uma prática que temos que evitar.
Por exemplo , muitos querem alterar configurações do sistema ,como cor ,rede,som ,drivers ,mas quase sempre usam frontends mal feitos e que não conseguem alterar de forma eficaz as configurações , pois provavelmente ele passa as configurações pra linha de comando ,e a linha de comando faz o trabalho.
Mas a dissonancia vem e vai.

Olhem a diferença no windows e no Macintosh.Eles eliminaram essa ideia de frontend e backend na area de adminsitração do sistema. Conectar a interntet,criar uma conexão ,configurar a rede ,som,mouse,drivers,video são todos feito pela a interface gráfica.


(Uma dica ,o Linux e os Unix Livres tem uma interface do usuário ESPETACULAR .,navegadores, browsers ,editores, mas na área adminiistrativa peca muito.Devemos criar interfaces graficas boas e decentes para que o usuário instale um driver sem muita dificuldade ou configure a rede sem muita dificuldade.E também não podemos criar interfaces gráficas que só instalam um tipo de driver .Devemos criar interfaces que facilite o usuário instalar qualquer tipo de driver com facilidade.)

Mais outro problema : Muitos aplicativos ainda não se libertaram da linha de comando .Um exemplo disso é o Mysql , apache , que embora no windows ,eles tenha um pequeno ícone pra controlar o acesso (mesmo sendo "frontend") , no Linux nem mesmo tem um ícone para controle .Tem que ficar passando comandos no terminal e fica a escondida do usuário .
Certas vezes é hilário o usuario instalar distros grandes como o fedora e o openSuse e estar com apache , mysql e outras coisas rodando sem saber. A culpa é do iniciante ??? Claro que não !!!
O problema é que tais distros possuam aplicativos que não possuam um acesso mínimo sequer pela interface gráfica.
Se existisse um icone no tray avisando que essas coisas estivessem rodando,o usuário teria oportunidade de terminar tais aplicacões não essenciais ao sistema.

Serviços como configuração de rede , banco de dados , aplicativos comuns todos eles devem estar dispostos para acesso a interface gráfica.E idealmente sem uso de front-GUI-back-CLI.



O que deve ser feito ?

Todo software funciona assim ,eles tem suas libs ,arquivos de configuração e a interface de acesso. A interface de acesso pode ser gráfica ou linha de comando.A interface de acesso pede informações para a libs e depois a interface de acesso joga as informações para o usuário.
O que acontece é que as pessoas usam a interface velha da linha de comando e criam outra interface gráfica dependente da linha de comando que então chamam de frotend.
Mas o ideal seria o usuário não usar a interface da linha de comando e sim ligar direto a interface gráfica com a biblioteca que processa os comandos. Pode haver um risco de segurança envolvido,embora os nossos sistema sejam capazes e seguros . O aplicativo inteiro trava,(embora com o frontend-backend também aconteça isso) .
Uma solução pra controlar esses riscos é criar um controlador igual aos que os anti-virus fázem .Colocar um pequeno icone no tray para controlar o anti-vírus.
Existem profissionais que precisam da linha de comando por questões de segurança.É simples , é só ligar a interface da linha de comando com a lib. Mas nunca,NUNCA , ligar a interface gráfica do usuário comum com a interface linha de comando com a interface do profissional.

Em compensação temos boas vantages: mais rápido pois não usa duas interfaces passando mensagens ,independencia da linha de comando , e sem dissonância.

Uma analogia : O Windows transporta informação usando somente o tunel.O Linux passa pelo túnel , faz os transportadores descerem do caminhao ,pegar caixa a caixa e passar pela ponte ,para assim entregarem a encomenda.


4° A Falta de uma API de tempo maior

O linux tem um problema grave e sério que faz todo o usuário jogar seus pacotes da distro anterior fora para instalar todos novo. O problema ,como você imaginam não é uma API estavel sem bugs ,mas a falta de uma api estável é consequencia de uma API muito curta.
Nós com o nosso ciclo extremamente rápido queremos que em todo lançamento saia uma distro sem bugs .Isso é impossível com ciclos exagerados de 6 meses.
Pra você ter uma ideia ,a m$ gastou mais de 5 anos e não conseguiu entregar um windows vi$ta com poucas falhas.
E nos então queremos em 6 meses fazer todo o ciclo de construção e teste pra sair uma distro perfeita!!!!!
O outro lado da estabilidade se refere ao tempo de vida de uma distro.Quanto tempo ela pode instalar novos programas sem a necessidade de atualizar uma nova versão .
Muitos desenvolvedores não querem tal tipo de coisa ,pois pra começar uma API deve durar idealmente 2 anos. Caso eles queira é só seguir a 1° e a 2 ° solução dos problemas que citei acima.
Primeiramente o Linux não tem uma API estável porque não sabe ver o que é do sistema e o que não é (1° problema). Pois o sistema é uma API , os aplicativos não são a API.
Como o Linux e os Unix livres não sabem , então os desenvolvedores de aplicativos não sabem como suportar algo, quais pacotes devem incluir e tudo o mais.E poucos usam tecnologias multi-slot que citei no segundo problema ,que é a capacidade de manter 2 ou mais bibliotecas iguais rodando ao mesmo tempo .Isso faz por exemplo a API durar bastante tempo .Sem contar os outros problemas que citei no 2° problema.


Uma analogia :Windows ;A cada 10 anos vocÊ desmonta o lego
Linux : A cada 6 meses você desmonta o lego mesmo não necessitando e mesmo que uma peça somente esteja com defeito.

Solução : Ver 1° e 2° problema.
Aumentar o ciclo de duração pra no minimo 1 ano e meio .


Acho que é só isso por enquanto


Obrigado!