terça-feira, 4 de setembro de 2018

Visualizar e alterar o cabeçalho de um arquivo

Olá, mundo.

Alguém já teve o desprazer de fazer o download de uma arquivo PDF e não conseguir exibi-lo no visualizador padrão?

Isso já aconteceu comigo algumas vezes, mas hoje precisei abrir um documento neste formato digital e simplesmente apareceu: NADA. A tela fica toda preta dentro do visualizador de PDF. Utilizo o Zathura, software que lhe permite escolher qual biblioteca será utilizada como backend para visualizar os PDFs (optei pela mais utilizada - poppler) e é altamente customizável através de plugins, entre outros recursos.

Daí veio a idéia de debugar através do terminal. Executei o comando com o nome do arquivo:

zathura arquivo.pdf

Eis que apareceu o erro error: Unknown file type: 'application/octet-stream', o que me permitiu identificar que o cabeçalho do arquivo não estava dentro do padrão PDF.

Com a ferramenta hexdump consegui visualizar os bytes não deveriam preceder o %PDF1.4.

hexdump -C arquivo.pdf | more

00000000  0d 0a 0d 0a 0d 0a 0d 0a  0d 0a 0d 0a 0d 0a 0d 0a  |................|
*
00000030  0d 0a 0d 0a 25 50 44 46  2d 31 2e 34 0a 25 e2 e3  |....%PDF-1.4.%..|
00000040  cf d3 0a 32 20 30 20 6f  62 6a 0a 3c 3c 2f 4c 65  |...2 0 obj.<</Le|
00000050  6e 67 74 68 20 34 38 37  39 2f 46 69 6c 74 65 72  |ngth 4879/Filter|
00000060  2f 46 6c 61 74 65 44 65  63 6f 64 65 3e 3e 73 74  |/FlateDecode>>st|
00000070  72 65 61 6d 0a 78 da a5  5a 0b 98 15 c5 95 ae d3  |ream.x..Z.......|

Daí, resolvi abrir o arquivo pelo VIM e ele apareceu assim:

^M
^M
^M
^M
%PDF-1.4
%âãÏÓ
2 0 obj
<</Length 4879/Filter/FlateDecode>>stream

Foram 26 linhas com o caractere ^M. Deletei essas linhas e salvei o arquivo.

Problema resolvido.

Após essa alteração a saída do comando hexdump -C arquivo.pdf passou a exibir a primeira linha assim:

00000000  25 50 44 46 2d 31 2e 34  0a 25 e2 e3 cf d3 0a 32  |%PDF-1.4.%.....2|

e o arquivo pôde ser aberto normalmente.

Share:

sexta-feira, 15 de junho de 2018

Converter manual (man) para PDF no Linux

Beleza, galera?

Dica rápida: Como converter qualquer manual (man) para PDF no Linux.

1. Abra o terminal

2. Execute o comando

man -t <nome_do_app> | ps2pdf - <arquivo_de_saida.pdf>

Por exemplo:

man -t bash | ps2pdf - manual_bash.pdf

Entendendo os comandos:

man -t: Executa o man e formata a saída com o groff.

bash: Nome do software que queremos o manual.

ps2pdf -: Faz a conversão da saída - formatada pelo groff. O símbolo - representa stdout (saída padrão).

manual_bash.pdf: Nome do arquivo que será gerado.

Um abraço e ffffffffffffffalou!
Share:

quarta-feira, 6 de junho de 2018

Debian 9 + Openbox

A insônia pode ser considerada aceitável quando é produtiva.

Eis que instalei o Debian minimal, lembrei dos velhos tempos de Openbox + tint2 + conky + compton + parcellite + feh + dmenu + scrot + dunst + algumas ferramentas do xfce, scripts...

Alterei alguns temas do conky e do tint2, fiz o wallpaper de forma simples no GIMP, baseado nas cores do Debian.







... falta algumas coisas.


Share:

sexta-feira, 1 de junho de 2018

Remover os avisos de erro ao desligar o Arch Linux

Ae galera do Arch Linux,
conhece o problema abaixo, que ocorre na hora de desligar o sistema?

shutdown[1783]: Failed to remount '/oldroot/sys/fs/cgroup/devices' read-only: Device or resource busy
shutdown[1]: Failed to wait for process: Protocol error
shutdown[1796]: Failed to remount '/oldroot/sys/fs/cgroup/pids' read-only: Device or resource busy
shutdown[1]: Failed to wait for process: Protocol error
shutdown[1801]: Failed to remount '/oldroot/sys/fs/cgroup/systemd' read-only: Device or resource busy
shutdown[1]: Failed to wait for process: Protocol error

