VirtualBox 3.0: Suporte a multiprocessadores

O projeto VirtualBox – patrocinado pela Sun Microsystems – lançou uma versão beta do que será seu software de virtualização para a arquitetura x86, o VirtualBox 3.0

Nesta versão, é incluso o xVM que oferece suporte a multiprocessamento simétrico aos hosts convidados com até 32 CPUs virtuais, bem como o suporte a aceleração OpenGL 2.0 por padrão, entre outras funcionalidades.

Esta nova versão, é orientada tanto a servidores, quanto a desktops e sistemas embarcados com base em plataformas x86, permitindo aos usuários do VirtualBox a executarem seus programas favoritos.
O release beta 1 da versão 3.0, é considerada “bleeding edge” (ou seja, não livre de bugs e crashs”), e o projeto informa para termos cautela em seu uso. As novas funcionalidades que estão presentes e serão inclusas na versão final, são:

- Suporte para até 32 processadores virtuais (necessita de Intel VT e AMD-V)
- Suporte a aplicações e jogos Direct3D 8/9 (experimental)
- Suporte ao OpenGL 2.0 (hospedes Windows, Linux e Solaris)
- Novo suporte a USB com maiores velocidades assincronas
- Correções ao compilar os módulos para o Kernel Linux
- Várias correções e novidades relacionadas a VMM, GUI, VHD, entre outros.

Em abril deste ano (2009), foi liberada a versão 2.2, que adicionou suporte ao Formato de Virtualização Aberta (OVF), permitindo aos usuários criarem máquinas virtuais para posteriormente exportá-las para um ambiente de desenvolvimento e produção. O VirtualBox 2.2, acrescentou também, melhorias no suporte ao Hypervisor, trazendo otimizações como aceleração de gráficos 3D’s para ambientes Linux e Solaris. Em dezembro de 2008, ao liberar a versão 2,1, foi apresentados melhoras no suporte a 64bits, aceleração 3D, e criação de redes mais simplificada em ambientes Linux e Windows, além de virtualização de hardware em Macintoshs como suporte completo a VMDK/VHD inclusos na liberação.

O VirtualBox é um software open source e livre, empacotado, sendo uma solução profissional para virtualização. Na verdade, ele não é totalmente open source, mas muito do VirtualBox, foi liberado sob a GPL em 2007, e os seus desenvolvedores, oferecem o VirtualBox OSE (edição em código aberto), como distribuição do código fonte. Sendo estes, distribuídos por muitos projetos e distribuições linux.

Um futuro incerto no Oracle

Após o lançamento da versão 2.2 em abril, a Sun aceitou uma oferta da gigante do mercado de banco de dados (Oracle) para adquirir a empresa, negociada a 7,4 bilhões de dólares. Naquele momento, os analistas previam que a Oracle, cedo ou tarde, poderia abandonar a maioria dos projetos de código aberto da Sun.
Isso pode ser verdadeiramente especial no caso do VirtualBox, uma vez que a Oracle, também adiquiriu um peso pesado na área de virtualização em maio, a Virtual Iron’s; empresa especializada em virtualização com base no Xen. Com isto, a empresa já oferece seu próprio produto de software de virtualização tendo como base o Xen, o Oracle Enterprise VM. Entretanto, a Oracle também, terá de encontrar um papel para o Sun xVM Server e o Solaris Containers (soluções e produtos para este nicho do mercado: virtualização)

Disponibilidade:

A primeira versão beta do VirtualBox 3.0, está agora, disponível para download gratuíto. Mais informações e links para download podem ser encontradas aqui.

Fontes: http://www.desktoplinux.com/news/NS7451157436.html?kc=rss

AMD e Seagate apresentam padrão SATA 6gbps

AMD e Seagate demonstraram em Nova Orleans a próxima geração Serial ATA. As novas especificações, SATA 6Gbps, irá oferecer o dobro de banda existente no padrão 3Gbps Serial ATA. Além de melhorias na largura de banda, o SATA 6Gbps oferecerá plena compatibilidade com a tecnologia anterior, tais como as normas 3Gbps e 1.5Gbps, incluindo as mesmas especificações para os conectores e cabos utilizados.

