sexta-feira, 14 de julho de 2017

GbPlugin apronta de novo

Algumas instalações do Windows 10 1703 estão em loop de reparo automático. Causa? Nosso velho conhecido GbPlugin.

O arquivo gbpddreg64.sys (ou gbpddreg32.sys em 32-bit), presente em C:\Windows\System32\drivers, fica truncado (0 bytes). Como isso acontece ninguém sabe.

Esta tela aparecerá com
bcdedit /set {default} recoveryenabled no

Por padrão, o ambiente de recuperação inicializará em caso de falha. Quando aparecer a mensagem "Reparo Automático não pôde reparar seu computador", clique em "Opções avançadas → Solução de Problemas → Opções avançadas → Prompt de Comando".

Ache a letra relativa à unidade do Windows usando dir C:, dir D:, etc. Usarei D: como exemplo.

Então, remova o maldito:

del D:\Windows\System32\drivers\gbpddreg64.sys

ou

del D:\Windows\System32\drivers\gbpddreg32.sys

Feche o prompt e clique em "Continuar". Deverá funcionar.

O serviço continuará em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\gbpddreg. Porém sem o arquivo, a inicialização prossegue. Neste post do Microsoft Community, recomendam copiar o dito cujo de C:\Program Files (x86)\GbPlugin (ou C:\Program Files\GbPlugin em 32-bit). Prefiro excluir a tranqueira.

segunda-feira, 26 de junho de 2017

Leve meu dinheiro, Nintendo

Super NES Classic Edition

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

US$ 79,90. Disponível em 29/09. Já imagino o preço absurdo aqui na banânia. Não importa. Esse console marcou minha infância. Os jogos não são muitos, mas são top.

Tomara que a Nintendo não repita o que aconteceu com o NES Classic Edition. Precisam produzir mais unidades desta vez para suprir a demanda, que deverá ser ainda maior.

domingo, 11 de junho de 2017

A monocultura x86

Intel fires warning shots at Microsoft, claims x86 emulation is a patent minefield (Ars Technica)

Ainda não sabemos como exatamente a Microsoft pretende emular o conjunto de instruções x86 quando o Windows 10 rodar sobre ARM. Se fosse implementar apenas as instruções do modo protegido do i386, provavelmente não haveria problema algum, visto que é improvável qualquer patente relacionada existir. No entanto, software atual precisa mais do que isso. Há diversas instruções adicionais possivelmente minadas por patentes, especialmente SIMD, que são requeridas nos dias de hoje.

Nossa dependência do conjunto de instruções x86 precisa diminuir. Se pensarmos bem, não escreve-se mais aplicativos comercialmente em assembly* há muito tempo. Usam-se linguagens de alto nível. Fica a cargo do compilador gerar código de máquina para a arquitetura escolhida. Não existe nada que impeça, no momento em que a plataforma Windows 10 ARM existir, desenvolvedores disponibilizarem binários ARM nativos. Suporte no Visual Studio existirá. No GCC e Clang não demorará. Tropeçamos, porém, no dilema do ovo e da galinha: enquanto não popularizar a plataforma, não haverá estímulo para os desenvolvedores recompilarem/ajustarem seus códigos; por outro lado, enquanto não houver aplicativos, a plataforma terá dificuldade em popularizar-se. A emulação x86 vem para resolver a segunda questão. Com o tempo, mais e mais programas passariam a ter versão ARM nativa e a dependência diminuiria.

Vamos aguardar a Microsoft detalhar as coisas.


* Programas que precisam de alto desempenho costumam ter algumas partes escritas em assembly usando um montador. Tais códigos geralmente detectam quais instruções são suportadas durante a execução e possuem um fallback genérico que roda (mais lentamente) em qualquer modelo que implemente a arquitetura em uso.

quarta-feira, 31 de maio de 2017

Dicas para transplantes de Windows (VirtualBox)

Seguindo o post anterior, quando movi uma instalação do Windows XP para o VirtualBox, neste tratarei de alguns detalhes chatos do processo.

Cenário comum é pegarmos uma máquina baleada, cujo hardware não funciona mais. Tiramos o disco, fazemos uma imagem e colocamos dentro do VirtualBox. Usando o Ghost no Windows PE, em certos casos — ainda não identifiquei em quais circunstâncias ocorre —, o arquivo VMDK/VHD não fica com permissão de escrita para usuários normais, apesar das ACLs estarem corretas. Isso ocorre porque o arquivo é criado com um Integrity Level alto. ILs têm prioridade maior do que as convencionais ACLs. Para complicar, não achei ferramenta embutida no sistema que permita remover ILs (icacls permite modificá-los com a opção /setintegritylevel). Precisamos de ferramenta de terceiros (obrigado, Microsoft!) para fazê-lo: chml.exe (link). Como Administrador:

