Linux e FSF

... sem ressentimentos Mr. Stallman

Ok, fazia tempo que eu não acessava a página da GNU... mas hoje tomei um susto! O Stallman se converteu... Linux na página da GNU? #WTF?

Bem, preciso explicar a surpresa!

No final dos anos 80, tínhamos poucas escolhas de SOs que rodassem nos ainda caros PCs. Um PC-XT custava o equivalente a $2500 dólares no Brasil e, montando nossos hardwares conseguíamos baixar uns $500 dólares. A comunidade científica ficava a mercê do DOS da IBM ou da Microsoft e, uns poucos illuminati tinham acesso ao Minix (que rodava em PC-AT 386).

Nós sabíamos que um tal de Stallman estava desenvolvendo um kernel Unix na Free Software Foundation (FSF), e esperávamos que o mesmo fosse liberado para nos tirar deste domínio feroz da MS e IBM. Apesar de muitos tentarem obter o código do Hurd (como é chamado o kernel da GNU) o Stallman o guardava a sete chaves.

Foi uma benção, o fato de um estudante da Finlândia, chamado Linus Torvalds, pegar o kernel do Minix e criar o kernel do Linux. "God bless Linus Torvalds". O que "emputeceu" o Stallman foi o fato de que a comunidade, ávida por uma mudança, adotou o Linux com uma rapidez impressionante. Além disso, um número significativo de aplicativos que rodavam sobre o Linux eram da GNU; e ele queria o nome GNU vinculado ao novo kernel. Algo como: GNU/Linux.

O Linus Torvalds e o Jon "Maddog" Hall não concordavam por dois motivos que o próprio Maddog me explicou. Primeiro, porque nem todo software que rodava no Linux era da GNU (X Windows, sendmail, vi, vários shells, OpenOffice etc. conforme ele mesmo cita). Em segundo lugar, porque, perante a legislação dos Estados Unidos, colocar duas trademarks juntas enfraquece a ambas. Mas isto não convenceu o "dono" da discórdia e o nome Linux passou a ser quase um tabu para o Stallman.

Explicada minha surpresa, em uma análise mais detalhada do site da GNU encontrei várias distros chamadas de GNU/Linux [1] (para testar e comentar no futuro) e uma explicação de porque as outras distros são excluídas [2]. Segundo o Stallman, são distribuições que trazem em si ou permitem instalação de programas não open source. Errr... qual o problema? Se eu quiser comprar um programa que rode no Linux ou no FreeBSD não vejo nenhum!

