Entrevista com Kris Moore, desenvolvedor-chefe do PC-BSD

KM: Tenho 27 anos, sou casado, tenho três filhos com menos de cinco anos (você deve imaginar a bagunça que se forma por aqui de vez em quando), moro próximo às lindas montanhas enevoadas do leste do Tenesse, na cidade de Maryville, e me sustento trabalhando no desenvolvimento do PC-BSD.

KM: No meio da década de 90, comecei a trabalhar como técnico de telefonia em um provedor de acesso discado, que por acaso rodava o FreeBSD em seus servidores. Foi minha primeira experiência com um sistema baseado em *nix, e aprendi muito brincando com a linha de comando pela primeira vez. Depois que saí da faculdade fiquei alguns anos sem mexer com o FreeBSD, até decidir configurar um servidor web baseado no Apache.

À essa altura, eu já tinha adquirido alguns desktops antigos e estava experimentando várias distribuições Linux neles, como Caldera, Red Hat e SuSE. Eu gostava da interface gráfica para instalação que esses sistemas ofereciam. Mas ao usar uma dessas distros no servidor web eu acabei tendo problemas de segurança, inclusive com um servidor que foi hackeado menos de 24 horas após o término da instalação padrão do servidor. Naquele momento, lembrei do nosso administrador de sistemas no provedor de internet, e de como ele vivia levantando a bandeira da segurança e da confiabilidade do FreeBSD, e decidi tentar de novo. Após umas poucas horas de configuração, meu servidor Apache FreeBSD estava a todo vapor, e o sistema continuou seguro e confiável por toda a sua vida.

KM: Na época em que eu configurava servidores baseados no BSD, eu ainda estava testando várias distribuições Linux no desktop. Por várias vezes eu rodei apenas o Linux no meu desktop, mas sempre tinha problemas. Na maioria das vezes não eram problemas de hardware; os problemas costumavam ficar no âmbito do gerenciamento de pacotes. Fui ficando cada vez mais frustrado com todo o conceito de uma distribuição “empacotada”, na qual todos os programas individuais são, na verdade, parte do sistema operacional em si. Tentar atualizar um pacote geralmente disparava a atualização de outras dependências, que por sua vez atualizavam outros programas, e era bem comum algo dar errado, causando uma grande confusão. E lá estava eu, tentando resolver tudo.

Nesse ponto eu comecei a pensar: por que é que hoje, já passado o ano 2000, eu ainda tenho que resolver algum problema bobo de dependências, quando tudo o que eu quero é rodar a versão mais recente do aplicativo X? Não que eu não tivesse como resolver os problemas, mas eu tinha mais o que fazer e não queria perder tempo. Então eu comecei a fazer experiências com o conceito de auto-extração, de um sistema de pacotes auto-contido, no qual os programas se instalavam e residiam em seus próprios diretórios separados, ao invés de espalhados pelo cenário do sistema operacional em vários diretórios e sistemas de arquivos.

A princípio pensei em testar o sistema de gerenciamento de pacotes auto-contido no Linux, mas logo descobri que as diferenças entre as várias distros seriam um enorme obstáculo e que, tirando um kernel em comum, elas eram todas diferentes entre si, e que um sistema único de gerenciamento de pacotes seria impossível. Isso também não casava com a minha idéia de manter o sistema operacional e o software completamente separados.

Por sorte eu já era bem fluente no FreeBSD, e decidi que construir nosso sistema operacional com base no BSD seria bem mais viável a longo termo. Eu achava, e ainda acho, que no fundo, o FreeBSD foi bem mais fácil de usar do que o Linux, devido à consistência que ele nos deu. Ele só precisava da mesma atenção que o Linux havia obtido ao longo dos anos, ou seja, de um instalador gráfico e de ferramentas gráficas para que mesmo usuários casuais de computador fossem capazes de usar o sistema.

KM: Já faz um tempo desde que parei para usar alguma das distribuições Linux mais badaladas, só conheço as versões mais recentes de passagem. No entanto, à primeira vista, para o usuário final, não parecem haver muitas diferenças. Rodamos o KDE, temos um desktop funcional, com suporte 3D, som, WiFi e quase os mesmos programas de código aberto, como Firefox, OpenOffice.org, K3B etc.