chml <unidade>:\caminho\imagem.vhd -rl

Pronto. O misterioso erro do VirtualBox reclamando que o disco virtual é somente leitura desaparecerá.


O próximo problema é aquela tradicional tela azul 0x0000007B ao iniciar. Com Windows Vista ou superior, ao usar o adaptador SATA (AHCI) do VirtualBox, modifique (offline se necessário) no registro do sistema convidado:

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\msahci]
"Start"=dword:00000000

Caso não funcione, temos como alternativa o adaptador SAS (LSI Logic), suportado desde o Windows 7:

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\LSI_SAS]
"Start"=dword:00000000

0 significa habilitado, 3 desabilitado. O adaptador SCSI (LSI Logic) também é suportado desde o 7 (subchave HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\LSI_SCSI). É considerado obsoleto, no entanto, e ao que parece foi removido no Windows 8.1. Prefira o adaptador SAS.

Geralmente é ControlSet001. Veja o valor de Default em HKEY_LOCAL_MACHINE\SYSTEM\Select para saber qual número usar.

Quando possível, faça uma faxina, desinstalando programas e drivers desnecessários, antes de virtualizar o sistema.

quarta-feira, 17 de maio de 2017

Novidades do EXT4

Fiquei um tempo afastado do EXT4. Por mais que mostre sua idade e seja considerado obsoleto pela Red Hat e Oracle, ainda é provavelmente o sistema de arquivos mais usado no mundo Linux.

Existem trezentas opções que podem ser habilitadas ou não no momento da criação do sistema de arquivos. E mais! O mesmo pode ser feito em sistemas existentes. Antes que pensem que acho isso bom: não acho. Porém é assim que os EXT vêm sendo desenvolvidos há décadas; logo, saudemos a tradição!

A partir do kernel 3.5, suporta checksums dos metadados. Considerado estável desde o 3.18. Quão estável? Não tenho ideia.

Parte 1: 64bit

Recurso adicionado na versão 1.42 da suíte e2fsprogs e presente desde o antigo kernel 2.6.28. O mke2fs (e atalho de conveniência mkfs.ext4) cria EXT4 com a opção 64bit ao detectar dispositivo maior que 16 TiB (auto_64-bit_support = 1 em /etc/mke2fs.conf) — mais especificamente 232 * tamanho_do_bloco (em 99% dos casos 4 KiB). Sem ele, não é possível formatar dispositivos acima dessa marca: o comando falhará. Podemos forçar a criação de volumes menores com o recurso habilitado usando a opção -O 64bit. Contudo, existe um bug no mke2fs, que impede o redimensionamento posterior caso o volume seja criado com essa opção e seja maior que o limite imposto pelo endereçamento de 32 bits (improvável usuários domésticos depararem-se com isso). Foi consertado na versão 1.42.10.

A partir da versão 1.43, 64bit é finalmente habilitado por padrão independentemente do tamanho do dispositivo \o/. Tais volumes são suportados desde o GRUB 2.02-beta1.

Parte 2: metadata_csum

Requer e2fsprogs 1.43 ou superior. Funciona melhor junto com 64bit. Por que não é requerido então? Sabe-se lá... coisas dos EXT.

Não interfere na compatibilidade com o GRUB.

Resumo

Tendo uma distribuição com kernel ≥ 3.18, e2fsprogs ≥ 1.43 e GRUB ≥ 2.02-beta1:

# mkfs.ext4 -O metadata_csum /dev/<dispositivo>

Mais ou menos, é equivalente ao XFSv5 no EXT4. Mas... ainda com limite de 16 TiB por arquivo. Há a opção bigalloc para remediar, porém recomendo migrar para outro sistema de arquivos (XFS, Btrfs) caso a limitação impacte seu uso.

terça-feira, 2 de maio de 2017

Compilação oficial do Firefox para Linux requer SSE2

