As razões:
Vários utilitários de programação como sistemas de controle de versão de arquivos (Cvs, Subversion), controle de requisitos (Trac, Mantis), servidores http, ftp, etc. estão disponíveis para um sistema operacional específico ou são mais fáceis de implantar em um servidor dedicado.
Tratando-se de servidor, Linux é praticamente inquestionável. Porém, nem sempre seu ambiente de trabalho se restringe a Linux. Um caso comum seria um desenvolvedor Delphi que obrigatoriamente usa Windows mas que também desenvolve ou tem que testar seus projetos em outras plataformas.
Usar boas ferramentas durante o ciclo de desenvolvimento de um sistema, seja ele de qualquer natureza, é comprovadamente uma forma de garantir controle e organização que consequentemente resultam em qualidade e aceleram o ciclo de desenvolvimento. Mesmo pra quem não trabalha em equipe, um sistema de controle de versão por exemplo é uma ótima ferramenta. Ele mantém o histórico do que você estava fazendo. Com ele você pode por exemplo voltar atrás após descobrir que a última alteração em um arquivo provocou um erro no sistema.
No mais, alguns tipos de aplicações necessitam de servidores para serem testadas/desenvolvidas. Um exemplo bem comum é a criação de aplicações web.
A idéia:
Partindo destas necessidades e razões tive a idéia de utilizar o conceito de máquinas virtuais para dividir um só ambiente de trabalho em dois. Em outras palavras, criar um servidor virtual embutido no meu ambiente de trabalho.
Para tal tarefa utilizei o Qemu.
Criei o disco virtual (arquivo) em uma partição do tipo FAT32 e instalei um servidor linux slackware 10.2. Nada complicado, pois existem artigos aos montes na internet sobre a instalação, tanto do qemu quanto do slackware.
Criei os discos em uma partição FAT32 para ser possível abrir o servidor quando estiver no Linux ou no Windows. Assim, sempre tenho a mão o servidor, ou seja, todos meus projetos.
Também dividi a instalação em três discos virtuais (head.img, home.img swap.img). Um para o /, outro para o swap e outro para o /home. Isso falicita na hora de fazer backup pois basta fazer do home.img. Para o swap.img basta uns 30 MB pois se precisar de mais memória você pode alterar na chamada do qemu.
O maior problema foi conseguir fazer o sistema hospedeiro ver o servidor virtual como outra máquina na rede. Existe suporte a utilização de TAP (uma placa de rede virtual) através do openVPN mas não obtive sucesso. Talvez porque envolva uma coisinha complicada de redes: bridge. Tentei por vários dias mas nada! :(. O VMWare faz isso automáticamente. Se alguém já conseguiu montar, por favor, me conte. Consegui fazer o servidor virtual ver o hospedeiro, mas não o contrário.
A solução que encontrei foi redirecionar as portas da máquina local para o servidor remoto através da opção --redir do Qemu. Assim, quando abro uma conexão na porta 21 (ftp) em localhost, ou seja, na máquina local, quem responde é o servidor virtual. Fica legal e bem transparente.
As opções a partir destes princípios são tantas que só vai depender de sua necessidade. Eu uso servidor http (porta 80), ftp (porta 21), Subversion, Trac, Python, Php e agora vou tentar montar um diretório ldap.
No Windows ficou mais lento que no Linux. Mas não consegui encontrar uma versão compilada do kqemu (modulo acelerador) para Windows, então, um pouco da diferença é esta. Mas a velocidade em geral é aceitável. No Linux fica quase transparente, até pra compilação de programas.
Minha máquina é um AMD XP 2400 com apenas 256 MB de memória.
No Windows ficou pedindo mais memória virtual :)
No Linux cheguei a chamar o qemu com 128 MB de memória com o Kde aberto e nem deu diferença, incrível :O (Nem usou swap)
De qualquer forma, não precisou de mais de 32MB pra funcionar. Umas das vantagens do Slackware como servidor. Você inicia somente o que precisa mesmo. É claro que o ambiente gráfico ficou de fora, afinal é um servidor.
Veja só o resultado da brincadeira.
