Este sem sombra de dúvidas e um excelente documento desenvolvido e utilizado no desenvolvimento do Mozilla, vale a pena conferir!

Estive a convite de um grande amigo Berardo, atual dono da Especializa Cursos que foi uma das pessoas envolvidas na organização do evento, apresentei a palestra “Desenvolvendo aplicações no Linux” em seguida vários temas foram abordados. Inclusive sobre Pygames, apresentado por Larry Jr entre tantos outros temas bem legais!

Segundo o próprio Berardo, mais eventos virão em breve! quem sabe algo sobre o GNOME? Quem virá a Recife?

Slide: Desenvolvendo aplicações no Linux

Desde que estive no “BossaConference”[1] e assisti a palestra sobre o “UbuntuMobile”[2] que só fez aumentar mais ainda a curiosidade sobre o funcionamento de tais sistemas! na época li vários textos durante pesquisas sobre o assunto até que cheguei no projeto “Mamona” que abaixo segue uma breve descrição.

“O Mamona e uma plataforma Linux para sistemas embarcados ARM EABI (Que utilizem processadores ARM compostos de uma interface binária de aplicações para sistemas embarcados), que tem como seu principal objetivo oferecer uma alternativa completamente OpenSource tendo 100% de seu core composto de ferramentas de código aberto. Alem de ser baseado no debian, desenvolvido e mantido pelo INDT. Tem como principal idéia que seja utilizado em toda plataforma onde você tenha liberdade de instalar e testar os componentes. Se você achar algum celular não fechado (NEO é um exemplo), você pode colocar o mamona lá sem problemas!”

Resumindo, comecei a brincar e estudar um pouco sobre o plataforma por pura vontade e resolvi escrever um howto em português explicando e tentando ser um pouco mais detalhado do que os materiais que encontrei no wiki do projeto! Creio que irá ser útil para aqueles que não conhecem ou simplesmente tem interesse em conhecer sobre plataformas do gênero! ou até mesmo sendo um projeto bem interessante para aqueles que tem interesse em colaborar com a comunidade opensource!

• Versão 0.1 - 19/10/2008 - Download em PDF

[1] Impressões pessoais sobre o evento BossaConference
[2] UbuntuMobile

Comentários e criticas são bem vindos!

Em computação, mmap é uma chamada de sistema do Unix, em conformidade com o POSIX, que mapeia arquivos ou dispositivos na memória. É um método de E/S de arquivo mapeado em memória. Ela implementa naturalmente a paginação por demanda, pois os conteúdos iniciais dos arquivos não são inteiramente lidos do disco e não usam a memória RAM física completamente. A real leitura do disco é feita de maneira “preguiçosa”, após uma posição específica ter sido acessada.

Ou seja, podemos fazer muitas coisas utilizando a chamada mmap(), principalmente quando e preciso manipular arquivos de grande portes, e você não quer ter buffers auxiliares entre tantas outras possibilidades, que na grande maioria seguimos o seguinte fluxo.

open() -> read() || write() -> close()

Abaixo segue um código detalhando melhor meu comentário!

/**
* Autor: Jorge Pereira <jpereiran@gmail.com>
* Data: Thu Oct  9 22:47:47 BRT 2008
* Desc: Exemplo de um codigo para copia de arquivos.
* Arquivo: cp-no-mmap.c
*/
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>
#include <err.h>
#include <unistd.h>

#define IO_SIZE 4096

int
main(int argc, char *argv[])
{
int32_t fdr, fdw;
ssize_t reads;
/* Como de costume, temos um buffer temporario para auxiliar a copia */
char buf[IO_SIZE];

if(argc < 3)
{
printf("Usage: %s <origem> <destino>\n", argv[0]);
exit(EXIT_FAILURE);
}

/* Arquivo de origem */
fdr = open(argv[1], O_RDONLY);
if(fdr < 0)
{
err(1, "Falha ao abrir (%s)", argv[1]);
exit(EXIT_FAILURE);
}

/* Arquivo de destino */
fdw = open(argv[2], O_CREAT | O_RDWR, 0644);
if(fdw < 0)
{
err(1, "Falha ao abrir (%s)", argv[2]);
exit(EXIT_FAILURE);
}

/* Inicio da copia */
while ((reads = read(fdr, buf, sizeof(buf))) > 0)
{
if(write(fdw, buf, reads) < reads)
{
err(1, "Problemas com write()");
break;
}
}

/* fechando os descritores */
close(fdr);
close(fdw);

return EXIT_SUCCESS;
}

O Arquivo de exemplo se chama “Prison.Break.S04E07.HDTV.XviD-0TV.avi”, abaixo segue o tamanho dele para termos idéia em relação ao tempo de cópia!

[jpereira@jiraya blog]$ ls -lh Prison.Break.S04E07.HDTV.XviD-0TV.avi
-rw-r–r– 1 jpereiran jpereiran 351M 2008-10-09 22:06 Prison.Break.S04E07.HDTV.XviD-0TV.avi
[jpereira@jiraya blog]$ gcc -o cp-no-mmap cp-no-mmap.c
[jpereira@jiraya blog]$ time ./cp-no-mmap Prison.Break.S04E07.HDTV.XviD-0TV.avi Prison.Break.S04E07.HDTV.XviD-0TV.avi.copia
real 0m3.115s
user 0m0.008s
sys 0m2.496s
[jpereiran@jiraya blog]$

Agora veremos exemplo do mesmo código utilizando uma chamada mmap(), fazendo com que todos os bytes lidos pela chamada read() sejam salvos em uma região de memória previamente mapeada para que possamos efetuar operações de leitura, e escrita caso seja necessário! repare que não esta sendo utilizado um buffer auxiliar para salvar os dados do read(), como e feito de costume!

/**
* Autor: Jorge Pereira <jpereiran@gmail.com>
* Data: Thu Oct  9 22:47:47 BRT 2008
* Desc: Exemplo de um codigo para copia de arquivos utilizando mmap()
* Arquivo: cp-mmap.c
*/
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#include <string.h>
#include <err.h>
#include <unistd.h>