Mas, sinceramente, parece haver um erro de interpretação do Stallman. Hoje não temos mais apenas PCs. Temos laptops, smartphones, tablets etc. que precisam de drivers proprietários para rodar os diversos SOs. Esta "turronice" do Stallman não tem sentido. Mas ele é complicado mesmo. Ele é tão radical que não participa de conferências onde o nome Linux não esteja associado ao GNU, como GNU/Linux. Ainda por cima, diferentemente do Maddog que é super "gente fina", o Stallman não faz nenhum esforço para ser simpático (veja neste blog um comentário: http://stulzer.net/blog/2008/03/18/a-terrivel-semana-que-richard-stallman-ficou-na-minha-casa/).

Acho que ele devia acabar o GNU/Hurd no lugar de ficar reclamando, mas parece que ele mesmo já se desencantou:

Stallman said that he was "not very optimistic about the GNU Hurd. It makes some progress, but to be really superior it would require solving a lot of deep problems" [3]

Pode ser que nesta era de novos gadgets achem um lugar para o Hurd também!

... E viva a diversidade!

Referências

[1] http://www.gnu.org/distros/free-distros.html

[2] http://www.gnu.org/distros/common-distros.html

[3] http://en.wikipedia.org/wiki/GNU_Hurd

Crédito da imagem: http://www.gnu.org

Kernel Panic

... don't panic!

Não, ainda não é o dia da toalha! Mas este post trata do pânico do núcleo de um sistema operacional. No Windows, conhecido como "tela azul da morte"... ok, não acontece só no Windows; no Unix também pode existir uma situação de travar o SO (tudo bem... é muito menos frequente e por motivos bem justificados). No Unix chama-se Kernel Panic!

Qualquer SO pode se encontrar em uma situação sem saída e, quando isto acontece, o sistema pode perder dados e entrar em um processo de instabilidade. Então para não perder dados ou danificar mais o SO ele para e espera ser reiniciado. Existe uma rotina, nos sistemas Unix e Linux que se chama panic(); ela exibe uma mensagem no console e grava uma imagem da memória do kernel na situação de emergência para ser depurada (debuged) numa outra ocasião.

Mas o que causa o pânico? Um erro de hardware ou mesmo de software, uma memória corrompida fisicamente ou por algum programa etc. causam uma situação de emergência e o sistema chama a função panic().

O código básico da função é:

 char    *panicstr;

 panic(s)

 char *s;

 {

        panicstr = s;

        update();

        printf("panic: %s\n", s);

        for(;;)

                idle();

 }

O "for(;;;)" é o loop em que o sistema entra para esperar pelo reboot! Antigamente, no Multics, grande parte do código do sistema tinha tratamento de excessões e correção de erros. No Unix, Ken Thompson e Denis Ritchie resolveram de modo mais simples: em caso de erro, emita uma mensagem de "Kernel Panic" e entre em loop. Assim, se houver uma falha de hardware ou mesmo um erro de software que desestabilize o sistema, ele para e emite a mensagem.

Nos kernels atuais, além da mensagem de erro e da parada em loop, o SO faz uma cópia da memória do sistema na hora que ocorre o problema. Esta cópia pode ser gravada em um arquivo para posterior análise e identificação do problema [1].

Apesar de ser uma rotina segura e importante, quando ela acontece em um servidor,  se transforma em um problema. Pode ser desejável ativar uma reinicialização automática. Para isso, basta acrescentar a linha:

kernel.panic = 60

no arquivo /etc/sysctl.conf salvar e reiniciar o processo com "sysctl -p". Isto fará com que o servidor reinicie em 1 minuto após um kernel panic! Se quiser testar podes simular um pânico:

# sync

# echo c > /proc/sysrq-trigger

Note que o 'c' tem que ser minúsculo e use com cuidado. Isto forçará um kernel panic e o computador reiniciará em um minuto, se o arquivo sysctl.conf foi configurado para isso.

OK ... e não esqueça a toalha!



Referências

[1] Novel.Com "Configure kernel core dump capture"
http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=3374462&sliceId=SAL_Public

Kernel 3.3 lançado

... é pra valer, o Kernel Linux 3.3 está na rua!

Anunciado em 18 de março, o novo kernel do Linux está "solto" (released). Com muitas novidades tanto para PCs/laptops, como para smartphones. Eu já havia anunciado algumas novidades do 3.3 em meu artigo anterior em janeiro sobre o assunto. Mas vale a pena um reprise com mais detalhes.

A primeira coisa interessante é a incorporação do código do kernel Android permitindo o boot direto do Android [1]. Finalmente, após um grande período de desentendimentos, as partes se acertaram e vários segmentos do kernel do Android foram incorporados e outros mais serão [2].

Isto tem uma grande importância, principalmente para o futuro really open source dos SOs de tabletes e smarts. Numa disputa (oficial) entre o Android e o iOS, os pequenos (windows, Symbian etc.) vão ter que rebolar para conseguir "um lugar ao sol"... quem ganha? O usuário!

Outra coisa interessante é o suporte à nova arquitetura da Texas Instruments, o TI C6X (C6000, C6-Integra DSP+ARM e DaVinci) que merece um BIG DOUBLE WOW ...

Rodar Linux numa arquitetura orientada à multimídia é uma grande conquista. Além disso, o processador C6-Integra implementa o multicore de DSP e ARM. E, evidentemente, suporta todos os membros da família C64x de processadores DSP multicore da Texas Instruments, capazes de processamento paralelo real de 64 bits, com uma arquitetura VLIW (Very Long Instruction Word) com um set de instruções otimizado para aplicativos DSP. [3,4]

De quebra, temos ainda a capacidade de reperfilar arranjos diferentes de RAID em Btrfs (B-tree file systems, conhecido também pelo apelido de Butter file system) e diversas melhorias em aplicativos de redes. Dentre elas, temos que ressaltar o Open vSwitch [5].

O Open vSwitch adiciona às qualidades de gerenciamento de redes do Linux, mais versatilidade, principalmente num cenário de virtualização de servidores. Por exemplo:

• Mobilidade de estado a cada rede;
• Resposta às dinâmicas de rede (balanceamento),
• Fácil manutenção de tags logicas (switches virtuais distribuidos, p. ex. VMWare, vDS ou Nexus)
• Integração com hardware direto no kernel

O kernel 3.3 tem, também, mais suporte à criptografia:

• caam - suporte a variantes MD5;
• Suporte à verificação de assinatura digital;
• Bibliotecas de multiprecisão do GnuPG: usado para implementação de RSA digital signature verification, com extensões IMA/EVM;
• serpent - com assembler paralelo i586/SSE2 e x86_64/SSE2;
• serpent-sse2 - com suporte a lrw e xts;
• talitos - com adição de algoritmos hmac;
• twofish-x86_64-3way - com adição de suporte a xts.

Este novo kernel traz muitas alterações no núcleo principal, com novas melhorias no gerenciamento de memória e paginação mais extensa com um debug mais intenso voltado para resistência a falhas. Os sistemas de arquivo suportados direto no kernel são o Btrfs (b-tree file system), o GFS2 (RH), o FUSE e o NFSD.

Além disso o novo kernel traz mais suporte a novos hardwares com novos drivers; suporte à virtualização com KVM e Xen; e mais ferramentas de segurança e auditoria.

Onde? ...  http://www.kernel.org/

Referências

[1] http://www.muktware.com/news/3273/linux-33-will-let-you-boot-android-greg-kh

[2] Corbet, J. "Bringing Android closer to the mainline", in lwn.net, 20/12/2011, [https://lwn.net/Articles/472984/]último acesso em 19/03/2012.

[3] http://linux-c6x.org

[4] http://processors.wiki.ti.com/index.php/Main_Page

[5] Corbet, J. "Routing Open vSwitch into the mainline", in lwn.net, 30/11/2011, [https://lwn.net/Articles/469775/], acesso em 19/03/2012

Crédito da imagem: http://fc01.deviantart.net/fs71/f/2011/060/3/a/tux_in_android_robot_costume_2_by_whidden-d3aq9k0.png

Windows 8 beta

... descendooo!

 Deve ser estratégia da Microsoft lançar um "bugado" entre as "distros" mais estáveis. Começou com o Millennium Edition, depois do 98 e antes do XP, depois o Vista, antes do Windows 7 e agora o Windows 8... Este bem-me-quer mal-me-quer já é clássico [1].

Observem que o Windows ME foi lançado porque o o XP não estava pronto. E o caso do Vista para o Windows 7 é o mesmo "lero"! Quem vai cair nessa de Windows 8?

Mas qual a vantagem de lançar um sistema buggy e atrasado? Bem, isto é uma estratégia para a paquidérmica Microsoft: fingir que está apresentando algo novo e pronto. Uma estratégia para fazer os tolos gastarem antes deles corrigirem os bugs e lançarem outra versão mais estável para estes mesmos tolos gastarem de novo. Lembram do caso de upgrade (service pack) do Vista que, na verdade, era um downgrade disfarçado para o XP? Foi vexaminoso. E os caras nem vermelho ficam... mas esta é a idéia!

Quando Bill Gates disse (na apresentação do Windows 95) que todo usuário Windows é um beta-tester da Microsoft. Escreveu: IDIOTA na testa dos consumidores tolos... e com letras garrafais!

Bem, tudo isto é parte da chamada "obsolescência programada" porque para rodar o Windows 8 precisamos de mais memória, mais capacidade de processamento... comprar computadores mais modernos, em suma!

Minha tentativa (frustrada) de instalá-lo no meu "velho" Toshiba (2 GB de RAM e 100 GB de disco, genuine intel dual core) mostra que é preciso muito mais que hardware para rodá-lo... é preciso dinheiro e tolice!

Ser obrigado a investir em novos computadores com hardware mais moderno, tendo ainda um com menos de 2 anos de uso é insano! Não sou contra ganhar dinheiro, aliás, citando meu amigo Jon "Maddog" Hall: "Free software stands for freedom, not for priceless"  (Jon, I don't remember if you told me that or did I read it. Maybe here  or at OpenBeach).

Até os asiáticos estão pedindo à Intel para abaixar os preços [2] ou será difícil desenvolver produtos competitivos no mercado com o Windows 8... não esqueçam: "o buguento Windows 8". Tudo bem... é beta! Mas procurem no Google pelos bugs e ficarão espantados de encontrar bugs na estrutura do sistema operacional... isto me assusta!

A apresentação do Windows 8, por Steven Sinofsky não me convence (no Youtube existem milhares de vídeos sobre o assunto). É sempre a mesma tentativa de mostrar particularidades que existem no Unix há tantos anos como se fosse a maior novidade tecnológica. "Fast and fluid" diz ele, mostrando vários aplicativos rodando ao mesmo tempo... Hallas! Pena que o grande número de usuários que não conhece Unix acha isto a maior loucura! Mas não tente copiar arquivos do Bluetooth e da rede ao mesmo tempo ou verás a lindíssima nova tela azul (Uiii! Ficou tão cute!).

Em sua apresentação [3] ele diz que o Windows 95 inciou uma "generational change" do sistema windows! Hum... com esta fritadeira de HD? Com aquele código do cmd.exe? (veja minha publicação sobre o Windows 7) Vai tentar enganar os trouxas, a mim não! Eu leio Assembly!

"Fast: vai ter um service pack logo!" and "Fluid: Como o dinheiro escorregará das mãos dos consumidores tolos".



Referências:

[1] Dvorak, J. C. "Will Windows 8 Be the Next Vista?", PC Magazine, march, 2012, http://www.pcmag.com/article2/0,2817,2401064,00.asp?utm_medium=referral&utm_source=pulsenews em 04/03/2012.

[2] Bylund, A. "Intel Can't Topple Apple's Portable Stronghold", http://www.dailyfinance.com/2011/09/20/intel-cant-topple-apples-portable-stronghold/ em 06/03/2012.

[3] Reisinger, D. "What Microsoft wants you to think about the Windows 8 beta", http://reviews.cnet.com/8301-13970_7-57387487-78/what-microsoft-wants-you-to-think-about-the-windows-8-beta/ em 04/03/2012.

Linux e teclados

um legado complicado...

Não é exatamente a minha praia mas algumas pessoas têm tido problemas com teclados no Linux. O fato é que por ser proprietário de uma SunBlade 2000 com um teclado Sun, já experimentei usar o teclado da Sun em um PC e tive este tipo de problema: basta encostar em uma tecla e o resultado é uma dúzia de caracteres. Assim, vou dar algumas dicas e , embora um pouco off-topic, o assunto está relacionado com o SO.

Trata-se de problemas com teclados específicos e/ou distribuições Linux que necessitam de uma configuração manual. As distribuições modernas não apresentam este problema — bem, pelo menos nunca tentei instalar o Ubuntu num i486, por exemplo.

Este problema acontece porque, durante o boot, o kernel ajusta a velocidade do teclado para o máximo valor (0x0305). Bem, isto não é problema para a maioria dos teclados modernos e nem funciona para teclados USB, mas alguns tipos de teclado respondem "violentamente" a isto. No Linux, o problema pode ser contornado usando o programa kbdrate (veja: man 8 kbdrate) que muda a velocidade de repetição do teclado.

Alternativamente, podes alterar o kernel e recompilá-lo. Mas antes, vamos entender o que e porque.

Em kernels mais antigos, o arquivo:

/usr/src/linux/arch/i386/boot/setup.S

tem um código Assembly para ajustar a taxa de repetição do teclado:

     ! set the keyboard repeat rate to the max

         mov     ax,#0x0305

         xor     bx,bx           ! clear bx

         int     0x16

Nos novos kernels, esta chamada de interrupção está no código do arquivo:

/usr/src/linux/arch/x86/boot/main.c

...

/*

 * Set the keyboard repeat rate to maximum.  Unclear why this

 * is done here; this might be possible to kill off as stale code.

 */

static void keyboard_set_repeat(void)

{

        struct biosregs ireg;

        initregs(&ireg);

        ireg.ax = 0x0305;

        intcall(0x16, &ireg, NULL);

}

...

void main(void)

{

...

        /* Set keyboard repeat rate (why?) */

        keyboard_set_repeat();

...

...

Este código chama a interrupção 16 da BIOS com o valor hexa 0305 no acumulador, ou seja, AH=03 (set keyboard rate) usando o valor 05 (máximo) para o AL. Esta faixa de valor (0-5) pode ser de 02 a 30 caracteres por segundo ou de 02 a 1440 em alguns teclados. E isto pode resultar, em alguns casos, em um teclado hiper-sensível.

A sugestão, de vários desenvolvedores do kernel é alterar ou mesmo retirar esta parte do código e recompilá-lo. Mas porque então não retirá-lo do código (o que já foi até sugerido ao Linus). Bem tudo tem uma explicação, embora o próprio Linus nunca tenha esclarecido.

Primeiro, eu imagino que isto seja um código legado e que é mantido para compatibilidade. Segundo é que, por experiência própria, esta solução pode causar problemas no Accelerated-X que pode ficar instável e demorar para terminar.

Ainda, existem certos hardware (p. ex. Dell Inspiron) que depois da hibernação ajusta a velocidade do teclado para o default, deixando-o mais lento. Neste último caso, pode-se regular a velocidade usando o comando:

$ kbdrate -r 30 -d 250

Isto não aconteceria se o kernel controlasse a interrupção da BIOS.

Embora eu concorde com o comentarista do código ("why this is done here?") é melhor deixar o código onde está. Afinal, quem vai usar um teclado "alienígena" em um computador "Frankenstein" deve saber onde e como alterar o código do kernel.

Happy linuxing!

PC-BSD 9.0

"... está para o FreeBSD como o Ubuntu está para o Debian" (Linux Today)

Recentemente, lendo a Linux Today tropecei no artigo da Linux User & Developer que aborda o PC-BSD [1]. Logo no início deste blog, eu já havia chamado a atenção dos leitores sobre o PC-BSD no meu primeiro artigo.

Na época o kernel do FreeBSD 9.0 ainda não era a distribuição STABLE e então comentei apenas en passant. Agora, com o kernel 9.0 "na rua" resolvi reinstalá-lo e testá-lo com mais detalhes. Foi uma semana bem agitada porque, como sempre, a instalação e teste de um novo sistema operacional toma o tempo da gente. A instalação em si foi muito tranquila e creio que qualquer usuário de PC ou Laptop com conhecimento mínimo pode instalá-lo sem problemas.

Feito o download do sistema [2], ele foi instalado em uma máquina virtual, como de costume, usando o VirtualBox da Oracle. Neste caso, foi usado o DVD de 32 bits, embora exista a opção de baixar o disco pronto do VirtualBox ou do VM Ware. A opção de baixar o DVD foi para poder instalar os fontes do kernel e o conjunto completo do ports. Mas, claro, tudo isto pode ser feito posteriormente, via cvsup.

A instalação de um BSD é sempre vista como coisa de nerd ou de hacker... não é bem assim e, hoje, é bem diferente de instalar um Linux Slackware ou mesmo o FreeBSD (que já melhorou muito no processo de instalação). Se nunca instalastes um BSD, sem problemas. A instalação do PC-BSD é gráfica, bem explicativa e fácil. No entanto, se precisar de ajuda, o PC-BSD tem um excelente manual de quase 300 páginas ou online.

Configuração da instalação de teste

Máquina virtual, 1 GB de RAM, 15 GB de disco, 32 MB de memória de vídeo, sistema de arquivo UFS. A opção pelo ZFS (veja meu post sobre o assunto) é recomendada apenas para um sistema de 64 bits e 4 GB de RAM.

Ambiente gráfico

Na instalação podes escolher o tipo de interface gráfica que preferes. Antigamente, as primeiras versões do PC-BSD ofereciam apenas o KDE como ambiente. Agora, podes escolher entre o GNOME 2, KDE 4.7, LXDE e XFCE ou todos.

A tela de login faz juz ao codinome do SO: ISOTOPE Edition e a princípio parece que vais entrar em um laboratório de química! Mas mesmo esta tela pode ser mudada depois

Ao logar, encontras 3 ícones no desktop: o AppCafe, PC-BSD Control Pannel e PC-BSD Handbook. O programa AppCafe é um instalador gráfico de programas baseado no formato PBI (Push Button Installer) mas é possível usar, também, o ports para compilar o software localmente, com especificidades do hardware usado. O AppCafe não é completo, ou seja, não lista todos os programas disponíveis para o PC-BSD mas todos os programas disponíveis para o FreeBSD podem ser instalados no PC-BSD, sem problemas via ports ou pkg_add.

AppCafe

O forte do PC-BSD é a documentação. Aliás, a documentação do FreeBSD também é bem completa (em vários níveis de abordagem). O PC-BSD tem um manual quase completo e bem organizado para dar suporte imediato ao usuário. Além disso Forum e Wikis são bem abundantes na web e o suporte é bem mais tranquilo, rápido e eficiente que o suporte de sistemas pagos.

Como o sistema FreeBSD prima pela segurança, o back-up é fundamental. Um aplicativo bem importante e interessante é o Life-Preserver que automatiza as cópias de segurança e pode sincronizar facilmente com um servidor tipo FreeNAS (veja meu post sobre o FreeNAS).

De modo geral, o PC_BSD deve agradar aos usuários de Linux ou oferecer uma boa alternativa aos usuários do Windows da MS que queiram usar o sistema operacional em que roda o MAC OS. A vantagem sobre o MAC OS é que não terás que pagar nada por isso.



Referências

[1] Koen Vervloesem "PC-BSD 9 review – to FreeBSD what Ubuntu is to Debian", http://www.linuxuser.co.uk/reviews/pc-bsd-9-review-to-freebsd-what-ubuntu-is-to-debian/ , fevereiro, 2012.

[2] http://www.pcbsd.org/

[3] Crédito das imagens: http://www.linuxuser.co.uk

Windows 8

... metro ou erro pra mais de metro!

Ok, eu sei que não está pronto (que demora heim!) mas eu queria testá-lo para dar algumas dicas de primeira mão. #FAIL !!! Era para ser um post surpresa, apresentando o novo sistema da Microsoft que iria desbancar o Androide, iOS e outros sistemas para dispositivos móveis.

Para começar, não ia instalá-lo mesmo em uma máquina dedicada; minha opção era o VirtualBox da Oracle... mas não funfa! Bem que tentei. Na página da MS não há nada que sugira o contrário pois os requisitos são:

"The Windows 8 Developer Preview works great on the same hardware that powers Windows Vista and Windows 7:

    1 gigahertz (GHz) or faster 32-bit (x86) or 64-bit (x64) processor
    1 gigabyte (GB) RAM (32-bit) or 2 GB RAM (64-bit)
    16 GB available hard disk space (32-bit) or 20 GB (64-bit)
    DirectX 9 graphics device with WDDM 1.0 or higher driver
    Taking advantage of touch input requires a screen that supports multi-touch
    To run Metro style Apps, you need a screen resolution of 1024 X 768 or greater"

Para a instalação foi usado: 1,5 GB RAM, 128 MB video, 20 GB disco... mais do que necessário. No boot apareceu a mesma tela horrorosa do windows 7 "loading files" sem aliases nas fontes e uma barra preto-e-branco. É de espantar de tão feio! Depois de um minuto de tela preta apareceu "Windows Developer Preview" no meio da tela, por uns 40 segundos e aí:

Um erro! Nos logs do VirtualBox o problema:

nspr-4 WARNING [COM]:  aRC=NS_ERROR_FAILURE (0x80004005)

aIID={dab4a2b8-c735-4f08-94fc-9bec84182e2f} aComponent={Host}

aText={VirtualBox is not currently allowed to access USB devices. You can change this by adding your user to the 'vboxusers' group. Please see the user manual for a more detailed explanation}, preserve=true

Que diabos! Não era preciso detectar USB se não está sendo usada e, muito menos se apossar dela. Em outros SOs nunca apareceu este problema. Mas tudo bem... demos permissão! Para isto é necessário editar o group e shadow do group... (vigr e vigr -s) e adicionar o usuário no grupo vboxusers, fazer logout e login novamente. Feito...

Nova tentativa e novo erro. Agora:

nspr-3   ERROR [COM]: aRC=VBOX_E_INVALID_VM_STATE (0x80bb0002)

aIID={5eaa9319-62fc-4b0a-843c-0cb1940f8a91} aComponent={Machine}

aText={Machine is not locked for session (session state: Unlocked)}, preserve=false

Caraca... o SO quer tomar posse de tudo? Agora quer a máquina só pra ele? Putz! Tentei, então, um VirtualBox em uma máquina rodando Windows 7... Precisam ver que linda ficou a tela azul! ;)

Mas lindo mesmo é o nome do arquivo WDF01000.sys (WaDaFuck!!!)

Um passeio pelos "fora" (plural de forum em latim, ok?) da microsoft e descobri que os usuários deste tipo de sistema só estão preocupados com perfumarias (tamanho do ícone, cor do fundo, etc.). De resto, eles gostam mesmo é de dar o boot na máquina! É a coisa mais normal e graciosa deste SO.

Ok... fui ao Google e tentar entender tudo isto e chegar à conclusão de que  o Windows 8 não funfa no VirtualBox da Oracle. Você pode tentar instalar o WDDM driver com aceleração 3D para resolver o problema mas não vale a vela para este defunto!

Melhor esperar um pouco mais para poder testá-lo... sorry guys, por enquanto vocês terão que sifu se quiserem instalar esta m*...