Seguindo o Firefox x86-32 para Windows, a compilação oficial da Mozilla para Linux x86-32 requer processador com SSE2 a partir da versão 53. É compilado com -march=pentium-m -msse -msse2 -mfpmath=sse. Ou seja, o conjunto de instruções do Pentium M, que por sua vez é basicamente o conjunto de instruções do Pentium III + SSE2.

Uma pequena parte do código é compilada com -march=pentiumpro -mno-sse -mno-sse2 -mfpmath=387 para conseguir exibir esta mensagem e finalizar com erro:

This browser version requires a processor with the SSE2 instruction set extension.
You may be able to obtain a version that does not require SSE2 from your Linux distribution.


Não afeta as compilações das distribuições, que definem suas próprias opções.

Lembrando que em x86-64 nada disso interessa, visto que SSE2 sempre está disponível.

domingo, 30 de abril de 2017

Transplantando instalação do XP para o VirtualBox

Pelos mais variados, às vezes absurdos, motivos, cacarecos com Windows XP ainda estão na ativa. Em geral, hardware cambaleante. Um provável meio de lidar com o abacaxi é passá-los para dentro de ambientes virtualizados. Sendo o VirtualBox gratuito, é a solução que usarei aqui.

Existem diversas ferramentas[1] para extrair o conteúdo do disco onde as velharias residem. O Symantec Ghost, o mais clássico dos programas para tal fim, suporta salvar diretamente em VMDK (VMware) desde a versão 11.5 e em VHD (Virtual PC, Hyper-V) desde a 12.

No entanto, usando a GUI do programa, não é possível salvar nesses formatos. Só permite fazê-lo no seu formato nativo GHO. Recorremos então à linha de comando.

O gdisk32 chamado sem argumentos nos dá os índices de cada dispositivo (estou rodando-o no Windows PE):

Disk  Partitions  Cylinders  Heads  Sectors  Mbytes  Model
  1        1        14593     255      63  114473.5  PH4-CE120
  2        1        38913     255      63  305245.3  WDC WD32 00BPVT-22JJ5T0 01

Com isso, acertamos src= nos comandos abaixo de acordo com a coluna "Disk".

VMDK:

ghost32 -clone,mode=create,src=1,dst=<unidade>:\caminho\imagem.vmdk -batch

Para salvar em VHD[2], basta mudar a extensão:

ghost32 -clone,mode=create,src=1,dst=<unidade>:\caminho\imagem.vhd -batch

Ambos formatos são suportados pelo VirtualBox. Prefiro VHD pois podemos montá-lo pelo Windows Explorer desde o 8. No 7, também é possível, porém sem a mesma praticidade, porque precisa ser feito via Gerenciamento de disco ou diskpart.

Agora, basta criar nova máquina virtual do tipo Windows XP (32-bit)[3] e usar a imagem VHD existente como disco. Detalhe importante! Até o XP, havia a salada de HALs! Caso o PC de origem use um dos HALs APIC (ACPI Uniprocessor PC ou ACPI Multiprocessor PC), você precisa marcar a opção "Habilitar o I/O APIC" nas propriedades, do contrário não iniciará:


Por fim, instale os Adicionais para Convidado.

Se você tiver imagens GHO, pode convertê-las para VMDK ou VHD usando o próprio Ghost:

ghost32 -clone,mode=restore,src=<unidade>:\caminho\imagem.gho,dst=<unidade>:\caminho\imagem.vmdk -batch
ghost32 -clone,mode=restore,src=<unidade>:\caminho\imagem.gho,dst=<unidade>:\caminho\imagem.vhd -batch


[1] O popular Disk2vhd é uma alternativa.
[2] VHD tem limite de ~2 TiB. O Ghost não suporta VHDX, formato mais novo, introduzido no Windows 8.1, sem a limitação. Nem faria diferença, pois igualmente não funciona no VirtualBox.
[3] Nem considerei o XP 64-bit pois é um Unicórnio. Em máquinas virtuais XP, o VirtualBox configura o controlador de disco IDE, que deve iniciar com qualquer instalação.

sexta-feira, 21 de abril de 2017

O útil blkdiscard

Todo mundo conhece o fstrim, que instrui o sistema de arquivos a avisar ao SSD quais blocos não está mais usando.

Digamos que temos uma partição e que desejamos apagar sua área por completo. Tradicionalmente, usaríamos algo como:

# dd if=/dev/zero of=/dev/sdxy bs=4k

Contudo, com SSDs, existe uma forma mais rápida e prática:

# blkdiscard -v /dev/sdxy