Muito bem. Para resolvê-lo siga esses passos:

1. Logue-se como root

2. Edite o arquivo /etc/mkinitcpio.conf

3. Procure pela parte que possui os HOOKS e adicione "shutdown"

De:


HOOKS=(base udev autodetect modconf block filesystems keyboard fsck)

Para:


HOOKS=(base udev autodetect modconf block filesystems keyboard fsck shutdown)

4. Salve o arquivo e rode o comando abaixo:


mkinitcpio -p linux

Se estiver utilizando o kernel LTS:
mkinitcpio -p linux-lts

5. Reinicie o sistema

Problema resolvido.

Abraços.
Share:

quarta-feira, 30 de maio de 2018

Instalação do KDE 5.12.5 LTS no Debian 9 (Stretch)

O lançamento do KDE Plasma 5.13 está cada vez mais próximo de acontecer - 07 de junho de 2018 (KDE Schedules) - e isto está causando ansiedade na comunidade Linux, principalmente aos adeptos do KDE.

Aqueles que preferem GNOME, Cinnamon, XFCE ou qualquer outro ambiente também serão beneficiados, pois com esse lançamento haverá melhorias de integração.
A integração entre os ambientes gráficos é bastante importante, não só pela interface uniformizada, mas também por recursos que rodam por trás desses ambientes (programas componentes, serviços, bibliotecas, etc).

Por exemplo, usuários do KDE (escrito em QT) precisam usar os programas GIMPINKSCAPEFIREFOX (escritos em GTK) para editar imagens e vetores, navegar na internet, etc. Os usuários do GNOME (escrito em GTK) precisam de ferramentas robustas de edição de vídeo, como o KDENLIVE, ferramentas para gravação e conversão de mídias, como o K3B (escritos em QT). E em meio a tudo isso temos o LIBREOFFICE (escrito em VCL), que suporta razoavelmente bem os ambientes gráficos, mas passa por constantes melhorias graças a uma comunidade super ativa. Quando não há integração entre esses frameworks (ou toolkits, como preferir), o ambiente não apenas fica feio como também não ocorre a comunicação adequada entre processos: alguns menus não aparecem, programas fecham inesperadamente, etc.

DEBIAN

O Debian é um sistema operacional e distribuição de Software Livre bastante estável, rápido e confiável. Para conseguir tantas qualidades exigiu-se muita dedicação e amadurecimento por parte dos seus desenvolvedores, principalmente do seu fundador Ian Murdock, que infelizmente nos deixou em 2015.

A estabilidade do Debian, por outro lado, traz consequências: pacotes antigos (bem mantidos, por sinal) e um ciclo de 2 anos para lançar novas versões, com "pequenas" atualizações de manutenção. A versão atual (9.0 - Stretch) foi lançada em 17 de Junho de 2017 e a atualização de manutenção mais recente é a 9.0.4, lançada em 10 de Março de 2018.

Temos disponível nessa versão do Debian o KDE Plasma 5.8 LTS, lançado em 04 de Outubro de 2016. Apesar de bem mantida (justamente por se tratar de uma versão LTS), em 01 de Fevereiro de 2018 tivemos o lançamento da versão 5.12 LTS, ou seja, aproximadamente dois anos depois. O que isso significa? Muitas novidades, correções, melhorias na interface, etc.




ATUALIZAÇÃO PARA A VERSÃO KDE PLASMA 5.12.5 LTS

Os desenvolvedores da distribuição Neptune OS disponibilizaram um script para atualizar o KDE Plasma no Debian.

Utilizei esse script em uma instalação limpa do Debian e funcionou perfeitamente. Mesmo assim, recomendo cautela.

É super simples. Basta executá-lo como root e seguir as instruções.
Share:

FEDORA BR - Comunidade Fedora (não oficial)

Ae, pessoal.

Estou passando pra dar um recado rapidinho.

Foi divulgado por Cristiano Furtado, no canal do Youtube Toca do Tux, o lançamento da comunidade não oficial FEDORA BR.



Preparem-se para boas novidades.

Clique aqui para assistir a entrevista, aproveite e se inscreva no canal.

Na descrição do vídeo possui todas as informações necessárias.



UPDATE: Pessoal, esqueci de comentar que esse logo utilizado na postagem não é o oficial da comunidade. Como não pedi autorização aos administradores achei mais prudente criar uma imagem para utilizar aqui na divulgação.
Share:

terça-feira, 29 de maio de 2018

Teste de velocidade de execução de código helloworld em Python, Bash e C

