quinta-feira, 29 de dezembro de 2016

Maldito Bluebirds dos drives ópticos LG

A LG andou colocando em alguns de seus drives ópticos um software inútil para Windows chamado Bluebirds. Depois, ao constatarem a burrada, disponibilizaram atualizações de firmware removendo-o.

Este aqui é um GH22NS50 com firmware TN00:



A porcaria aparece como um disco (CDFS) enquanto uma mídia de verdade não for inserida.

segunda-feira, 26 de dezembro de 2016

sexta-feira, 16 de dezembro de 2016

Novidades do XFS

EXT4 é legado

Upcoming XFS Work in Linux v4.8 v4.9 and v4.10+ (Oracle Mainline Linux Kernel Development)

Darrick J. Wong, da Oracle, juntou-se ao time de desenvolvimento do sistema de arquivos XFS e tem feito contribuições significativas.

No kernel 4.8, foi adicionada mais uma árvore B+, que mapeia, dentro dos metadados, cada bloco a seu dono[1]. Na versão 4.9, foi introduzido suporte ao compartilhamento de extents, cujo pilar é outra outra árvore B+[2]. Assim, copy-on-write[3], um dos diferenciais do Btrfs, chega ao XFS[4].

Ambos recursos dependem do formato V5 e são experimentais.

A árvore B+ adicionada no kernel 4.8 (rmapbt) será aproveitada a partir do kernel 4.11, que, confirmado o cronograma, trará capacidade de autoconsertar alguns problemas na estrutura do sistema de arquivos sem precisar desmontá-lo. Dependerá, no espaço de usuário, da ferramenta xfs_scrub da suíte xfsprogs[5], que interagirá com o kernel através de uma nova requisição da chamada de sistema ioctl()[6].

Levando em conta como o formato V5 foi desenvolvido, suponho que demore cerca de um ano para tais novidades maturarem.

Durante a instalação, o Red Hat Enterprise Linux 7.3 cria XFSv5 (sem finobt/spinodes). Do 7.0 ao 7.2, era criado XFSv4. Aos poucos, o novo formato e seus recursos são adotados em ambientes de produção.


[1] xfsprogs 4.8.0+: mkfs.xfs -m rmapbt=0|1.
[2] xfsprogs 4.9.0+: mkfs.xfs -m reflink=0|1.
[3] User notes on dedupe (Btrfs wiki); XFS has gained super CoW powers!.
[4] XFS não suporta subvolumes como o Btrfs; portanto, apenas arquivos individuais podem ser reflinkados; como exemplo de implementação, ver este commit do systemd.
[5] xfsprogs 4.11.0+ provavelmente.
[6] XFS_IOC_SCRUB_METADATA, que dependerá da opção CONFIG_XFS_ONLINE_REPAIR, desabilitada por padrão enquanto for experimental.

sexta-feira, 9 de dezembro de 2016

ReCore


Armação K-9 (cão) com núcleo azul de personalidade "Mack"; Joule Adams, a heroína

ReCore (Xbox One): https://www.recoregame.com

Mesmo não tendo a mesma qualidade de Rise of the Tomb Raider, gostei do jogo. Pena ReCore ser bem bugado. Numa das masmorras, entre uma sala e outra, o motor do jogo simplesmente falhou em renderizar o cenário inteiro, que ficou 100% branco. Arrisquei fazer Joule "entrar" ali: "caiu" por vários segundos no branco total até morrer. Bug bizarro. Além de vários outros glitches menores, como objetos que podem ser parcialmente atravessados e regiões nas beiradas dos cenários em que Joule não tem mais como subir e, se cair e morrer, o último ponto de salvamento retorna ao local sem saída. Depois que terminei-o, saiu uma atualização. Tomara que comecem a diminuir a quantidade de bugs.

quinta-feira, 8 de dezembro de 2016

Windows 10 rodará sobre ARM

Thinking About x86 Emulation on ARM (Thurrott.com)
ARM-Based Windows 10 Portable PCs!? Hell Yes! (Thurrott.com)

Não. Não trata-se de um novo Windows RT. É o Windows 10 de verdade. Mais: será capaz de rodar programas Win32 (x86) graças a um emulador que a empresa está desenvolvendo. Virá após a atualização Redstone 2 ("Creators Update"), lá pelo final de 2017.

Haverá certo impacto no desempenho ao rodar programas Win32. No entanto, com os avanços dos SoCs ARM, será suficiente para códigos não tão exigentes. Aqueles que precisarem de máximo desempenho, poderão requerer hardware x86 ou disponibilizar uma versão ARM nativa (algo que deverá envolver alguns ajustes e uma recompilação). Acredito que o atual esforço de padronizar a plataforma ARM com UEFI+ACPI está dentre os pilares técnicos da decisão.

Grande notícia! Ninguém mais aguenta o monopólio (ou oligopólio caso a AMD consiga sair das cordas com o Zen) do mercado de processadores x86. O anúncio trata exclusivamente de SoCs da Qualcomm. Não é de duvidar, porém, que, caso faça sucesso, chips de outros fabricantes sejam certificados para rodar o sistema. É do interesse da Microsoft estancar a sangria de usuários. O Windows está entrincheirado em vários mercados, mas, para o mero consumidor de conteúdo, a tendência nos próximos anos é o sistema operacional gradualmente ir perdendo relevância. Ter o Windows 10 rodando em, digamos, SoCs baratos da MediaTek é uma forma de combater isso. Ademais, como especula Paul Thurrott, a mesma tecnologia pode ser levada ao Windows 10 Mobile.

quarta-feira, 7 de dezembro de 2016

sexta-feira, 18 de novembro de 2016

segunda-feira, 31 de outubro de 2016

Windows Update do 7 finalmente consertado

Já circula pelos fóruns a notícia. A lentidão insuportável do Windows Update do 7 é consertada pela atualização KB3172605, como descrito neste artigo da Microsoft.

Atualizei o post sobre o assunto: Windows Update do 7 é uma lesma (II)

quarta-feira, 19 de outubro de 2016

NCQ TRIM

A opção de montagem discard em geral prejudica o desempenho, pois os comandos TRIM esvaziam a fila NCQ, aumentando a latência. A especificação SATA 3.1 (julho de 2011) traz NCQ TRIM, async TRIM, que não drena a fila e, em teoria™, não prejudica o desempenho[1].

Foi adicionado ao kernel 3.12:

libata: Add support for SEND/RECEIVE FPDMA QUEUED
libata: Add support for queued DSM TRIM

O dispositivo precisa dizer ao sistema operacional que suporta o recurso. De alguns anos para cá, estão disponíveis SSDs com a tecnologia no mercado. Infelizmente, com uma tonelada de bugs. Muitos firmwares simplesmente corrompem dados ao receberem comandos NCQ TRIM. Foi necessário criar uma lista negra de modelos e versões de firmware com suporte quebrado (ver arquivo drivers/ata/libata-core.c no código fonte do kernel).

Na versão 4.2, ficou mais fácil ver o estado do suporte via sysfs, bem como habilitar ou não através de opções de boot:

libata: Expose TRIM capability in sysfs
libata: Allow NCQ TRIM to be enabled or disabled with a module parameter

Até o momento, a recomendação continua sendo não usar a opção discard e rodar o fstrim de vez em quando. Inclusive a suíte util-linux distribui fstrim.service e fstrim.timer com essa finalidade.

Quem tiver um SSD moderno, com firmware atualizado, e /sys/class/ata_device/devX.Y/trim contiver queued, pode arriscar adicionando discard no fstab e desabilitando TRIM periódico (batched discard) com systemctl disable fstrim.timer (Ubuntu usa um script em /etc/cron.weekly/fstrim; comentá-lo deve servir). Não me responsabilizo se você perder todos seus dados.


[1] Sempre há otimizações a serem feitas nos sistemas de arquivos, como estas propostas para o XFS por Christoph Hellwig.

quarta-feira, 12 de outubro de 2016

Fontes de PCs Dell

Fontes de PCs compactos (Small Form Factor — SFF) da Dell usam geralmente dois formatos de uns tempos para cá:

SFX low-profile (5 cm x 10 cm) ou TFX (6,5 cm x 8,5 cm).

Enquanto modelos antigos usavam LFX (6,2 cm x 7,2 cm).

Neste artigo do Clube do Hardware há mais informações sobre os padrões.

O problema é achar para vender algo de boa qualidade nesses formatos. TFX é um pouco menos difícil de encontrar sem recorrer à Dell (mas, é claro, no Brasil o grau de dificuldade é sempre maior). Temos os modelos, dentre as marcas nobres, FSP FSP300-60GHT, SeaSonic SS-300TFX e SS-350TGM.

Infelizmente, parece que a empresa tem usado formatos proprietários nos seus PCs SFF recentes. E nem todas as séries, nas versões minitorre (MT), trazem fontes ATX convencionais; gambiarras estão descartadas, porque o gabinete é estreito demais.

