Feeds:
Posts
Comments

If for some weird reason you need to connect two QEMU/KVM instances via a virtual null modem cable, here’s how to do it:

$ mkfifo null-cable-1.{in,out}
$ ln null-cable-1.in null-cable-2.out
$ ln null-cable-1.out null-cable-2.in
$ qemu -m 512 -nographic -serial pty -serial pipe:null-cable-1 -hda image1.qcow2
$ qemu -m 512 -nographic -serial pty -serial pipe:null-cable-2 -hda image2.qcow2

For each instance, you’ll be dropped into a monitor prompt:

char device redirected to /dev/pts/9
QEMU 0.12.1 monitor - type 'help' for more information
(qemu)

The machine is running already, but in the background. To access its console, open the pty mentioned in the output:

$ screen /dev/pts/9

cúmulo da desorganização

Acabo de perceber que tenho um arquivo na raiz do meu $HOME chamado ipsec.pdf datado de 2006 cujo conteúdo é um HTML de 404 Not Found. Pra você ver como sou organizado…

Imagem

Imagem

Suporte técnico da Vivo para Linux

Esses dias assinei um plano 3G da Vivo. Chegando em casa, comecei a usar a conexão 3G ao invés do ADSL que tenho aqui para testar o serviço. Foi meio broxante quando depois de um tempo de uso (1 hora talvez? não sei) a conexão ficou extremamente lenta, com pings de 30 segundos ou mais (o recorde foi 200 segundos!). Lá vou eu, ligar pro suporte da Vivo no mesmo dia em que assinei o serviço. A 1ª impressão foi pro ralo.

Interessante que o menu do telefone já classifica o usuário por sistema operacional:

Se você usa um computador com Windows, tecle 1.
Se você usa um computador com Mac OS, tecle 2.
Se você usa um computador com Linux, tecle 3.

Legal, eles reconhecem que existem clientes que usam Linux! Teclei 3. A experiência não foi lá tão boa, mas isso não surpreendeu. Obviamente o suporte da Vivo coloca sempre a culpa no seu equipamento e o problema nunca é na rede deles, então pedem pra fazer trocentos procedimentos de configuração e teste antes de cogitarem que eles têm que fazer algo do lado deles.

Mas isso é outra história. O interessante foi o procedimento que ele pediu pra eu fazer. Em primeiro lugar, pediu para abrir um terminal e digitar:

$ sudo echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6

Imagine o tempo que levou pra soletrar tudo isso.:-)

A 1ª coisa que salta aos olhos é que o comando tem um erro típico de quem não manja muito de Linux (quem eles contrataram pra elaborar os procedimentos de Linux deles?!?): o comando “echo 1” rodará como usuário root, mas a parte do “> blah” é feita pelo shell do usuário, portanto vai dar erro de permissão na hora de escrever no disable_ipv6.

Mais impressionante que isso, o atendente pediu pra eu digitar a parte do “$␣”, ou seja ele soletrou “Cifrão, espaço, s, u, d, o, …”.

FacePalm

Quando terminei de digitar o comando (fazendo as alterações necessárias) e apertei enter, ele perguntou se apareceu “Operação bem sucedida”.

NOT-SURE-IF-A-TROLL-OR-JUST-STUPID

Eu expliquei pra ele que quando não aparece nada é porque o comando deu certo então seguimos adiante. A próxima coisa que eu tinha que fazer era reiniciar o computador. Wait wat? Todo esse trabalho soletrando um comando gigante pra editar uma variável no /proc e ele quer que eu reinicie?

mr-bean-irritado

Pra quem não usa ou não manja de Linux (o que não tem problema nenhum, e é até saudável, a menos que você trabalhe com suporte técnico): as alterações no /proc são “efêmeras” e na próxima vez em que o computador é ligado volta tudo como estava antes.

O lado bom da história é que a Vivo suporta Linux. Os atendentes também são surpreendentemente prestativos. Quando o procedimento acima não funcionou (quem diria?), eu fiquei discutindo com o cara outras possibilidades, ele deu algumas sugestões genéricas, inclusive uma que ajudou bastante: o problema talvez fosse que o modem muda de 3G (HSUPA) para 2G (EDGE), e aí fica lento. Passei a reparar nisso e realmente é o que acontece.

