Usando o MemTest86 em UEFI
Um dos primeiros posts deste blog foi sobre como usar o Memtest86+.
Desde lá, a PassMark comprou o projeto original (sem o +) e voltou a desenvolvê-lo exclusivamente para UEFI (atual versão 7.x). A antiga versão 4.x (BIOS-only) foi descontinuada. O fork Memtest86+ também parece ter sido abandonado.
É disponibilizado um programa para criar pendrive booteável, mas, para quem apenas quer a versão UEFI, é exagero. Visto que o firmware sabe ler FAT e FAT32, basta copiarmos a pasta EFI da imagem ISO. Funciona com Secure Boot.
Postado por Marcos FRM às 07:30 2 comentários:
Windows 10 1709 e compartilhamentos sem autenticação
Foram notícia, quando a versão 1709 saiu, as mudanças feitas pela Microsoft no servidor e cliente SMB:
SMBv1 (Windows XP/Server 2003 e anteriores) foi aposentado. Com exceção de certos NAS rodando versões caducas do Samba, SMBv1 não faz mais falta.
Outra mudança mais sutil deu as caras nas versões Server, Enterprise e Education:
Acesso a compartilhamentos sem autenticação, através da conta Convidado, são bloqueados. Tais compartilhamentos são habilitados, no Windows, selecionando "Desativar compartilhamento protegido por senha" em "Central de Rede e Compartilhamento → Alterar as configurações de compartilhamento avançadas", ou ao usar map to guest = Bad User no Samba.
Mesmo não sendo boa prática, é algo comum em pequenas redes.
Para voltar a acessá-los:
Ou via GPO:
Configuração do Computador → Modelos Administrativos → Rede → Estação de trabalho do LANMAN
Habilitar logons de convidados não seguros (Habilitado)
Postado por Marcos FRM às 16:34 Um comentário:
Marcadores: gpo, samba, windows
Depois que o MPC-HC foi descontinuado, precisava substituí-lo. Usar software abandonado traz riscos, pois falhas de segurança não são corrigidas.
VLC é o candidato ao posto. Infelizmente, a versão 2.2.8 não está em bom estado no Windows. Decodificação via GPU não funciona e, mesmo ao usar a CPU, o desempenho é ruim. Alguns vídeos que tocam perfeitamente no MPC-HC engasgam no VLC.
Partes importantes do programa foram reescritas na recém lançada versão 3.0.0, resolvendo vários bugs. Passou a ser meu novo tocador de vídeos no Windows (no Linux o é faz tempo).
Lista de mudanças: NEWS.
Postado por Marcos FRM às 15:11 2 comentários:
Como evitar que o Windows 10 apague o cache de miniaturas
Depois que o Windows 10 atualizou para a versão 1709, codinome Redstone 3, vulgo Fall Creators Update, o cache de miniaturas do Windows Explorer passou a ser apagado automaticamente no mínimo uma vez por dia. Horrível, pois, ao acessar pastas com muitas imagens e vídeos, as miniaturas são recriadas, tornando a navegação lenta e a busca difícil.
Não tenho ideia da motivação por trás desse comportamento. Ou se é apenas bug. No Microsoft Community, achei esta dica:
Até agora resolveu!
Postado por Marcos FRM às 17:40 Nenhum comentário:
Usando o sfdisk
Os programas cfdisk, fdisk e sfdisk, da suíte util-linux, voltaram a ser desenvolvidos de uns anos para cá. São particionadores modernos, que levam em conta a topologia do disco ao alinhar as partições e suportam GPT.
Me concentrarei no sfdisk, a ferramenta scriptável. Existem duas formas de fornecer-lhe entrada.
Esta é mais simples:
início tamanho tipo booteável
Os campos são separados por espaços, vírgulas ou ponto e vírgulas (uso vírgulas). Ao ser omitido, o programa adota um valor padrão para cada campo:
início:    primeiro setor livre
tamanho:   máximo disponível
tipo:      partição Linux, 0x83 (MBR/MS-DOS), 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (GPT)
(ver sfdisk(8) para outros tipos)
booteável: desabilitado (MBR/MS-DOS apenas)
Ao criar mais de uma partição, cada uma é representada por uma linha. Exemplo:
,50G,L,*
- início: vazio (nada antes da vírgula), corresponde ao primeiro setor disponível, que, num disco limpo, considerando o alinhamento, equivale ao setor 2048.
- tamanho: 50 GiB (pode ser arredondado devido ao alinhamento).
- tipo: L é um atalho para partição Linux.
- booteável: * significa habilitado (vazio ou - significa desabilitado).
- início: vazio (nada antes da vírgula), corresponde ao primeiro setor após a partição anterior de 50 GiB (pode ser arredondado devido ao alinhamento).
- tamanho: vazio (nada entre as vírgulas), máximo disponível.
- booteável: vazio (desabilitado).
Especificar tipo L é opcional, visto que é o padrão. Contudo, coloco mesmo assim para ajudar na organização.
Tipo de particionamento é especificado através da opção --label, cujos valores possíveis são dos, gpt, sun e sgi (os dois últimos não têm utilidade em PCs).
Voltando ao exemplo, podemos simplesmente enviar as linhas via STDIN:
# echo -e ',50G,L,*\n,,L' | sfdisk --label=dos /dev/sdx
# echo -e ',512M,U\n,,L' | sfdisk --label=gpt /dev/sdx
(U é EFI System Partition)
Como discutido em Assinaturas, temos opções para evitar colisões de assinaturas: --wipe para o disco inteiro e --wipe-partitions para partições.
Para passar o rodo num disco já particionado e recomeçar do zero:
# echo -e ',50G,L,*\n,,L' | sfdisk --wipe=always --wipe-partitions=always --label=dos /dev/sdx
Cria novo rótulo (nova tabela de partições), apagando todas eventuais assinaturas presentes.
Ambas passaram a funcionar sem bugs a partir da versão 2.30 da suíte util-linux.
Ao usar --wipe=always, existe uma grande probabilidade do udevd interferir no processo. O sfdisk apaga a assinatura de disco existente antes de continuar. Isso gera um uevent — o disco deixou de ser particionado momentaneamente —, que dispara processamento do udevd, com finalidade de atualizar suas propriedades. O sfdisk pode falhar em informar ao kernel quando o novo particionamento for completado se o udevd ainda estiver mantendo o dispositivo aberto.
Existe uma API que suprime o processamento de uevents enquanto uma trava exclusiva for mantida no dispositivo.
# echo -e ',50G,L,*\n,,L' | flock /dev/sdx sfdisk --wipe=always --wipe-partitions=always --label=dos /dev/sdx
A invocação de flock garante que o comando não falhará. Caso o udevd esteja trabalhando no dispositivo, flock aguarda. E, quando sfdisk finaliza, a trava é removida e o processamento de uevents recomeça.
Por fim, chamamos udevadm settle depois do particionamento. Assim, garantimos que a fila de eventos do udevd estará vazia quando passarmos para os próximos comandos do script. Os dispositivos das partições (/dev/sdx1, /dev/sdx2, etc) estarão prontos, livres de quaisquer assinaturas anteriores, para serem formatados com seu sistema de arquivos preferido.
Postado por Marcos FRM às 17:59 Nenhum comentário:
Sem antivírus? Windows Update ficará empacado
Quem não usa antivírus precisa adicionar esta chave no registro, pois do contrário o Windows Update não baixará as atualizações KB4056892 (Windows 10 1709), KB4056891 (Windows 10 1703), KB4056890 (Windows 10 1607), KB4056898 (Windows 8.1) e KB4056897 (Windows 7):
Mitigam as falhas de segurança Meltdown (Intel) e Spectre (variante 1; Intel e AMD). Já a variante 2 da Spectre (Intel e AMD) só com atualização de BIOS/UEFI ou recompilação dos programas por um compilador que implemente retpolines.
Postado por Marcos FRM às 08:44 8 comentários:
Terminei de ler os três livros da série: Divergente, Insurgente e Convergente. Legais, apesar dos constantes questionamentos amorosos de Tris cansarem, principalmente no primeiro.
Daí fui assistir aos filmes... que decepção.
Em Divergente, até que o roteiro ficou mais ou menos dentro da história. O final, quando Quatro comanda a simulação de ataque, é modificado, porém dá para engolir com boa vontade.
Em Insurgente, começa a invencionice. Partes que me irritaram: o interrogatório de Tris e Quatro na sede da Franqueza, o esfaqueamento de Eric por Tris, suprimido do filme, a rendição espontânea de Tris à Erudição, sua quase execução e o assassinato de Jeanine.
Quatro, no interrogatório, é frio como de costume. Tris, naquela altura, não é mais tão sentimental. Sente-se angustiada por ter matado seu amigo Will. Remói-se em pensamentos quando lembra disso, mas não perde o controle. Resite ao soro da verdade e decide falar sobre o assunto por escolha. Entristecida, coloca para fora, mesmo sabendo que arruinará a amizade com sua melhor amiga Christina. Ao contrário da palhaçada do filme, onde Tris tem um ataque de choro.
A partir da rendição de Tris à Erudição, o filme esculhamba para valer. No livro, Tris — depois de salva por Peter —, traindo Quatro, tenta impedir que Tori, comandande da Audácia e líder da revolta junto com Evelyn e seu exército sem-facção, mate Jeanine, mas acaba não conseguindo. Terminada a revolta, Evelyn sobrepuja Tori e passa a comandar a cidade, acabando com as facções. Surgem os Leais, grupo revolucionário defensor das mesmas. Esse grupo começa o próximo livro, Convergente. Isso tudo está modificado ou inexistente no filme. E a tal da caixa com a mensagem de Edith Prior não existe no livro. Quatro, obrigando Caleb a ajudá-lo, acha a gravação no laboratório de Jeanine.
A série Divergente é uma ficção crível. Excetuando-se uma passagem que outra um pouco forçada, não há elementos futurísticos caricatos. No entanto, na adaptação para cinema de Convergente, fizeram uma baboseira realmente inviável, cuja fidelidade à história é zero. Para piorar, é um daqueles filmes que abusam de efeitos especiais, sem parar. Intragável. Nem mesmo a morte de Tris, a protagonista!, no final é seguida. A propósito, não gostei que Tris tenha morrido. :-(
Como sempre: prefira os livros.
Postado por Marcos FRM às 15:16 Nenhum comentário:
PCID/INVPCID: fundamentais agora em hardware Intel
Para não comprometer demais o desempenho de programas que dependam muito de chamadas de sistema, os patches que mitigam a falha Meltdown têm requerimentos importantes, para os quais ninguém dava bola antes: PCID (Process-Context IDentifier) e a instrução INVPCID (INValidate Process-Context IDentifier).
PCID está presente desde os Intel Sandy Bridge, a segunda geração dos i3/i5/i7. INVPCID está presente desde os Haswell, a quarta geração.
Windows requer INVPCID para não precisar recorrer a flushes de TLB a cada interrupção ou troca de contexto. Linux requer pelo menos PCID.
No Linux, procure por pcid e invpcid na linha flags de /proc/cpuinfo (ou na saída de lscpu). No Windows, use o Coreinfo (asterisco ao lado de PCID e INVPCID).
Nota 1: PCIDs são suportados apenas em x86-64.
Nota 2: Processadores AMD não são afetados.
Postado por Marcos FRM às 09:29 Nenhum comentário:
Marcadores: hardware, linux, segurança, windows
Sobre as falhas Meltdown e Spectre:
https://groups.google.com/forum/m/#!topic/mechanical-sympathy/L9mHTbeQLNU
https://www.renditioninfosec.com/files/Rendition_Infosec_Meltdown_and_Spectre.pdf
https://fedoramagazine.org/kpti-new-kernel-feature-mitigate-meltdown/
https://sites.google.com/a/chromium.org/dev/Home/chromium-security/ssca
Como sempre: atualize seu sistema operacional, programas (navegadores, especialmente!) e BIOS/UEFI.
Mesmo assim, solução definitiva apenas com novo hardware...
Gostei dos logotipos.
Postado por Marcos FRM às 19:22 Nenhum comentário:
486 ainda é levado em conta no GNU/Linux
https://lists.freedesktop.org/archives/systemd-devel/2017-December/040054.html
https://github.com/systemd/systemd/commit/d31b0033b7743393562a2e9d3c1e74afea981c13
Agora você, que ainda usa um 486, precisa achar uma distribuição que gere seus binários com o conjunto de instruções do velho processador, o que está cada vez mais difícil.
A instrução CPUID existe desde a safra final dos 486 da Intel (os com alimentação de 3,3V, acho...).
Postado por Marcos FRM às 17:46 Um comentário:
Marcadores: baú, hardware, linux, systemd
Adaptador USB-Serial HL-340
Este adaptador genérico (USB ID 1a86:7523) é encontrado por menos de 20 reais. Durabilidade parece não ser das melhores, mas para uso esporádico serve.
Driver para Windows está aqui:
No Linux, existe suporte nativo através do módulo ch341. O dispositivo /dev/ttyUSB0 será criado automaticamente.
Uma utilidade para as portas seriais (enquanto elas ainda existem)
Postado por Marcos FRM às 14:50 Nenhum comentário:
Marcadores: drivers, hardware, linux, windows
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[1] 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...
[1] 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.
Postado por Marcos FRM às 16:11 4 comentários:
Marcadores: chrome, firefox
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.
Luminist - Super Metroid: Resynthesized - Brinstar - Overgrown
→ strafefox - Documentários sobre videogames antigos. Muito informativo. Produção profissional.
→ Classic Gaming Quarterly - Idem.
Postado por Marcos FRM às 15:26 Nenhum comentário:
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.