Pelo jeito, garantia de poder trocar de fonte à vontade só nos XPS, que usam o padrão ATX convencional. Nos Precision minitorre mais simples (série 3000)[1], até é possível trocar por outra não original, visto que o tamanho é compatível, porém é necessário um adaptador, pois a Dell fez o favor de substituir o tradicional conector ATX de 24 pinos por uma estrovenga de 8 pinos[2].


[1] A série 5000 usa outra jabuticaba. Ok, sendo justo com a Dell, o objetivo daquela plaquinha é tornar a fonte destacável. Substituível sem necessidade de mexer nos cabos internos. Supõe-se que quem compra uma máquina cara assim possa arcar com peças originais mais tarde.
[2] Os OptiPlex MT antigos eram assim também.

domingo, 25 de setembro de 2016

Soquete AM4 dá as caras

AMD 7th Gen Bristol Ridge and AM4 Analysis: Up to A12-9800, B350/A320 Chipset, OEMs first, PIBs Later (AnandTech)

Aí está o futuro da AMD. Soquete unificado, que servirá para todas as famílias de processadores da empresa.

Vejam o provável roadmap da AMD aqui (segunda página do artigo). Infelizmente, a microarquitetura Zen de início será usada apenas no segmento high-end. APUs continuarão com uma derivada da Bulldozer (Excavator v2), um tapa buraco. Espero que consigam colocar em pouco tempo os núcleos Zen em toda sua linha de processadores.

Estamos a poucos meses de termos processadores decentes da AMD. Há anos não vemos um...

quinta-feira, 25 de agosto de 2016

APNG será suportado no Chrome

The GIF Is Dead. Long Live the GIF. (Popular Mechanics) (via OSNews)

GIF, uma antiguidade que resiste ao caixão. Em grande parte pela falta de consenso entre os navegadores — principalmente depois que o reinado do Internet Explorer começou a acabar. Sem amplo suporte, os concorrentes modernos do GIF não ganharam tração.

APNG (Animated PNG) é suportado faz tempo no motor Gecko (Firefox) e no Presto (Opera antigo). No ano passado, foi adicionado ao WebKit (Safari). A grande notícia é que será implementado também no Blink (Chrome, Opera novo):

Animated PNG - Chrome Platform Status

As discussões haviam parado, mas nos últimos meses recomeçaram e a previsão é de até o fim do ano estar pronto.

Uma vez no Chrome, seu uso tende a aumentar e o GIF poderá ser aposentado ao poucos.

quarta-feira, 24 de agosto de 2016

ACLs e XATTRs nos principais sistemas de arquivos Linux

EXT4 XFS
POSIX_ACL CONFIG_EXT4_FS_POSIX_ACL CONFIG_XFS_POSIX_ACL
XATTR CONFIG_EXT4_FS_XATTR[1] sempre habilitado
SECURITY CONFIG_EXT4_FS_SECURITY CONFIG_XFS_SECURITY[2]
OP. MOUNT desnecessárias[3] desnecessárias

Btrfs JFS
POSIX_ACL CONFIG_BTRFS_FS_POSIX_ACL CONFIG_JFS_POSIX_ACL
XATTR sempre habilitado sempre habilitado
SECURITY sempre habilitado CONFIG_JFS_SECURITY
OP. MOUNT desnecessárias desnecessárias

ReiserFS
POSIX_ACL CONFIG_REISERFS_FS_POSIX_ACL
XATTR CONFIG_REISERFS_FS_XATTR
SECURITY CONFIG_REISERFS_FS_SECURITY
OP. MOUNT acl,user_xattr

Legenda:

- POSIX_ACL: configuração requerida para habilitar ACLs.
- XATTR: configuração requerida para habilitar atributos extendidos (XATTRs).
- SECURITY: configuração requerida para permitir o uso de XATTRs por módulos LSM (SELinux, Smack, etc.).
- OP. MOUNT: opções de montagem requeridas para habilitar ACLs e XATTRs.

As configurações dos três primeiros itens são definidas na hora da compilação e são controladas pelos empacotadores das distribuições. São recursos básicos, habilitados em praticamente todo lugar.

Caso complicado: EXT2/3/4

Desde o kernel 2.6.33 é possível usar o driver ext4 para montar volumes EXT2 e EXT3 (CONFIG_EXT4_USE_FOR_EXT23). No 4.3, o driver ext3 foi removido; portanto, o ext4 é sempre usado em volumes EXT3 a partir dessa versão. O driver ext2 continua disponível e a configuração para usar o ext4 em volumes EXT2 foi renomeada para CONFIG_EXT4_USE_FOR_EXT2. Levando em conta que desde o 2.6.38 o driver ext4 aplica as opções acl,user_xattr por padrão, caso sua distribuição tenha um kernel minimamente recente e habilite CONFIG_EXT4_USE_FOR_EXT23 ou CONFIG_EXT4_USE_FOR_EXT2 (a maioria habilita[4]), sistemas EXT2 e EXT3 também sempre terão suporte a ACLs e XATTRs sem precisar mexer nas opções de montagem.

Desde muito tempo atrás (lá na pré-história do kernel 2.4), sistemas EXT permitem que algumas opções de montagem pré-definidas sejam salvas em seus superblocos, o que possibilita, na hora da criação do sistema de arquivos, ao mke2fs (e seus atalhos de conveniência mkfs.ext2, mkfs.ext3 e mkfs.ext4) as definir. O mesmo pode ser feito posteriormente através da opção -o da ferramenta tune2fs. São respeitadas pelos três drivers, ext2, ext3 e ext4. A partir da versão 1.42, o mke2fs cria sistemas de arquivos EXT2/3/4 com as opções acl,user_xattr salvas no superbloco por padrão (redundante[5] com o driver ext4 desde o kernel 2.6.38). Note que as opções noacl,nouser_xattr, usadas para desabilitar os recursos, não podem ser armazenadas no superbloco[6]. Precisam ser passadas ao mount (via -o) ou postas no fstab.

Considerando volumes EXT2/3/4 com defaults em fs_mntops (fstab):

ACLs e XATTRs
Kernel ≥ 2.6.38 com
CONFIG_EXT4_USE_FOR_EXT23 ou
CONFIG_EXT4_USE_FOR_EXT2
habilitados
Kernel ≥ 2.6.38 sem
CONFIG_EXT4_USE_FOR_EXT23 ou
CONFIG_EXT4_USE_FOR_EXT2
EXT4: habilitados
EXT3 (kernel ≥ 4.3): habilitados
EXT3 (kernel < 4.3) e EXT2: dependem
das opções salvas no superbloco[7]
Kernel < 2.6.38 dependem das opções salvas
no superbloco

Ou seja, com exceção do ReiserFS, que ainda requer opções de montagem, os principais sistemas de arquivos vêm de fábrica com ACLs e XATTRs habilitados por padrão em distribuições modernas.


[1] A partir do kernel 3.8, a opção não existe mais e o suporte é sempre habilitado.
[2] A partir do kernel 2.6.26, a opção não existe mais e o suporte é sempre habilitado.
[3] Desde o kernel 2.6.38.
[4] CentOS 7+, Debian 8+, Ubuntu 14.04+, Fedora, openSUSE, Arch.
[5] Mesmo depois de remover as opções do superbloco com tune2fs -o ^acl,^user_xattr <dispositivo> e remontá-lo, o sistema de arquivos continuará suportando ACLs e XATTRs.
[6] Desde o kernel 2.6.35 e e2fsprogs 1.41.13, opções de montagem arbitrárias podem ser armazenadas no superbloco com tune2fs -E mount_opts="opção1 opção2 ..." <dispositivo>. No entanto, são interpretadas apenas pelo driver ext4 e não servem para noacl,nouser_xattr.
[7] Ver com tune2fs -l <dispositivo>.

terça-feira, 16 de agosto de 2016

Novidades do FSArchiver 0.8.0


- Suporta FAT16/32. Adicionado levando em conta seu uso em sistemas UEFI, para o volume da partição ESP (EFI System Partition).

- XFSv5 é restaurado mantendo a configuração -i sparse de acordo com o sistema original (desde a versão 0.6.24).

- É possível especificar na linha de comando, na ação restfs, uuid= e label=, que permitem substituir os valores armazenados na imagem. Muito útil para XFSv5, pois possibilita restaurar o sistema de arquivos com um UUID aleatório sem precisar aumentar o kernel mínimo requerido rodando xfs_admin depois, pois o UUID será passado diretamente ao mkfs.xfs (≥ 4.3.0) na hora de criá-lo. Isso também evita incompatibilidade com o GRUB, que até recentemente não suportava meta_uuid.

- Btrfs é restaurado preservando o UUID da imagem. Detalhe: mkfs.btrfs falha se já existir um sistema de arquivos com UUID igual, contudo. Nesse caso, a saída é especificar um novo através da opção uuid=.

Excelente programa. O melhor para clonagem de sistemas de arquivos Linux.