Esse comando usa a requisição BLKDISCARD da chamada de sistema ioctl() e nos entrega a área que compreende a partição /dev/sdxy zerada. Por usar o comando ATA TRIM, é rápido. Não funciona com discos rígidos. Neles, o kernel retorna erro e o comando avisa que não há suporte.

Ou seja, blkdiscard é análogo ao fstrim, porém trabalha no nível do dispositivo de bloco, não do sistema de arquivos. Pode ser usado no disco inteiro também (/dev/sdx).

[Atualização - 20/06/2017] Infelizmente, não é todo SSD que garante setores zerados depois de TRIM. Por isso não podemos depender do blkdiscard para limpar discos, partições. A saída é usar blkdiscard -z (abaixo) ou continuar com o dd.

Mesmo com HDDs, pode ser útil em certos casos*, pois com a opção -z (--zeroout) faz o mesmo que o dd faria:

# blkdiscard -z -v /dev/sdxy

blkdiscard -z usa a requisição BLKZEROOUT da chamada de sistema ioctl().

Com -v, mostra um sumário ao término do processo.

Versão mínima requerida do kernel é 2.6.28 (BLKDISCARD) e 3.7 (BLKZEROOUT) e a ferramenta existe desde a versão 2.23 da suíte util-linux.


* Não recomendo rodá-lo em áreas grandes demais, maiores do que alguns gigabytes, de discos rígidos. Enquanto a chamada de sistema não retornar, o processo fica no estado uninterruptible sleep e não pode ser terminado manualmente.

sexta-feira, 7 de abril de 2017

quarta-feira, 5 de abril de 2017

Unity e Mir estão mortos

Ubuntu Unity is dead: Desktop will switch back to GNOME next year (Ars Technica)

Vão para a cova ao lado da ocupada pelo Upstart. Que descansem em paz. GNOME + Wayland a partir do Ubuntu 18.04 LTS.

Visto que são projetos cobertos por CLA, não é de estranhar que tenham morrido...

A divisão desnecessária causada pelo Mir tem um fim com esse anúncio. Tivesse a Canonical não despejado FUD sobre o Wayland quando iniciou sua aventura solo sem apoio comunitário, talvez hoje tivéssemos o protocolo Wayland em estágio de desenvolvimento mais avançado bem como melhores compositores.

domingo, 2 de abril de 2017

Autoconfiguração de proxy com NetworkManager + PACRunner

No NetworkManager 1.6, temos novidades na forma de lidar com configuração automática de proxies. Agora, o NM pode obter a configuração via WPAD (DHCP) e enviá-la ao PACRunner, outro daemon, ativado via D-Bus, que trata de processar o JavaScript recebido e responder às requisições dos clientes. Os proxies podem ser configurados de acordo com a interface, caso mais de uma exista.

Os clientes falam diretamente com o PACRunner usando sua interface via D-Bus, ou, para os que linkam a libproxy, uma biblioteca de compatibilidade provida pelo daemon faz o mesmo. Essa biblioteca substitui a libproxy original, sendo mais simples e eficiente. Trabalha apenas consultando-o via D-Bus.

O design está aqui: https://wiki.gnome.org/Projects/NetworkManager/Proxies

        +----------------+
        | NetworkManager |
        +----------------+
                |
                | D-Bus (org.pacrunner.Manager.CreateProxyConfiguration)
                v
        +----------------+         +-----------+
        |   PACRunner    | <---->  | v8, mozjs |
        +----------------+         +-----------+
            ^         ^
            |          \ D-Bus (org.pacrunner.Client.FindProxyForURL)
            |           +----------+
            |                       \
            |                        v
            |             +----------------------+
            |             |                      |
            |             |    libproxy.so do    |
            |             |      PACRunner       |
            |             |   (API compatível)   |
            |             |                      |
            |             +----------------------+
            |                        ^
            |                        | libproxy API (px_proxy_factory_get_proxies)
            |                        v
            |                  +-----------+
            |                  | Cliente 2 |
            |                  +-----------+
            |
            | D-Bus (org.pacrunner.Client.FindProxyForURL)
            v
      +-----------+
      | Cliente 1 |
      +-----------+

Nem tudo são flores

E se o cliente não conversar com o PACRunner via D-Bus nem linkar a libproxy? Daí restam as variáveis de ambiente, que são terrivelmente problemáticas com autoconfiguração de proxy e não são suportadas pelo PACRunner.

