Postagens

Mostrando postagens de janeiro, 2016

O futuro da internet é sem plugins

Imagem
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 c

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

Imagem
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 ap

Desembarcando no Arch (O Retorno)

Imagem
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-XXX

Arris TG862 não redireciona portas

Imagem
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.

FSArchiver com suporte ao XFS V5

Meus agradecimentos ao Francois Dupoux pela presteza em modificar o FSArchiver de modo a torná-lo compatível com XFS V5. A partir do FSArchiver 0.6.20 fica assim: - Imagens contendo XFS criadas com FSArchiver ≤ 0.6.19 são sempre restauradas como XFS V4. - XFS V4 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 XFS V4, é idem acima. - Se a imagem contiver XFS V5, é 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 XFS V5 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