Primeiro, vamos começar com as instalações.

Lembrando que se trata de um computador com recursos limitados, eu vou instalar as aplicações e fazer alterações em todas elas, para que rodem de forma satisfatória nesse ambiente.

Porém, se você tem um computador com mais recursos, não precisa seguir esse artigo à risca, você pode instalar as aplicações e não aplicar as alterações que eu vou fazer, porque em matéria de instalação e bem direto apt-get install e já era!!!

Se você está no mesmo barco que eu e tem um computador limitado, por favor, procure fugir das suas distros preferidas e aventure-se em um mundo, talvez, desconhecido.

Eu sei que existe uma multidão de usuários do Ubuntu lendo esse artigo e eu digo sem ofensas, o Ubuntu é muito carregado para esse ambiente de 128 MB, você pode até dizer que vai rodar sem o X11, mas acredite, mesmo sem o X11, se você instalar um Ubuntu aqui, você não vai ter o desempenho total que você poderia ter com outra distro. Por favor, não atire a primeira pedra sem antes testar o que eu estou falando.

Antes de decidir qual GNU/Linux usar nesse computador, eu fiz o teste com três distros; eu tentei instalar mais que três, porém, sempre esbarrava em alguma coisa que não funcionava, monitor, mouse, rede sem fio, etc. As únicas três distros que rodaram sem problemas, foram Debian Squeeze, CrunchBang e ArchBang.

Minha opinião final é a seguinte:

• Debian :: apesar de rodar nesse ambiente, não é o mais apropriado se você não o conhece, pois ele vai precisar de algumas configurações extras.
• CrunchBang :: excelente para esse ambiente, é uma alternativa para quem vem da família do Ubuntu, apesar do Crunch não ser baseado no Ubuntu, ele é baseado no pai do Ubuntu, o Debian. Porém, ele é mais pré-configurado que o Debian.
• ArchBang :: se você não tem medo de experimentar algo novo e quer o máximo de proveito da sua máquina, Arch é o sistema para você.

Caso contrário, você prefere não se aventurar, quer uma coisa mais segura no sentido que você sabe o que está fazendo e quer evitar recorrer ao Google toda vez que esbarrar em problemas, mantenha-se com o Crunch.

Eu vou explicar à maneira do CrunchBang, bem que eu gostaria de ensinar à maneira Arch, porém, como o Arch é um mundo novo para mim e eu estou ensinando, é melhor evitar falar besteira. Eu vou explicar a maneira que eu já sei.

Caso alguém queira comentar a respeito do Arch, os problemas que eu enfrentei foram somente dois: um, eu não consegui converter o script de inicialização para o systemd para fazer da aplicação um serviço do sistema e, o segundo problema, é que ao fazer um pacman -Syyu, eu quebrei o meu sistema. :(

Mas uma coisa é certa, tudo o que eu estou fazendo aqui, é possível ser feito em todas as distros, caso você tenha um Gentoo, Arch, Sabayon, etc, você sabe como converter os scripts de inicialização de serviços para systemd, vá em frente. Se alguma aplicação aqui indicada, não tem um binário no seu repositório, veja o site do criador do software, lá você vai ter acesso ao código-fonte e pode compilar.

Para instalar o CrunchBang, siga as instruções pelo nosso amigo VOLeiro "Removido". Sério, é esse nome mesmo, e de acordo com o perfil dele, ele tem 113 anos de experiência. :)

• CrunchBang Backported - Instalação e Configuração [Artigo]

MediaTomb - é o nosso programa principal que vai fazer o Stream do conteúdo na rede, portanto, todo o poder da RAM vai ser exclusivo dele, não vamos limitar ele, correto?

ERRADO, ele é sim a peça mais importante, porém, vamos limitá-lo. Nada de transcoding ou escaneamento por inodes, no caso de você ter mais de 1000 mídias no seu HD, aposente o SQLite e use o MySQL. Eu sei que tem gente que vai dizer que isso não faz sentido, porém, isso faz sim.

MySQL - o banco de dados MySQL usa mais recursos que o SQLite em base de dados com poucas entradas, para tal, o SQLite é melhor, porém, se você tem uma base de dados que passam de 1000 entradas, os valore se invertem e o SQLite começa a empacar. Assim sendo, vamos usar o MySQL com recursos reduzidos.

Eu sei que o MySQL é mais cheio de bugs que o SQLite, porém, os dados armazenados serão links para mídia, ou seja, se um ficar errado, é só recarregar a database e pronto, links serão corrigidos.

Apache - o mais experiente dos servidores. Nessa escolha, você pode até dizer que eu falhei, pois existem forks do Apache que são melhores. Alguns podem até citar nomes, como Cherokee, lighttpd, thttpd, etc. Porém, aqui, eu preferi uma tática mais segura.

Já que eu não conheço outro servidor HTTP, eu preferi me manter seguro no que eu já conheço e não me aventurar, assim sendo, eu vou reduzir os recursos do Apache também.

Como você pode ver pela explicação que eu dou, esse artigo e bem modulado, quer dizer, tem coisas que eu vou falar aqui que podem ser ignoradas e outras que podem ser aprimoradas, se você encontrar alguma configuração que faz o trabalho melhor que o que eu apresento aqui, por favor, poste seu comentário e enriqueça o artigo.