Arch e openSUSE não empacotam o PACRunner. Já a versão que está no Fedora é velha demais e é compilada com --disable-libproxy.

Bugs

NetworkManager 1.6.2 (última versão estável enquanto escrevo) não envia a configuração ao PACRunner (BGO#780558).

Ainda ruim

Autoconfiguração de proxy no GNU/Linux tem avançado a passos de tartaruga. O esqueleto de uma configuração funcional existe; os clientes, contudo, precisam parar de depender de variáveis de ambiente. Visto que a libproxy possui uma API simples, o ecosistema poderia padronizar nela a tarefa de lidar com proxies. Dos componentes básicos, a libcurl é usada por muitos códigos que acessam a internet. Precisaria ser a primeira a passar a usá-la (patch existe).

sábado, 18 de março de 2017

Pavilion 14-n050br que não desliga

Este notebook HP Pavilion 14-n050br (E7J04LA#AC4) estava com o mesmo problema do Dell do post anterior. Veio de fábrica com o Windows 8, posteriormente atualizado para o 8.1 e depois 10. A última instalação do 10 foi limpa, em UEFI com Secure Boot habilitado.

Felizmente bastou atualizar o firmware da versão F.66 para a F.70 e foi resolvido. O driver Intel MEI ficou na versão instalada pelo próprio Windows 10 1607 (11.0.0.1146).

[Atualização - 24/03/2017] Escrevi cedo demais. Ocasionalmente ainda falhava. Atualizei o driver Intel MEI para esta versão 11.0.0.1177 e até agora não incomodou.

quinta-feira, 9 de março de 2017

Inspiron 5547 que não desliga

Este notebook Dell Inspiron 5547 (etiqueta de serviço 3SSFM22) não desligava. Veio com Windows 8, posteriormente atualizado para o 10 (instalação limpa). Primeira providência foi atualizar o firmware da versão A07 para a A10 (na A08 o Windows 10 passou a ser oficialmente suportado). No entanto, continuou o problema.

Solucionei instalando driver mais recente da Intel Management Engine Interface (11.0.0.1173):

http://www.dell.com/support/home/br/pt/brdhs1/Drivers/DriversDetails?driverId=3MD6D

A versão instalada pelo Windows 10 1607 era a 11.0.0.1146.

Complica o fato do driver listado no site da Dell para o modelo ser obsoleto e não resolver nada (o link acima é do Inspiron 5557).

sexta-feira, 3 de março de 2017

A boca livre não terminou

Havia testado o caso de máquinas com chaves do 8 e 8.1 salvas no firmware, nas quais podemos atualizar para o Windows 10 diretamente através de instalação limpa com a mídia adequada, mesmo após o encerramento em 29 de julho de 2016 da campanha de atualização em massa.

Hoje, fiz o teste que faltava: a partir do Windows 7, coloquei a mídia equivalente do 10 e rodei setup.exe. Atualizou e ativou.

Portanto, apenas foi descontinuado o mecanismo via Windows Update. Fazendo na mão continua sendo possível.

sexta-feira, 17 de fevereiro de 2017

Ghost 12 suporta (com bugs) EXT4

Desde 2015, o venerável Symantec Ghost[1], parte da Ghost Solution Suite (atualmente na versão 3.1), voltou a ser atualizado, saindo da cansada versão 11.5.1 para a 12. Além de suportar oficialmente os Windows modernos (ver esta tabela), também trouxe suporte[2] ao sistema de arquivos EXT4. Na 11.5.1, suportava apenas EXT2 e EXT3. Volumes EXT4 eram rejeitados com um tal erro 652 (Attempted to access an inconsistent Linux partition). Estranho não ter uma palavra sobre a novidade nas notas de lançamento.


A versão 12 preserva todas as características de volumes EXT4 formatados com o mke2fs da série 1.42[3] (via mkfs.ext4), com exceção de uninit_bg, que faz pouca diferença, pois afeta apenas o tempo requerido pelo e2fsck para verificar o sistema de arquivos.

No entanto, se o sistema de arquivos tiver o recurso 64bit habilitado (a partir do mke2fs 1.43 o é por padrão), daí o programa falha por completo. Não é exibido erro algum ao criar e restaurar a imagem, porém o sistema de arquivos fica totalmente corrompido depois de restaurado. Provavelmente o pessoal da Symantec está testando seu código usando distribuições velhas como referência. Vamos ver se em versões futuras (depois da 12.0.0.8065; GSS 3.1 MP5) arrumam esse problema. [Atualização - 07/04/2017] Resolvido na versão 12.0.0.10517.


[1] Existe uma confusão entre Norton Ghost e Symantec Ghost. Ver este meu post no fórum CdH sobre isso.
[2] Significa salvar só os dados, recriando o sistema de arquivos no momento da restauração, já entregando-o redimensionado caso necessário. Dessa maneira, o tamanho da imagem é otimizado. Similar ao FSArchiver. Não é uma cópia bit a bit como o dd faria.
[3] Até a 1.42, auto_64-bit_support = 1 era configurado em /etc/mke2fs.conf: habilitava 64bit apenas em volumes maiores que 16 TiB. Ou seja, na prática, na esmagadora maioria das instalações, o recurso não estava presente. Na 1.43, passou a ser sempre habilitado — o mesmo comportamento foi backportado para o pacote 1.42.9 do RHEL 7.

sábado, 11 de fevereiro de 2017

systemctl enable|disable|mask --now

A partir do systemd 220, a opção --now poupa uma invocação adicional do systemctl quando queremos habilitar e iniciar, ou desabilitar e parar um daemon.

# systemctl enable xxx.service
# systemctl start xxx.service

               |
               v

# systemctl enable --now xxx.service

# systemctl disable xxx.service
# systemctl stop xxx.service

               |
               v

# systemctl disable --now xxx.service

# systemctl mask xxx.service
# systemctl stop xxx.service

               |
               v

# systemctl mask --now xxx.service

Melhor de tudo: a equipe da Red Hat backportou o recurso para a versão 219 do RHEL 7.2.

quinta-feira, 9 de fevereiro de 2017

segunda-feira, 30 de janeiro de 2017

Bugs do Firefox para monitorar (II)

Mais dois bugs do Firefox me interessam no momento.

https://bugzilla.mozilla.org/show_bug.cgi?id=1207306

A partir do Firefox 49, separou-se o processo que renderiza a interface do que renderiza o conteúdo das páginas. Ainda assim, todas as abas continuam compartilhando um único processo. Nesse primeiro passo, o objetivo foi fazer a interface sempre ser responsiva. Usuários antigos devem lembrar como era irritante uma página pesada acabar com a responsividade da interface. Isso pelo menos está resolvido. Contudo, uma aba mal comportada ainda deixa as outras esperando. A solução virá com o projeto e10s-multi, que aproximará o Fx dos demais navegadores modernos, separando grupos de abas em diferentes processos.

https://bugzilla.mozilla.org/show_bug.cgi?id=336193

Para sistemas Unix-like. Fazer o navegador finalizar de forma limpa ao receber SIGTERM. Hoje, um killall firefox realiza uma finalização forçada, que causa o travamento do plugin-container e dispara a restauração de abas na próxima vez em que o programa iniciar. Bug constrangedor, que tem mais de 10 anos.

sexta-feira, 27 de janeiro de 2017

Super Metroid: uma obra-prima

Tenho assistido aos vídeos da série Retro Gaming do canal REACT no YouTube. Com um pouco de experiência nas costas, é interessante ver como o pessoal mais novo reage aos jogos que tínhamos décadas atrás.

Daí chego em:

SUPER METROID (30th Anniversary Metroid) (Teens React: Retro Gaming)

Aos 50 segundos, Tori diz I actually like retro games cuz normally they are pretty simple.

O quê???

Super Metroid é um dos melhores jogos de todos os tempos. Longo o suficiente*, complexo e difícil (sem ser impossível). O gráfico é perfeito, top da geração 16-bit, e a trilha sonora combina magistralmente com sua atmosfera sombria.

SUPER METROID - The Perennial Masterpiece | GEEK CRITIQUE

Wikia: Super Metroid


* Para jogadores normais. Viciados terminam-o coletando 100% dos itens em cerca de 1 hora.

terça-feira, 17 de janeiro de 2017

SUSE dentro do Windows 10

Make Windows green again – Part 1 (SUSE Blog) (via Thurrott.com)

É possível trocar o espaço de usuário básico do Ubuntu usado pelo Windows Subsystem for Linux (WSL) do Windows 10 pelo do (open)SUSE. Confesso que me sinto mais confortável no ambiente verde do camaleão.

E tem isto (não testei): https://github.com/RoliSoft/WSL-Distribution-Switcher.