terça-feira, 8 de agosto de 2017

Firefox com múltiplos processos

A primeira etapa do projeto Electrolysis (e10s) foi completada no Firefox 49. Não havendo extensões incompatíveis*, o navegador usa três processos: um para a interface, um para o conteúdo das abas e outro para os plugins.

Esse processo separado para a interface acabou com o vexatório cenário de parecer tudo travado quando sites pesados eram carregados.

Contudo, os conteúdos das abas ainda compartilhavam o mesmo processo. Um aba ocupada trancava as demais.

No Firefox 54, a segunda etapa do projeto (e10s-multi) começou a ser implementada. Desde que nenhuma extensão bloqueie, quatro processos para o conteúdo das abas são ativados (sob demanda) de acordo com uma probabilidade estabelecida pela Mozilla. Me perdi seguindo o código, porém acho que começou com 1% dos usuários. Na recém lançada versão 55, a proporção passou a ser de 50%.

Portanto, a partir da versão 55, número considerável de usuários rodará com múltiplos processos. Em about:support, olhe as linhas "Janelas multiprocesso" e "Web Content Processes". Se na primeira aparecer 1/1 e na segunda X/4, está ativo. Quem quiser habilitar manualmente, basta ir em about:config e configurar dom.ipc.processCount com 4.

Vinha rodando com quatro processos (configurados manualmente) desde o Firefox 54. Porém foi agora no 55 que realmente notei grande diferença. O navegador está mais ágil. Finalmente.


* É necessário declararem que funcionam com mais de um processo. Há desenvolvedores de extensões, no entanto, que não estão nem aí e até o momento não deram a mínima para isso. Dois exemplos: Ubuntu Modifications (Ubuntu e derivados) e Kaspersky Protection do antivírus homônimo (Windows). Nesses casos, nem mesmo a interface roda num processo separado. Total falta de respeito com os usuários. Que venha logo o Firefox 57, que suportará apenas WebExtensions, compatíveis out-of-box.

domingo, 6 de agosto de 2017

Driver de áudio Realtek que funciona em chipset SiS

Vamos programar o Delorean para voltar a 2007 mais ou menos. Quando a SiS ainda produzia alguns poucos chipsets. Em conjunto com CODECs de áudio da Realtek (ALC268 + SiS 672 especialmente), usando o driver High Definition Audio nativo do Windows 7 ou o oficial da Realtek, resultava em som falhado, com cliques, interrupções.

A empresa disponibilizou um driver modificado que resolve o problema. Está no FTP deles:

OnlyFor_SiS_Chipset_5898_PG281_VISTA_TurnOff_PullMode_Upd.zip

Usuário: enduser
Senha: enduser256

(fonte)

quarta-feira, 2 de agosto de 2017

Windows 10 não cria disquete de boot com MS-DOS

Chocado fiquei ao me deparar com este commit do Rufus.

Até o 8.1, a imagem usada desde o Windows ME para criar disquetes de boot com o MS-DOS 8.0 estava embutida em %WINDIR%\System32\diskcopy.dll. O Rufus usava-a para criar pendrives de boot com o MS-DOS. No Windows 10, o arquivo foi removido. Realmente, na janela de formação do Windows, em "Opções de formatação", não existe mais a opção "Criar um disco de inicialização do MS-DOS"!

Não que faça diferença, pois o FreeDOS dá conta do recado para a única tarefa ainda relevante em sistemas DOS: atualização de BIOS e firmwares.

Tropecei nisso dando uma revigorada no Guia de atualização de BIOS.

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).