Robin Hood: The most famous archer

"I advice you, people: Use Archlinux! Pacman rules!"

Finalmente o PekWM como WM do Gnome!!

Estava esperando por isso há muito tempo e uma mudança realizada na git version ontem pelo Pekdon (principal coder do pekwm e seu idealizador) hoje permite.

Primeiro, no gnome, vá em sistema>Editor de configurações

Neste (Gconf), vá em /gnome/session/required_components/windowmanager

Clique 2 vezes e mude o valor de metacity (o que provavelmente estará lá) para pekwm. Feche o Gconf.

Depois vá em sistema>preferências>aplicativos de sessão>programas iniciais>adicione

Adicionar programa inicial:

Nome: PekWM
Comando: pekwm --replace
Comentário: pekwm

Reinie o gnome e tenha o Pekwm como seu WM!

Screenshot:

Notem as tabs na barra de título. Não é o metacity, mas o pekwm! =D

Novo Xorg+hal+startx=us international keyboard no eeepc finalmente funcionando!!

Essa é pra todos os que tem um eeepc e querem usar um WM como o pekwm somente chamando do xinitrc... e estão tentando há meses, por causa da confusão criada pelo hal (já dizia o 2001: Uma Odisséia no Espaço que não seria uma boa) + o novo X, que por causa da integração com o primeiro, agora reconhece tudo numa boa. Bem, não foi bem assim no meu caso... segue a solução! ;)

Em um terminal qualquer da vida:

1) $cp /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi /etc/hal/fdi/policy/10-keymap.fdi

2) $nano/vi/gedit/kwrite/ou qualquer outro /etc/hal/fdi/policy/10-keymap.fdi (como root, claro)

Leia atentamente o arquivo abaixo e altere no seu, com o seguinte conteúdo:

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.keymap">
<append key="info.callouts.add" type="strlist">hal-setup-keymap</append>
</match>

<match key="info.capabilities" contains="input.keys">
<merge key="input.xkb.rules" type="string">base</merge>

<!-- If we're using Linux, we use evdev by default (falling back to
keyboard otherwise). -->
<merge key="input.xkb.model" type="string">keyboard</merge>
<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"
string="Linux">
<merge key="input.xkb.model" type="string">asus_laptop</merge>
</match>

<merge key="input.xkb.layout" type="string">us</merge>
<merge key="input.xkb.variant" type="string">alt-intl</merge>
</match>
</device>
</deviceinfo>

3) Promova as alterações destacadas aqui em negrito no seu arquivo e salve.

4) Teoricamente reinicie o hal e o X ou dê um reboot a la windows (supondo, é claro , que haja um script pra ativar o hal no boot).

5) Abra um terminal no X e clique em ¨´¨ seguido de ¨a¨ e em ¨´¨ seguido de ¨e¨.

6) Sorria e pense: ¨ainda bem que o pibarnas existe e passou uns 4 meses pra fazer isso!¨

