domingo, 19 de novembro de 2017

Bem-vindo, Chrome

Depois de quinze anos com o Firefox sendo meu navegador principal, migrei para o Chrome. A principal motivação foi o mau estado do Firefox para Android e Linux. Em ambas plataformas, o Chrome é muito superior. Preciso ter meus favoritos, senhas, abas, sincronizadas. Manter navegadores diferentes em cada dispositivo está fora de cogitação.

Firefox para Android é pesadíssimo (não era alguns anos atrás); funciona mal em aparelhos com 1 GiB de RAM. Na versão para Linux, bugs se acumulam e recursos são preteridos.

Parabenizo o empacotador do Chromium* do Arch, Evangelos Foutras. Faz excelente trabalho, sempre em contato com os desenvolvedores do Google. Os bugs do pacote não caem no esquecimento e, quando não são resolvidos, pelo menos são encaminhados.

Para não ficar só no elogio, o Chrome para Windows desde a versão 52 renderiza fontes exclusivamente via DirectWrite, API adicionada no Windows 7. Com drivers de vídeo recentes, é excelente. No entanto, com drivers antigos, o resultado com texto pequeno agrada pouca gente. Isso me lembra que está na hora de trocar de PC...


* Quase não há diferença entre Chrome e Chromium, além deste ter código fonte disponível e não trazer a marca do Google. Fico com a facilidade de tê-lo diretamente no repositório.

terça-feira, 7 de novembro de 2017

Recomendações de canais do YouTube

Nada mais deprimente do que a seção em alta do YouTube. Contudo, sob a superfície, existe muito material excelente lá. Aqui vão algumas recomendações relacionadas a videogames.

lara6683 - Simpática, bonita e competente pianista, violinista. Destaque para suas interpretações de trilhas sonoras de videogames.

Lara plays the Dark World Theme from Zelda: A Link to the Past
Lara plays the Rocky Maridia theme from Super Metroid

Luminist - Conhece as trilhas sonoras de Metroid e Super Metroid? Então imagine-as interpretadas usando um sintetizador KORG MS-20 Mini mais alguns samples escolhidos a dedo. Nova vida às faixas originais. Tem também material de autoria própria, igualmente excepcional.

Metroid - Title Theme (Analog Synth remake)
Luminist - Super Metroid: Resynthesized - Brinstar - Overgrown

strafefox - Documentários sobre videogames antigos. Muito informativo. Produção profissional.

The Making of Sonic The Hedgehog : Inspirations
The Making of Donkey Kong Country

Classic Gaming Quarterly - Idem.

The Launch of the Sega Genesis (1989)
The Launch of the Super Nintendo (1991)

domingo, 5 de novembro de 2017

Um novo XFCE


Adotei o XFCE como ambiente desktop faz alguns meses. Fora das personalizações estéticas, é tudo padrão do Arch, que, por sua vez, é fiel ao upstream.

Portanto, Xfwm é o gerenciador de janelas, ou compositor. Até a atual versão 4.12, nenhuma estratégia para evitar tearing é usada. Os efeitos são tão visíveis que prejudicam até navegação na internet.

Na versão de desenvolvimento 4.13, os quadros, depois de montados com XRender, são exibidos via XPresent, extensão relativamente recente (2013) do protocolo X11, que depende de drivers que implementem DRI3. Drivers abertos são compatíveis; proprietários, não. Como fallback, o código também passou a suportar OpenGL, mas não tenho como testar. Segundo discussões no Bugzilla, XPresent/DRI3 exige menos do hardware gráfico e por isso tem preferência.

Decidi arriscar e migrei para o Xfwm 4.13 com ajuda do AUR. Demais componentes do XFCE ficaram nas versões oficiais do repositório. Minha "GPU" é uma Intel GM45 e uso o driver modesetting[1] do Xorg.

A diferença é simplesmente impressionante para quem estava acostumado com tearing infernal. Não há mais tearing! Nenhuma configuração especial é requerida[2]. Afinal, estamos em 2017. Será sem dúvida o principal diferencial do futuro XFCE 4.14.