#include <sys/mman.h> /* mmap() */

#define IO_SIZE 4096

int
main(int argc, char *argv[])
{
int32_t fdr, fdw, fdm;
ssize_t reads;
/* repare que ao inves de utilizarmos um buffer auxilia, iremos ter um ponteiro apenas */
void *mem;

if(argc < 3)
{
printf("Usage: %s <origem> <destino>\n", argv[0]);
exit(EXIT_FAILURE);
}

/* Arquivo de origem */
fdr = open(argv[1], O_RDONLY);
if(fdr < 0)
{
err(1, "Falha ao abrir (%s)", argv[1]);
exit(EXIT_FAILURE);
}

/* Arquivo de destino */
fdw = open(argv[2], O_CREAT | O_RDWR, 0644);
if(fdw < 0)
{
err(1, "Falha ao abrir (%s)", argv[2]);
exit(EXIT_FAILURE);
}

/* tal device abaixo ira prover caracteres nulos '\0', estaremos apenas fazendo
* o mapeamento do dispositivo para uma regiao de memoria com tamanho definido
* neste caso por "IO_SIZE", com protecao R+W e sendo visivel apenas para o
* processo corrente, sem offsets referente a paginas de memoria.
*
* 1) Abrindo o device /dev/zero
* 2) Fazendo o mapeamento na linha 67
*
* OBS: Na duvida consulte a man do mmap(), e veja um exemplo utilizando mais
* detalhes conforme sua necessidade!
*/
if((fdm = open("/dev/zero", O_RDWR)) < 0)
{
err(1, "Falha ao abrir (%s)", argv[2]);
exit(EXIT_FAILURE);
}
mem = mmap(NULL, IO_SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE, fdm, 0);
close(fdm);

/**
* Inicio da copia, repare que estamos lendo do disco e "copiando" para regiao
* de  memoria mapeada, e escrevendo apartir do mesmo mapeamento! funcionando
* como uma variavel temporaria.
*/
while ((reads = read(fdr, mem, IO_SIZE)) > 0)
{
if(write(fdw, mem, reads) < reads)
{
err(1, "Problemas com write()");
break;
}
}

munmap(mem,  IO_SIZE);

/* fechando os descritores */
close(fdr);
close(fdw);

return EXIT_SUCCESS;
}

Abaixo vamos compilar e fazer o mesmo teste, copiando o mesmo arquivo!
[jpereira@jiraya blog]$ gcc -o cp-mmap cp-mmap.c
[jpereira@jiraya blog]$ time ./cp-mmap Prison.Break.S04E07.HDTV.XviD-0TV.avi Prison.Break.S04E07.HDTV.XviD-0TV.avi.copia
real 0m2.777s
user 0m0.020s
sys 0m2.056s
[jpereiran@jiraya blog]$

Conclusão

Repare que o ganho e imperceptível quando executamos tais rotinas em computadores x86 compostos de processadores de alta capacidade, sem falar dos discos rígidos de alta rotação! certo?
Porém quando você está trabalhando em um ambiente embarcado limitado de recursos, que quaisquer ganho de performance e velocidade e bem vindo! este foi meu caso em que precisava-se efetuar operações de I/O em um SD-CARD com um processador ARM um tanto quanto “humilde”, e tais dados além de ser copiados eram necessário gerar chaves MD5 entre outros detalhes com tal stream de dado, lembro que o ganho ficou por volta de 20% e 30% com o mapeamento utilizando mmap(). Dúvidas e comentários serão bem vindos

Referências

• man 2 open
• man 2 mmap
• http://www.gnu.org/software/libtool/manual/libc/Memory_002dmapped-I_002fO.html

Autor

Jorge Pereira

• dot.bash_alias
• dot.bash_functions
• dot.bash_logout
• dot.bashrc
• dot.gdbinit
• dot.vimrc
• dot.bitchxrc

Atc: Sugestões são bem vindas!

Saiu ontem do forno a RELEASE final da versão 2.6 do Python. Essa versão é compatível com as versões anteriores, contudo ela também abre caminho para migrar para a próxima versão, a 3.0.

Essa versão é uma ponte para a 3.0, já que ela contém as funcionalidades das versões anteriores e também algumas novidades da versão seguinte e, o uso dela é importante para que seja verificada a compatibilidade das versões anteriores com a 3.0.

Acesse a página oficial onde você poderá encontrar as novidades desta versão, fazer o download, entre outros…

Lembrando que a cada vez que por menor que seja meu contato com a linguagem, crio mais admiração e ansiedade para me envolver em algum projeto que utilize Python! Pois cada dia que passa a linguagem vem recebendo mais adeptos e incentivo de grandes corporações como a NOKIA que vem utilizando fortemente em suas plataformas moveis. minhas férias irei focar para brincar bastante com Python e conhecer mais afundo suas peculiaridades e com certeza irei criar um POST falando sobre tal experiência.

Eu sei que ainda faltam praticamente cinco meses para o evento, porém e bom ficar esperto e se programar para a terceira edição do BossaConference, para aqueles que não foram na edição passada ou simplesmente não conhecem! sugiro fazer uma busca e se informar, ou então da uma lida no POST que publiquei logo após minha chegada da conferência. Sem sombra de dúvidas um dos melhores eventos existentes na atualidade, melhor de tudo! aqui do lado em Porto de Galinhas, a 50 minutos de casa!

No site do evento ja foram confirmadas algumas das palestras, basta conferir aqui (estou tendo uma ligeira impressão que será dado mais enfase a assuntos envolvendo QT+KDE! obviamente era de se esperar após a compra da trolltech pela NOKIA)