O ponto em que os usuários começariam a notar a diferença seria no gerenciamento de pacotes. Ao invés de um grande programa de gerenciamento, ou de um repositório, os usuários baixariam um único arquivo .pbi (Firefox3.0.1.pbi, por exemplo). Clicando duas vezes sobre ele, o Firefox será instalado em seu próprio diretório, como /Programs/Firefox3.0.1. Sem confusão, sem bagunça, simplesmente funciona como deveria.

Outra área na qual os usuários mais experientes vão notar uma diferença é ao explorar o prompt de comandos. Debaixo do capô, o PC-BSD é 100% FreeBSD. Não é um fork. Isso quer dizer que os usuários mais experientes podem usar os sistemas de pacotes e ports do FreeBSD, recompilar kernels e configurar o sistema da maneira que acharem melhor.

KM: Nós nos comunicamos com os desenvolvedores do DesktopBSD de tempos em tempos. A maioria dos nossos objetivos é parecida, exceto no que concerne ao gerenciamento de pacotes. O DesktopBSD oferece uma ótima ferramenta gráfica que permite aos usuários instalar software pelos sistemas de ports e pacotes do FreeBSD. Isso apela mais aos usuários técnicos do desktop, enquanto o PC-BSD tenta se focar no sistema PBI, que nós achamos que permite a *qualquer* usuário, esteja ele vindo do Windows ou do Mac OS X, mudar para o nosso sistema e sentir-se produtivo imediatamente.

KM: O PC-BSD 7 é um grande passo à frente. Em primeiro lugar, mudamos a numeração das versões para refletir a versão do FreeBSD básico, e é por isso que pulamos do PC-BSD 1.5 para o PC-BSD 7. Esse é nosso primeiro lançamento baseado no FreeBSD 7, que inclui suporte muito melhorado a drivers, suporte a WiFi, um suporte bem melhor a SMP com o escalonador ULE e mais. Também mudamos para o KDE 4.1 e portamos nosso sistema PBI e as ferramentas gráficas para o Qt 4.x ao mesmo tempo. A versão 7 oferecerá diversos métodos novos de instalação, incluindo os CDs de 1 a 3, um DVD, uma imagem USB e uma imagem em CD/USB apenas para boot, que permite realizar a instalação pela rede local ou pela internet. Isso deve tornar a instalação do PC-BSD mais fácil do que nunca, com opções para todos.

KM: Essa foi uma decisão difícil, mas achamos que valeu à pena. Como essa versão já é um grande salto para o FreeBSD 7, vai valer à pena a longo prazo. Agora que todas as nossas ferramentas são baseadas no KDE4/Qt4, podemos simplesmente liberar patches e atualizações online para o KDE 4.x rapidamente, o que não é um salto tão grande quanto seria lançarmos o sistema com o KDE 3.5 para tentarmos mudar para o KDE 4 poucos meses depois. A essa altura, não pretendemos incluir o KDE 3.5.9 na instalação padrão, mas os usuários técnicos dispostos a fazê-lo por meio dos ports após a instalação do sistema são bem-vindos (os dois KDEs podem ser instalados ao mesmo tempo).

KM: Na verdade, estamos oferecendo quatro sistemas de arquivos, incluindo o ZFS, que pode ser habilitado durante o boot de instalação. Mas o ZFS é voltado para instalações de servidores e provavelmente não será visto nos desktops com tanta freqüência devido às suas altas exigências em termos de hardware e RAM. Na área do desktop, decidimos oferecer algumas opções desta vez. Antes o padrão era UFS2 + Soft Updates, e isso permanece nessa versão. Isso aconteceu porque durante a fase de testes ele se mostrou a escolha mais confiável e consistente para um desktop. O UFS com Journaling também é uma boa escolha para o desktop, já que ele elimina a necessidade de rodar um “fsck” após uma falta de luz, dentre outras coisas.

KM: Ainda estou trabalhando no sistema de atualizações e espero fazer com que ele permita atualizar do PC-BSD 1.5.x para o 7. Mas eu recomendaria fortemente uma instalação limpa, já que há muitas diferenças entre essa versão e a outra, e a maioria dos programas instalados no PC-BSD 1.x (baseado no FreeBSD 6) provavelmente não terá compatibilidade binária com o 7.

KM: O código entrou em freeze na segunda, dia 25, e na semana que vem devemos lançar um beta público. Depois disso, se não encontrarmos bugs mais graves, devemos fazer o lançamento entre o início e o meio de setembro.