Btrfs é um sistema de arquivos relativamente "recente" (o desenvolvimento começou em 2008) com um bocado de features interessantes. Neste post, falarei uma porção de coisas sobre como usar uma partição Btrfs como sistema de arquivos raiz no Debian. O Btrfs ainda é considerado experimental (embora seja bastante estável em kernels recentes), e eu não confiaria meus arquivos pessoais a ele no momento (meu /home é uma partição ext4), mas como sistema de arquivos raiz de uma máquina de uso pessoal (que se eu perder é só reinstalar), acredito que os benefícios compensam os riscos.
[Update: Aparentemente ele não é tão estável assim.]
A principal razão pela qual eu migrei meu / para Btrfs foi para usar sua feature de snapshots, que permite criar uma "duplicata" do estado do sistema de arquivos em um dado momento. A criação de um snapshot não duplica os arquivos; ao invés disso, os arquivos são compartilhados entre as duas "versões" do sistema de arquivos, e só são copiados à medida em que são modificados, o que torna a criação do snapshot praticamente instantânea e não consome espaço desnecessariamente. Com isso você pode, por exemplo, tirar um snapshot do /, atualizar/bagunçar o sistema e, se alguma coisa der errado, voltar ao estado anterior são e salvo.
Kernel 3.14 ou superior. O suporte a Btrfs do kernel atual (3.2) do Debian stable é bastante precário (eu consegui derrubar ele com um for ((i=0; ; i++)); do mkdir $i; done em um filesystem recém criado). As opções são:
Para usar o backports, basta adicionar o repositório wheezy-backports no /etc/apt/sources.list. (Leitor do futuro: substitua wheezy pelo nome da release stable do momento.) Por exemplo, se o seu sources.list contém linhas como:
deb http://ftp.br.debian.org/debian wheezy main contrib non-free
adicione a linha:
deb http://ftp.br.debian.org/debian wheezy-backports main contrib non-free
Em seguida, dê um apt-get update para baixar os índices dos repositórios. (Alternativamente, você pode abrir o aptitude e teclar u.) Feito isso, você poderá instalar o pacote de kernel apropriado à sua máquina (e.g., linux-image-3.14-0.bpo.2-686-pae) com o apt-get ou o aptitude.
Package: * Pin: release a=testing Pin-Priority: 400 Package: * Pin: release a=unstable Pin-Priority: 90
Isso dá prioridade 500 aos pacotes da testing e 90 aos da unstable. Traduzindo da manpage:
Prioridades (P) atribuídas no arquivo de preferências do APT devem ser inteiros positivos ou negativos. Eles são interpretados da seguinte maneira (a grosso modo):
P >= 1000 Faz com que uma versão seja instalada mesmo que isso constitua um downgrade do pacote 990 <= P < 1000 Faz com que uma versão seja instalada mesmo que ela não pertença à target release, a menos que a versão instalada seja mais recente 500 <= P < 990 Faz com que uma versão seja instalada a menos que haja uma versão disponível pertencente à target release ou a versão instalada seja mais recente 100 <= P < 500 Faz com que uma versão seja instalada a menos que haja uma versão disponível em outra distribuição ou que a versão instalada seja mais recente 0 < P < 100 Faz com que uma versão seja instalada apenas se não houver uma versão instalada do pacote P < 0 Impede que a versão seja instalada
Tendo adicionado o repositório da unstable (com uma linha tal como
deb http://ftp.br.debian.org/debian sid main contrib non-free
no /etc/apt/sources.list), basta dar um apt-get update ou similar e instalar o pacote apropriado (linux-image-3.16-1-686-pae na minha máquina).
btrfs-tools 3.14 ou superior. Disponível tanto no repositório da backports quanto no da unstable.
Para poder bootar a partir de um raiz Btrfs, você precisará adicionar suporte ao filesystem ao seu initramfs. Para isso, adicione as seguintes linhas ao /etc/initramfs-tools/modules:
crc32c btrfs
e execute update-initramfs -u -k all.
A linha crc32c é particularmente relevante: Geralmente, o update-initramfs é esperto o suficiente para incluir junto com um módulo todas as suas dependências no initramfs. Porém, por um bug no módulo btrfs, ele não indica explicitamente sua dependência pelo módulo crc32c. Se o módulo crc32c não for incluído manualmente na lista, a carga do módulo btrfs falhará no boot, com uma mensagem do tipo can't load module btrfs (kernel/fs/btrfs/btrfs.ko): unknown symbol in module, or unknown parameter. (Isso me tomou uma boa hora de sofrimento.)
Para transformar seu raiz em Btrfs, você precisará bootar com um outro sistema e seguir uma de duas rotas:
Antes de rebootar o sistema no filesystem recém criado, lembre-se de altarar o etc/fstab do sistema. Você poderá ter que trocar:
Se o seu /boot fica dentro na mesma partição que o raiz, você pode ter que fazer alguma mudança no seu gerenciador de boot para garantir que ele consiga ler o Btrfs. O GRUB 2 aparentemente consegue ler Btrfs sem problemas. (Eu ainda uso o bom e velho GRUB 0.97, mas meu /boot é uma partição ext2 separada.)
O Btrfs organiza o filesystem em subvolumes. Inicialmente, o filesystem contém apenas um "subvolume raiz", mas outros subvolumes podem ser criados com o comando btrfs subvolume create /caminho/novo-nome, onde /caminho é um diretório dentro do filesystem de interesse. btrfs subvolume list /caminho lista todos os subvolumes (e respectivos IDs) contidos em um filesystem.
O comando btrfs subvolume snapshot /caminho-subvol-origem /caminho-subvol-destino duplica um subvolume, i.e., cria um "snapshot". Depois da duplicação, os dois subvolumes são independentes: alterações em um não se refletem no outro.
Um filesystem Btrfs possui um subvolume padrão, i.e., o subvolume que é usado como raiz do filesystem se nenhum outro for especificado. Inicialmente, o "subvolume raiz" é o padrão, mas você pode usar o comando btrfs subvolume set-default ID /caminho (onde ID é o ID mostrado por btrfs subvolume list) para escolher outro. Com isso você pode setar o subvolume padrão para um snapshot com um estado anterior do sistema, por exemplo, reiniciar a máquina, e magicamente seu sistema volta a ser o que era no momento do snapshot.
Você pode montar um subvolume diferente do padrão passando a opção -o subvolid=ID para o comando mount. -o subvolid=0 monta o subvolume raiz original. Você pode montar a mesma partição mais de uma vez.
Como eu mencionei antes, ao invés de copiar o backup do sistema diretamente para o raiz da nova partição, pode ser mais conveniente criar um subvolume primeiro, especialmente se você pretende usar a feature de snapshots com freqüência. Por exemplo, ao criar o filesystem:
# mount /dev/xxx /mnt/sistema # cp -avx /mnt/sistema /algum/lugar/backup # umount /mnt/sistema # mkfs.btrfs -f /dev/xxx # mount /dev/xxx /mnt/sistema # btrfs subvolume create /mnt/sistema/current # btrfs subvolume list /mnt/sistema ID 264 gen 142 top level 5 path current # btrfs subvolume set-default 264 /mnt/sistema # cp -avx /algum/lugar/backup/* /mnt/sistema/current # (realize as adaptações pré-boot adequadas)
Com o subvolume padrão setado, você pode reiniciar e bootar o sistema novo normalmente. Quando você quiser fazer um snapshot, basta montar o raiz original em algum lugar (e.g., /mnt/root) e fazer as operações de interesse:
# mount -o subvolid=0 /dev/xxx /mnt/root # btrfs subvolume snapshot /mnt/root/current /mnt/root/snapshot-20120912 # umount /mnt/root
Feito isso, você pode bagunçar com seu sistema à vontade e, se quiser voltar atrás, pode executar:
btrfs subvolume set-default ID-do-snapshot
e reiniciar a partir do snapshot. Ou, se preferir não alterar o snapshot, você pode duplicá-lo primeiro e reiniciar pela cópia:
# mount -o subvolid=0 /dev/xxx /mnt/root # btrfs subvolume snapshot /mnt/root/snapshot-20120912 /mnt/root/current2 # btrfs subvolume list /mnt/root ID 264 gen 142 top level 5 path current ID 266 gen 142 top level 5 path snapshot-20120912 ID 268 gen 142 top level 5 path current2 # btrfs subvolume set-default 268 /mnt/root # reboot
Lembre-se de depois apagar o current antigo (com btrfs subvolume delete /mnt/root/current), caso não queira que ele fique ocupando espaço para sempre.
A vantagem de criar um subvolume primeiro antes de copiar o sistema é deixar o subvolume raiz original contendo apenas subvolumes, evitando misturar subvolumes e arquivos de sistema no mesmo nível. Isso permite manipular todos os subvolumes/snapshots da mesma maneira (qualquer versão do sistema pode ser apagada facilmente, por exemplo; com o sistema no raiz original isso não seria possível).
O utilitário btrfs permite abreviar comandos, desde que as abreviações não sejam ambíguas. Por exemplo, btrfs subvolume list / pode ser escrito como btrfs sub l /.
Espaço usado e livre em Btrfs são conceitos um tanto quanto curiosos, devido ao mecanismo de copy-on-write, suporte a compressão e outras peculiaridades do Btrfs. O comando btrfs filesystem df /caminho pode dar um resultado mais preciso do que o df -h.
Descobrir o espaço utilizado por cada subvolume é uma questão mais complicada (até porque subvolumes podem compartilhar dados). Se o mecanismo de quotas for habilitado no subvolume raiz original (com o comando btrfs quota enable /mnt/root), é possível usar o comando btrfs qgroup show /, que lista a quantidade de dados apontada por cada subvolume e a quantidade de dados não compartilhada com nenhum outro subvolume (e que portanto seria liberada se o subvolume fosse apagado). Para mais informações, dê uma olhada neste artigo.
É possível criar um snapshot somente-leitura passando a opção -r para o comando btrfs subvolume snapshot. A vantagem é que é mais difícil de destruir um backup do sistema assim. A desvantagem é que não é mais possível bootar pelo snapshot como se fosse um sistema comum.
Eu já falei de capabilities por aqui algumas vezes antes. Neste post tentarei explicar o que elas são e por que eu acho que elas são a panacéia universal (ok, não, mas por que eu acho que elas são um avanço em comparação com as permissões convencionais do Unix).
(Antes de mais nada, gostaria de ressaltar que as capabilities a que eu me refiro aqui não têm nada que ver com o que o Linux chama de capabilities, que são basicamente uma maneira de separar o tradicional balaio de poderes do root em unidades que podem ser atribuídas individualmente a processos (e.g., com isso é possível dar a um processo o poder de alterar o relógio do sistema sem conceder todos os outros poderes de root junto).)
Uma capability é um objeto ou "token" que representa a habilidade de um processo de acessar um certo recurso, tal como um arquivo ou uma conexão de rede. Capabilities possuem três propriedades importantes:
Turns out que file descriptors no Unix possuem essas três propriedades. Ao abrir um arquivo no Unix, o processo recebe um número inteiro que é um índice na tabela de file descriptors do processo, que é acessível apenas pelo kernel. File descriptors abertos podem ser passados adiante para os filhos de um processo ou transferidos via sockets. Uma vez aberto o arquivo, as credenciais do processo são irrelevantes para o seu acesso: um processo pode, por exemplo, começar executando como root, abrir um recurso privilegiado (e.g., ouvir em uma porta menor que 1024), e depois trocar de credenciais para um usuário menos poderoso sem perder o acesso ao recurso privilegiado, pois a posse do file descriptor da conexão é suficiente para garantir-lhe acesso ao recurso. (Um file descriptor não é uma capability pura porque conserva outros dados além dos necessários ao acesso do recurso, tais como a posição do cursor no arquivo, o que dificulta seu uso compartilhado por outros processos depois de transmitido, mas em essência trata-se de uma capability.)
A mágica de um modelo de segurança baseado em capabilities, entretanto, é que todo acesso a recursos é feito por meio de capabilities, e um processo tem acesso apenas aos recursos representados pelas capabilities que lhe são entregues. No Unix, por outro lado, um processo recebe acesso implícito e mais ou menos inevitável a diversos recursos, tais como o filesystem e a habilidade de criar conexões de rede. É possível cercar o acesso a esses recursos, e.g., usando chroot para entregar um filesystem alternativo ao processo (mas não é possível não entregar filesystem nenhum ao processo) ou regras de firewall para bloquear o acesso do processo à rede (geralmente indiretamente, e.g., rodando o processo com outro usuário e bloqueando o usuário no iptables), mas há uma série de dificuldades e inconvenientes envolvidos:
A raiz do problema é que o modelo de segurança do Unix foi criado no contexto dos sistemas multi-usuário dos anos 1970, em que a preocupação primária era proteger os usuários uns dos outros e o sistema dos usuários. Hoje em dia as preocupações são outras: no caso de computadores pessoais, a maioria das máquinas roda com um único usuário, e queremos proteger o usuário de programas potencialmente mal-comportados (seja por conterem vulnerabilidades, seja por descuido do programador, seja porque o programa é intencionalmente malicioso) que o próprio usuário executa. No caso de servidores, queremos minimizar o potencial de desastre caso um serviço seja comprometido. Capabilities se encaixam melhor (acredito) com essas preocupações do que o modelo de segurança tradicional do Unix, pois permitem um controle maior de o que um processo é capaz de acessar. Ao invés de passarmos aos programas o acesso ao filesystem inteiro e os nomes de arquivos que queremos que o programa manipule, passamos capabilities aos arquivos de interesse, sem entregar o acesso a todo o resto do filesystem junto. Ao invés de chamar todos os programas com o poder de abrir conexões de rede, podemos passar esse poder apenas aos processos que realmente tenham que ter esse acesso.
A essas alturas você talvez esteja se perguntando: "Ok, meu filho, e como isso resolve o problema do browser? Eu não vou ter que entregar uma capability para acessar todos os meus arquivos para o caso de eu querer fazer upload de um deles? Hã? Hã?"
A solução é uma das coisas mais legais que se consegue fazer com capabilities. Lembre-se de que capabilities podem ser transmitidas entre processos. Isso significa que nós podemos ter um daemon (chamemo-lo fileopend) capaz de fornecer capabilities. Ao iniciarmos o browser, passamos a ele uma capability que é um canal de comunicação com o fileopend. Quando o usuário vai fazer upload de alguma coisa, ao invés de o browser abrir a janelinha de "Abrir arquivo", ele manda uma requisição de abertura de arquivo ao fileopend. O fileopend, então, mostra a janelinha de "Abrir arquivo" ao usuário. O usuário escolhe o arquivo, e então o fileopend o abre e envia a capability correspondente àquele arquivo específico para o browser. O browser, assim, só tem acesso a arquivos que o usuário tenha selecionado explicitamente na janela de "Abrir arquivo".
Genial, hã?
Atualmente existe um projeto chamado Capsicum: practical capabilities for UNIX, que teve bastante progresso recentemente. Trata-se de uma implementação de capabilities no FreeBSD, que está sendo adaptada para o Linux. O projeto inclusive produziu uma versão do Chromium baseada em capabilities, usando uma idéia análoga à do fileopend (que eles chamam de "user angels") para abrir arquivos do usuário.
Mas teoricamente, seria possível implementar capabilities em user-space no Unix com uma pequena dose de faconice. No cenário mais simples, seria possível rodar cada processo com um usuário/grupo diferente (gerar um UID/GID para cada processo novo), em um chroot, com acesso à rede bloqueado no firewall, etc., apenas com um canal de comunicação com um daemon que intermediaria o acesso dos processos a todos os recursos, tais como arquivos, conexões de rede, etc. Esse daemon faria o papel do kernel em um sistema com suporte nativo a capabilities. O problema com essa abordagem é performance: todo acesso a recursos teria que passar pelo canal de comunicação entre os processos comuns e o daemon. Porém, uma vez que file descriptors podem ser transmitidos por sockets no Unix, seria possível usar o daemon apenas para criar e transmitir file descriptors (capabilities) para os processos. Uma vez de posse do file descriptor, o processo pode utilizar o recurso "nativamente". A perda de performance seria apenas na abertura de recursos, e talvez não fosse tão significativa. Anyway, graças ao Capsicum, estamos em vias de ter capabilities nativas no Linux (hopefully no kernel mainline) sem ter que apelar a gambiarras.
Unix is dead. Long live Unix.
Escrevi um pequeno script em Perl para converter um archive de mailing list do LISTSERV para o formato mbox, que pode ser importado em diversos clientes de e-mail. Possa ele ser-vos útil.
Esses dias fui assistir um filme com uma resolução maior do que a minha tela com o mplayer e meu Atom não estava dando conta de fazer o zoom out/scaling em tempo real.
Solução? O mplayer suporta uma opção -sws N, que permite escolher o algoritmo de software scaling a ser usado. Usando -sws 4, obtém-se um zoom de qualidade levemente pior, mas que consome menos processamento.
Outra opção útil é -autosync N, que controla a sincronia entre áudio e vídeo. A documentação do mplayer recomenda -autosync 30 para resolver problemas de sincronia com drivers de áudio problemáticos. No meu caso, -autosync 1 pareceu funcionar melhor. Não sei exatamente o que faz essa opção, sinceramente. Para mais informações, consulte a manpage do mplayer.
Quem me contou foi esse cara.
Às vezes executamos comandos do tipo:
cat imagem_grande_que_demora_para_copiar.img >/dev/sdb
e queremos saber o andamento do processo. Quando copiamos os dados de um disco para um arquivo podemos simplesmente olhar o tamanho do arquivo para ter uma idéia do andamento da operação, mas quando o destino é um disco isso não é possível.
É possível, entretanto, olhar a posição do cursor no arquivo. No Unix, todo arquivo aberto tem associado a si um cursor, i.e., a posição a partir da qual operações de leitura e escrita operam por padrão; cada leitura ou escrita no arquivo avança a posição do cursor.
Podemos utilizar um programinha chamado lsof (list open files, pacote lsof no Debian/Ubuntu) para visualizar diversas informações sobre arquivos abertos, dentre elas a posição do cursor. Por padrão, o lsof mostra uma coluna que contém ou a posição do cursor ou o tamanho do arquivo, dependendo do tipo de arquivo; a opção -o (offset) força o lsof a mostrar sempre o cursor. Além disso, por padrão o lsof mostra a posição em hexadecimal se ela ocupar mais de 8 dígitos decimais; a opção -o 0 desabilita esse comportamento. As duas opções podem ser combinadas como -oo0.
Por padrão, todos os arquivos abertos são listados. É possível especificar os nomes dos arquivos a serem listados, ou os nomes (-c nome) ou PIDs (-p pid) dos processos cujos arquivos abertos se deseja ver. Por exemplo:
# cat /dev/sda5 >/dev/sda6 & [1] 28252 # lsof -oo0 /dev/sda6 COMMAND PID USER FD TYPE DEVICE OFFSET NODE NAME cat 28252 root 1w BLK 8,6 0t254476288 1303 /dev/sda6
Para mais informações, consulte a manpage do lsof.
# ls -lah foo -rw-r--r-- 1 root root 512M Jul 18 23:00 foo # time cat foo >bar real 0m21.304s user 0m0.068s sys 0m5.212s # time dd if=foo of=bar 1048576+0 records in 1048576+0 records out 536870912 bytes (537 MB) copied, 39.397 s, 13.6 MB/s real 0m39.621s user 0m1.528s sys 0m25.910s
O motivo para isso é que o dd sempre copia os arquivos usando um tamanho de bloco fixo (indicado pelo parâmetro bs=tamanho, 512 bytes por padrão), enquanto o cat usa um tamanho de bloco "ótimo", o que permite que ele faça a cópia com menos chamadas de sistema (o que se reflete no tempo de sys na saída do comando time). Alternativamente, você pode especificar um tamanho de bloco maior para o dd (e.g., bs=1M), mas isso não apresenta nenhuma vantagem sobre usar o cat, a menos que você queira especificar o tamanho do arquivo também (e.g., no clássico dd if=/dev/zero of=foo bs=1M count=512 (que no entanto também pode ser substituído por um head -c 512M /dev/zero >foo)).
Em algum momento do ano passado, por falta de coisa melhor para fazer, eu me parei a ler o manual da GNU libc. Não cheguei a ir muito longe, mas descobri um bocado de coisas interessantes no processo.
A scanf é uma das primeiras funções que vemos quando aprendemos C. Por isso mesmo, acabamos vendo só a funcionalidade básica para sobrevivência. Aí achamos que conhecemos a scanf e nunca mais nos preocupamos com ela. Ela possui um bocado de features interessantes, entretanto:
Uma conseqüência disso é que um programa do tipo while (x!=0) scanf("%d", &x);, ao se deparar com uma entrada do tipo foo, entra em loop infinito (pois a scanf nunca consegue ler o %d, não altera o valor de x, e o foo fica para sempre no buffer de entrada).
char *string;
scanf("%as", &string);
Existe uma função getline(char **linha, size_t *tamanho, FILE *stream), que recebe um ponteiro para um buffer inicial e seu tamanho, lê uma linha de tamanho arbitrário, realocando o buffer e atualizando o tamanho automaticamente, e retorna o número de caracteres lidos (que pode ser menor que o buffer, em princípio). Se linha for um ponteiro para um ponteiro nulo, o buffer inicial será alocado automaticamente. E.g.:
char *buf = NULL; size_t bufsize, bytes_read; bytes_read = getline(&buf, &bufsize, stdin);
Também existe uma função getdelim, que faz a mesma coisa, mas usa um delimitador diferente de \n como fim da "linha".
Essas funções não são parte do C padrão, e sim das extensões do GNU e de versões recentes do POSIX.
A glibc tem muita coisa (a versão em PDF do manual tem cerca de mil páginas). Vale a pena dar uma olhada no manual, nem que seja apenas para descobrir que tipo de recursos ela fornece, caso um dia você precise de algum deles.
Para o meu choque e horror, acabei de me dar conta de que Tcl pode ser uma alternativa decente ao shell do Unix. Essa galera me convenceu ainda mais disso. Com meia dúzia de funções auxiliares para fazer piping e redirecionamentos de maneira mais conveniente, essa pode ser uma boa solução.
Por um lado, problem solved. Por outro lado, isso me tira uns 80% da motivação para escrever um shell. Talvez o que seria uma boa é criar uma "extensão" de Tcl que permita o uso da sintaxe convencional do shell para pipes e redirecionamentos. O fato de que o Tcl usa strings para representar todos os tipos de dados inclusive torna trivial o problema de passar dados estruturados entre processos no Unix.
Well, melhor seguir adiante com o resto dos meus planos de dominação mundial.
[P.S.: Eis uma introdução interessante aos poderes do Tcl.]
Por falta de coisa mais interessante para fazer, e já que RSS não é exatamente a tecnologia da modinha, estou disponibilizando experimentalmente um feed do blog no Twitter. A continuidade do "serviço" está sujeita à existência de usuários. [Update: Pensando melhor, provavelmente todo o mundo que tem interesse em seguir blogs usa RSS. Enfim, o feed está aí, por enquanto.]
A parte interessante da história é que eu descobri um bocado de clientes de linha de comando do Twitter no processo. Dos que eu experimentei, o que melhor me satisfez foi o t. (Eu experimentei mais outros dois clientes: o TTYtter, um cliente interativo pra lá de bizarro, mas com mil features e aparentemente fácil de estender; e o twidge, que aparentemente não suporta UTF-8. Existem dúzias de outros clientes, como uma pesquisa no Google revela.)
Os poderes mágicos do t derivam do fato de ele ser particularmente conveniente de usar em scripts. Um exemplo extraído da documentação:
Favorite the last 10 tweets that mention you
t mentions -n 10 -l | awk '{print $1}' | xargs t favorite
É possível instalar o t pelo RubyGems, através do comando gem install t. Antes de instalá-lo, certifique-se de que você tem instalado o Ruby e o RubyGems (pacotes ruby, ruby-dev e rubygems no Debian/Ubuntu; não ter o ruby-dev é um problema comum).
Uma vez instalado, é necessário executar t authorize, para realizar o processo de registro da aplicação no Twitter e de autorização do acesso da aplicação à sua conta. Você pode executar t sem argumentos para ver uma lista dos comandos disponíveis. Para mais informações, dê uma olhada no README na página do projeto.
(Quem me contou foi essa página.)
O SoX (SOund eXchange; pacotes sox e libsox-fmt-all no Debian) é uma biblioteca e um programa de linha de comando que permitem converter entre diversos formatos de arquivo de áudio, opcionalmente aplicando filtros. A sintaxe básica do comando sox é:
sox [opções-globais]
[opções-de-formato] entrada1
[[opções-de-formato] entrada2 ...]
[opções-de-formato] saída
[filtros ...]
Por exemplo, para gravar do microfone (usando ALSA) em um arquivo WAV:
sox -t alsa default -t wav blabla.wav
(Use Control-C para terminar a gravação. Tecnicamente o -t wav pode ser omitido, já que o sox é capaz de deduzir o formato do arquivo pela extensão.)
Um par de filtros particularmente interessante é o noiseprof/noisered, que permitem eliminar ou reduzir ruído constante de fundo. Isso é feito em duas etapas. Primeiro, executa-se o sox com o filtro noiseprof [profile.txt] sobre uma "amostra de silêncio", i.e., um trecho de áudio que consista apenas do ruído de fundo, de maneira a produzir um profile de ruído. Você pode capturar o "silêncio" do microfone ou de algum outro arquivo que consista apenas de silêncio (a opção --null pode ser usada no lugar do arquivo de saída, já que estamos interessados apenas no profile de ruído):
sox -t alsa default --null noiseprof profile.txt sox algum-arquivo-que-consista-apenas-de-silêncio.wav --null noiseprof profile.txt
Alternativamente, você pode selecionar um trecho de um arquivo com o filtro trim início [duração] e usá-lo como fonte de silêncio:
# Seleciona o intervalo de de 1s até 2.5s. Aqui usamos '-t alsa default' como # saída para podermos ouvir se o trecho selecionado de fato corresponde a "silêncio". sox entrada.wav -t alsa default trim 1 1.5 noiseprof profile.txt
Se o nome do arquivo de profile for omitido, o sox escreve o profile na stdout.
Gerado o profile de ruído, podemos usar o filtro noisered [profile.txt [quantidade]] para remover o ruído do arquivo completo. quantidade é um número entre 0 e 1 indicando a quantidade de ruído que deve ser removida. Quanto maior o número, mais ruído será removido – e mais não-ruído também. Experimente com números pequenos (e.g., 0, 0.05, 0.1, etc.) primeiro.
sox entrada.wav saída.wav noisered profile.txt 0.05
Se você tem um microfone problemático, você pode querer guardar o arquivo de profile para usos futuros (assumindo que o padrão de ruído produzido seja sempre o mesmo).
Se o arquivo de entrada para o noisered não for especificado ou for -, o sox lê o profile da stdin. Assim, você pode combinar o profiling e a redução em um pipeline:
sox entrada.wav --null trim 0 1 noiseprof | sox entrada.wav saída.wav noisered - 0.05
Para mais informações, consulte a manpage do sox.
O GNU Barcode (pacote barcode no Debian) é uma biblioteca e um utilitário de linha de comando capaz de gerar códigos de barras de diversos tipos nos formatos PS e PCL. O programa possui diversas opções, que permitem controlar o tamanho e a posição dos códigos na página gerada, entre outras coisas.
Por exemplo, o comando:
barcode -c -e i25 -b 00123456 >codigo.ps
gera um PS com uma página contendo um código de barras sem checksum (-c) do tipo "interleaved 2-of-5" (-e i25), codificando a string 00123456. (Não vou nem dizer para que alguém geraria um código desses.)
Para converter o PS para um PNG, você pode usar o GIMP, ou o comando convert do ImageMagick (pacote imagemagick):
convert -trim codigo.ps codigo.png
Use it well.
« Mais recentes / Newer posts | Mais antigos / Older posts »
Copyright © 2010-2024 Vítor De Araújo
O conteúdo deste blog, a menos que de outra forma especificado, pode ser utilizado segundo os termos da licença Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International.
Powered by Blognir.