A AMD e Seagate tem trabalhado extensivamente no fine-tuning de streaming de dados para levar tais características aos usuários que esperam para ver melhorias significativas nesta área ao longo do modelo 3Gbps incluindo a implementação do NCQ em novas unidades. Além disso, o novo esquema de gestão de energia permite que a plataforma possa, instantaneamente, ligar e desligar a interface SATA 6Gbps, ao contrário do modelo de gestão dos atuais sistemas SATA.

Atualmente, os  discos rígidos Serial ATA presentes no mercado,  possuem as taxas de transferência com média de pico em torno de 120MB/s, mas estas taxas de leituras não são mantidas; nas transferências da unidade de buffer (cache) é possível chegar a 288MB/s. Nestes modelos, os caches estão em torno de 32MB com alguns modelos a 64MB, isso irá colocar ainda mais pressão sobre o padrão atual. De fato, a unidade (7.200,12), que a Seagate demonstrou (Barracuda), tem hoje, médias de leituras chegando a 589MB/s.

No entanto, quem irá se beneficiar de verdade com o novo padrão 6Gbps serão as unidades baseadas no padrão flash. Já existe hoje, drives SSD como o Intel X25-E sustentado leitura e escrita com taxas de 200MB/s; com a nova unidade, projeta para os próximos meses deste ano, provavelmente irá acabar por saturar o atual mercado que trabalham com as interfaces de 3Gbps. Os primeiros clientes que Seagate e a AMD pensam em apresentar esta nova tecnologia são os entusiastas (mercado high end), em seguida o mercado low-end ( \o/ ), chegando aos usuários que utilizam stream vídeos de alta definição ou que trabalham com intesivo processamento gráfico e multimidia.

Vale lembrar que as empresas manifestaram que este não é um produto oficial lançado. Isso acontecerá futuramente neste ano, quando AMD anunciará formalmente a sua próxima geração de chipset, mostrando total suporte ao padrão e normas do SATA 6Gbps. Ambas as companhias disseram-nos que os produtos SATA 6Gbps poderão chegar antes do final de 2009, mas nada foi declarado oficialmente.

Fonte: http://www.anandtech.com/weblog/showpost.aspx?i=580

09 de Março de 2009

DWA-110 com módulo nativo

Após alguns serviços feito em um notebook e configuração de um modem 3g no Mac OS X de um amigo, fui presenteado com um adaptador Wireless, D-Link, modelo DWA-110.

Aqui em casa, meu irmão já possui um mesmo adaptador deste, em que também vinha utilizando no Windows XP (a um bom tempo) e também no Windows Vista 32 bits através de uma certa gambiarra com os drivers presentes no CD, além, também do Mac OS X. Passou um certo período, encontrei o driver do mesmo para o Windows Vista 64 bits pelo qual, instalado e configurado, vem funcionando muito bem nos sistemas dele.

Eu, porém, havia deixado o adaptador meio que de lado após uma tentativa frustrada de vê-lo à funcionar no Linux através do ndiswrapper em que “gambiarra” é pouco pelo que é feito com as “dlls” e firmware presente nos drivers for Windows.

Foi que então, que de tanto desplugar o cabo de rede conectado ao PC pra testar ou fazer download de softwares e atualizações em outros computadores que faço manutenções pra ganhar algum a mais… acabei percebendo que preciso refazer a clipagem dele (mais sempre esqueço de trazer os clips e o alicate pra fazer o serviço)… com isso, estava sem nada a fazer (mesmo com a rede funcionando) e resolvi procurar informações para colocar esse D-Link DWA-110 a funcionar no Linux de uma vez por todas.

E aqui, começou minha aventura.

