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    2016-07-31 16:51:35.000000000 -0300
+++ /etc/squid/errorpage.css    2016-08-02 13:29:24.964433501 -0300
@@ -21,9 +21,11 @@
 html body {
     margin: 0;
     padding: 0;
-    background: #efefef;
     font-size: 12px;
     color: #1e1e1e;
+    background: black url('http://centos.localdomain/interestelar.jpg') no-repeat fixed center top;
+    background-size: cover;
+    text-shadow: 3px 3px 5px lightgrey;
 }
 
 /* Page displayed title area */
@@ -31,15 +33,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') no-repeat left;
 }
 
 /* initial title */
 #titles h1 {
-    color: #000000;
+    color: white;
 }
 #titles h2 {
-    color: #000000;
+    color: white;
 }
 
 /* special event: FTP success page titles */
@@ -52,6 +54,8 @@
 #content {
     padding: 10px;
     background: #ffffff;
+    opacity: 0.8;
+    text-shadow: none;
 }
 
 /* General text */
@@ -71,12 +75,11 @@
 }
 
 pre {
-    font-family:sans-serif;
 }
 
 /* special event: FTP / Gopher directory listing */
 #dirmsg {
-    font-family: courier;
+    font-family: courier, monospace;
     color: black;
     font-size: 10pt;
 }
@@ -102,4 +105,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. ☺

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.