That`s all folks!! {=D

Windows x Linux

"Olá, Madame, Sr. Presidente... Senhorita, como vai?"















"Mal ele sabe que vc usa Archlinux, hein filha?!?"


"Humpf!"

Vc precisa de um client IRC online? Mibbit.com!!

É isso mesmo! Se vc está no trabalho, ou em trânsito, e longe de seu cliente IRC, mas dispõe de um browser, visite http://mibbit.com/ e pronto! Coloque um de seus servidores favoritos, user e senha e já pode contatar seus amigos ou esclarecer dúvidas!

Grande abraço a todos!

PI

Problema de conjuntos resolvido com ferramentas do Linux

Essa experiência foi suscitada a partir de uma questão prática: Um dia enviei um tarball do meu diretório de wallpapers pro meu amigo Sryche (Cainã Costa). Depois, acrescentei outras wallpapers no mesmo diretório. O problema é que o Sryche novamente me pediu wallpapers, mas somente os que ele não tinha. Como fazer? Ele me mostrou o caminho então e aqui eu reproduzo a experiência, primeiro em tese e depois explico na prática:

Primeiro criei 1 diretório de testes com dois dirs dentro dele:

$ mkdir -p testes/waka{1,2}

Dentro de ~/testes/waka1 criei 3 arquivos e os copiei para waka2 (eu poderia simplesmente copiar o waka1 para waka2 com outro nome, mas prefiro fazer dessa forma por conta da lógica do problema):

$ cd testes/waka1/

$ touch teste-{a,b,c} && cp teste-* ../waka2

Portanto, dentro de waka1 e waka2, o conteúdo agora era idêntico: 3 arquivos, teste-a, teste-b e teste-c.

Depois, dentro de waka1, eu criei mais 3 arquivos:

$ touch teste-{d,e,f}

Agora, o conteúdo dos dirs diferiam, pois o waka1 tinha 6 elementos e o waka2, apenas 3.

Depois, dei um $ ls ../waka2 > arg ainda dentro do dir waka1, criando um arquivo com os elementos de waka2, que me servirá mais tarde de argumento.

E finalmente no dir waka1 eu removi apenas os arquivos que eu não tinha em waka2:

$ xargs --arg-file=arg rm ;

O ls waka1 demonstrará o resultado da experiência. Só restaram, obviamente, os arquivos que não existem em waka2.

Foi assim que resolvemos o problema do envio dos wallpapers.

Na ocorrência real, eu não sabia quantos e quais os wallpapers tinham sido adicionados ao diretório (eu poderia ver pela data com ls, e com sed, grep e outros comandos, tentar resolver o problema, mas tb não sabia quando os tinha enviado). Assim, o Sryche deu um ls no diretório que ele recebeu lá e me enviou a saída por pastebin (o problema todo é que eram muitos wallpapers e na época o Sryche tinha conexão discada). Eu copiei a minha pasta de diretórios e usando a saída do Sryche como argumento, removi todos os wallpapers que ele já tinha. O que restou, obviamente, eram os wallpapers que ele não tinha, então empacotei o diretório e disponibilizei ao Sryche com um link em um HD virtual.

A resolução do problema coube ao Sryche e estou publicando-a porque a achei simples e genial (disse a ele à época) e acho que a lógica envolvida pode ajudar mais pessoas em problemas similares.

Se vc tem uma outra maneira de resolver esse interessante problema só com comandos do linux, por favor, deixe-nos conhecê-la, através de um comentário!

Grande abraço a todos!

Openbox: trays e bmpanel

Todos sabem que sou amante dos gerentes de janelas minimalistas, que ocupam pouco espaço na memória e que uso muito o openbox. Na verdade, existe uma funcionalidade que o openbox não provê nativamente e em virtude dessa deficiência, é necessário usar um programa externo. Tal funcionalidade é o que se chama de systray, que é geralmente uma pequena barra onde ficam alocados os ícones de certas aplicações, como o parcellite, o beep-media-player-x, o quodlibet (geralmente players têm essa característica). Então, você pode interagir com o programa mesmo ali de seu ícone na systray, no caso de players, com comandos como "play", "pause", stop, etc.

Contudo, como disse anteriormente, o fato é que no openbox, essa funcionalidade não é provida, de modo que eu tive problemas com aplicações como o player beep-media-player-x (minha aplicação favorita para ouvir rádio na web), porque em sua configuração padrão, quando você clica no "x" da janela, a aplicação não é morta, mas sim minimizada para o ícone do systray. E o que fazer quando não há systray? O programa ficava rodando, ocupando memória, sem o conhecimento do usuário.

Para contornar esse problema, muitos usuários do openbox, inclusive eu, optavam por instalar painéis, no meu caso, o pypanel (vide meus antigos screenshots). O pypanel então me garantia uma barra de aplicações, uma systray e um relógio.

Entretanto, como um pente de memória do meu computador estava com defeito e teve de ser retirado, com apenas 512 Mb de memória, virei um maníaco por programas que ocupam pouca memória. Um dia, movido por essa mania, resolvi tirar o "pid" do pypanel com o comando "ps" e submetê-lo ao juiz "pmap". Quase desmaiei! O pypanel estava gastando tanta memória quanto o próprio openbox!! Então comecei a buscar alternativas.

O primeiro programa que utilizei para isso foi o docker, um programa que aproveita a funcionalidade "dock" do openbox e serve de systray. Muito simples, sem muitas opções, mas ocupa pouco espaço na memória. Depois, usei o stalonetray, um programinha leve, com bastante opções que podem ser arranjadas em ~/.stalonetrayrc. Adorei esse programa, mas um pequeno bug no ícone do programa "parcellite", fez-me procurar outro. O ícone, apesar de haver configuração em stalonetrayrc para o tamanho do ícone, insistia em ficar com um tamanho bem maior, o que não ocorria em outros trays. Isso poderia ser contornado com a opção "withdrawn", porém eu ganhava com isso um contorno horrivel no meu pequeno systray. Por recomendação do Borromini do canal #openbox, usei o trayer, que apesar de não ter um arquivo de configuração como o stalonetray, tem muitas opções, que podem ser iniciadas ou através de um terminal, ou dos clássicos ~/.xinitrc e ~/autostart.sh. Todavia, o programa ocupava tanta memória que também resolvi desistir.

Continuava a usar o stalonetray com o dclock (porque sem painel não tinha relógio) quando a even, companheira de distro, e uma das atuais líderes do projeto Arch-br, sugeriu-me usar um painel, isto mesmo, um painel muito leve chamado bmpanel. Quando fui usá--lo e o submeti a testes de memória, qual foi a minha surpresa! O bmpanel, com barra de aplicações, relógio personalizável, mostrador de áreas de trabalho e systray, usava menos memória que o dclock + stalonetray. Quando vi isso, nem titubeei, e além de passar a usar constantemente o bmpanel, recomendei-o, tal como a even fez comigo, a outros amigos que usam openbox e outros *boxes.

Aqui fica a minha experiência e sugestão, além de screenshots para ilustrar o que disse. Grande abraço a todos!

Ss1: Openbox + pypanel = consumo do openbox

Ss2: Openbox + pypanel = consumo do pypanel

Ss3: Openbox + docker

Ss4: Openbox + dclock + stalonetray (no withdrawn mode)

Ss5: Openbox + dclock + stalonetray (withdrawn mode)

Ss6: Openbox + dclock + trayer = consumo do trayer

Ss7: Openbox + bmpanel = consumo do bmpanel