Fui direto no AUR procurar pelo módulo rt73 (descobri que era este módulo, durante minha primeira tentativa de instalação com o Ndiswrapper)… e para minha grata surpresa, lá estavam alguns pacotes relacionados ao conteúdo da minha busca. Também, por motivo de informação, tal adaptador utiliza-se de chips Ralink.

Fiz o download de dois deles:

1° – Módulo: http://aur.archlinux.org/packages.php?ID=15377

2° – Perfil de configuração para o netcfg2: http://aur.archlinux.org/packages.php?ID=17224

O primeiro pacote, é o módulo do kernel que será responsável pelo funcionamento de seu dispositivo Wireless.

Para montar o pacote contendo o módulo, é necessário instalar o pacote rt2×00-rt71w-fw presente no repositório core.

Instalado esta dependência, é só proceder com a compilação do módulo/pacote, e após isto, instalá-lo com um pacman -U rt73-k2wrlz-3.0.2-2-x86_64.pkg.tar.gz - Verifique a versão do pacote e arquitetura de seu Arch Linux no momento de instalação.

O 2º pacote a se montar, contém os arquivos (criado e mantido pelo thotypous – Paulo Matias) que são responsáveis para o correto uso do módulo rt73 pelo netcfg, servindo então, como arquivo de configuração de perfil de conexão. Também, após feito, deverá ser instalado com um pacman -U netcfg-rt73-0.1-1-x86_64.pkg.tar.gz.

Caso precise de informações dos passos corretos para a compilação de pacotes do AUR, queira por gentileza ler este artigo no Wiki do Arch Linux.

Configurações:

Agora que já temos o módulo e os arquivos de configuração para o netcfg, vamos então, configurar o sistema e colocar o adaptador a funcionar.

Após plugado o dispositivo, é preciso “derrubar” o módulo rt73usb e subir o módulo correto (rt73), caso contrário, haverá conflito e o adaptador não irá funcionar.

Um simples rmmod rt73usb e na sequência um modprobe rt73, soluciona temporariamente este fato.

Para automatizar este processo, simplesmente  editamos o /etc/rc.conf fazendo as seguintes alterações:

MOD_BLACKLIST=(rt73usb)
MODULES=(... ... rt73 ... ...)

Dica de Ubermensch nos comentários no link do pacote do rt73-k2wrlz.

Também, é preciso criar um perfil contendo as informações de sua rede sem fio. Para isso, é necessário criar o arquivo (ou arquivos se você se conecta em mais de uma rede sem fio) em /etc/network.d/

Este perfil, deve seguir o modelo que o netcfg precisa… informações a respeito de como proceder, podem ser vistas aqui.

Em meu caso específico, criei o arquivo /etc/network.d/wep, com as configurações referentes a minha rede. Reparem no conteúdo do arquivo:

CONNECTION=”wirelessral“
DESCRIPTION=”A wep encrypted wireless connection using static ip”
INTERFACE=rausb0
SCAN=”yes”
SECURITY=”wep”
ESSID=”nomedarede“
KEY=”1234567890“
IP=”static”
IFOPTS=”10.0.0.11 netmask 255.255.255.0 broadcast 10.0.0.255″
GATEWAY=”10.0.0.1″
DNS1=10.0.0.1
DNS2=200.204.0.10
DNS3=200.204.0.138
DNS4=208.67.222.222
DNS5=208.67.220.220

Como veêm, utilizo um ip fixo declarado em IP=”static”; a interface de rede é a rausb0 verificado através do comando iwconfig; utilizo uma chave wep e não wpa; e em CONNECTION, é usado o perfil de configuração instalado do pacote netcfg-rt73 do thotypous. Siga este modelo para uma conexão wi-fi com ip fixo ou utilize as dicas no Wiki do Arch Linux Brasil para fazer uma configuração baseada em dhcp:

http://wiki.archlinux-br.org/Perfis_de_Rede

Neste momento, já é possível conectar a rede através do Access Point e se ouver uma conexão a internet disponível, navegar e fazer tudo o que você faria normalmente em uma rede cabeada. Para isso, digite no terminal, um dos seguintes comandos para conseguir a conexão:

netcfg-auto-wireless rausb0

ou

netcfg2 wep

O primeiro, escaneará o ambiente a procura de uma rede para que ele possa se conectar… havendo mais de uma, ele conectará na primeira que encontrar.

O segundo comando, buscará pelo sinal do perfil de rede em /etc/network.d/wep configurada anteriormente por nós, encontrando o sinal, é feita  a conexão e estaremos prontos para aproveitar dos serviços disponíveis na rede.

Pronto.. agora é só navegar e aproveitar?

Sim e não! Depois de pronto as configurações aqui apresentadas, você estará navegando se as seguiu corretamente e tendo em vista de que este artigo é voltado para o adaptador DWA-110, fabricado pela D-Link… com certeza estará navegando.

O detalhe é que toda vez que reiniciar ou ligar seu computador, você terá, como root, realizar a conexão manualmente. Para evitar de um usuário ter que digitar netcfg2 wep toda vez que ligar seu computador ou outros comandos necessários ao funcionamento do sistema, existe o /etc/rc.conf para deixar automático isto.

Como modelo, segue o link de como está o meu rc.conf

Analisem que segui em partes o que a página do Wiki recomenda e o categoricamente o que o user do AUR (Ubermensch) escreveu. (Linhas 38 e 39 do arquivo)

Não utilizo mais a eth0 e nem mais a eth1 por enquanto. Apesar de a qualquer momento, eu possa voltar a utilizá-la caso queira, basta que se descomente a linha 62 e/ou 63, onde está as informações concernente ao número ip, mascara de rede.

Atenção especial, á linha 65, onde, não se encontram informações a eth0 ou eth1, contendo apenas a interface que utilizo agora, onde, diferentemente das interfaces cabeadas, é colocado o nome do perfil da wirelless:

INTERFACES=(lo wep)

Outro detalhe é que não utilizei a string“auto-wireless rausb0″ na NETWORKS, conforme dizia a wiki (Linha 84), bastou apenas…

NETWORKS=(wep)

Além disso, é preciso adicionar a Sessão DAEMON, o daemon net-profiles, conforme instruções do Wiki (Linha93)

Depois deste aprendizado, fiquei tranquilo e quase que totalmente satisfeito com relação a Wireless em minha residência, pois, é só ligar o micro, que já estou conectado!

Outras opções:

Uma parte do “quase satisfeito”, se dá, ao fato de eu estar procurando um software para gerenciar “outras” conexões sem fio com uma maior simplicidade… (tipo.. usar a net do vizinho.. xD.. rss).

Estava interessado no kwifimanager, mais ele ainda não está portado para o KDE 4 e acredito que um outro projeto possa entrar no lugar dele nos próximo release do KDE.