Meu script foi atualizado.

domingo, 14 de agosto de 2016

Ainda é possível atualizar do Windows 8/8.1 para o 10

Semana passada, instalei o Windows 10 1607 (compilação 14393, vulgo Redstone 1) Single Language do zero em um notebook Dell que estava com o 8.1 (este havia sido atualizado do 8 de fábrica). Não foi uma atualização. Apaguei o particionamento com o diskpart antes. O instalador nem pediu chave, sinal de que detectou e aceitou a gravada no firmware. Ao final, estava ativado.

Ontem, tive a oportunidade de testar o mesmo processo, porém num tudo em um da CCE que ainda rodava o Windows 8. Inicialização através da mídia, particionamento apagado, instalação do zero: instalador não pediu chave e o sistema ativou sem soluçar.

Então, pelo menos em máquinas com chaves do 8 e 8.1 no firmware, ainda está sendo possível atualizar para o 10 (lembrando que oficialmente a gratuidade acabou em 29 de julho deste ano). Melhor ainda: diretamente via instalação limpa. Vamos ver por quanto tempo.

segunda-feira, 1 de agosto de 2016

Personalizando as páginas de erro do Squid

O daemon monta as páginas com base nos esqueletos presentes em /usr/share/squid/errors/<locale>/. São servidas de acordo com a língua do cliente obtida do cabeçalho HTTP. Do arquivo /etc/squid/errorpage.css sai o estilo. Seu conteúdo é injetado no HTML dentro de um elemento <style>.

Pacotes RPM marcam /etc/squid/errorpage.css como %config(noreplace): ao ser editado localmente, nunca é substituído por cópia mais recente do pacote (/etc/squid/errorpage.css.rpmnew será criado caso necessário). No que diz respeito à aparência, esse arquivo é território do administrador.

Imagens precisam ser hospedadas num servidor web acessível aos clientes.

Aparência padrão

Mexendo um pouquinho no CSS.

--- /etc/squid/errorpage.css    2017-02-06 09:20:07.000000000 -0200
+++ /etc/squid/errorpage.css    2017-02-10 13:52:05.462396002 -0200
@@ -21,9 +21,10 @@
 html body {
     margin: 0;
     padding: 0;
-    background: #efefef;
     font-size: 12px;
     color: #1e1e1e;
+    background: url('http://centos.localdomain/interestelar.jpg') center top/cover no-repeat fixed black;
+    text-shadow: 3px 3px 5px lightgrey;
 }
 
 /* Page displayed title area */
@@ -31,15 +32,15 @@
     margin-left: 15px;
     padding: 10px;
     padding-left: 100px;
-    background: url('/squid-internal-static/icons/SN.png') no-repeat left;
+    background: url('http://centos.localdomain/cafe.png') left/90px no-repeat;
 }
 
 /* initial title */
 #titles h1 {
-    color: #000000;
+    color: white;
 }
 #titles h2 {
-    color: #000000;
+    color: white;
 }
 
 /* special event: FTP success page titles */
@@ -52,6 +53,8 @@
 #content {
     padding: 10px;
     background: #ffffff;
+    opacity: 0.8;
+    text-shadow: none;
 }
 
 /* General text */
@@ -101,4 +104,5 @@
 #footer {
     font-size: 9px;
     padding-left: 10px;
+    color: white;
 }

Aplicamos com systemctl reload squid.service.

Resultado:

Interestelar

(imagem daqui)

Fica menos monótono para os clientes. ☺

[Atualização - 10/02/2017] Colocar background-size dentro de background.

terça-feira, 26 de julho de 2016

XFSv5: nota para as distribuições (III)

Continua a saga (ver post anterior). Temos outra opção no mkfs.xfs causadora de incompatibilidade: -i sparse.

Está disponível a partir do mkfs.xfs 4.2.0. No kernel, a partir da versão 4.2. Recurso considerado experimental até o 4.7. No 4.8, será declarado estável e então não demorará para o mkfs.xfs habilitá-lo por padrão.

Tabela atualizada:

Kernel mkfs.xfs
≥ 2.6.23 e ≤ 3.12 -m crc=0 -n ftype=0
3.13 e 3.14 -m crc=0 -n ftype=1
3.15 -m crc=1,finobt=0 -i sparse=0
≥ 3.16 e ≤ 4.7 -m crc=1,finobt=1 -i sparse=0
≥ 4.8 -m crc=1,finobt=1 -i sparse=1
Versões requeridas do mkfs.xfs:

-m crc ≥ 3.2.0 -m finobt ≥ 3.2.1 -n ftype ≥ 3.2.0 -i sparse ≥ 4.2.0

-m crc=X,finobt=Y equivale a
-m crc=X -m finobt=Y

Reclamei dos novos recursos que quebram compatibilidade com versões anteriores do kernel. No entanto, pensando bem, não deixa de ser positivo, pois mostra um código em constante desenvolvimento, que não está morto como outros sistemas de arquivos (ReiserFS e JFS, por exemplo). E a quantidade de variáveis ainda é aceitável, dá para memorizar — ao contrário da loucura dos EXT.

Ainda sobre isso, o GRUB 2.02-beta3 adicionou suporte ao XFSv5, porém, em volumes com meta UUID configurado, falhava. Reportei o bug, que foi corrigido. Próxima tarefa é reportar outro relativo a volumes criados com -i sparse=1, não suportados pelo bootloader.

quarta-feira, 20 de julho de 2016

Ubuntu e o tal boot com "concurrency"

Como ativar todos os núcleos do seu processador no boot do Ubuntu (Diolinux)

O mau cheiroso script /etc/init.d/rc nem é executado no boot:

Mask /etc/init.d/rc and /etc/init.d/rcS from initscripts

Trata-se de entulho remanescente do tempo das cavernas.

Rode aí:
(Ubuntu 16.04)

$ systemctl is-enabled rc.service 
masked

Um serviço masked está super ultra desabilitado.

Tem influência no desempenho o serviço ondemand.service. Por padrão, o kernel do Ubuntu configura o escalonador de frequência de todos os núcleos com performance [1], que os mantêm sempre na frequência máxima nominal — faz sentido durante o boot, para usar ao máximo o hardware, sem preocupar-se com consumo elétrico. O serviço, depois de 60 segundos, altera todos os núcleos para ondemand, com objetivo de aproveitar os recursos SpeedStep, Cool'n'Quiet e similares. Até o Ubuntu 16.04, esse serviço é na verdade um script SysV (/etc/init.d/ondemand), suportado pelo systemd através do sysv-generator. No futuro Ubuntu 16.10, será um pouco diferente:

On Ubuntu, provide an "ondemand.service" that replaces /etc/init.d/ondemand

O shell script /lib/systemd/set-cpufreq é chamado através de um arquivo .service nativo, Type=idle, executado pelo systemd quando não houver mais jobs pendentes, em outras palavras, no final do boot. Outra mudança é que, ao ser detectado o uso do driver intel_pstate, o script não mexe no escalonador e mantém performance. Esse driver funciona de forma diferente do acpi-cpufreq e powernow-k8 e com ele não é recomendado usar ondemand (bons dados vindos do pessoal da Canonical podem ser obtidos aqui).

Quanto ao número de núcleos ativos, não há nada a fazer. O kernel ativa todos, a menos que passemos a opção de boot maxcpus=<número>. A saída de lscpu diz quantos núcleos estão ativos ("On-line CPU(s) list"). É uma maneira amigável de mostrar o que está em /sys/devices/system/cpu/online.

Resumo: ao que tudo indica, a tal configuração milagrosa não tem efeito algum.


[1] CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y.

sexta-feira, 15 de julho de 2016

Tela preta no Dell Vostro 3550 com o Windows 10

Mesmo sintoma do Inspiron 14 N4050. Este Vostro 3550 tem etiqueta de serviço G64X9R1. Estava com BIOS A7 (18/07/2011). Resolveu depois de atualizar para a última versão A12 (18/02/2014).

Quem está pendurado no pincel sem imagem no Windows 10, use a saída VGA, que funciona.

Dell Vostro 3550 System BIOS

O executável 3550A12.EXE roda em Windows e DOS, como de costume.

terça-feira, 12 de julho de 2016

segunda-feira, 11 de julho de 2016

Contato

Fazia tempo que pretendia assistir à adaptação cinematográfica de Contato (1985), de Carl Sagan, dirigida por Robert Zemeckis e lançada em 1997.

Blu-ray, livro

Como todos filmes adaptados de livros, o enredo é severamente simplificado. Contudo, em Contato os roteiristas abusaram. Há várias passagens esquisitas.

- Logo de início, é dito que a mãe de Eleanor Arroway morreu devido a complicações no parto. No livro, sua mãe morre de causas naturais na velhice.
- Ellie, ainda no começo do filme, começa um tênue relacionamento amoroso com Palmer Joss. Em nenhum momento no livro os dois chegam sequer a flertar.
- A Máquina transporta uma pessoa apenas e Ellie é a escolhida. No livro, são cinco pessoas, dentre elas Ellie.
- O relacionamento entre Ellie e Ken der Heer não é abordado.
- O pai biológico de Ellie não é revelado.
- Praticamente a parte científica inteira se perde: explicações sobre quasares, pulsares, buracos negros, etc. Nada sobre o computador supercondutor Cray 21.

