A ferramenta adequada para o trabalho
Há meses escrevi um texto e fiz algumas piadas a respeito do fato de estarem fazendo mal-uso do Kurumin, um live-cd baseado no knoppix que é, por sua vez, baseado no Debian. Diante da enorme quantidade de mal-entendidos que foram gerados e da compreensão truncada a respeito da minha motivação e argumentos, resolvi escrever um artigo diferente, mais focado e factual.
Antes de qualquer coisa, acho importante mencionar que nada tenho especificamente contra o Kurumin. Muito pelo contrário, desde seu lançamento acho que ele é uma ferramenta muito boa para demonstrar que GNU/Linux pode ser fácil de usar ao não-iniciado. O exibi em apresentações que fiz e continuo dando CDs de Kurumin para usuários de Windows que querem somente conhecer o sistema pela primeira vez.
O objetivo dele é esse mesmo: ser simples de usar. Em diversas entrevistas e textos seu autor, Carlos Morimoto, explicita esse objetivo e dá exemplos de características do Kurumin criadas para atender a esse objetivo como, por exemplo, suporte automatizado aos softmodems (os infames "winmodems") mais usados.
Desde mais ou menos final de 2003 eu tenho visto muita gente de universidades, empresas e órgãos públicos considerando usar o Kurumin para instalação nos desktops corporativos e, também, tive conhecimento de alguns casos de pessoas considerando o Kurumin para instalação de servidores. Isso me preocupa, porque, apesar de o Kurumin ser uma ferramenta muito boa para aquilo a que se propõe inicialmente, não há preocupação especificamente com pontos importantíssimos para esses tipos de uso que citei.
Tanto os desktops corporativos quanto os servidores da rede de uma organização contêm dados importantes que precisam ser protegidos. Além disso, a decisão por uma plataforma implica em capacitação de funcionários e adequação de cultura operacional. Por isso mesmo, várias características são importantes em sistemas que sejam instalados para esses usos: segurança, estabilidade e capacidade de manutenção.
É necessário que um time de segurança esteja tomando conta diariamente dos problemas que aparecem e que seja possível atualizar todos os sistemas de forma gerenciável para que os consertos sejam incorporados o mais rapidamente possível. A estabilidade que de falo não é simplesmente o programa não "dar pau", mas também não ter modificações na interface, no modo de usar, nas configurações; todas essas mudanças exigem mais esforço de capacitação e suporte e precisam poder ser planejadas. A capacidade de manutenção está basicamente em responder à seguinte pergunta: é possível manter seu sistema funcionando com atualizações de segurança sendo instaladas rapidamente sem que mudanças na usabilidade e configurações aconteçam?
Cada distribuição tem seus objetivos; para atingir esses objetivos a empresa, pessoa ou projeto que a cria define padrões de qualidade mínimos a serem atingidos e políticas de empacotamento que guiam a forma como os softwares são integrados ao sistema. O Projeto Debian, o exemplo mais próximo que tenho, além de definir o limite ideológico de que somente software que atenda aos requisitos da Definição Debian de Software Livre pode fazer parte da distribuição oficial, tem comprometimentos com uma Política de Lançamento e uma Política de Empacotamento que definem, em conjunto, o que se pode esperar de qualidade, estabilidade (nos mais diversos sentidos da palavra) e padronização de um sistema Debian. Para garantir a segurança mantendo a estabilidade, o Debian tem um time de segurança que fornece pacotes com consertos de segurança sem mudar de versão.
São essas políticas e compromissos de uma e outra distribuição que especificam quais os requisitos de segurança, estabilidade e capacidade de manutenção de que falei acima serão atendidos. Assim como o Debian, a Mandriva tem os seus, o Slackware tem os seus. Este último, por exemplo, assume o compromisso de manter os softwares do jeito que os seus criadores os planejaram para serem distribuídos, sem alterar localização de arquivos, por exemplo, com a intenção de garantir que a documentação original seja plenamente coerente com a situação que o administrador vai encontrar.
O Kurumin perde pontos como opção para esses propósitos quando analisamos seus objetivos e políticas a partir das soluções técnicas dadas aos mais diversos problemas. Uma das brincadeiras que eu fiz com o Kurumin há um tempo atrás e que gerou muita polêmica era um log de IRC em que um usuário tentava fazer a atualização do Kurumin usando os repositórios do Debian. Acabamos descobrindo que um dos pacotes básicos do sistema estava numa versão extremamente antiga que, segundo o autor, provinha do Knoppix, ainda e nunca tinha sido tocada. Um exemplo desse tipo de comportamento instável da manutenção de um sistema Kurumin pode ser visto no seu próprio fórum. Como curiosidade, note que nessa discussão um dos usuários afirma estar adotando Kurumin em ambiente de trabalho.
Usar a Debian testing ou a Debian unstable para manter o sistema atualizado parece ser o método "oficial", como podemos ver no ChangeLog, especificamente do Kurumin 3.1:
O apt-get upgrade continua funcionando perfeitamente nesta versão. Você pode manter o Kurumin atualizado com o Debian testing rodando os comandos "apt-get update" e em seguida "apt-get upgrade" periódicamente. Podem haver pequenas alterações nas configurações do sistema e este tipo de coisas, mas no geral os pacotes do testing são bastante estáveis.
A citação acima serve para demonstrar como a estabilidade não é mantida quando cita as pequenas alterações que podem acontecer. As suítes "unstable" e "testing" do Debian não garantem estabilidade, capacidade de manutenção e nem segurança, embora os consertos de segurança normalmente cheguem rapidamente à unstable (já que a maioria dos desenvolvedores a usam) e, mais recentemente, um time de segurança da testing tenha sido formado e, na maior parte do tempo, ambas sejam bastante usáveis. É importante observar que esse não é um problema inerente ao sistema Kurumin em si, mas sim um problema advindo da decisão de projeto de não fazer manutenção completa continuada para uma versão lançada. As suítes "unstable" e "testing" são mutáveis e quebráveis por natureza, já que fazem parte do ciclo de desenvolvimento e controle de qualidade do Debian. Elas foram feitas para que os desenvolvedores Debian encontrem os problemas e não os deixem passar para um lançamento estável.
Não há, também, políticas de empacotamento e lançamento que especifiquem expectativas mínimas de qualidade e definição clara do que é esperado para um lançamento. No capítulo 8 do seu livro "Entendendo e Dominando o Linux (Sétima Edição)", em que Morimoto explica como criar uma personalização de distribuição sua, por exemplo há uma seção sobre como personalizar a configuração padrão do KDE e uma seção sobre como criar pacotes .deb.
No caso do KDE as direções dadas são difíceis de manter e só atingem novos usuários, no caso de uma instalação, ignorando completamente as orientações do manual de administração do KDE (veja em especial a seção "Cascading Configuration". O método de criação de pacotes Debian ignora completamente a Política de Empacotamento do Projeto Debian, citada anteriormente, e ignora mesmo as direções dadas pelo Guia dos Novos Mantenedores; não há pacotes-fonte o que, além de deixar a dúvida a respeito da violação da licença de alguns softwares, torna a manutenção dos pacotes quase impraticável e a manutenção sensata de segurança impossível, já que as relações declaradas no pacote fonte e o método de compilação e construção não é padrão.
Mas isso é inerentemente ruim? Não necessariamente. Nem quero com isso implicar que o autor do Kurumin não sabe onde procurar ou não saiba o jeito certo de fazer as coisas. Isso é uma decisão de projeto consoante com o objetivo maior de ser o mais simples possível para o usuário que vai testar o GNU/Linux ou usá-lo eventualmente num computador em que não possa fazer uma instalação permanente, desde que seja esse o objetivo, é claro. Quando se começa a falar em instalação em dezenas de desktops em uma organização, universidade, por exemplo, ou, pior, instalação em servidores, no entanto, a coisa começa a ficar preocupante.
A ferramenta mais adequada para cada situação é a que deve ser escolhida para aquela situação. O Kurumin é uma ferramenta excelente para demonstrar o GNU/Linux ou para carregar consigo e poder usar as ferramentas do GNU/Linux em uma máquina que não pode ter sua instalação alterada e não atende às suas necessidades. Para instalação de desktops e servidores temos diversas opções no mundo do Software Livre hoje que se adequam perfeitamente às mais variadas necessidades sem quebrar os princípios básicos da boa administração, especialmente em ambientes em que se espera que haja um administrador que sabe o que está fazendo, dispensando, assim, as facilidades gráficas oferecidas em detrimento daqueles pelo Kurumin.
© 2004, Gustavo Noronha Silva
Esse é um texto de opinião e pode ser distribuído não-modificado livremente desde que citada a fonte. Modificações são permitidas desde que uma nota anteceda o texto atestando que modificações foram feitas e identificando o autor das modificações, além de citar a fonte da versão original.
