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.