Entre outras. Faz alguns anos desde minha leitura. Provavelmente estou esquecendo outros pontos importantes.

Temos um retrato pobre da personalidade dos personagens — isso quando simplesmente não são ignorados, como Vasily Gregorovich Lunacharsky (conhecido como Vaygay — por ele sim Ellie nutre afeição no limiar da amizade) e Abonnema Eda. S. R. Hadden é quase uma caricatura no filme. Excêntrico e misterioso, é um personagem interessante. A densidade dos diálogos entre Ellie e Palmer Joss e de toda a cena da praia, com as reminiscências dos cinco viajantes, é inexistente no filme.

Para quem leu o livro, que é muito bom, o filme deixa a desejar. De positivo, gostei da atuação de Jodie Foster e dos efeitos especiais. Nota 6 no máximo.

quarta-feira, 22 de junho de 2016

Apple File System

APFS in Detail: Overview (Adam Leventhal's blog)
Introducing Apple File System (WWDC16, PDF)

Boa notícia. Já estava mais do que na hora de um substituto para o HFS+ aparecer. A Apple pretende colocá-lo em produção em 2017. Será tempo recorde, levando com conta que é um sistema de arquivos desenvolvido do zero a partir de 2014. Sistemas de arquivos precisam de pelo menos dez anos para amadurecerem, diz o provérbio.

quarta-feira, 15 de junho de 2016

Assinaturas

Quando formatamos um dispositivo de armazenamento, colocamos um sistema arquivos numa região delimitada. Às ferramentas que os criam, precisamos dizer qual área compreenderá essa região. Tradicionalmente, especificamos um dispositivo de bloco como /dev/sdc1.

Imagine um disco de 2 MiB (2097152 bytes) com setores de 512 bytes (4096 setores), particionamento MBR (MS-DOS) e uma única partição primária.

    Disco
    /dev/sdc
    +----------------------------------------------------------------------------+
    |                   Espaço não                                               |
    |                   particionado                                             |
    |   +--------------+  /      \  +----------------------------------------+   |
    |   | MBR, tabela  |            | Partição 1                             |   |
    |   | de partições |            | /dev/sdc1                              |   |
    |   |              |            |                                        |   |
    |   +--------------+            +----------------------------------------+   |
LBA |   0              1           / 2048                               4095 /   |
    |                             /                                         /    |
    +----------------------------/-----------------------------------------/-----+
                                /                                         /
                                +----------------------------------------+
                                |                                        |
                                |                                        |
                                |                                        |
                                +----------------------------------------+
                                0                                      2047

(fora de escala)

O kernel interpreta a tabela de partições do disco /dev/sdc e cria o dispositivo /dev/sdc1 [1], que corresponde à área entre os setores 2048 e 4095 neste exemplo. Quando um programa acessar o setor 0 de /dev/sdc1, estará na verdade acessando o setor 2048 do disco. Da mesma forma, o último setor de /dev/sdc1 (2047) equivale ao setor 4095 do disco. Essa tradução é feita automaticamente pelo kernel.

Portanto, ao rodarmos mkfs.ext4 /dev/sdc1, dizemos ao programa para criar um sistema de arquivos EXT4 entre os setores 2048 e 4095 do disco. O resto fica intocado.

Cada sistema de arquivos possui alguns bytes em posições específicas (assinaturas) que os identificam. À medida que sobre uma mesma área criamos diferentes sistemas de arquivos, é prudente, a cada formatação, apagar assinaturas anteriores eventualmente presentes. Ter mais de uma assinatura numa mesma área é roleta russa, pois o volume pode, se por azar o offset conferir, ser montado com o driver de outro sistema de arquivos (colisão), que por sua vez pode considerá-lo inconsistente e na pior das hipóteses tentar consertá-lo sobrescrevendo setores e causando perda de dados no sistema arquivos verdadeiro. Idem com as ferramentas de verificação (fsck).

Na libblkid, parte da suíte util-linux, há funções de detecção e apagamento de assinaturas, e um extenso banco de dados contendo várias delas, que podem ser usadas por outros programas. O wipefs, da própria suíte, é um consumidor dessas interfaces. Idealmente, todos os mkfs deveriam linkar a libblkid e usá-la com essa finalidade, mas nem todos o fazem.

quarta-feira, 8 de junho de 2016

Firefox 49 requererá SSE2

Snif, snif, não poderei mais rodar o Firefox no Windows ☹

Espantoso assombrações como Athlon XP, Duron e afins ainda terem influência em softwares atuais. SSE2 é suportado desde o Athlon 64 (K8, 2003) e Pentium 4 (Willamette, 2000).

O Visual C++ 2015 (compilador C/C++ do Visual Studio, vulgo MSVC) tem um bug que, em x86-32, emite instruções SSE mesmo quando configurado para não fazê-lo (/arch:IA32). Esse bug acendeu a discussão sobre o assunto. Para o Firefox 48, voltarão ao VS2013 temporariamente, cujos binários produzidos, devido à configuração da Mozilla, continuarão rodando em máquinas sem nem mesmo SSE!

No ciclo do Firefox 49, colocarão o VS2015 de volta e nas compilações x86-32 trocarão /arch:IA32 por /arch:SSE2 (que, a propósito, é padrão a partir do VS2012). O instalador do Firefox 49 será modificado para não prosseguir ao detectar processador sem SSE2. A infraestrutura de atualização funcionará assim: instalações anteriores precisarão atualizar obrigatoriamente para a versão 48 primeiro, que estará apta a detectar quais instruções adicionais são suportadas, de forma a oferecer ou não versões posteriores. Máquinas sem SSE2 ficarão na versão 48 para sempre. Restará para esse pessoal rodar a versão 45 ESR enquanto for suportada (idem com o Thunderbird).

Em x86-64, SSE2 é sempre presente pois faz parte do conjunto base de instruções da arquitetura. /arch:SSE2 não tem efeito na versão x86-64 do MSVC. Nela, é possível apenas habilitar geração de código com instruções AVX (/arch:AVX) ou AVX2 (/arch:AVX2).

Ganho de desempenho do navegador em x86-32 com /arch:SSE2 é de até 18%.

No Linux a situação está indefinida. As distribuições possuem política que define globalmente o conjunto de instruções requerido por todos os pacotes do repositório. Será improvável aceitarem o Firefox x86-32 requerendo SSE2, a menos que uma cirurgia downstream para isso seja complexa e torne a manutenção do pacote um inferno, como aconteceu com o Chromium no Debian.

quinta-feira, 2 de junho de 2016

Flatpak

Este é um projeto absolutamente fundamental:

Flatpak - the future of application distribution

É o antigo xdg-app (antes GNOME Apps), sobre o qual comentei anos atrás. Não existe a mais mínima chance do GNU/Linux vingar em dispositivos que não sejam embarcados ou servidores sem algo assim, que facilite a distribuição de programas e seja independente da estrutura de empacotamento convencional (DEB, RPM, etc.). É similar ao Snappy da Canonical, com a vantagem de não requerer assinatura de contributor licence agreement nas contribuições de código. Não recomendo a ninguém doar código para qualquer empresa/entidade que seja. No fim, quem perde é quem exige-o.

domingo, 29 de maio de 2016

Rise of the Tomb Raider

Com meu chapéu de jogador casual na cabeça, digo que Rise of the Tomb Raider (Xbox One) é muito bom. Gráficos e trilha sonora são bem feitos — o tema da Cisterna Antiga merece destaque —, a jogabilidade é excelente e o enredo interessante.


À medida que ganhamos experiência, podemos desbloquear, nos acampamentos — usados para viajar de uma região a outra rapidamente —, várias habilidades e aprimoramentos (capacidade de carregar mais munição, eliminação furtiva silenciosa, maior resistência a dano, etc.). Lara Croft vai acumulando recursos naturais também, arrancando minério de cavernas, coletando cogumelos, madeira, óleo, caçando bichos (pele, galhadas; ursos e lobos são os mais difíceis), usados para construir melhorias para as armas e roupas. Armas adicionais estão disponíveis, divididas em pedaços, em baús espalhados pelo território. Relíquias e murais aumentam a proficiência em línguas (russo, mongol, grego), permitindo a leitura de monólitos, que por sua vez, além de aumentarem a experiência, disponibilizam no mapa a localização de certos itens — isso facilita pacas, pois muitos deles estão escondidos, principalmente moedas.

Além de caçar animais e matar inimigos, temos que resolver quebra-cabeças complicados (alguns nem tanto) para abrir caminhos, como nas tumbas de desafio opcionais, cujos prêmios são habilidades.


Finalmente fontes legíveis no openSUSE Leap 42.1

Trabalhar com informações erradas dificilmente produz bom resultado. Sempre pensei que o pacote freetype2 do openSUSE vinha com subpixel rendering. Porque o panaca aqui via no pacote fonte o arquivo freetype2-subpixel.patch contendo:

Index: freetype-2.5.4/include/config/ftoption.h
===================================================================
--- freetype-2.5.4.orig/include/config/ftoption.h
+++ freetype-2.5.4/include/config/ftoption.h
@@ -92,7 +92,7 @@ FT_BEGIN_HEADER
   /* This is done to allow FreeType clients to run unmodified, forcing     */
   /* them to display normal gray-level anti-aliased glyphs.                */
   /*                                                                       */
-/* #define FT_CONFIG_OPTION_SUBPIXEL_RENDERING */
+#define FT_CONFIG_OPTION_SUBPIXEL_RENDERING
 
 
   /*************************************************************************/
@@ -604,7 +604,7 @@ FT_BEGIN_HEADER
   /*   This option requires TT_CONFIG_OPTION_BYTECODE_INTERPRETER to be    */
   /*   defined.                                                            */
   /*                                                                       */
-/* #define TT_CONFIG_OPTION_SUBPIXEL_HINTING */
+#define TT_CONFIG_OPTION_SUBPIXEL_HINTING
 
 
   /*************************************************************************/

Imaginava eu: ahh, está ativo.

Só que não estava. Na seção %prep de freetype2.spec tem isto:

%define enable_subpixel_rendering 0
%setup -q -n freetype-%{version} -a 1
%patch1 -p1
%patch308961 -p 1
%patch202 -p1
%if %{enable_subpixel_rendering}
%patch200 -p1
%endif

Aquele %define ali é o causador do sofrimento. Maldito!

Este post no fórum do openSUSE esclareceu a questão.

Daí a solução veio fácil. Adicionar um repositório contendo uma compilação da libfreetype.so.6 com subpixel rendering.

# zypper ar -f -n 'namtrac FreeType' http://download.opensuse.org/repositories/home:/namtrac:/subpixel/openSUSE_Leap_42.1/ namtrac-subpixel
# zypper -n --gpg-auto-import-keys dup
# sed -i '/^USE_LCDFILTER=/ s/lcdnone/lcddefault/' /etc/sysconfig/fonts-config
# sed -i '/^USE_RGBA=/ s/none/rgb/' /etc/sysconfig/fonts-config
# fonts-config

sexta-feira, 27 de maio de 2016

Bugs do Firefox para monitorar

Dois bugs do Firefox me interessam no momento.

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

Fazer o navegador usar na barra de título a cor configurada pelo usuário, no Windows 10, quando a opção "Configurações → Personalização → Cores → Exibir cores em Iniciar, na barra de tarefas, na central de ações e na barra de título" estiver habilitada. Na atual versão 46, sempre é usada a cor cinza. Esse recurso existe desde a compilação 10525.

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

No Linux, usar a barra de título para colocar as abas, acabando com desperdício de espaço vertical. Antigamente podíamos obter resultado parecido com a extensão HTitle (descontinuada). A Canonical aplica um patch downstream que faz algo similar no Unity. Esse bug trata da solução oficial cross-distro e depende da integração com GTK+ 3, que está mais ou menos completa e é padrão nas compilações da Mozilla a partir da versão 46. Para variar, ainda há bugs e, com exceção das distribuições aventureiras, os empacotadores estão hesitando habilitá-la nos ciclos estáveis.

domingo, 22 de maio de 2016

Esconder backdoors é para os fracos

A Allwinner distribui um kernel Linux modificado (usado, por exemplo, nas placas Banana Pi e Orange Pi) para sua família de SoC ARM sunxi. Até aí nada demais. Infelizmente é prática comum na indústria, que tem dificuldades de trabalhar junto ao upstream e fazer versões mainline funcionarem em seus produtos.

Porém os caras esqueceram (?) de remover um código que permite qualquer um obter acesso root sem dificuldade alguma:

Allwinner Technology committed to resolving Linux Kernel software issue (GitHub)

Fail. Ou não.

sexta-feira, 20 de maio de 2016

Windows Update do 7 é uma lesma (II)

A lentidão do Windows Update do 7 é consertada (ver este artigo da Microsoft) com KB3177467 (atualização do maquinário do Windows Update, requerida pelo pacote quase SP2 KB3125574) e KB3172605. Portanto, minha recomendação é numa instalação limpa do 7 Service Pack 1 começar com:

- KB3177467 (substitui KB3020369): pré-requisito para KB3172605 e KB3125574.
- KB3172605: conserta lentidão do Windows Update.
... reiniciar ...
- KB3125574: pacote à la Service Pack 2.

Vale o mesmo ao integrar na mídia de instalação.

Links diretos para KB3125574 peguem lá no blog RETROWARE.

quarta-feira, 18 de maio de 2016

Quase um Service Pack 2 para Windows 7

Simplifying updates for Windows 7 and 8.1 (Windows for IT Pros) (via Ars Technica)

Até que enfim! Constrangedor é o treco depender do Microsoft Update Catalog, que até mesmo no Internet Explorer precisa de gambiarras. Antes isso do que nada...

segunda-feira, 16 de maio de 2016

BCM4313 caindo no Windows 10

Este adaptador sem fio da Broadcom (14e4:4727) é uma desgraça. Só incomoda, tanto no Windows quanto no Linux. A todo momento a conexão para de funcionar, ficando "nula ou limitada". Igualmente ao 7, a saída no 10 é fazer um downgrade do driver 6.30.x.x para o 5.100.x.x.

Não precisamos catar drivers por aí. O próprio Windows 10 tem versões anteriores em sua biblioteca. Vá nas propriedades do adaptador no gerenciador de dispositivos e atualize-o, mandando procurar no computador. Desmarque "Mostrar hardware compatível" e escolha "Dell Wireless 1490 Dual Band WLAN Mini-Card". Ignore o aviso sobre possíveis problemas de compatibilidade.


Ficará assim:

6.30.223.256 → 5.100.245.200

domingo, 15 de maio de 2016

Desativando o Windows Defender no 10

Atualizei para o 10 minha última máquina que ainda rodava o Windows 7. Fora a mão de obra de fazer uma instalação limpa depois de ganhar a licença grátis, não enfrentei surpresas. Nesta compilação 10586 (versão 1511, vulgo Threshold 2), o 10 está bem razoável. Só pelo Windows Update menos lento vale o upgrade. E, falemos a verdade, o 7 está aos poucos virando um cacareco. Era hora de aproveitar a oferta, visto que a boca livre termina no final de julho.

Entrave foi o Windows Defender, que é o Microsoft Security Essentials embutido no sistema a partir do 8. Há pencas de tutoriais pela internet explicando como desativá-lo. Quem tem o 10 Pro ou Enterprise, pode fazê-lo via GPO, que é o meio mais garantido, pois nem manualmente é possível ativá-lo usando a interface do programa depois.

Sempre citam:

Configuração do Computador → Modelos Administrativos → Componentes do Windows → Windows Defender
    Desativar Windows Defender (Habilitado)

Acontece que não existe no Threshold 2! Correto é:

Configuração do Computador → Modelos Administrativos → Componentes do Windows → Endpoint Protection
    Desativar Endpoint Protection (Habilitado)

Marcos, para que isso? Ao instalarmos outros antivírus eles geralmente não desativam o Defender automaticamente? Sim. É que não uso antivírus. Não sou adepto do óleo de cobra. As unidades de execução do meu processador agradecem.

domingo, 8 de maio de 2016

Debian dá adeus a CPUs pré-i686

Debian i386 architecture now requires a 686-class processor (debian-devel-announce) (via Phoronix)

O Debian tem tradição de suportar hardware velho. Enquanto outras distribuições já abandonaram por completo o conjunto de instruções x86-32 (RHEL, SLE), ou tratam-o como secundário, só agora foi decidido que processadores pré-i686 não serão mais suportados no futuro Debian 9 (Stretch).

Anteriormente, o 3.1 (Sarge) removeu suporte ao i386 e o 6 (Squeeze) ao i486 — os guias de instalação do 6 e 7 (Wheezy) estão errados. Desde o 6 até o atual 8 (Jessie), processador i586 (Pentium e compatíveis) é requerido.

Portanto, a versão x86-32 do Debian 9 requererá no mínimo: Intel Pentium Pro, AMD Athlon, VIA C7.

sexta-feira, 22 de abril de 2016

Permissão de execução no Windows

Apesar de uso não muito difundido, o Windows tem o conceito de permissão de execução para arquivos e diretórios, de forma similar aos Unix-like: em diretórios, permite atravessá-los [1] e, em arquivos, permite sua execução se for um programa — os arquivos continuam podendo ser lidos, modificados, ou quaisquer sejam as demais permissões. A permissão em questão é "Percorrer pasta/executar arquivo".

Para manter a semântica de acesso ao sistema de arquivos compatível com o MS-DOS, o Windows NT mantém o comportamento de criar todos arquivos com permissão de execução por padrão.

Nas permissões simplificadas, RX (Ler & executar) é garantido a todos praticamente.

Há pela internet quem recomende removê-la recursivamente (via herança, de preferência) no diretório do perfil do usuário. No entanto, não me parece ser boa ideia, visto que provavelmente quebrará instaladores que usem %TEMP% e aplicativos que coloquem executáveis em %APPDATA% e/ou %LOCALAPPDATA%, como uTorrent e Chrome. Até pode ser uma opção em sistemas bem travados, onde nada mais será instalado. Ainda assim são necessários testes.

Abordagem mais segura é remover a permissão apenas em pastas específicas do perfil, em particular na Downloads.

icacls "%USERPROFILE%\Downloads" /deny *S-1-3-0:(OI)(IO)(X)

O comando adiciona uma permissão de negação (/deny) de execução ((X)) ao proprietário criador (*S-1-3-0), que aplica-se apenas a arquivos, deixando o diretório e subdiretórios de fora, e é propagada a todos objetos descendentes ((OI)(IO)).

Funciona bem.


A mensagem de erro é confusa. O Windows pôde sim acessar o arquivo, só não pôde executá-lo...

sábado, 2 de abril de 2016

Hora de migrar para o Squid 4

Ontem foi lançado o Squid 4.0.8 (beta). Por ser um código já mais ou menos estabilizado, decidi colocá-lo em produção. Veremos o que explode.

Notas de lançamento: Squid 4.0.8 release notes

O bug 3574 não foi totalmente consertado aparentemente. Reportado aqui. Como não mata por completo o daemon (o processo é executado novamente), dá para ir usando.

Meu pacote caseiro: Pacote do Squid para o CentOS 7

quinta-feira, 31 de março de 2016

Bash e cia. no Windows 10

Linux Command Line on Windows | Build 2016 (Channel 9)
Ubuntu on Windows -- The Ubuntu Userspace for Windows Developers (From the Canyon Edge)

Muito legal. Aí está o Subsystem for Unix-based Applications (SUA), descendente do subsistema POSIX, que o NT tem há séculos, revigorado. Chama-se agora Windows Subsystem for Linux (WSL). Ao invés de manter seus próprios binários, a Microsoft decidiu usar uma imagem com o espaço de usuário básico (Bash e demais ferramentas principais de linha de comando) do Ubuntu — menos o kernel Linux (já que o NT emula-o). São os mesmos binários de uma instalação convencional. Nada impediria usar binários de outra distribuição qualquer, acredito eu.

Rede funciona e dá para instalar programas diretamente dos repositórios. Diretório raiz e $HOME ficam em %LOCALAPPDATA%\Lxss. Volumes do Windows são automaticamente montados em /mnt/<letra>. Demoliu o Ubuntu? Deve ser possível apagar a pasta rootfs dali e fazer o Windows despejar a imagem novinha em folha de volta. Pronto, reinstalado.

Quem usa o Cygwin estará em casa. Porém tem diferença. Os binários do Cygwin são PE e o GCC dele gera código Win32. Essa imagem do Ubuntu é composta por binários ELF. O GCC ali gera binários ELF também, exatamente da mesma forma que uma instalação nativa do Ubuntu geraria.

Pode ser expandido para emular a pilha gráfica (X, Wayland, Mir)? Pelo vídeo, acho que não.

Pacotes das distribuições são realmente seguros?

Distribution packages considered insecure (Lukas's Random Thoughts)

É um argumento válido e demonstrável. Não questiono a infraestrutura que gera os pacotes. Apesar de alguns tropeços no passado, as distribuições têm sistemas seguros. Trata-se dos binários entregues aos usuários, se são seguros, se não possuem falhas de segurança conhecidas.

expressei aqui que acho a atual forma de distribuição de programas do GNU/Linux quebrada no que diz respeito aos desktops (e adiciono plataformas móveis). Porém para servidores é interessante, pois neles podemos esperar que tudo venha dos repositórios oficiais.

Para o modelo funcionar, no entanto, requerimentos são necessários: empacotadores e projeto upstream responsivos. Isso nem sempre há. Como resultado, podemos ter pacotes abandonados, que ficam um tempão com vulnerabilidades e bugs diversos sem correção.

Uma característica na política de atualização de versões estáveis, particularmente do Debian, mas também adotada por outras distribuições, é a proibição de atualizações até de minor versions dos pacotes. O empacotador é obrigado a escolher a dedo (cherry-pick) apenas patches que consertem bugs de segurança, ficando de mãos amarradas enquanto o projeto upstream já consertou uma miríade de outros problemas. Exceções existem para outros bugs, quando graves, ainda que dependam da boa vontade e competência do empacotador.

Quando há, fortuitamente, upstream ativo, preocupado em manter versões antigas vivas (repetindo, nem sempre há!), considero uma péssima política. Suponha que um pacote qualquer tenha duas major versions, 5.x e 6.x. E uma distribuição use a série 5.x. Enquanto o upstream lançar atualizações dessa série, o downstream (a distribuição) deveria atualizar imediatamente, trabalhando junto ao upstream com intuito de garantir que nenhuma API será quebrada — esse é o objetivo de minor versions.

Não incomum temos algo diverso: o pacote travado numa versão 5.x específica, que vai ficando cada vez mais velha, com alguns backports aqui e acolá, e uma tonelada de bugs.

Por fim, temos a pior possibilidade, que é a falta de empacotadores responsivos. Nesse caso, os usuários ficam simplesmente no mato sem cachorro. Pendurados no pincel.

Portanto, ciclo de vida estável, onde atualizações são previsíveis e não trazem mudanças bruscas, tem propósito, mas nem sempre a coisa funciona bem na prática.

segunda-feira, 28 de março de 2016

Descent II: clássico dos anos 90

Joguei bastante Descent II por volta de 1997, num Pentium MMX com Windows 95. Para meu deleite, achei no Mercado Livre um CD da coleção Games do Estadão:


É uma cópia original do jogo, com a devida licença da Interplay.

Só roda em Windows modernos dentro do DOSBox. E a resolução é limitada a 800x600 (sem cockpit) ou 640x480 (com cockpit).

Felizmente o código fonte do Descent e Descent II foi tornado público para uso não comercial e não demorou para almas caridosas darem uma melhorada: DXX-Rebirth.

D2X-Rebirth roda nativamente no Windows, OS X e Linux. Precisa dos arquivos com os dados do jogo da versão original (está explicado direitinho em README-D2X.txt).

sexta-feira, 18 de março de 2016

Banjo-Kazooie é excelente

Finalmente terminei os dois principais jogos da série: Banjo-Kazooie (1998) e Banjo-Tooie (2000). As versões para Xbox 360, que estão disponíveis para Xbox One na coleção Rare Replay, possuem melhorias em comparação com as originais para Nintendo 64. Resolução widescreen, cores mais vivas e o mais importante: no Banjo-Kazooie, o jogo memoriza quais itens foram pegos. Era um bug que causava confusão no tempo do N64.

A construção dos personagens, o urso Banjo e a passarinha Kazooie sendo as estrelas, é muito bem feita. Banjo é bobão, enquanto Kazooie é sarcástica. Um contraste divertido. Logo de início tomei gosto de ler os diálogos durante o desenrolar dos jogos. Valeu a pena.

A mecânica de ambos é similar. Banjo-Tooie é mais longo e complexo, com muitos movimentos adicionais não presentes no primeiro jogo, e com um modo de tiro (de ovos ☺), em primeira pessoa, que, confesso, não me atraiu. A possibilidade de separar Banjo da Kazooie deu ao Tooie diversão adicional, por outro lado. Grunty Industries, por exemplo, é um mundo intrincado onde temos que recorrer bastante aos pads de separação.

Show são as trilhas sonoras de Grant Kirkhope:

Banjo-Kazooie Music Extended
Banjo-Tooie Music Extended

Qual é melhor? Difícil responder. Banjo-Kazooie ganha por um pequena margem para mim.

No Banjo-Kazooie consegui pegar praticamente todos os itens, menos um Jiggy: aquele maldito detrás da hélice do navio em Rusty Bucket Bay. Já no Banjo-Tooie faltaram mais coisas. Terminei com 75 Jiggys (de 80) e não consegui bater Canary Mary na última competição em Cloud Cuckooland, cujo prêmio é uma folha do Cheato. Uns três Jinjos ainda preciso resgatar também.

Meus mundos preferidos

Banjo-Kazooie - Freezeezy Peak

Brrr, que frio!

Banjo-Tooie - Hailfire Peaks (lado da lava)

Afff, que calor!

Wikia: Banjo-Kazooie, Banjo-Tooie

terça-feira, 8 de março de 2016

Squid 4 + systemd: combinação que funciona

Até o Squid 3.5, o comportamento do daemon é incompatível com inits modernos e exige gambiarras ou funcionalidade limitada (-N).

Recapitulando como é até a versão 3.5:

PID1
 \_ MASTER/PARENT
     \_ WORKER <--- PROCESSO PAI DE FATO (ARQUIVO PID)
         \_ FILHO 1
         \_ FILHO 2
            ...

No Squid 4, beta enquanto escrevo, é assim:

PID1
 \_ MASTER/PARENT <--- PROCESSO PAI DE FATO (ARQUIVO PID)
     \_ WORKER
         \_ FILHO 1
         \_ FILHO 2
            ...

Ou seja, o processo a ser monitorado (e sinalizado) passou a ser filho direto do init, que agora pode fazê-lo via SIGCHLD. Portanto, usando Type=forking e rodando o daemon sem a opção -N, temos uma configuração funcional. Continua não bloqueando ao receber SIGTERM; o systemd, mesmo assim, aguarda o processo principal terminar, sendo finalizado corretamente. E, sem -N, o modo de múltiplos processos funciona.

Desde a versão 3.5.11, o daemon não morre mais se receber SIGHUP antes de completar a inicialização. Geralmente um shell script, em /etc/NetworkManager/dispatcher.d, chama systemctl reload squid.service toda vez que a configuração de rede mudar (por causa dos servidores DNS em particular). Levando em conta que o NetworkManager é executado pouco antes do Squid, o sinal vinha de forma aleatória, potencialmente matando-o.

Restava um problema: criação da estrutura do cache em disco (cache_dir em /etc/squid/squid.conf). squid -z realiza a daemonização logo no início chamando fork() e exit(), com objetivo de desligar-se do processo que o executou e tornar-se filho do init. Esse comportamento é esperado com Type=forking. Porém squid -z é executado antes do daemon em si, posto num shell script em ExecStartPre=. Cria a estrutura quando não existir e depois finaliza-se. ExecStartPre= comporta-se como um serviço Type=oneshot. O systemd executa o que estiver ali e, no momento em que o processo finalizar (não importando se existirem filhos ainda rodando), considera-o terminado e mata tudo antes de passar para ExecStart=.

Precisávamos fazer squid -z esperar seus filhos terminarem. A partir da versão 4.0.8, temos a nova opção --foreground para tal fim.

Então, basta rodar squid --foreground -z em ExecStartPre= e está resolvido.

terça-feira, 1 de março de 2016

"Bloqueio de instalação de novos programas"


Tradução:
Nosso software é bugado demais para funcionar numa conta limitada. E nem é capaz de pedir elevação de privilégio para ser ao menos instalado! Portanto, destrua a segurança do seu Windows. Você estará ajudando a manter a arte da Programação Orientada a Gambiarras (POG) viva. Obrigado. (a) Circuitec

sexta-feira, 26 de fevereiro de 2016

MKV no Xbox One

Faz algum tempo a Microsoft passou a suportar Matroska (MKV) e FLAC no Windows. O aplicativo Media Player do Xbox One também toca ambos — provavelmente herdou o suporte do Windows 10. Infelizmente, a implementação é incompleta demais.

Lado bom:

- Toca MKV com os principais codecs dentro (inclusive FLAC).

Lado ruim:

- Não indexa capítulos.
- Não exibe legendas embutidas.

Assim fica difícil! Matroska ganhou popularidade, entre outras razões, por tais recursos.

quinta-feira, 18 de fevereiro de 2016

O estrago feito na segurança do Windows antes do Vista

Uma característica dos fóruns sempre me irritou: a quantidade absurda de tópicos sobre "remoção de malware". Os que contêm aquelas sequências intermináveis e maravilhosas de logs, no mais evidente clima de help desk. Assunto enfadonho. Enxugação de gelo sem fim.

A culpa pela situação atual do ecosistema Win32 é em grande parte da Microsoft, que demorou demais a começar a colocar limites nas contas de usuário criadas seguindo uma instalação normal. Até o Windows XP, jogavam no colo de todos uma conta administrativa sem restrições! O estrago na segurança foi brutal, além de acostumar mal os usuários. O bem-vindo UAC do Vista, não por outra razão, foi torpedeado.

O Windows NT (cuja primeira versão, 3.1, é de 1993) é multiusuário desde sua concepção. Naqueles tempos, quando ainda era possível usar FAT no volume de boot, porém, o sistema de permissões só funcionava eficazmente com NTFS e as ACLs precisavam ser configuradas manualmente. Eram permissivas, Todos possuíam controle total, por exemplo, em "Arquivos de programas" e "WINNT". Uma política padrão de ACLs restritivas, com suporte à propagação via herança, nos moldes do que é usado hoje, foi implementada no Windows 2000.

Básico do básico!

Por ter sido o primeiro superconjunto da plataforma Windows, foi um crime NTFS não ter sido mandatório no 2000, o que apenas veio a ser feito em 2007 com o Vista. Limitação que existia no NT 4.0 do volume de boot ser formatado em FAT e depois convertido para NTFS foi superada. Assim, unindo NTFS, conta limitada por padrão e as novas ACLs restritivas, daria um sistema bem mais seguro. Visto que estamos fazendo um exercício de futurologia retrógrada (estou programando o DeLorean aqui), teria sido necessário adaptar também a GUI a fim de facilitar a administração para usuários limitados. Itens do "Painel de Controle" teriam que poder ser, graficamente, invocados usando outro usuário. Alguma infraestrutura já existia no 2000 com o "Serviço RunAs" (renomeado para "Logon secundário" em versões posteriores), que permitia um usuário rodar programas como outro sem precisar fazer logoff. Imagine um precursor do UAC.

Haveria quebradeira. Ganho, por outro lado, teria sido enorme, pois ajudaria a limpar o ecosistema Win32. Inexpugnável o Windows não tornaria-se da noite para o dia. Começaria, entretanto, a ser criada uma cultura saudável, acabando com a prática nefasta, quase norma, naquela época, dos aplicativos assumirem que rodariam como administrador. Logar com usuário administrador deveria ter sido dificultado ao máximo e marcas d'água com caveiras e bombas explodindo exibidas continuamente. Ocorreu o inverso ao nada fazerem: todo mundo ficou mal habituado, desenvolvedores e usuários. Um usuário limitado só pode demolir seu próprio perfil, não o sistema e programas nem outros perfis — desconsiderando falhas que permitam escalação de privilégio. É simples. A separação clara, inequívoca, presente nos Unix-like entre o que pertence ao sistema operacional e o que é do usuário. Desde 1993 o Windows NT tem o mesmo! Nele, a linha divisória, todavia, é tênue por causa das desastrosas decisões. Num Unix-like, caso um aplicativo, após instalado, queira escrever dados fora da pasta /home, trata-se simplesmente de bug que precisa ser consertado. No Windows, ahh... desative o UAC, habilite modo de compatibilidade, rode-o como administrador e coisas do tipo. Nããão!

Foi o lado negro da compatibilidade a qualquer custo. Para melhor absorver os aplicativos dos Windows 9x, jogaram vários anos do correto design do NT no lixo. O resultado está aí até hoje. A Microsoft pode alegar que, no setor corporativo, antes do XP, quando o foco dos NT não eram usuários domésticos, esperava-se que administradores competentes tomassem medidas adequadas. Dá para engolir, afinal os 9x eram montes de estrume. Mas e o XP? O XP foi o primeiro NT oficialmente doméstico. Nem depois de Bill Gates lançar a iniciativa "Trustworthy Computing", anos antes do Service Pack 2, cujo lema foi deixá-lo menos inseguro, algo foi feito nesse sentido.

A esperança, em tempos de Windows 10, é que aplicativos Modern/Universais emplaquem, porque rodam em sandboxes e não podem destruir o sistema nem o perfil. Com o Windows Phone (oops, agora é Mobile de novo) indo de mal a pior e a falta de adesão dos desenvolvedores no front dos desktops, é meio difícil acreditar por enquanto.

domingo, 14 de fevereiro de 2016

systemctl cat/edit

Não faz muito saímos do systemd 208 do CentOS 7.0 e 7.1 para o 219 do 7.2. A nova versão traz dois novos comandos no systemctl: cat (209) e edit (218).

O primeiro, apesar de simples, é muito útil. Serve para mostrar a íntegra do arquivo unit em questão e também eventuais drop-ins e overrides.

# systemctl cat bacana.service
# /usr/lib/systemd/system/bacana.service
[Unit]
Description=Serviço bacana

[Service]
ExecStart=/usr/bin/sleep 10000000

[Install]
WantedBy=multi-user.target

Suponhamos que precisemos modificar bacana.service e ordená-lo após, por exemplo, crond.service. Usamos:

# systemctl edit bacana.service

Será aberto num editor um arquivo (drop-in) de nome override.conf dentro do diretório /etc/systemd/system/bacana.service.d (será criado se necessário). Para escolher qual editor usar, as variáveis de ambiente SYSTEMD_EDITOR, EDITOR e VISUAL (nessa ordem) são interpretadas. Se não existir nenhuma delas, são tentados em ordem: nano, vim e vi.

Colocamos então as configurações desejadas, lembrando de especificar a seção ([Unit], [Service], etc) a que pertencem:

[Unit]
After=crond.service
Wants=crond.service

Salvamos o arquivo. Quando o editor finalizar, o systemd automaticamente recarregará sua configuração (equivalente a systemctl daemon-reload). Dependendo de onde você tenha mexido, pode ser necessário reiniciar o daemon para aplicar as mudanças, o que deverá ser feito manualmente. Consultamos se tudo está correto:

# systemctl cat bacana.service
# /usr/lib/systemd/system/bacana.service
[Unit]
Description=Serviço bacana

[Service]
ExecStart=/usr/bin/sleep 10000000

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/bacana.service.d/override.conf
[Unit]
After=crond.service
Wants=crond.service

Caso as alterações sejam grandes demais, podemos adicionar a opção --full, que substituirá o arquivo (override) de /usr/lib/systemd/system criando outro com o mesmo nome em /etc/systemd/system e lhe entregando prontinho para ser modificado dentro do editor (drop-ins criados previamente são mantidos):

# systemctl edit --full bacana.service

Era possível fazer o mesmo manualmente desde a versão 198.

quarta-feira, 3 de fevereiro de 2016

Mudanças visuais no blog (IV)

Aqui acaba o delírio que tive com as fontes remotas. O blog volta à sanidade com a tradicional dupla Verdana/Georgia.

sexta-feira, 29 de janeiro de 2016

O futuro da internet é sem plugins

Java, Flash, Silverlight, ..., o que vocês merecem é o implacável ataque do Jinjonator!

Oracle is finally killing the Java browser plug-in (ExtremeTech)

A Oracle diz que, após o Java 9, matará seu plugin para os navegadores. Finalmente! Lugar para tais códigos não existe na internet moderna. Java e Flash, citando apenas os principais, são constantes fontes de insegurança e instabilidade dentro dos navegadores.

Na recente compilação 64-bit do Firefox para Windows, a Mozilla usa uma lista branca que apenas libera dois plugins: Flash e Silverlight. E é temporário: já avisaram que daqui cerca de um ano não terão mais piedade. A versão 32-bit, por outro lado, continuará suportando os plugins, pelo menos por enquanto.

Este é um esforço cujo início deu-se no Chrome. Sites que dependem de tais tecnologias obsoletas devem tomar vergonha e usar recursos nativos dos navegadores. Um caso de uso principal, contudo, não foi coberto ainda: acesso a dispositivos USB, como leitores de cartões e tokens criptográficos. Atualmente, são usados applets Java para isso. Está sendo desenvolvida uma especificação para tal fim: WebUSB API.

Apesar de ser rascunho, aos poucos é implementada no Chromium. No Firefox, ainda está na fase de discussão.

Depois que os navegadores concordarem numa API padronizada e resolverem a questão da segurança, que é um desafio e tanto, o último reduto do Java nos navegadores será demolido. No entanto, já antevejo os bancos e serviços do governo demorando anos até adaptarem-se por aqui... ☹

domingo, 24 de janeiro de 2016

Moto G3 não mostra conteúdo do cartão SD depois de atualizar para o Android 6.0

Depois que meu Motorola Moto G3 foi atualizado do Android 5.1.1 de fábrica para o 6.0, não conseguia mais acessar o cartão de memória através do cabo USB (via protocolo MTP). O volume do cartão aparecia como vazio no PC. A solução está aqui:

http://android.stackexchange.com/a/59687

Ainda sobre o assunto, uma mudança do 6.0 causadora de confusão é que agora por padrão a interface USB do aparelho é configurada no modo "Carregamento apenas", que não disponibiliza nenhum armazenamento, seja interno ou externo, ao PC. Fiquei perdido por colocarem, quando o cabo está plugado, um diálogo para alterar o modo acessível através da área de notificações, que por sua vez não aparece na tela de bloqueio.


Tem gente reclamando, porém acho uma boa mudança. Existem tantas máquinas infestadas de malware por aí que o sujeito pluga o cabo para carregar e sai "premiado". Com a nova configuração não tem risco. Se você quiser transferir dados, precisa dizer explicitamente ao aparelho.

sábado, 23 de janeiro de 2016

Mudanças visuais no blog (III)

Desta vez, substituí Merriweather por Droid Serif em todos os títulos. Acelera o carregamento para quem tem as fontes Droid instaladas localmente. Eu gosto de fontes com serifa nos títulos. O Blogger finalmente integrou a fonte Roboto em sua interface de configuração. Mas sabe de uma coisa? Fica Droid Sans, assim uso uma família só.

E aumentei o tamanho da fonte para 16 pixels no conteúdo dos posts. Com 14 pixels às vezes precisava aumentar o zoom. Junto, os títulos foram levemente aumentados e a largura também. A página ainda cabe dentro de 1280 pixels de largura.

quarta-feira, 20 de janeiro de 2016

Desembarcando no Arch (O Retorno)

Minha alforria do GRUB

Bootloader no-nonsense: systemd-boot

Não tenho nada contra o escopo do GRUB de ser um bootloader tipo pia da cozinha, que suporta tudo de todas as maneiras possíveis. Repugnante é o formato usado em seus arquivos de configuração.

Como bom nômade, migrei para o Arch depois de longa estada no openSUSE. Só que desta vez decidi não usar o GRUB de jeito nenhum. Configurei meu notebook para iniciar em UEFI e passadas algumas horas, com relativa facilidade, tinha um Arch funcional e enxuto com o GNOME. No lugar do inchado bootloader, pus o systemd-boot, antigo Gummiboot. Achei a página que trata dele na wiki desnecessariamente complicada.

Meu particionamento é o mais KISS possível (sugiro o cfdisk):

Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

Device       Start       End   Sectors   Size Type
/dev/sda1     2048   1050623   1048576   512M EFI System
/dev/sda2  1050624 976773134 975722511 465.3G Linux filesystem

sexta-feira, 8 de janeiro de 2016

Arris TG862 não redireciona portas

Neste roteador, caso "Ativar firewall" esteja desmarcado, nenhum redirecionamento de porta (que definimos em "Servidores Virtuais") funciona.

Perdi uma hora quebrando a cabeça com isso. Não sei se a NET entregou-o configurado assim. Bastou habilitar e os redirecionamentos passaram a funcionar.

domingo, 3 de janeiro de 2016

FSArchiver com suporte ao XFSv5

Meus agradecimentos ao Francois Dupoux pela presteza em modificar o FSArchiver de modo a torná-lo compatível com XFSv5.

A partir do FSArchiver 0.6.20 fica assim:

- Imagens contendo XFS criadas com FSArchiver ≤ 0.6.19 são sempre restauradas como XFSv4.
- XFSv4 sempre é criado com -n ftype=0 para garantir ampla compatibilidade.
- Imagens criadas com FSArchiver ≥ 0.6.20 armazenam a versão do XFS. Dependendo da versão da suíte xfsprogs usada no momento da restauração, o comportamento é o seguinte:
    - Se a imagem contiver XFSv4, é idem acima.
    - Se a imagem contiver XFSv5, é restaurado mantendo a versão 5 se xfsprogs ≥ 4.3.0, porque apenas a partir dessa versão o mkfs.xfs permite definir o UUID no momento da criação do sistema de arquivos. Como em todos os blocos de metadados do XFSv5 o UUID está estampado, trocá-lo depois de ter sido criado (possível a partir de xfsprogs ≥ 4.2.0) joga o kernel mínimo necessário para o 4.3. Sem contar que o sistema de arquivos continua usando o UUID antigo para identificar os metadados. A única solução limpa é defini-lo via mkfs.xfs, que também mantém o kernel mínimo no 3.15 (-m crc=1,finobt=0) ou 3.16 (-m crc=1,finobt=1).
    - Se a imagem contiver XFSv5 e tivermos xfsprogs < 4.3.0, o programa faz um downgrade para XFSv4 e emite um aviso. Assim o administrador não fica na mão num caso de emergência.
    - A imagem armazena se o sistema de arquivos XFSv5 original tinha finobt habilitado ou não. A configuração é respeitada ao restaurar o volume (pressupondo xfsprogs ≥ 4.3.0).

Parte da empreitada foi o trabalho de pesquisar quais recursos eram suportados por cada versão das ferramentas, o que já havia feito aqui no blog nos posts relativos ao XFS. Francois desenvolveu a lógica e programou-a em C, cujo resultado testei usando diferentes combinações de imagens (V4-0.6.19, V4, V4-com-ftype, V5, V5-sem-finobt) e versões da suíte xfsprogs (3.1.9, 3.2.0, 3.2.2, 4.3.0). Ganhei até uma menção no arquivo THANKS. ☺

Feliz 2016 a todos os leitores!