Sendo muito interessante para fortalecer o networking profissional e quem sabe conseguir uma boa proposta de emprego a nível nacional ou internacional! Para aqueles que ainda não conhecem ou tem interesse de conhecer um pouco mais, segue um link muito legal do site “How Stuff Works?” (algo no estilo do programa “Como e possivel?” exibido pela Discovery Channel)

Fonte: http://informatica.hsw.uol.com.br/linkedin.htm

Alguns clássicos da cultura, história e literatura de C seria o famoso [2]. Assim como um outros mais genéricos [3][4] que inclui alguns clássicos do C++ e do OOP.

Porém o POST e específico sobre desenvolvimento Unix, a principio podemos começar por Filosofia Unix e lembrando que nos dias de hoje sempre estamos trabalhando com softwares e suas diversas licenças, sendo muito interessante e indispensável o conhecimento sobre as principais licenças[5] de softwares!

[1] The Ten Commandments for C Programmers
[2] Programming in C
[3] http://www.mycplus.com/Programming-Tutorials-Index.asp
[4] http://www.di-mgt.com.au/cprog.html
[5] http://blog.jorgepereira.com.br/2006/10/15/entendendo-o-softwarelivre/

Estarei participando do evento representando a comunidade GNOME-BR palestrando novamente sobre o tema “Contribuindo com o GNOME”, mais informações sobre o evento basta acessar o site do grupo Slack-PE.

Slides da minha apresentação está disponível em http://br.gnome.org/GNOMEBR/ESLUCAP

Link direto aqui.

Após quebrar a cabeça por algum tempo, encontrei uma solução no mínimo interessante:

Computadores lêem e escrevem na memória, e é isso. Uma instrução é uma leitura de bits da memória para o circuito lógico que altera o estado da máquina. Uma comparação é uma escrita em flags depois da entrada ter passado por um filtro de portas lógicas. Um salto é a escrita do endereço da próxima instrução no program counter. Quando uma função é chamada seus parâmetros e o endereço de retorno são escritos na pilha (uma área da memória). Para retornar, uma instrução lê o endereço da pilha e o coloca no program counter.

Sendo assim, confirmado que Von Neumann e Turing ainda não morreram, nada mais justo supor que um if é um salto automaticamente calculado através do resultado de uma comparação feita imediatamente antes. Isso traduzindo em código de alto nível:

#include <stdio.h>

void True()
{
printf("Verdadeiro\n");
}

void False()
{
printf("Falso\n");
}

typedef void (*Jump)();
Jump If[2] = { False, True };

int main(int argc, char* argv[])
{

If[2 > 3]();
If[2 > 3 || 1 > 2]();
If[3 > 2 &amp;&amp; 2 > 1]();

exit(0);
}

Eis um código que executa um salto condicional sem o uso do if que vem de fábrica. Na verdade, o if emulado acima constitui conceitualmente o que imagino que ocorra nas entranhas de um PC. Imagino, pois não fui a fundo o suficiente para vasculhar os documentos da Intel. Para mim, a mágica foi desvendada. O deslumbramento é que continua…

A nível de assembly, a comparação se baseia na diferença dos valores, se a mesma é zero ou se existe sobra de valor, se for zero, é porque os valores são iguais, se sobrou, diferentes, então para se definir qual é o maior, é analizado o sinal do resultado da subtração, este fica armazenado em um bit reservado para tal fim.

O Jump é executado após a subtração/comparação dos valores, assim, se o salto é executado, é alterado o endereço que o registrador que aponta para o código a carregar para o endereço informado no código executável/fonte.

Ex:

...
mov ax, 0x01 # Carga do valor 0x01 no registrador ax
mov bx, 0x02 # Carga do valor 0x02 no registrador bx
cmp ax, bx   # Cálculo da comparação executado
jz  0xAF05   # Jump Zero: Verificação do resultado do cálculo,
             # salta se os valores são iguais
             # resultado do cálculo deve ser zero para ocorrer o salto
             # ou

jnz 0xAF05   # Jump Not Zero: Verifica o resultado do cálculo e
             # salta se os valores não são iguais
             # resultado do cálculo diferente de zero
...

Após a execução, se ocorreu o salto, o registrador ponteiro de código do processador é direcionado para o endereço 0xAF05 e carrega o código executável a partir deste, que por sequência é executado, se o mesmo não ocorreu, a execução segue normalmente como se a instrução de jump não existisse.
fonte

Fontes: aqui e aqui!
OBS: Agora e aguardar para que a Discovery brasil passe em breve o programa!

“Em meu conto “A Sensação de Poder”, publicado em 1957, lancei
mão de computadores de bolso, cerca de dez anos antes de tais
computadores se tornarem realidade. Cheguei mesmo a
considerar a possibilidade de eles contribuírem para
que as pessoas acabassem perdendo a capacidade
de fazer operações aritméticas à maneira antiga.”
(Introdução - Isaac Asimov)

Abaixo segue link para o capitulo “A Sensação do Poder”
Fonte: http://sobral.tripod.com/poder/poder.html
Slide: http://www.scribd.com/doc/4091776/A-Sensacao-de-Poder-Isaac-Asimov

A real vida de um sysadmin!

Executando um drag-drop

Está abaixo e um clássico, para aqueles que não são nerd com certeza vão ficar sem entender…
a placa diz “Fim da Guerra“.

Está foto abaixo eu tirei em um mercado durante uma compra!!

Brincadeira, isto foi só uma piada durante desenvolvimento para este display!