Opa!!
Quero demonstrar um pequeno teste. Pequeno mesmo, pois se trata apenas de um Hello World escrito em Python, em Shell e em C.

-- Mas qual o objetivo?

O objetivo é mostrar a diferença que existe no tempo de execução "em milisegundos" de um simples Hello World escrito em linguagens diferentes.

Lembrando que C se diferencia das outras linguagens aqui citadas por se tratar de uma liguagem compilada (Python e Shell são interpretadas).

Apesar de milisegundos parecer pouco, quando trazemos para a vida real e executamos vários processos, com vários arquivos, de forma repetida, essa "pequena" diferença pode influenciar bastante.

Primeiro, em Python:
< arquivo: hello.py >

#!/usr/bin/python3

print('Hello World')

Em seguida, em Shell, na qual testaremos com echo e com printf:
  • echo
< arquivo: hello_echo.sh >

#!/bin/bash

echo "Hello World"

  • printf
< arquivo: hello_printf.sh >

#!/bin/bash

printf "Hello World\n"

Tradução livre da diferença entre echo e printf
Tanto o echo quanto o printf são comandos internos do Bash, sendo que o printf se tornou um comando interno a partir do Bash v. 4.1.7. O echo sempre finaliza sua execução com status 0, e simplesmente imprime os argumentos seguidos por EOL (caractere "end of line", ou seja, quebra de linha) na saída padrão, enquanto printf permite a definição de uma string de formatação e fornece um código de status diferente de 0 em caso de falha.
Unix Stack Exchange


* Vale lembrar que você pode evitar o caractere EOL no comando echo, mas não por padrão.

Por fim, em C:
< arquivo: hello.c >

#include <stdio.h>

int main(void) {
    printf("Hello World\n");
    return 0;
}

Pronto. Códigos criados, compilação concluída, permissões de execução dadas, vamos rodar com o comando time e verificar o resultado:



Conforme a imagem, o Python foi o que mais demorou para exibir o texto "Hello World":

real    0m0.036s
user    0m0.018s
sys     0m0.018s

Em seguida, o shell script (tanto o echo quanto o printf):

real    0m0.014s
user    0m0.006s
sys     0m0.000s

Por fim o C, que foi o mais rápido:

real    0m0.011s
user    0m0.001s
sys     0m0.001s

Para finalizar, testaremos um loop no qual o shell imprime 1000 vezes o Hello World, direcionando a saída padrão para /dev/null

Vamos utilizar dois formatos de iteração. O formato convencional e o "BRACE EXPANSION" {START..END} apenas para demonstração

Em Python:

$ time for ((i=0;i<=999;i++)) ; do /usr/bin/python3 -c 'print("Hello World")' > /dev/null ; done

real    0m31.275s
user    0m26.692s
sys     0m4.638s

$ time for i in {0..999} ; do /usr/bin/python3 -c 'print("Hello World")' > /dev/null ; done

real    0m31.585s
user    0m26.565s
sys     0m5.034s

Em Shell:
  • echo

$ time for ((i=0;i<=999;i++)) ; do echo "Hello World" > /dev/null ; done

real    0m0.030s
user    0m0.020s
sys     0m0.010s

$ time for i in {0..999} ; do echo "Hello World" > /dev/null ; done

real    0m0.028s
user    0m0.009s
sys     0m0.019s

  • printf

$ time for ((i=0;i<=999;i++)) ; do printf "Hello World\n" > /dev/null ; done

real    0m0.030s
user    0m0.022s
sys     0m0.009s

$ time for i in {0..999} ; do printf "Hello World\n" > /dev/null ; done

real    0m0.028s
user    0m0.009s
sys     0m0.019s


Observe que obtivemos resultados próximos entre os comandos echo e printf, e que em ambos os casos a utilização do "Brace Expansion" trouxe um pequeno ganho de velocidade

Em C:

$ time for ((i=0;i<=999;i++)) ; do ./hello > /dev/null ; done

real    0m1.589s
user    0m1.175s
sys     0m0.541s

$ time for i in {0..999} ; do ./hello > /dev/null ; done

real    0m1.527s
user    0m1.156s
sys     0m0.493s

Finalizamos os testes com o LOOP e pudemos observar que o Python levou quase 32 segundos para finalizar a execução, enquanto o C realizou em aproximadamente 2 segundos e o shell em apenas 30 milisegundos.

Não quero com isso afirmar que a linguagem A é mais rápida que a linguagem B, afinal não tenho grandes conhecimentos de programação e otimização de código, mas é importante analisar que "milisegundos" podem acelerar bastante a conclusão de alguns procedimentos no dia a dia de um sys-admin.

Abraços, galera.
Share: