|
Página 3 de 4
A questão da Qualidade
O que é Qualidade? A Qualidade é um conceito subliminar. Mesmo que você não saiba definir o que é Qualidade, você sabe que um produto tem Qualidade em relação a outro porque esse produto é bom, e o outro, nem tanto.
Por exemplo: eu vou colocar na sua frente duas garrafas de refrigerante e dizer que você pode levar, de graça, uma delas, a que você escolher. De um lado, uma garrafa de Coca-Cola. De outro, uma garrafa de Fruki Cola. Ambas são a mesma substância, ambas têm a mesma quantidade, ambas são fabricadas no Brasil mas, sinceramente, qual você escolheria? O nome Coca-Cola já é algo já conhecido em todo o mundo e, mesmo que depois você descubra que a Fruki Cola seja boa, você certamente escolheria a Coca-Cola, porque, em sua mente, essa posui mais qualidade. Por que um iPod é melhor que um MP4 da Foston? Porque o produto da Apple tem mais qualidade.
Esse conceito pode estar implícito mas, na vida real, poucas pessoas conseguem colocar a Qualidade em seus produtos. No caso das distros nacionais, a Qualidade está em pequenos detalhes, detalhes estes que são, na maioria das vezes, esquecidos ou ignorados pelos desenvolvedores das distribuições. São coisas que não nos damos conta, mas que fazem toda a diferença.
Será que isso roda no meu computador?
Conforme disse antes, o desenvolvimento não acaba quando uma imagem ISO é enviada para um servidor. Muito pelo contrário, é aí que ele realmente começa. O fato é que a maioria das distribuições é feita por pessoal não-qualificado que não têm condições adequadas de testar os seus produtos.
Por exemplo: se eu estou desenvolvendo uma distro e, após queimar o CD, eu vir que esta funciona do jeito que eu esperava no meu computador, um Core2Duo de 4 GHz com 2 GB de memória e HD de 250 GB, eu posso concluir que está tudo certo e posso fazer upload. Mas será que essa distro que eu criei vai rodar no Pentium II 233 MHZ com 64 MB de memória RAM e HD de 4 GB do cara que a baixou do meu site? Será que a placa de vídeo do micro do meu usuário vai suportar o ambiente desktop que eu coloquei por padrão? Será que o meu usuário não possui nenhum item de hardware incompatível, que possa fazer com que o sistema trave durante o boot? Será que o drive de CD dele é rápido o suficiente para carregar o sistema deste disco? Será que o XGL vai funcionar naquela placa Trident?
A verdade absoluta é: NINGUÉM SABE COMO É O MICRO DO SEU USUÁRIO.
Em ambientes profissionais, as empresas possuem um vasto leque de configurações, com micros que vão de 486 a modelos top de linha. Eles podem, então, testar o sistema pronto em todas essas configurações e, quando do lançamento, dizer onde ele funciona, onde é necessário fazer pequenos ajustes para que ele funcione, e onde ele definitivamente não fuinciona. Já no Brasil, a maioria dos desenvolvedores cria suas distros nos micros que estão em suas casas e, no final, apenas têm a certeza que o programa funciona naquela configuração. Cabe ao usuário descobrir por conta própria se o sistema que ele ficou uma noite inteira baixando vai se entender com tudo que ele possui.
Pra quem eu peço ajuda?
A maioria dos desenvolvedores pensa que os usuários vão baixar a distribuição, vão dar o boot e vão viver felizes para sempre. Ledo engano. O pensamento primário na mente de um desenvolvedor deve ser: Isso NÃO vai funcionar no micro do meu usuário.
Se eu criei alguma coisa, eu sou obrigado a dizer como ela funciona. E aí vem uma questão vital, muitas vezes esquecida pelos desenvolvedores: suporte técnico.
Qual é a forma de suporte técnico da sua distribuição? Será que, se eu tiver uma dificuldade, eu poderei ligar para um número telefônico ou mandar um e-mail e um profissional devidamente capacitado irá me ajudar a solucionar o meu problema, ou será que eu vou ter que postar a minha dúvida em um PHPBB da vida e esperar que outros usuários me digam como resolver a questão? E será que a resolução proposta vai realmente solucionar o meu problema ou será que, além de resolver o meu problema, vai me causar outros que eu não tinha antes de aplicá-la?
Não estou dizendo que as distros não devam ter um fórum comunitário mas, sim, que esta não deve ser a solução exclusiva de suporte oferecida pelos mantenedores.
Pacotes e Atualizações
De onde vêm os pacotes que formam a minha distro? Esta é uma questão crucial que não recebe a devida atenção. Muitas pessoas criam distros baseadas no Debian ou Ubuntu e configuram os repositórios dos seus sistemas como sendo os repositórios das distros originais.
Até aí nenhum problema, a não ser por um pequeno detalhe: o desenvolvedor não tem nenhum controle sobre o que é colocado e retirado destes repositórios. Por exemplo: vamos dizer que eu fiz uma distro baseada no Debian Etch na qual eu modifiquei algumas coisas para que ela ficasse... melhor. Aí, um pacote X é atualizado nos repositórios. Os usuários, evidentemente, vão baixar automaticamente esse pacote e... ao reiniciarem o sistema, BUM! Nada funcona!
O que aconteceu? Provavelmente, a atualização lançada pelo time de desenvolvedores oficiais causou algum conflito com algo que eu coloquei ou deixei de colocar na minha distribuição e isso fez o sistema cair. E o pior é que eu não posso escrever uma carta dizendo: “Seu pacote destruiu minha distribuição!” Eles provavelmente responderão com um “Nós não fazemos pacotes para sua distribuição, nós fazemos pacotes para o Debian”.
Se o desenvolvedor tivesse o seu próprio repositório de pacotes, isso seria diferente. Ao ser anunciada a nova versão de um pacote, os desenvolvedores poderiam testá-lo antes de liberá-lo para o público e, se houvesse algum problema, eles poderiam recompilá-lo ou mudar algo nele ou, em último caso, escolher não lançá-lo naquele momento. Isto dá mais controle. Para ter uma idéia, há alguns anos um pacote do X.org lançado nos servidores do Ubuntu derrubou o sistema. A Canonical rapidamente encontrou e corrigiu o problema, e isso que eles tinham seu próprio repositório. Imaginem se não tivessem, como saberiam qual o culpado pelo problema?
Outro caso é o famoso apt-get dist-upgrade do Kurumin. Como pode um sistema literalmente se quebrar depois de ser atualizado? Isso não pode acontecer e, se o Kurumin tivesse seu próprio repositório de pacotes, certamente não aconteceria.
Código-Fonte
Se sua distribuição é livre, ela deve vir com o código-fonte. Mas, onde eu posso conseguí-lo? A maioria dos desenvolvedores se esquece desse detalhe e, na hora H, dizem educadamente algo como “O código-fonte está no FTP do Debian. Vá lá e se vire” .
Embora a GPLv3 permita isso, há um grande número de pacotes que ainda estão sob a GPLv2, que proibe a prática. Assim, se seu desenvolvedor não oferecer para você um CD de fontes junto com o CD binário, desconfie.
Não Serás Redundante
É óbvio que existem vários programas que servem para a mesma coisa, cada um com suas próprias características, e é claro que o usuário é livre para escolher o que achar melhor para si, o que não significa que você deva colocar todos eles em sua distribuição para que o usuário escolha, como ocorria com as primeiras versões do Kurumin. A distribuição deve ter apenas um, ou no máximo dois programas que façam a mesma coisa, e você deve dar ao usuário a oportunidade de baixar os outros, se ele assim quiser. Isso se chama aproveitar bem o espaço. Do contrário, do que adianta colocar 20 navegadores de internet e nenhum driver de winmodem porque não coube no CD?
Documentação
É uma verdade fundamental que ninguém lê ajuda, manuais de instruções e coisas do tipo. Mas isso não significa que você deva se abster desse detalhe. É óbvio que KDE, Gnome e OpenOffice possuem seus próprios manuais de ajuda, mas aqueles são os manuais deles, com uma linguagem técnica demais para ser entendida por meros mortais. Você deve criar seus próprios manuais de ajuda, explicando com suas palavras como usar o sistema, desde as coisas mais simples até as coisas mais complexas, em uma linguagem que o público-alvo que você escolheu para sua distro entenda. Dúvidas que nos fazem ter vontade de jogar o usuário pela janela, como por exemplo “Se eu salvar um documento no Windows no A:, como eu faço para abrí-lo aqui? ” devem ser respondidas da forma mais educada e clara possível (sim, eu já tive que responder essa pergunta...). Colocar videotutoriais é uma ótima idéia, disponibilizar uma documentação impressa e ilustrada, melhor ainda.
|