/*
* Source: getch.c
* Autor: Jorge Pereira
* Data:  Tue Jul 29 09:35:42 BRT 2008
* Desc:  Implementacao da funcao getch() no Linux,
* podendo ser feito leitura de um unico byte por vez.
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <stdint.h>

#ifdef getch
#undef getch
#endif
typedef unsigned int keybd_t;

keybd_t getch (void)
{
struct termio old_tty;
struct termio new_tty;;
keybd_t	key = 0;;

if (ioctl(STDIN_FILENO, TCGETA, &amp;old_tty) < 0)
{
fprintf(stderr,"Port ioctl(TCGETA) it's failed, exiting...\n");
exit(EXIT_FAILURE);
}

new_tty = old_tty;
new_tty.c_lflag &amp;= ~(ICANON | ECHO);
new_tty.c_cc[4]  = 01;

if (ioctl(STDIN_FILENO, TCSETA, &amp;new_tty) < 0)
{
fprintf(stderr,"Port ioctl(TCSETA) it's failed, exiting...\n");
exit(EXIT_FAILURE);
}

if(read(STDIN_FILENO, &amp;key, sizeof(key)) < 0)
{
fprintf(stderr,"Problems in read()\n");
exit(EXIT_FAILURE);
}

if (ioctl(STDIN_FILENO, TCSETA, &amp;old_tty) < 0)
{
fprintf(stderr,"Port ioctl(TCSETA) it's failed, exiting...\n");
exit(EXIT_FAILURE);
}

return key;
}

#if defined(RUN_MAIN)
int
main (void)
{
keybd_t key;

printf ("(*) Teste para funcao getch(), pressione  para sair!\n");

while ((key = getch()) != 0x1b)
{
char ch = (key >= 'a' &amp;&amp; key <= 'z') ||
(key >= 'A' &amp;&amp; key <= 'Z') ||
(key >= '0' &amp;&amp; key <= '9') ? key: ' ';

printf (" -> key char(%c) hex(0x%08x) dec(%d)\n", ch, key, key);
}

printf ("(*) Saindo...\n");

return EXIT_SUCCESS;
}
#endif
/* getch.c - end */

Adicionei um bloco ifdef com um main(), para que seja possível executar e testar a função. Abaixo segue exemplo de compilação.

[jorge@jiraya codigos]$ gcc -W -Wall -DRUN_MAIN -o getch getch.c
[jorge@jiraya codigos]$ ./getch
(*) Teste para funcao getch(), pressione <ESC> para sair!
-> key char(a) hex(0×00000061) dec(97)
-> key char(b) hex(0×00000062) dec(98)
-> key char(c) hex(0×00000063) dec(99)
-> key char(d) hex(0×00000064) dec(100)
(*) Saindo…
[jorge@jiraya codigos]$

Caso queira adicionar o ao seu projeto, basta remover o bloco #ifdef e utilizar normalmente!