[1] De uns tempos para cá, as principais distribuições dão preferência ao driver modesetting em hardware Intel minimamente recente (Gen4+). Nesse driver, 2D é acelerado quando possível com OpenGL.
[2] Até a versão 4.12, existe a opção "Sincronizar desenho ao branco vertical" (em "Configurações → Ajustes do gerenciador de janelas → Compositor"). Não serve para nada e foi removida na 4.13.

domingo, 22 de outubro de 2017

Novidade na mídia de instalação do Windows 10 1709

Na versão 1709, codinome "Redstone 3", a mídia do MSDN ("multi-edition") traz mais versões!


Antes, vinha apenas com a Home e a Pro. A presença da Home Single Language, especialmente, é bem-vinda. \o/

sexta-feira, 29 de setembro de 2017

Timeout ao desmontar compartilhamento SMB durante o desligamento

Pontos de montagem autofs são úteis para compartilhamentos de rede. Com o systemd, basta adicionar, em /etc/fstab, x-systemd.automount nas opções. Exemplo:

//192.168.0.10/Arquivos /mnt/Arquivos cifs credentials=/etc/senha-servidor,uid=marcos,gid=marcos,file_mode=0600,dir_mode=0700,x-systemd.automount 0 0

Isso evita que precisemos habilitar um serviço que implemente network-online.target, como NetworkManager-wait-online.service ou systemd-networkd-wait-online.service. Assim, não há atraso durante a inicialização. Apenas quando o ponto de montagem for acessado será montado.

Porém, durante o desligamento, a desmontagem sempre dava timeout e causava atraso com o NetworkManager ao usar conexões sem fio.

Analisando a cadeia de dependências, nada achei de errado. Estava em outro lugar o problema. O nm-applet, aquele programinha que fica no tray, salva conexões sem fio*, pelo menos ao usar o plugin nativo keyfile, com o parâmetro connection.permissions configurado para o usuário corrente. Isso diz para o daemon que, quando o usuário fizer logout, a conexão deve ser finalizada. Como o logout ocorre antes do processo de desligamento, a rede é desconectada cedo demais e a desmontagem falha. Portanto, precisamos tornar a conexão global, não restrita a usuário algum. Podemos fazer via nm-connection-editor:

Marcar "Todos os usuários podem conectar a esta rede"

Ou através da linha de comando:

$ nmcli connection modify <ssid> connection.permissions ""

(substituindo <ssid> pelo nome da rede)


* Conexões cabeadas são globais por padrão.

domingo, 27 de agosto de 2017

FSArchiver 0.8.2 suporta melhor o EXT4

Mais recursos são preservados: 64bit, inline_data, metadata_csum, project, sparse_super2.

Ao restaurar imagens de sistemas de arquivos EXT num dispositivo igual ou maior do que 16 TiB (considerando blocos de 4 KiB), o programa comporta-se da seguinte forma.

Sistema de origem EXT2 ou EXT3:

- O programa abortará. EXT2 e EXT3 não suportam volumes dessa capacidade. A mensagem de erro recomendará um quebra-galho: adicionar mkfs=ext4 (exemplo: fsarchiver restfs imagem.fsa id=0,dest=/dev/sdxy,mkfs=ext4). No entanto, o sistema EXT4 criado dessa maneira terá um conjunto de recursos reduzido. Use em último caso.

Sistema de origem EXT4:

- Se e2fsprogs < 1.42, o programa abortará. É versão mínima que suporta 64bit.

- Se e2fsprogs ≥ 1.42, os recursos 64bit e uninit_bg serão automaticamente habilitados, mesmo que não estejam presentes na imagem. O segundo é opcional, porém sem ele a formatação de dispositivos grandes demora uma eternidade (dependendo da velocidade, vários minutos!). Como trata-se de recurso antigo, presente desde o tempo em que o EXT4 foi declarado estável (lá no kernel 2.6.28), optou-se por sempre habilitá-lo. O sistema de arquivos já sofreu upgrade mais drástico de qualquer jeito — 64bit quebra compatibilidade de leitura e escrita com versões do kernel e programas que não o suportem; uninit_bg, por outro lado, quebra apenas de escrita. Por fim, para prevenir bug presente entre as versões 1.42 e 1.42.9 do mke2fs, resize_inode é sempre desabilitado.

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 igual ou 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 com essa capacidade: 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 a opção e cujo tamanho atinja 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.