Contras:
- Ubuntu 9.10: Ainda tem muitas interfaces confusas como a de gestão de redes. Podia ser melhor;
- Windows 7: para você administrar o Windows você tem que abrir muitas janelas. Tantas janelas quanto forem necessárias para se perder.

Conclusão:
- Ubuntu 9.10: Pagaria R$ 50,00 pelo Ubuntu Revolução 2.0;
- Windows 7: Pagaria R$ 50,00 por um Windows Revolução 2.0;

@André Luis Pereira e @russo

Esta empresa que falei acima possuia 250 servidores com Windows e 300 com Linux na época em que trabalhei, de várias marcas (mas principalmente da IBM e da Dell). A empresa tinha uma larga tradição de usar Windows nos seus servidores e, ao migrar para Linux, foi natural para eles deixarem em várias máquinas um login gráfico por default (faço uma comparação: o Windows Server 2008 possui um modo de instalação chamado “Server Core”, em que só é instalado um “modo texto” do Windows, com o PowerShell interagindo com o usuário. Não é porque o usuário comum do Windows Server 2008 prefere utilizá-lo no modo gráfico que ele seja incompetente).

E, para todos os efeitos, vários utilitários de performance e manutenção do BD Oracle, escritos em Java, funcionam desavergonhadamente na interface gráfica).

E com isso prejudicam a grande maioria.

Desde que tenha qualidade técnica, não vejo problema. O meu problema foi com a adoção de PulseAudio pelas distribuições. Pessoalmente eu considero uma abordagem de boa qualidade técnica com relação a áudio a abordagem que o pessoal do FreeBSD vem utilizando.

Essa do FreeBSD eu estou por fora, você poderia me informar sobre ela?
E manda o seu e-mail para mim, na minha página de usuário do vivaolinux você pode enviar uma mensagem para mim.

Eu sei disso, mas já que será a comunidade a verdadeiramente contribuir, por que não contribuir para alsa de uma vez?

Desde que tenha qualidade técnica, não vejo problema. O meu problema foi com a adoção de PulseAudio pelas distribuições. Pessoalmente eu considero uma abordagem de boa qualidade técnica com relação a áudio a abordagem que o pessoal do FreeBSD vem utilizando.

O negócio é que mesmo que versões novas possam sofrer uma mudança de licença, a licença das versões que já foram lançadas não pode ser alterada retroativamente, então nada impede que a comunidade continue esses projetos por conta própria nesses casos, mesmo sem apoio do copyright holder original. No caso do OSS, a comunidade ainda poderia escolher qual licença utilizar, GPL, BSD ou CDDL.

Eu sei disso, mas já que será a comunidade a verdadeiramente contribuir, por que não contribuir para alsa de uma vez?

E é BSD, quando for mais usado ou dominar, o que garante que a 4Front vai continuar disponibilizando as modificações livremente na versão de licença GPL?

Eles são os donos do copyright, então eles realmente podem mudar a licença quando quiserem. Mas o mesmo vale para MySQL, VirtualBox, Qt e outros projetos que tenham um único copyright holder.

Isso não acontece com o Linux por exemplo, pois o Linux é constituído de várias partes, cuja posse pertence a diferentes indivíduos ou empresas, então para mudar a licença, precisaria de consenso entre todas as partes.

O negócio é que mesmo que versões novas possam sofrer uma mudança de licença, a licença das versões que já foram lançadas não pode ser alterada retroativamente, então nada impede que a comunidade continue esses projetos por conta própria nesses casos, mesmo sem apoio do copyright holder original. No caso do OSS, a comunidade ainda poderia escolher qual licença utilizar, GPL, BSD ou CDDL.

Assim como o MySQL, por exemplo? OK, não dá pra comparar a Sun com a 4front (em tamanho), mas o fato de ser controlado por uma empresa a princípio não seria problema para um código que está disponível tanto sob GPL como sob BSD.

Eu também não me sinto confortável em usar o OSS. Eu gosto do Qt, mas o OSS … .
E é BSD, quando for mais usado ou dominar, o que garante que a 4Front vai continuar disponibilizando as modificações livremente na versão de licença GPL?

O OSS mudou de licença várias vezes e por isso o alsa foi criado. Não foi proposital, mas agora voltar para o OSS e jogar o alsa fora seria tarde demais, além do desenvolvimento do OSS ser basicamente controlado por uma empresa apenas.

Assim como o MySQL, por exemplo? OK, não dá pra comparar a Sun com a 4front (em tamanho), mas o fato de ser controlado por uma empresa a princípio não seria problema para um código que está disponível tanto sob GPL como sob BSD.

mas não é muito fácil de setar o dmix.

As distribuições poderiam vir com ele já setado. Assim como elas já vem com várias coisas preconfiguradas, por que não vir com isso preconfigurado?

Além disso, o pulseaudio pode ser desligado facilmente. Não sei se no ubuntu é fácil mas em outras é.

