Arch Linux vs. Usuário, Missão Impossível ao Extremo!!!!
Estou tentando ao máximo possível me libertar da praga de ajudar usuários que não sabem diferenciar um problema de software e um problema causado pela distribuição.
Muitos vivem reclamando que Arch bug isso, bug aquilo, dev isso, dev aquilo. Ver esse tipo de atitude dos usuários, que não tentam pensar ou descobrir as origens do problema, cansa e muito. E O PIOR, não tentam se quer, aprender como funciona o gerenciamento de pacotes e como funciona o desenvolvimento da distribuição, que são pontos importantes para evitar problemas com qualquer distribuição E MUITO MENOS reportam os problemas que acontecem, desse jeito fica complicado, pois ninguém tem bola de cristal.
Bons exemplos disso foram os updates do X.org, quando mudou a forma de detectar os devices e passou a usar o HAL, causando transtorno a algumas pessoas que precisaram aprender a configurar seus teclados e touchpads e atualização do GNOME 2.28. E hoje, é a nova versão do Xorg (xorg-server 1.7.x).
Tenho links de blogs e de fóruns, mas para evitar qualquer tipo de problema não postarei.
Qual o motivo dessa “revolta”?
Primeiro, se o usuário tem problemas com update, ele não procura no site, não assina a lista dev public, não procura no fórum oficial e nem no bugs report da distribuição. Segundo, o infeliz não procura olhar nos logs (do Xorg principalmente), não sabe olhar nos sites dos projetos (como Gnome, Kde, Xfce, etc…) para ver o que mudou de uma versão para outra. Não faz isso e já vai que nem louco postar no fórum, mail-list e perguntar no IRC o motivo do problema, se alguém demora para responder ou ignora, o usuário já sai chingando a distribuição, dizendo que não presta, é bugada, é distro amadora, etc.
Terceiro, Arch é focado basicamente em binários, consequentemente requer bastante cuidado. Não é igual ao Gentoo, onde você pode customizar tudo o que quer e não se preocupar com os updates.
Como no OpenBSD, teoricamente os desenvolvedores das distribuições, sabem o que estão fazendo, e recomendam não customizar tanto um software, e quando fazem essas customizações, muitos usuários não sabem lidar com as ideias dos desenvolvedores e com o pacman (suas configurações). Se você configura uma coisa e não quer que aquela configuração seja atualiza, dê uma olhada na man page do pacman.conf, e observe a opção NoUpgrade, isso é um excelente exemplo da falta de descaso com a distribuição.
Se realmente querem customizar e ainda sim querem usar o Arch, usem o ABS e aprendam também a usar a opção, IgnorePkg junto com NoUpgrade. Sendo assim, aguentem a consequência de fazer o update manualmente. O que acaba nos levando ao Quarto ponto, dependências.
Essas reclamações são as que enchem mais a paciência ou terminam com ela. O que tem de reclamação sobre isso não é brincadeira. Se o senhor não quer dependência X, Y, Z, faça como no lance das customizações.
“Ahhhh mas é o KDE, é muito grande, é um grupo, editar as PKGBUILDS não dá!”
Isso é clássico… KDE hoje é modular, o pacman já suporta split de pacotes, ficando mais fácil essa tarefa.
Quinto ponto, falei acima que é importante você conhecer a distribuição na parte de gerenciamento de pacotes e no desenvolvimento da mesma, em outras distribuições (como Debian, Gentoo e Slackware) os usuários são ligados nesses pontos sendo que no Arch muitos não fazem o mesmo, até hoje não entendo o motivo disso. Qual a diferença do Arch para as outras???
Analisando esses pontos, IMHO… Opinião TOTALMENTE pessoal (só para reforçar), 92% dos casos de problemas causados no Arch é pura culpa do usuário, como tem nos reviews e descrições feitas do Arch, distribuição feita para usuários experientes ou usuários que querem entender como funciona, que querem estudar.
Veja o FAQ do Arch, leia esta pergunta, mais esta e esta aqui. E ENTENDA BEM O QUE É E COMO AS COISAS FUNCIONAM NO ARCH!!!! EVITE PROBLEMAS PARA VOCÊ E PARA OS OUTROS que tentam te ajudar, infeliz!
Padawan, para você conseguir isso, precisa deixar de ser preguiçoso e começar a pensar, ler e saber solucionar seus problemas sozinho.
E agora Mestre Yoda e os outros 8% dos problemas?? Isso fica dividido entre problemas do upstream e falta de massa cinza na cabeça de alguns desenvolvedores. Vamos explicar um fato que engloba esses 2 aspectos e vocês vão entender: Primeiro temos uma thread que fala sobre o teste do novo Xorg e falando dos seus problemas e agora temos outra thread que fala sobre os problemas que o Xorg teve depois que foi movido para o extra.
Agora explicarei os problemas do Arch e do Upstream causadores dos problemas.
O problema do Arch é a falta de planejamento de desenvolvimento, cada um no seu quadrado. Se alguém mantém o Xorg e deixa no testing até que se resolva os problemas dos drivers, ninguém deveria meter o dedão e mover para o extra (que foi o problema dessa nova versão do xorg e pode ser visto nas 2 threads que coloquei aqui). Ninguém quer manter 2 versões de pacotes, a não ser, que seja altamente/extremamente necessário ou não tenha outra saída para resolver os problemas encontrados.
Sempre fui a favor de apenas 5~7 pessoas ajudando a manter o repositório core, assim aumentaria a estabilidade e a compatibilidade dos pacotes, dividir a pequena equipe em subgrupos (Xorg, KDE, Gnome, etc.), como existe no gentoo e debian. Cada um no seu quadrado. Como isso basicamete não existe, acontece esse tipo de problema como o atual do xorg.
Outro quesito importante é a parte de segurança que não é muito o forte do Arch, uma alternativa que ajudaria nisso seria o Sheriff, um software que “faz um diff” de vulnerabilidade entre NetBSD e Arch, feito pelo Paulo “thotypous” Matias, foi bem aceito pela equipe do Arch, só que não vingou e está a um ano sem desenvolvimento. Alguém se habilita a ajudar no projeto??
Segurança deveria ser mais ativo no desenvolvimento do Arch.
Upstream é coisa séria, como esses modificam as coisas, acaba meio que contribuindo e botando em cheque a credibilidade do Arch, pois o Arch bota no repositório e o usuário se vire para se adequar as mudanças dos projetos. Motivo??? Que o Arch não testa os pacotes, será mesmo????
Arch deixa kernel (depois de várias lapadas na cara que os desenvolvedores levaram) por um tempo indeterminado, pode ser de 1 dia a mais de mês no testing e agora temos o kernel-lts (que é uma ótima alternativa). Gnome 2.28.x ficou no unstable por 1 mês, o Kde 4 da mesma forma, Xorg do mesmo jeito e mesmo assim existe problemas, por que isso???
Pelo simples fato do Arch não ter usuários suficientes para ajudar nos testes, como Debian, Gentoo e Slackware tem. Para inicio se o que falei aqui fosse feito tanto por parte dos usuários e dos desenvolvedores, Arch melhoraria mais sua estabilidade e muito sua credibilidade.
Arch Linux vs. Stable
Apesar de tudo que falei acima, considero Arch bem estável.
Muitos usuários reclamam disso por dois motivos, primeiro por querer upstream bem testado (praticamente impossível, pois aqui eles são testados o suficiente para garantir que funcionam) tipo debian e segundo por terem vontade de usarem Arch em servidores.
A primeira já abordei um pouco, a segunda é meio complicada, mas também pega um pouco do que falei acima… Só que o principal para se pensar no segundo motivo, está aqui.
Fora realizar testes antes de jogar em produção, para garantir que a lei de Murphy não te pegue de surpresa. E por favor, saibam usar o ABS + pacman.conf adequadamente.
Como tem no wiki: “Você faz a estabilidade do seu Arch Linux!”
Já que você faz a estabilidade, qual a razão de você acompanhar o update de cada pacote em outras distribuições quando você usa em servidores e não faz no Arch???
Esse é um erro fatal de muitos, como já disse… ABS + pacman.conf na cabeça, pensem nisso. 😉
Bom, por enquanto é isso. Se você não gosta ou não concorda com o que falei aqui sobre o Arch. Melhor você usar Debian!
Arch Linux não é pra qualquer um, ele seleciona bem seus usuários. x)
Saudações,
Leandro “skate_forever” Inácio