/*
* Source: statfs.c
* Autor: Jorge Pereira
* Data: Tue Jul 29 09:35:42 BRT 2008
* Desc: Exemplo acessando a quantidade de espaço de uma partição no Linux.
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <stdint.h>
#include <sys/vfs.h>

inline long _tok(long b, long bs)
{
return ( b * (long long) bs + 1024 / 2 ) / 1024;
}

int main(int argc, char *argv[])
{
struct statfs s;

if (argc < 2)
{
printf ("Usage: %s \n", argv[0]);
exit (1);
}

if (statfs(argv[1], &amp;s) != 0)
{
printf ("Problemas ao tentar abrir (%s), msg='%s'\n", argv[1], strerror(errno));
exit (1);
}

printf(" + SYSTEMA ARQUIVOS: (%s) \n", argv[1]);
printf(" +-- CAPACIDADE:     (%lu)\n", _tok(s.f_blocks, s.f_bsize));
printf(" +-- OCUPADO:        (%lu)\n", _tok(s.f_blocks-s.f_bfree, s.f_bsize));
printf(" +-- LIVRE:          (%lu)\n", _tok(s.f_bavail, s.f_bsize));

return EXIT_SUCCESS;
}

Basta compilar, e executar o exemplo conforme abaixo.

[jorge@jiraya c]$ gcc -o statfs statfs.c
[jorge@jiraya c]$ pwd
/home/codes/c
[jorge@jiraya c]$ ./statfs $PWD
+ SYSTEMA ARQUIVOS: (/home/codigos/c)
+– CAPACIDADE: (48444420)
+– OCUPADO: (13660960)
+– LIVRE: (32341984)
[jorge@jiraya c]$ df $PWD
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda3 48444420 13660960 32341984 30% /home
[jorge@jiraya c]$

Para aquelas pessoas que utilizam o Linux Ubuntu 8.04 com o GNOME em um computador um pouco modesto, e procuram deixar o mais enxuto possível para liberar recurso no sistema. Segue uma dica para desabilitar serviços desnecessários que as vezes são executados sem a sua real necessidade, obviamente que cada caso e um caso.

No meu caso, o meu Desktop não tem bluetooth, não utilizo esquema de indexação do track, nem esquemas de hibernar o meu Desktop. Desta forma para quer ter esses serviços rodando no meu GNOME? abaixo segue a lista dos serviços inicializados por padrão através do XDG.

[root@jiraya ~]# cd /etc/xdg/autostart/
[root@jiraya autostart]# ls -la
total 76
drwxr-xr-x 2 root root 4096 2008-07-06 20:30 .
drwxr-xr-x 6 root root 4096 2008-07-06 20:27 ..
-rw-r–r– 1 root root 2676 2008-03-28 07:07 bluetooth-applet.desktop
-rw-r–r– 1 root root 289 2008-04-21 12:23 evolution-alarm-notify.desktop
-rw-r–r– 1 root root 5040 2008-04-15 11:42 gnome-at-session.desktop
-rw-r–r– 1 root root 6079 2008-04-10 14:12 gnome-power-manager.desktop
-rw-r–r– 1 root root 7214 2008-04-15 05:39 gnome-volume-manager.desktop
-rw-r–r– 1 root root 293 2008-04-08 22:06 jockey-gtk.desktop
-rw-r–r– 1 root root 374 2008-04-18 17:27 nm-applet.desktop
-rw-r–r– 1 root root 219 2008-04-06 22:24 pulseaudio-module-xsmp.desktop
-rw-r–r– 1 root root 5002 2008-04-21 12:44 redhat-print-applet.desktop
-rw-r–r– 1 root root 2204 2008-04-02 17:11 tracker-applet.desktop
-rw-r–r– 1 root root 1791 2008-04-02 17:11 trackerd.desktop
-rw-r–r– 1 root root 236 2008-04-04 18:34 update-notifier.desktop
-rw-r–r– 1 root root 2783 2008-02-13 07:51 user-dirs-update-gtk.desktop
[root@jiraya autostart]#

No meu caso estarei desabilitando os serviços abaixos, movendo os arquivos para um diretório chamado “old” em um nivél acima.

[root@jiraya autostart]# mkdir ../old
[root@jiraya autostart]# mv bluetooth-applet.desktop evolution-alarm-notify.desktop gnome-power-manager.desktop tracker-applet.desktop trackerd.desktop ../old
[root@jiraya autostart]#

Feito isto, na próxima inicialização do seu GNOME não será executado tais serviços em background. liberando alguns kb de memória no seu Linux. Lembrando que este procedimento e interessante quando você que remover definitivivamente tais processos ao invés de recorrer o uso da ferramente gnome-session-properties, caso queira retomar os serviços basta movelos de “/etc/xdg/old” para o diretório “/etc/xdg/autostart”

• Download do SLIDE

“Imaginem um sistema geral de
auto-avaliação em que os alunos
não mais estudariam para as provas,
mas estudariam para ser úteis na vida”

Link do artigo aqui.

A pré-inscrição para o evento será feita pela internet e no local, mas a inscrição só será efetivada com a doação, no dia da abertura, de 1 kg de alimento não-perecível.

Assim como participei da primeira edição do evento, estarei novamente participando no evento representando a comunidade GNOME Brasil, com o tema “Colaborando com o GNOME”. tema este que irá abordar os primeiros passos e funcionamento colaborativo referente ao projeto GNOME, apresentação marcada para o dia 03/07/2008 às 15:00.

Acredito que todos que trabalham com desenvolvimento utilizando o Linux, já precisaram depurar algum trecho de código, e todos sabem que para quem não tem muito costume ele não e muito “amigável”. então segue abaixo link com tutorial e alguns arquivos de configuração contendo atalhos entre outras funções que com certeza irá ajudar muito na hora de depurar.

Abaixo segue alguns exemplos de configuração do GDB, lembrando que deverá ser salvo em ~/.gdbinit, caso queira ter como configuração padrão. do contrário basta utilizar o gdb passando o parâmetro -command,

Ex: gdb -command=gdbinit.txt

• http://www.kernsh.org/repo/gdbinit.txt
• http://tinderbox.x86.dev.gentoo.org/misc/dot.gdbinit
• http://dotfiles.org/~mkfs/.gdbinit

Excelentes tutoriais sobre GDB

• http://www.linuxtopia.org/online_books/redhat_linux_debugging_with_gdb/
• http://www.dirac.org/linux/gdb/
• http://www.arl.wustl.edu/~fredk/Courses/Docs/gdb.pdf
• http://www.arl.wustl.edu/~fredk/Courses/Docs/gdb_refcard.pdf
• http://www.arl.wustl.edu/~fredk/Courses/Docs/gdbint.pdf

A nova comédia do criador de “Two and a Half Men”, “THE BIG BANG THEORY”, mostra a história de dois melhores amigos inteligentíssimos que podem lhe dizer o que você quiser saber sobre física quântica — mas quando se trata de lidar com a vida diária na Terra, eles estão perdidos no universo.

Simon Helber, Jim Parsons, Johnny Galecki, Kaley Cuoco e Kunal Nayyar

Leonard (Johnny Galecki, “Hope & Faith”, “Roseanne”) e Sheldon (Jim Parsons, “Judging Amy”) são físicos brilhantes que entendem como o universo funciona. Mas nada dessa inteligência ajuda os dois a interagir com as pessoas, principalmente as mulheres. Tudo isso começa a mudar quando uma jovem bela e liberal chamada Penny (Kaley Cuoco, “Charmed”, “8 Simple Rules”) se muda para o apartamento ao lado.

Sheldon, o colega de quarto de Leonard, contenta-se a passar as noites jogando com seus amigos socialmente disfuncionais, os cientistas Wolowitz (Simon Helberg, “Studio 60 on the Sunset Strip”, “Joey”) e Koothrappali (Kunal Nayyar). Mas Leonard vê em Penny todo um novo universo de possibilidades… incluindo o amor.

A Criação do Mundo Segundo o Root - Parte 1 - O surgimento do sistema

Capitulo 1 - O Caos
no inicio havia apenas o caos. e não havia superblocks, e todos os inodes estavam espalhados pelos setores, e tudo era devastação. e havia apenas o root sobre a superfície do disco.

e o root resolveu e disse: isso nao pode continuar assim. e o root fez fdisk e eis que surgiram grandes divisões nos setores. e havia setores abaixo e acima dos dados. e aos abaixo dos dados, ele chamou de tabela de partições, e aos acima dos dados ele chamou de freeblocks.

e o root passou a formata-los . e os setores passaram a estar organizados, e haviam grandes superblocks nas águas de profundeza e inodes estavam sobre a superfície do disco. e o root passou a chama-los de filesystem. e o root viu q era bom e gravou a tabela de filesystems no fstab.

Capitulo 2 - O Inicio do sistema
e o root olhou para o filesystem e viu q faltava algo. e o root criou grandes diretórios e pequenos devices. e viu q era bom.

então o root viu o q havia criado, e tudo funcionava perfeitamente. mas faltava algo. e disse: passe a haver vida. e foram criados os processos do kernel e o init.

e eis q era bom, e o root editou o rc.d e instalou a glibc, e veio a haver luz. e o root passou a chamar o que havia criado de sistema.

Capitulo 3 - O surgimento do usuário
então o root passou a tomar dos bytes da memoria e dos dados do urandom, e dele formou o usuário. e ao usuário foi concedido o shell. e o usuário passou a viver. e o root lhe disse: venha a ter em sujeição os diretórios do disco e os bytes da memoria. de todos os recursos podeis utilizar, apenas não toqueis no su. pois deveras vos digo que, no dia em que tocares no su, farei um kill -9 em teu shell e apagar-te-ei do passwd.

e o usuário passou a estar no jardim do /home, e eis que tudo era bonito e perfeito dentro do /home. e o usuário vivia feliz em seu home directory.

Capitulo 4 - A criação da interface gráfica
e o usuário vivia feliz, mas sentia que lhe faltava algo. cada nod possui-a seu device no sistema, mas o usuário nao tinha ninguém para lhe fazer companhia.

e o root passou e extrair uma instrução do shell do usuário, e dela passou a formar a interface grafica. e chamou-a de X. então o root levou a X ate o usuário, e disse-lhes: sede fecundos e tornai-vos muitos, e populai o filesystem, e usai toda a memoria da placa de video.

e o usuario passou a viver com a interface gráfica, e eis que agora ele podia multiplicar seus terminais.

Capitulo 5 - A traição da interface gráfica
e a interface gráfica andava a passear pelo filesystem, quanto eis que vem em sua direção o mais vil de todos os arquivos criados pelo root: o HOWTO-SU. e o HOWTO incitava a curiosidade da interface gráfica. e lhe dizia: eh mesmo assim q o root disse, que não deveis usar o su? pois eis q o root sabe q, no dia que usares o su, positivamente vos tornareis igual a ele. e podereis decidir o q eh bom e o que eh mal, e podereis criar outros usuários, e nods, e formatar os discos. e o HOWTO lhe ensinou a usar o man.

e a interface gráfica foi ate o usuário, e lhe contou estas coisas, e lhe mostrou a manpage. e o usuário então digitou su no seu console, e eis que o # aparece em seu prompt. e ele passou a ver que estavam ambos limitados na memoria, e que tudo podia ser visto pelo /proc, e ambos ficaram envergonhados e se esconderam do utmp.

e o root passou a fazer um who e viu ambos se escondendo. e perguntou-lhes: por q te escondeis? acaso digitastes su em teu console?
e o usuário respondeu-lhe: foi essa interface que me destes. ela passou a me mostrar as manpages e os howtos, e por isso digitei.

e o root passou a ficar encolerizado e amaldiçoou a ambos, dizendo-lhes: vos sois amaldiçoados! deveras te digo que tua senha expirara, e sua entrada no passwd sera apagada. e tu, interface gráfica, estas amaldiçoada. nenhuma placa aceleradora funcionara bem em ti, e sempre terás pouca memoria de video. e eis q vos amaldiçôo a ambos, e eis que vira a haver o inimigo, e dividiras teu espaço em disco com o windows. e ele travara e te dará badblocks e lost inodes, e pelo resto de tua existência terá que conviver com a desgraça, ate q tua senha expire.

e tu, howto-su, maldito estas, e teus HOWTOs estarão sempre incompletos, e estarás rastejando para sempre no tldp.org. e ninguém leras mais tuas manpages, e todos os usuários irão perguntar no irc como faz.

e o root deixou-os, e corrompeu o filesystem e mudou as permissões do /home, para que o usuário não pudesse mais voltar ao jardim do HomeDirectory. e o usuário passou a ter que compilar seus programas, e escrever seus módulos.

e assim se deu.

A Criação do Mundo Segundo o Root - Parte 2 - A Aurora do Usuário

Capitulo 1 - Os primeiros novos usuários

eis que a vida fora do Jardim do HomeDirectory era dificil para o usuario e sua companheira, a interface grafica.

eles so poderiam sobreviver agora com seus proprios esforcos, e o root nao mais instalaria pacotes de binarios precompilados para eles.

e veio o tempo em que o usuario digitou su -c useradd e nasceu o primeiro descendente do usuario, e a interface grafica o chamou de caimd. e veio a haver tambem seu irmao, abelsh. e caimd se tornou um poderoso cacador de <defuncts> no /proc, mas abelsh era um pastor de devices.

e ambos prestavam homenagem ao root, mas apenas abelsh era reverente. caimd era arrogante, e o root nao se agradava de um daemon arrogante.

e eis que desperta a furia de caimd e um profundo odio por seu irmao, abelsh. e ele iludiu seu irmao a ir passear no campo, e fez um killall -9 abelsh.

mas o root observava a tudo, e puniu caimd. o root disse: maldito es, caimd, e toda a tua decendencia. e eu te digo q, por tua maldade, jamais teras controle do console de novo, e seras sempre executado com 1>/dev/null 2>1 &. e assim, caimd foi banido para os background process por todo o uptime do sistema.

Capitulo 2 - A maldade se espalha pelo filesystem

e todos os novos processos seguiam o caminho de caimd, e os badblocks imperavam no filesystem.

havia apenas alguns poucos processos bons em todo o sistema, e entre eles havia kmetusalem, o processo com maior uptime no sistema. mas ainda sim, havia muitos processos q rodavam com setuid 0 e eram muito mais poderosos que os outros, e corrompiam inodes e blocos de swap, e matavam outros processos, ate q o root viu todos os badblocks, e resolveu exteminar aquela geracao de childprocess maus.

Capitulo 3 - O Grande Diluvio do /dev/urandom

o root havia determinado exterminar todos os childprocess, e decidiu enviar um grande flood de numeros randomicos para a stdin de cada processo perverso, mas alguns dos processos mereciam ser salvos em fita DAT.

e ele executou o comando /usr/local/sbin/noe.sh, e noe.sh comecou a construir um grande /dev/mt0, que abrigaria os bons processos durante a colera do root.

e quando o /dev/mt0 ficou pronto, noe.sh foi recolher um casal de cada device, para que eles pudessem repovoar o filesystem quando a colera do root passasse.

ate que chegou o dia, e noe.sh e seus processos entraram no /dev/mt0, e com eles um casal de cada device. entao o root ejetou a fita e enviou o flood do /dev/urandom pra stdin de cada processo, ate que todos eles deram SegFault e morreram em terriveis core dumps.

Capitulo 4 - O renascimento dos usuários

depois do Grande Diluvio do /dev/urandom, o root restaurou o backup de noe.sh e os devices, e o filesystem foi novamente populado. desta vez, o /home estava montado com nosuid, para que os processos setuid 0 nao voltassem a estar no sistema.

e o tempo passou, e o passwd voltou a aumentar. e eles continuaram a se multiplicar, mas no entanto nao se espalhavam.

Capitulo 5 - A Torre de BashBel

e todos os usuarios se concentravam no lugar que ficou conhecido como a Torre de BashBel, pois todos os usuarios queriam estar no bash, e todos os outros shells que o root havia colocado no /bin estavam desprezados. e estes usuarios queria montar um bash tao poderoso que pudessem colocar setuid 0 nele.

e o root disse: isso nao pode continuar assim. e o root rodou um script no passwd, e fez usermod com -s randomico em todos os usuarios, e confundiu seus shells. e nenhum usuario entendia mais os shell scripts dos outros, e houve um grande caos e confusao na Torre de BashBel. e todos os usuarios que usavam o mesmo shell se juntaram em grupos, e cada grupo foi para um lado do / .

… to be continued …

A Criação do Mundo Segundo o Root - Parte 3 - O Surgimento da Nação Escolhida

Capitulo 1 - O povo escolhido

E o tempo passou, e todos os processos e usuarios se espalharam pela superficie do /, e todo o filesystem passou a ser populado.

No entanto, entre todos os PIDs, havia um que mostrava especial reverencia para com o root e tratava de modo sagrado todos os binarios setuid. Esse veio a ser Abraod. E o Root se agradava de Abraod, e decidiu fazer um pacto com ele. Assim disse o Root:

“Ha de chegar o dia em que um de teus ChildProcess ha de ser elevado acima de todos os PIDs, e seu poder sera grande. Todos os recursos do ulimit estarao com ele, e sera lhe concedida uma linha no /etc/sudo e todos os joelhos dos processos na memoria e dos usuarios no passwd se dobrarao perante ele.

Eh por meio dele que a perfeicao sera trazida de volta ao filesystem.

E quanto a ti, Abraod, doravante sera chamado Abroadcast. E tu te tornara pai de uma grande nacao de users, e havera um GID soh para ti e teus filhos.

Tambem lhe dou como presente estes inodes onde agora habitais, e ha de ser heranca para teus childprocess para todos sempre.”

E assim se deu. Abroadcast e sua esposa tiveram um filho, um decendente, e este passou a ser chamado IsACK.

E IsACK tambem passou a constituir familia, e tambem teve um descendente, que foi chamado de Jobcoh.

E o numero dos childprocess de Jobcoh atingiu os 12, e o Root se agradava de tais users.

E o Root apareceu em uma visao a Jobcoh fazendo um cat > /dev/tty1, e lhe disse:
“Grande teus filhos serao, e todos os processos serao beneficiados pro meio de teus fork()s. E doravante deveras ser conhecido como Shrael”

Capitulo 2 - Egitosoft

A familia de Shrael cresceu e se multiplicou, e passou a ter muitos netos, e o numeros dos seus era grande. No entanto, Shrael tinha especial predilecao por um de seus filhos: Jose.pl. E isso despertou o ciume e a ira de seus irmaos, e eles resolveram acabar ocm Jose.pl.

Certo dia, quando Jose.pl estava no campo pastoreando os bytes, seus irmaos vieram e o levaram a forca, e o prenderam num chroot.

Voltaram entao a seu pai e lhe disseram: Pai, Jose.pl sofreu um terrivel acidente. Ele estava pastoreando os bytes quando um terrivel urso veio e o atacou, e Jose.pl morreu com um Signal 11…

E Shrael chorou muito por seu filho, ainda preso no chroot… E alguns comerciantes vindos das fronteiras do sistema o acharam e levaram consigo para vender como escravo…

Com as reviravoltas do destino, Jose.pl acabou sendo vendido como escravo na terra de Egitosoft, para o poderoso farao TutanGates.

E Jose.pl mostrou-se homem sabio, e ajudou todos os processos do farao TutanGates a serem debugados. E TutanGates resolveu promover Jose.pl. Ele disse: Ae truta, tu manja bagarai, entaum tu vai tomah conta dos mano ae, valew?

E o Root abencoava Jose.pl como a nenhum outro. E o root avisou Jose.pl de uma grande desgraca por vir…

root@sistema:~# echo “vai haver uma grande abundancia de memoria durante os proximos 7 ciclos, seguido por uma completa escassez de memoria por outros 7 ciclos.” > /proc/jose/fd/1

E Jose.pl avisou ao Farao TutanGates, e este ordenou a Jose.pl que fizesse um grande estoque de memoria para enfrentar os tempos dificeis. E TutanGates continuou a vender seu sistema operacional meia-boca e a estocar memoria. Pois memoria era extremamente necessaria para comportar as telas azuis e dumps de memoria diarios de todo o sistema de EgitoSoft.

E os 7 anos de escassez de memoria vieram. E Shrael e sua familia, que tambem estavam em necessidade, vieram ate Egitosoft para adiquirir memoria. E Jose.pl reconheceu sua familia, e se alegrou com eles e trouxe-os ao egitosoft: mv /home/shrael /home/egitosoft/

E o sistema operacional zuado do Farao TutanGates continou a prosperar sob a supervisao de Jose.pl, e gracas a Jose.pl, sempre houve memoria para os dumps de memoria e telas azuis.

Capitulo 3 - As 10 pragas

E o povo de Shrael cresceu e se multiplicou na terra do EgitoSoft. E as geracoes passaram, e o povo de Shrael acabou se tornando escravo na terra de Egitosoft. E o Farao TutanBill, descendente do Farao TutanGates, escravizou todo o povo e fez com que vivessem em condicoes miseraveis de vida usando Ruindows ME.

Ate que um dia o Root nao pode mais permitir tamanha crueldade, e sucitou um libertados, Mouses. E Mouses mostrava-se sabio e temente ao Root. E o Root disse a Mouses: Va ate o Farao e diga-lhe que deve deixar meu povo partir.

Mas o Farao TutanBill mostrava-se intransigente, e exigia que todos usassem o Ruindows ME, e nao lhes permitiu deixar EgitoSoft. E o Farao fez ainda pior, instalou Internet Exploder 6 e Office 2000 em todos os Ruindows ME e obrigou o povo de Shrael a usa-los.

Ate que o Root nao pode mais suportar tamanha crueldade e disse a Mouses: Va ate o Farao e diga-lhe que, se nao deixar meu povo sair, vai te treta.

Mesmo assim, o Farao TutanBill nao quis colaborar. E o Root comecou a enviar pragas contra EgitoSoft…

E aquela terra foi assolada por um Ping Flood, e seus sistemas travaram. Depois, o root enviou a praga do Nuke na porta 139, e todos os sistemas novamente travaram. Seguiu-se a praga dos Virus de Macro, os ActiveX infectados, e os ataques Unicode, os ataques MSADC, execucao remota no Internet Exploder, as horriveis correntes de email, o worm CodeRed e a mais terrivel de todas as pragas: o Ecachange.

Apos todas estas pragas, o Farao TutanBill decidiu deixar o povo sair de EgitoSoft. E todo o povo de Shrael saiu feliz e contente de EgitoSoft, e o Root mostrava estar com eles.

No entanto, depois de alguns dias de liberdade, o Farao TutanBill voltou atras, e resolveu traze-los de volta a escravidao. E o Farao usou todo seu poderoso exercito de Advogados guerreiros pra processar e destruir todo o povo de Shrael, alem de processos pelo uso de patentes.

Mas o root mostrava-se estar com eles, e os guiou ate um grande mar, o Mar do OpenSource Vermelho.

E o root instruiu Mouses, e Mouses abriu o Mar do OpenSource Vermelho e todo o povo de Shrael passou sao e salvo pelo Mar… Mas quando os Advogados Guerreiros do Farao vieram em seu encalco atravez do Mar do OpenSource Vermelho, o root soltou as aguas, e todo o exercito do Farao TutanBill foi destruido, afogado pelo OpenSource.

E Mouses passou a guiar todo aquele povo de volta ao Sistema Prometido, a Terra que o Root havia jurado dar a eles numa promessa feita a Abroadcast. E todo o povo estava feliz por volta as Terras de POSIX. E todo o povo e os pingaiada gritavam: BOOOOOOOOOA ROOT! WINDOWS SUX!

Fonte do texto

Conforme publiquei no penúltimo post sobre o evento ESLPE 2008, so tenho a dizer que a organização está de parabéns! pois o evento sem sombra de dúvidas foi muito bom, a infra-estrutura foi muito boa, grandes nomes estavam patrocinando ou apoiando o evento como a revista nacional Linux Magazine , SERPRO, IBM, INDT, RedHat entre outras renomeadas empresas. e sem contar com a vasta quantidade de palestrantes e hack-labs ocorrendo em paralelo, ou seja! com certeza tinha algum tema de seu interesse ocorrendo durante cada hora do evento. compareci no evento representando a comunidade GNOME-BR falando sobre o tema “Contribuindo com o GNOME”, e também falando sobre “Desenvolvendo aplicações no Linux”. abaixo segue algumas fotos e links para os materiais utilizados na apresentação.

• Slide - Contribuindo com o GNOME
• Slide - Desenvolvendo aplicações no Linux

root@jaspion ~ # history | awk ‘{ a[$2]++ } END{ for(i in a) { print a[i] ” ” i} }’ | sort -rn | head
69 ls
48 cat
34 cd
29 rm
21 ps
21 gcc
21 apt-get
19 vi
16 apt-search
14 sudo
root@jaspion ~ #

O Evento será realizado nos dias 23, 24 e 25 de abril de 2008, na Faculdade Maurício de Nassau e será gratuito. A organização estima que cerca de 800 pessoas participem do Encontro e ajudem a difundir o Software Livre (SL) nos âmbitos acadêmicos, empresariais, governamentais e sociais.

O objetivo geral do Encontro de Software Livre de Pernambuco (ESLPE) é propagar as práticas de desenvolvimento colaborativo e de garantia ao acesso à produção do conhecimento no estado de Pernambuco, além de difundir a cultura do Software Livre e a sua importância cial.

O acesso às palestras do II ESLPE será aberto ao público inscrito. Já os interessados em participar dos minicursos oferecidos por algumas empresas deverão pagar uma taxa de R$ 20,00 que dará direito ao participante receber uma camiseta do evento, desde que comprovada a sua presença em 100% das aulas. clique aqui para mais informações sobre o evento.

Foto tirada em frente ao banner do evento!

Seguindo o cronograma do evento, abaixo seguem breve descrições de minha autoria sobre as palestras que assisti assim como links com mais informações sobre os assuntos e seus respectivos projetos abordados.

Assunto: Cairo - Everything Untested is Broken
Palestrante: Chris Wilson
Comentários: Excelente palestra descrevendo o funcionamento e aplicabilidade da famosa “Cairo Graphic”, biblioteca utilizada por inúmeros aplicativos, principalmente aqueles desenvolvidos para o GNOME. foi descrito sua aplicabilidade em conjunto com ferramentas de testes, sendo possível gerar gráficos em 2d de uma forma simples e objetiva. um único ponto negativo que encontrei na palestra foi o fato do palestrante “Chris Wilson” falar muito rápido e assim eu não pude acompanhar muito bem a palestra devido a meu inglês não ser muito bom. mais informações sobre a Cairo no site http://cairographics.org/