Das duas distribuições com PulseAudio que testei (Mandriva e Ubuntu), no Mandriva era fácil desabilitar (bastava clicar em um botão do painel de controle).

No Ubuntu era bastante difícil – encontrei algumas dicas na web, mas não funcionavam. No fim acabei tendo de dar um “chmod 0″ no executável do pulseaudio, aí sim ele parou de carregar. É incrível como eles colocaram hooks para carregar o pulseaudio em cada milimetro do sistema.

Mas o ponto também não é esse. O ponto é que o PulseAudio é mais um fator que agrega peso desnecessário e complexidade desnecessária a algumas distribuições hoje em dia, existindo ainda risco de começar uma dependência tecnológica dele caso as coisas continuem como estão. É claro que o PulseAudio não é o único desses fatores, mas certamente é um deles, e na minha opinião foi um erro das distribuições utilizá-lo por padrão (não vejo problema em fornecê-lo como opção) – não era necessário.

http://en.wikipedia.org/wiki/Open_Sound_System#Free.2C_proprietary.2C_free

O alsa faz mixagem de sons sozinho quando a placa não tem suporte a mixagem por hardware (coisa que não acontece na maioria das placas de som onboard baratas de hoje)

http://alsa.opensrc.org/index.php/Hardware_mixing,_software_mixing
http://en.wikipedia.org/wiki/Advanced_Linux_Sound_Architecture

mas não é muito fácil de setar o dmix.

Além disso, o pulseaudio pode ser desligado facilmente. Não sei se no ubuntu é fácil mas em outras é.

* Controle de volume por aplicativo

O OSS faz isso.

* Uma arquitetura de plugins expansível com suporte para módulos

A alsa-libs tem uma arquitetura de plugins.

* Compatibilidade com muitas aplicações populares de áudio

Assim como OSS e ALSA?

* Suporte para múltiplas fontes de áudio e sumidouros

Gstreamer?

* Low-latência operante e suporte a medição de latência

Usando ALSA ou OSS, a latência é bem menor, pois tem uma camada a menos.

* Um zero-cópia memória arquitetura processador para a eficiência dos recursos

Google Translator?

* Uma interface de linha de comando com capacidades de scripting

Todos tem isso.

* Um daemon de som com capacidades de reconfiguração por linha de comando

Mesma coisa do item anterior?

* Built-in amostra conversão e capacidade de reamostragem

O OSS faz isso. O ALSA configurado corretamente, também.

* A capacidade de combinar várias placas de som em uma

Não possuo conhecimento de algo nativo no ALSA ou OSS para isso, mas há ferramentas externas para isso.

* A capacidade de sincronizar múltiplos fluxos de reprodução

OSS ou ALSA com dmix fazem isso.

Se as placas de som de PCs atuais pudessem mixar por hardware várias streams de som e fossem homogêneas, talvez não precisássemos mesmo de nenhum servidor de áudio, mas já que precisamos, pelo menos o pulseaudio é independente do ambiente gráfico (KDE, gnome, etc) e de sistema operacional, ao contrário de outras soluções passadas.

Não precisamos de um servidor de áudio para fazer mixagem. O OSS faz isso nativamente, e o ALSA faz isso caso o dmix esteja ativado.

Tem até esse tutorial abaixo, mas é muito empenho pra se tocar um BD.

https://help.ubuntu.com/community/RestrictedFormats/BluRayAndHDDVD

Se estiver engando e já tiver algo nem que seja comercial, agradeço qquer HELP.

Tenho nesse PC um dualboot, só pra tocar os BD, tenho uns 10 player diferentes, e todos funcionam perfeitamente.

http://pt.wikipedia.org/wiki/PulseAudio

As principais características do Pulseaudio incluem:

* Controle de volume por aplicativo
* Uma arquitetura de plugins expansível com suporte para módulos
* Compatibilidade com muitas aplicações populares de áudio
* Suporte para múltiplas fontes de áudio e sumidouros
* Low-latência operante e suporte a medição de latência
* Um zero-cópia memória arquitetura processador para a eficiência dos recursos
* Uma interface de linha de comando com capacidades de scripting
* Um daemon de som com capacidades de reconfiguração por linha de comando
* Built-in amostra conversão e capacidade de reamostragem
* A capacidade de combinar várias placas de som em uma
* A capacidade de sincronizar múltiplos fluxos de reprodução

Se as placas de som de PCs atuais pudessem mixar por hardware várias streams de som e fossem homogêneas, talvez não precisássemos mesmo de nenhum servidor de áudio, mas já que precisamos, pelo menos o pulseaudio é independente do ambiente gráfico (KDE, gnome, etc) e de sistema operacional, ao contrário de outras soluções passadas.

Ele só não está 100% maduro e só dá problemas em alguns hardwares mas nos que funciona é bem estável. Os aplicativos de som antigos é que não estão preparados para ele e é isso que causa a má impressão para certas pessoas.

Estou feliz por ter me liberado por completo do domínio da Microsoft já há quase 10 anos, mas não faria um hype desses com argumentos tão toscos e falsos…