Já estou fugindo do assunto mas resumidamente, em outra ligação a atendente mencionou que é possível forçar o modem a ficar só no 3G, e isso poderia resolver o problema. O procedimento que ela tinha era só pro Windows infelizmente mas tá valendo, entrei no Windows. Só que meu modem é da Claro e o “discador” que veio nele também, e ele é ligeiramente diferente do da Vivo. Apesar disso ela ficou um tempão tentando me ajudar, tentando mapear o procedimento que ela tinha pra interface do meu discador. No fim achei a opção e realmente resolveu o problema!

Agora, por que o modem muda pra EDGE? Isso ninguém soube explicar, e ainda não consegui convencer a Vivo a fazer uma revisão na rede dela aqui no meu bairro…

I have been meaning to write this post for a long time.

One thing which I often found myself doing was typing echo $? after running a command to find out if there was any error, or appending || echo failed to the end of the command line.

Commands generally warn if there was an error, but you have to stop for a second and carefully read the output to see whether anything went wrong. I’m lazy and that additional second and the extra cognitive effort always bothered me.

I eventually had the idea of making the shell prompt show the exit status of the last command if it was non-zero. I use zsh, so it’s got to be possible.:-)

It turns out it is, this is my PS1 variable now:

CYAN="%{"$'33[00;36m'"%}"
RED="%{"$'33[01;31m'"%}"
NORM="%{"$'33[00m'"%}"

export PS1="${CYAN}%m${NORM}%# %(?..${RED}(%?%)${NORM} )"

The magical part is %(?..${RED}(%?%)${NORM} ). Here’s the result:

zsh prompt

As a side note, one other thing that the screenshot shows is the right-hand prompt. This is a great feature of zsh, and I use it to show the current working directory. That way, no matter where I am in the filesystem, the cursor prompt always starts at the same column. Here’s my RPS1 variable:

MAGENTA="%{"$'33[00;35m'"%}"

export RPS1="${MAGENTA}%~${NORM}"

Since version 2.6, you can tell Amarok to convert (transcode) every music track to MP3 when copying it to a given device.

There’s a bug, however which causes MP3 files converted from Ogg Vorbis to lose all metadata (artist, album, title etc). This is a showstopper for me.

This happens because Amarok needs to pass an option to ffmpeg to tell it to get the metadata from the first stream found in the Ogg file as opposed to the default of getting it from global metadata. Unfortunately as far as I can tell there’s no way to configure the ffmpeg command line used by Amarok. The solution then is to replace the ffmpeg binary in the path with a script that will do that, like this one:

#!/usr/bin/python
import os
import sys

AVCONV_FFMPEG = '/usr/bin/ffmpeg.distrib'
os.execv(AVCONV_FFMPEG, sys.argv + ['-map_metadata', '0:0,s0'])

In Debian or Ubuntu, you can divert the real ffmpeg binary and install the script above as /usr/bin/ffmpeg:

$ sudo dpkg-divert --add /usr/bin/ffmpeg
$ sudo cp /tmp/fake-ffmpeg.py /usr/bin/ffmpeg
$ sudo chmod +x /usr/bin/ffmpeg

There’s another bug where Amarok needlessly converts even MP3 files when copying them to the device.

Blog do Obstinado

Para a eventualidade de alguém ainda assinar este blog:

Criei um outro blog para relatar minhas experiências com o Obstinado, meu veleiro:

http://veleiroobstinado.wordpress.com/

Vou ver se tem algum esquema de notificar neste blog quando tem um post novo no outro.

Building a kernel for the Dreamplug still requires using a set of out-of-tree patches, since Dreamplug support is still being merged upstream. There are a few versions of these patches adapted for different kernel versions floating around. I have adapted them to apply to 3.4.x. You can get them from my github repository. Follow the README instructions to apply them and build the kernel. I included a kernel config file too.

The Dreamplug support patches that are being merged upstream use a device tree to tell the kernel about board-specific configuration that it needs to run on a given machine. The boot loader is supposed to hand that device tree binary to the kernel, or if your boot loader doesn’t support that (the u-boot version which comes pre-installed with the Dreamplug doesn’t) then you need to append a device tree binary to your kernel image after building it, or flash a new u-boot version.

To avoid all that fuss, the first patch in my series has a small hack that hard-codes the kernel to boot only on the Dreamplug, avoiding the need for a device tree. It also makes the kernel expect the GuruPlug machine id (which is what the factory Dreamplug u-boot advertises) instead of the Dreamplug machine id (which is what newer versions of u-boot advertise). It’s easy to drop this part of the patch if you updated your Dreamplug or made the factory u-boot use the new machine id (apparently you can do that, I didn’t try).

Follow

Get every new post delivered to your Inbox.

Join 357 other followers