Outro software que li maravilhas em blogs e na grande rede, foi o wifi-radar (que está disponível no repositório community, meu maior problema com ele, está no fato dele utilizar GTK como biblioteca gráfica (mão na roda pra quem usa Gnome… não é meu caso) e eu não querer mais um “alienigena gráfico” por aqui… Já basta o Firefox! – Quem sabe se a necessidade for maior, isso me obrigue a usá-lo?

Por outro lado, existe o Wireless Assistant (wlassistant), onde existe uma GUI em QT3 (?).. – é QT3 – .. Este software, possui ferramentas para detectação e configuração de redes sem fio presentes em um determinado ambiente. Até gostei do software, mais poxa – mais uma biblioteca gráfica é triste.

Também procurei algum “applet” que poderia ser usado no system tray ou no desktop como plasmoid, em que eu possa ver a qual andas o sinal da rede, acabei por interessar-me pelo Plasma Wifi 0.5… ainda não consegui colocá-lo a funcionar por algumas mudanças nos arquivos e PATH’s no KDE 4.2… em breve, em breve.

Acho que vou de Arch Assistant mesmo.

É isso ai.. gostei de eliminar cabos.

Informações:

http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html

http://wiki.archlinux-br.org/Perfis_de_Rede

http://homepages.tu-darmstadt.de/~p_larbig/wlan/

http://aur.archlinux.org/packages.php?ID=15377

http://aur.archlinux.org/packages.php?ID=17224

http://www.ralinktech.com.tw/

http://paste.archlinux-br.org/941

Google Ghrome para Linux utilizará GTK+

Uma das principais críticas que o navegador web Google Chrome tem recebido até o momento, é por ainda não estar disponível para qualquer outra plataforma se não o Windows. O Google prometeu entregar Chrome para Mac OS X e Linux, mas como nem tudo ocorre como o esperado, está um tanto quanto difícil de se desenvolver, antecipando a interface do Google Chrome, explicou Ben Goodgear em um e-mail. Também foi revelado que a versão do Chrome para Linux, utilizará a toolkit Gtk +.

A decisão de utilizar uma toolkit nativa para gerar a interface do usuário em cada plataforma tem feito tudo ficar mais difícil e demorado para se entregar as versões do Chrome para o Mac OS X e Linux.

Várias pessoas perguntam de o por que o Google não utilizar apenas a Qt e pronto, fazendo todo o processo em um único lote, tornando as coisas mais fáceis. Goodger explica que o Google “[evita] plataformas cruzadas em seus projetos de Interface com o usuário, pois enquanto eles podem oferecer aquilo que aparentemente possa parecer ser um caminho rápido na busca de uma UI nativa em uma variedade de plataformas alvo, acaba sendo um tanto quanto mais problemático quando você se aprofunda mais no projeto“. Suas requisições, soam como que “pedindo e falando em outro idioma“, acrescenta. Além disso, Goodger alega que usando algo parecido com Qt “limita o que pode-se fazer a subconjuntos menores comuns que são suportados  e enquadrados em cada plataforma.”

Quanto à versão Linux, o Google inicialmente pensava em um clone da versão para Windows como aceitável, uma vez que o próprio Chrome já está usável como aplicação. No entanto, as pessoas que trabalham sobre a versão Linux do Chrome, fizeram questão de usar a GTK + em vez dessa “ideia”, o Google aceitou tal opção. Desde seu nascimento o Chrome é open source, ele poderá ainda, possívelmente ser desenvolvida uma versão em que utilize-se da toolkit Qt  de uma forma independente do Google, é claro.

Quando se trata da versão do Mac, Goodger explica que o plano vem sendo desenvolver uma versão nativa como um todo. “Uma cópia da versão Windows, definitivamente, também não é aceitável no MacOS X”, afirma Goodger, “onde as APIs para desenvolvimento de interfaces são altamente evoluídas e existem muitas características proeminentes. Então, esse é e sempre foi o plano.“

A versão para Mac está chegando a um prazo tolerável, e espera-se que o Google, entregue as duas versões (Linux e Mac) em meados de Junho deste ano.

Boas notícias, será o implemento de algo parecido com a extensão NoScript do Firefox, pois, de acordo com alguns usuários, este é o modelo de segurança ideal que ainda está faltando.

Fonte: Artigo originalmente de Thom Holwerda, traduzido livremente de http://www.osnews.com/story/20980/Linux_Version_of_Chrome_To_Use_Gtk_

Sobre a hora Unix

A verdade é que perdi tal  hora UNIX a “alguns” minutos atras…

Como sempre, atrasado (¬¬’) .. inclusive para estas coisas! Acredito que preciso rever meus conceitos e horários! =P

Estava lendo a respeito do Ext4 e pensando em uma migração do sistema de arquivos para este formato e acabei me esquecendo.

Bem.. o mundo não acabou 

Data e Hora: Sex Fev 13 21:37:55 BRST 2009
Data e Hora UNIX: 1234568275

Para entender como o Unix conta o tempo, recomendo a leitura desse artigo na Wikipedia:

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