A briga com o novo notebook continua. Estou aproveitando as férias para terminar de configurar.
No Debian, só consegui reconhecer a placa wireless depois que atualizei o kernel. Tentei recompilar o kernel padrão do Debian mas lí em algum lugar que somente as versões mais novas trabalham bem com minha wireless.
Com isso, a placa de vídeo também funcionou com o driver intel, e consegui configurar o gráfico em 1366x768, que é o correto. Mas ao abrir algum vídeo, a parte gráfica trava.
No Gentoo eu consegui configurar corretamente tanto a wireless como o gráfico. Tentei abrir um vídeo e não travou.
Pelo que eu percebi até agora o gráfico está funcionando com o driver da intel. Ainda não tentei fazer a troca para o driver da ati. Mas como não costumo usar nada 3D não está fazendo diferença por enquanto.
O som desse notebook não se compara ao do meu notebook antigo. De todos os notebooks que eu já ví até agora, o som do Toshiba é insuperável (é Toshiba mesmo, e não Semp Toshiba. O Toshiba que eu tinha era importado). Isso se não levar em consideração esses notebooks mais caros feitos para jogo, pois eles costumam ter uma placa de som e uns auto-falantes e melhor qualidade. Mas o Toshiba tem um som excelente em qualquer modelo.
Bom, depois que eu tentar fazer o gráfico funcionar com driver 3D eu posto minha experiência.
terça-feira, 5 de julho de 2011
sábado, 18 de junho de 2011
Notebook com placa de vídeo 3D
Depois de muito tempo, eis que consigo escrever novamente em meu blog. Ultimamente estava sem assunto, pois estava trabalhando na documentação de um projeto. E também fiz um curso sobre Storage e switch para storage.
Também ministrei um curso de Linux Básico pelo CISL - Comite de Implantação de Software Livre do Governo Federal. Irei escrever depois sobre isso.
Vamos então para o assunto principal do post.
Resolvi comprar um novo notebook, visto que o meu já tinha alguns anos. Depois de muito pesquisar escolhi um Dell Vostro 3450.
Novo processador Core i5 2410. Revestimento em alumínio, 1 pente de 4GB de memória (o que é muito bom, pois se eu quiser expandir só preciso comprar outro de 4GB). Muito bom mesmo.
O grande problema: ele vem com placa 3D. Mas hoje em dia, muitos notebooks que tem placa 3D, na verdade tem 2 placas de vídeo. Um chamada de "discrete" (3D) e outra chamada de "integrated". São as placas híbridas.
Com isso, a placa 3D só é ativada quando há necessidade de um maior desempenho de vídeo. Isso economiza energia, pois as placas 3D consomem bem mais que as placas que não tem aceleração gráfica.
Em alguns notebooks é possível deixar somente uma delas ativadas através do BIOS. Com isso, o Linux só reconhece a placa ativada, e não há problema nenhum para configurar. Mas o meu notebook não tem essa opção, ou seja, por enquanto só consegui carregar o modo gráfico usando driver vesa, com resolução 1024x768.
Mas durante algumas horas de pesquisas, encontrei alguns tutorias de como fazer para configurar corretamente. Assim que eu conseguir eu posto a experiência.
Por enquanto preciso fazer a wireless funcionar, porque ela também não funcionou automaticamente. Vou dar uma prioridade maior a isso, pois tem algumas pessoas interessadas em comprar meu notebook antigo.
Também ministrei um curso de Linux Básico pelo CISL - Comite de Implantação de Software Livre do Governo Federal. Irei escrever depois sobre isso.
Vamos então para o assunto principal do post.
Resolvi comprar um novo notebook, visto que o meu já tinha alguns anos. Depois de muito pesquisar escolhi um Dell Vostro 3450.
Novo processador Core i5 2410. Revestimento em alumínio, 1 pente de 4GB de memória (o que é muito bom, pois se eu quiser expandir só preciso comprar outro de 4GB). Muito bom mesmo.
O grande problema: ele vem com placa 3D. Mas hoje em dia, muitos notebooks que tem placa 3D, na verdade tem 2 placas de vídeo. Um chamada de "discrete" (3D) e outra chamada de "integrated". São as placas híbridas.
Com isso, a placa 3D só é ativada quando há necessidade de um maior desempenho de vídeo. Isso economiza energia, pois as placas 3D consomem bem mais que as placas que não tem aceleração gráfica.
Em alguns notebooks é possível deixar somente uma delas ativadas através do BIOS. Com isso, o Linux só reconhece a placa ativada, e não há problema nenhum para configurar. Mas o meu notebook não tem essa opção, ou seja, por enquanto só consegui carregar o modo gráfico usando driver vesa, com resolução 1024x768.
Mas durante algumas horas de pesquisas, encontrei alguns tutorias de como fazer para configurar corretamente. Assim que eu conseguir eu posto a experiência.
Por enquanto preciso fazer a wireless funcionar, porque ela também não funcionou automaticamente. Vou dar uma prioridade maior a isso, pois tem algumas pessoas interessadas em comprar meu notebook antigo.
sexta-feira, 13 de maio de 2011
Dicas de atualização do seu Gentoo Linux
Assim como a instalação, a atualização do Gentoo é um processo demorado. Isso deve-se ao fato de todos os pacotes serem compilados localmente.
A atualização é feita com o comando
# emerge --update world --deep
Depois de finalizar a atualização é importante executar dois comandos,
# revdep-rebuild
# etc-update
O segundo verifica se arquivos de configuração dos pacotes que foram instalados tiveram alguma alguma modificação em relação a versão anterior. Ele não verifica se o usuário alterou o arquivo, ou seja, caso alguma customização tenha sido feita, ela será retirada, e o arquivo instalado será o padrão do novo pacote.
O comando sempre lista os arquivos que serão alterados, e é possível ver as diferenças para as versões anteriores. Pode-se por exemplo, fazer um backup dos arquivos, deixar o comando sobrescrevê-los, e depois reconfigurá-los conforme a necessidade de cada um.
Já o revdep-rebuild é muito importante, pois ele verifica se, a versão antiga dos pacotes tem alguma dependência. Se tiver, esses pacotes dependentes serão recompilados.
Após a atualização é importante verificar as mensagens geradas (caso não consiga ver no terminal por algum motivo, é possível vê-las no arquivo /var/log/portage/elog/summary.log.
Alguns pacotes podem retornar uma mensagem que contenha uma informação como por exemplo:
Old versions of installed libraries were detected on your system.
In order to avoid breaking packages that depend on these old libs,
the libraries are not being removed. You need to run revdep-rebuild
in order to remove these old dependencies. If you do not have this
helper program, simply emerge the 'gentoolkit' package.
# revdep-rebuild --library '/usr/lib64/liblzma.so.0'
Once you've finished running revdep-rebuild, it should be safe to
delete the old libraries. Here is a copy & paste for the lazy:
# rm '/usr/lib64/liblzma.so.0'
É muito interessante executar esses comandos, pois isso irá recompilar as dependências somente desse pacote, e depois pode-se remover a versão antiga da biblioteca, que não será mais utilizada.
Ao realizar esses comandos deve-se ter paciência para que eles terminem, pois em alguns casos pode-se ter alguma conseqüência grave.
Outro dia, após atualizar meu Gentoo, fui executar o revdep-rebuild --library para uma das bibliotecas instaladas. Alguns dos pacotes dependentes iriam demorar muito para compilar, por isso resolvi interromper o processo antes de iniciar a compilação.
Como resultado, meu servidor X não carregou mais corretamente. Vendo seu log, verifiquei que o problema era uma biblioteca que havia sido corrompida. Tentei recompilar a biblioteca, mas algumas outras bibliotecas necessárias para o gcc também haviam sido corrompidas.
Para resolver o problema tive que baixar o stage e copiar algumas bibliotecas para substituir as que foram corrompidas. Com isso foi possível recompilar os pacotes.
Ainda não terminei a recuperação. Provavelmente ainda precisarei recompilar vários pacotes para resolver todos os problemas.
Com isso fica a dica: nunca interrompa o processo de atualização do Gentoo. Tanto para atualização/instalação de pacotes como para o revdep-rebuild sempre utilize o parâmetro -v para ver o que será executado. Execute os comandos somente quando tiver certeza que poderá esperar a finalização deles.
Aproveitando a oportunidade: atualize seu Gentoo periodicamente, caso contrário haverá muitas atualização a serem feitas de uma vez.
A atualização é feita com o comando
# emerge --update world --deep
Depois de finalizar a atualização é importante executar dois comandos,
# revdep-rebuild
# etc-update
O segundo verifica se arquivos de configuração dos pacotes que foram instalados tiveram alguma alguma modificação em relação a versão anterior. Ele não verifica se o usuário alterou o arquivo, ou seja, caso alguma customização tenha sido feita, ela será retirada, e o arquivo instalado será o padrão do novo pacote.
O comando sempre lista os arquivos que serão alterados, e é possível ver as diferenças para as versões anteriores. Pode-se por exemplo, fazer um backup dos arquivos, deixar o comando sobrescrevê-los, e depois reconfigurá-los conforme a necessidade de cada um.
Já o revdep-rebuild é muito importante, pois ele verifica se, a versão antiga dos pacotes tem alguma dependência. Se tiver, esses pacotes dependentes serão recompilados.
Após a atualização é importante verificar as mensagens geradas (caso não consiga ver no terminal por algum motivo, é possível vê-las no arquivo /var/log/portage/elog/summary.log.
Alguns pacotes podem retornar uma mensagem que contenha uma informação como por exemplo:
Old versions of installed libraries were detected on your system.
In order to avoid breaking packages that depend on these old libs,
the libraries are not being removed. You need to run revdep-rebuild
in order to remove these old dependencies. If you do not have this
helper program, simply emerge the 'gentoolkit' package.
# revdep-rebuild --library '/usr/lib64/liblzma.so.0'
Once you've finished running revdep-rebuild, it should be safe to
delete the old libraries. Here is a copy & paste for the lazy:
# rm '/usr/lib64/liblzma.so.0'
É muito interessante executar esses comandos, pois isso irá recompilar as dependências somente desse pacote, e depois pode-se remover a versão antiga da biblioteca, que não será mais utilizada.
Ao realizar esses comandos deve-se ter paciência para que eles terminem, pois em alguns casos pode-se ter alguma conseqüência grave.
Outro dia, após atualizar meu Gentoo, fui executar o revdep-rebuild --library para uma das bibliotecas instaladas. Alguns dos pacotes dependentes iriam demorar muito para compilar, por isso resolvi interromper o processo antes de iniciar a compilação.
Como resultado, meu servidor X não carregou mais corretamente. Vendo seu log, verifiquei que o problema era uma biblioteca que havia sido corrompida. Tentei recompilar a biblioteca, mas algumas outras bibliotecas necessárias para o gcc também haviam sido corrompidas.
Para resolver o problema tive que baixar o stage e copiar algumas bibliotecas para substituir as que foram corrompidas. Com isso foi possível recompilar os pacotes.
Ainda não terminei a recuperação. Provavelmente ainda precisarei recompilar vários pacotes para resolver todos os problemas.
Com isso fica a dica: nunca interrompa o processo de atualização do Gentoo. Tanto para atualização/instalação de pacotes como para o revdep-rebuild sempre utilize o parâmetro -v para ver o que será executado. Execute os comandos somente quando tiver certeza que poderá esperar a finalização deles.
Aproveitando a oportunidade: atualize seu Gentoo periodicamente, caso contrário haverá muitas atualização a serem feitas de uma vez.
quinta-feira, 28 de abril de 2011
Samba com LDAP sem smbldap-tools
Quando se pensa em uma integração de Samba com LDAP normalmente utiliza-se o pacote smbldap-tools. Mas é possível fazer com que o Samba acesse a base LDAP diretamente.
Fiz um artigo com os procedimentos necessários. Não me apeguei muito a configuração do Samba e do OpenLDAP, pois há diversos tutorias sobre eles na Internet.
O artigo está disponível no Megaupload.
Segundo o man do Samba, o processo de login no domínio fica bem mais rápido configurando-se dessa forma.
Fiz um artigo com os procedimentos necessários. Não me apeguei muito a configuração do Samba e do OpenLDAP, pois há diversos tutorias sobre eles na Internet.
O artigo está disponível no Megaupload.
Segundo o man do Samba, o processo de login no domínio fica bem mais rápido configurando-se dessa forma.
terça-feira, 19 de abril de 2011
Banco de Dados
Para facilitar algumas buscas em um arquivo CSV em meu trabalho, resolvi carregar esse arquivo em um banco de dados relacional MySQL. Obs.: Como trabalho em uma área que mexe com diretórios LDAP, eu deveria ter carregado em uma base LDAP, mas algumas buscas são realmente mais fáceis com SQL.
Eu precisava saber os tipos de funcionários existentes na empresa. Fiz então a seguinte busca:
SELECT codigoCaracteristica, quadro
FROM `Empregados`
GROUP BY codigoCaracteristica
E ela trouxe os dados como deveria.
Pensando um pouco, imaginei que isso poderia ser feito de outras maneiras, e pensei também que, isso poderia ter um desempenho diferente.
Levando-se em conta que o campo codigoCaracteristica é um campo indexado, e o campo quadro não é. O banco tem 11.411 registros. O banco tinha acabado de ser criado, portanto não havia cache.
Realizei 3 buscas diferentes, com os seguintes tempos de resposta:
SELECT DISTINCT codigoCaracteristica, quadro
FROM `Empregados`
Mostrando registros 0 - 3 (4 total, Consulta levou 0.0194 segundos)
SELECT codigoCaracteristica, quadro
FROM `Empregados`
GROUP BY codigoCaracteristica
Mostrando registros 0 - 3 (4 total, Consulta levou 0.0141 segundos)
SELECT codigoCaracteristica, quadro
FROM `Empregados`
GROUP BY quadro
Mostrando registros 0 - 3 (4 total, Consulta levou 0.0335 segundos)
A diferença entre fazer um group by em um campo indexado foi significativa. Mas não considerei relevante a diferença entre fazer um distinct e um group by em um campo indexado.
Acredito que buscas utilizando distinct e group by, mas utilizando mais de uma tabela, deva trazer diferenças mais significativas, mas não fiz testes para verificar.
Eu precisava saber os tipos de funcionários existentes na empresa. Fiz então a seguinte busca:
SELECT codigoCaracteristica, quadro
FROM `Empregados`
GROUP BY codigoCaracteristica
E ela trouxe os dados como deveria.
Pensando um pouco, imaginei que isso poderia ser feito de outras maneiras, e pensei também que, isso poderia ter um desempenho diferente.
Levando-se em conta que o campo codigoCaracteristica é um campo indexado, e o campo quadro não é. O banco tem 11.411 registros. O banco tinha acabado de ser criado, portanto não havia cache.
Realizei 3 buscas diferentes, com os seguintes tempos de resposta:
SELECT DISTINCT codigoCaracteristica, quadro
FROM `Empregados`
Mostrando registros 0 - 3 (4 total, Consulta levou 0.0194 segundos)
SELECT codigoCaracteristica, quadro
FROM `Empregados`
GROUP BY codigoCaracteristica
Mostrando registros 0 - 3 (4 total, Consulta levou 0.0141 segundos)
SELECT codigoCaracteristica, quadro
FROM `Empregados`
GROUP BY quadro
Mostrando registros 0 - 3 (4 total, Consulta levou 0.0335 segundos)
A diferença entre fazer um group by em um campo indexado foi significativa. Mas não considerei relevante a diferença entre fazer um distinct e um group by em um campo indexado.
Acredito que buscas utilizando distinct e group by, mas utilizando mais de uma tabela, deva trazer diferenças mais significativas, mas não fiz testes para verificar.
domingo, 3 de abril de 2011
Configuração de teclado: udev + UPower
Final de semana fui atualizar meu Gentoo, e uma das atualizações disponíveis era a do gnome. Finalizada a instalação percebo que existem algumas diferenças no funcionamento do teclado e do mouse.
Antes, o teclado e mouse funcionavam com o HAL, e agora utilza udev. Devido a isso, meu teclado, que é padrão Americano Internacional, não estava mais acentuando.
Após muita pesquisa, verifiquei que o HAL é considerado obsoleto, e que no lugar dele, usa-se o udev e UPower.
A dificuldade foi que, com o HAL, era possível desativar a inserção automática de dispositivos e configurá-los através do arquivo /etc/X11/xorg.conf. Com o udev/UPower, isso não foi possível. Mas quando o udev carregava a configuração do teclado, ele definia o layout como us, e não como us_intl.
Era possível verificar tudo isso através do log do servidor X (/var/log/Xorg.0.log) que exibia uma mensagem como a abaixo:
Verificado isso, comecei nova pesquisa, e nesta wiki do ArchLinux, a solução foi encontrada. Para configurar o teclado agora, é preciso editar o arquivo /etc/X11/xorg.d/10-evdev.conf, que tem uma sintaxe muito parecida com o xorg.conf.
No meu caso, precisei criar o diretório xorg.conf.d dentro de /etc/X11, e copiar um arquivo base de /usr/share/X11/xorg.conf.d.
Feito isso somente inseri algumas linhas na área definida para o teclado, ficando como o abaixo:
Option "XkbOptions" "grp:menu_toggle,grp_led:scroll"
EndSection
Section "InputClass"
Identifier "evdev touchpad catchall"
MatchIsTouchpad "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection
Section "InputClass"
Identifier "evdev tablet catchall"
MatchIsTablet "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection
Section "InputClass"
Identifier "evdev touchscreen catchall"
MatchIsTouchscreen "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection
As linhas adicionadas são as em negrito.
Aproveitei a oportunidade e pesquisei também como fazer para definir mais de um layout de teclado para o caso de eu querer ligar um teclado abnt2. Como pode-se ver, a linha Option "XkbLayout" "us_intl,br" define dois layouts, o us_intl e o br. A linha seguinte Option "XkbOptions" "grp:menu_toggle,grp_led:scroll" diz que, se pressionar o botão de "menu de contexto" do teclado, haverá a troca de layout, e o led de scroll lock irá indicar esta troca.
A tecla de "menu de contexto" foi uma escolha pessoal, visto que é uma tecla que eu não utilizava para nada. Outras opções podem ser vistas nesta wiki do Gentoo.
Antes, o teclado e mouse funcionavam com o HAL, e agora utilza udev. Devido a isso, meu teclado, que é padrão Americano Internacional, não estava mais acentuando.
Após muita pesquisa, verifiquei que o HAL é considerado obsoleto, e que no lugar dele, usa-se o udev e UPower.
A dificuldade foi que, com o HAL, era possível desativar a inserção automática de dispositivos e configurá-los através do arquivo /etc/X11/xorg.conf. Com o udev/UPower, isso não foi possível. Mas quando o udev carregava a configuração do teclado, ele definia o layout como us, e não como us_intl.
Era possível verificar tudo isso através do log do servidor X (/var/log/Xorg.0.log) que exibia uma mensagem como a abaixo:
[ 3955.251] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD)
[ 3955.251] (**) Option "xkb_rules" "evdev"
[ 3955.251] (**) Option "xkb_model" "evdev"
[ 3955.251] (**) Option "xkb_layout" "us"
[ 3955.251] (**) Option "xkb_rules" "evdev"
[ 3955.251] (**) Option "xkb_model" "evdev"
[ 3955.251] (**) Option "xkb_layout" "us"
Verificado isso, comecei nova pesquisa, e nesta wiki do ArchLinux, a solução foi encontrada. Para configurar o teclado agora, é preciso editar o arquivo /etc/X11/xorg.d/10-evdev.conf, que tem uma sintaxe muito parecida com o xorg.conf.
No meu caso, precisei criar o diretório xorg.conf.d dentro de /etc/X11, e copiar um arquivo base de /usr/share/X11/xorg.conf.d.
Feito isso somente inseri algumas linhas na área definida para o teclado, ficando como o abaixo:
Section "InputClass"
Identifier "evdev pointer catchall"
MatchIsPointer "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection
Section "InputClass"
Identifier "evdev keyboard catchall"
MatchIsKeyboard "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
Option "XkbLayout" "us_intl,br"Identifier "evdev pointer catchall"
MatchIsPointer "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection
Section "InputClass"
Identifier "evdev keyboard catchall"
MatchIsKeyboard "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
Option "XkbOptions" "grp:menu_toggle,grp_led:scroll"
EndSection
Section "InputClass"
Identifier "evdev touchpad catchall"
MatchIsTouchpad "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection
Section "InputClass"
Identifier "evdev tablet catchall"
MatchIsTablet "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection
Section "InputClass"
Identifier "evdev touchscreen catchall"
MatchIsTouchscreen "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
EndSection
As linhas adicionadas são as em negrito.
Aproveitei a oportunidade e pesquisei também como fazer para definir mais de um layout de teclado para o caso de eu querer ligar um teclado abnt2. Como pode-se ver, a linha Option "XkbLayout" "us_intl,br" define dois layouts, o us_intl e o br. A linha seguinte Option "XkbOptions" "grp:menu_toggle,grp_led:scroll" diz que, se pressionar o botão de "menu de contexto" do teclado, haverá a troca de layout, e o led de scroll lock irá indicar esta troca.
A tecla de "menu de contexto" foi uma escolha pessoal, visto que é uma tecla que eu não utilizava para nada. Outras opções podem ser vistas nesta wiki do Gentoo.
sexta-feira, 1 de abril de 2011
Palestra: Processo de desenvolvimento do Kernel e do QEMU
Hoje tive a oportunidade de assistir uma palestra em minha empresa sobre o Processo de desenvolvimento do Kernel Linux e do Qemu.
O palestrante, Glauber Costa, é engenheiro e mestre em computação pela Unicamp. É envolvido com o processo de desenvolvimento do kernel Linux desde 2004. Está envolvido no projeto Qemu a cerca de 3 anos. Já trabalho no Linux Technology center da IBM e atualmente trabalha no grupo de virtualização da Red Hat.
O objetivo da palestra foi mostrar como funciona o processo de desenvolvimento de dois softwares livres.
Segundo Glauber, o processo de desenvolvimento do kernel funciona como uma árvore de confiança. O mantenedor do kernel não revisa todo o código. Ele confia no mantenedor de cada ramo da árvore de desenvolvimento, que por sua vez, confia nos sub-ramos, se eles existirem. Cada mantenedor fica responsável por garantir que todo o código de sua árvore é confiável, seja revisando, seja confiando em outra pessoa que revisaram.
Isso é necessário porque não é possível alguém revisar todas as alterações, pois atualmente o kernel tem mais de 14 milhões de linhas.
O Qemu é utilizado para virtualização, e começou como um projeto individual de Fabrice Bellard.
Por ser um projeto individual, as colaborações muitas vezes demoravam para serem inseridas a ele. Isso tornava a evolução lenta.
Com o advento da virtualização, alguns desenvolvedores viram que era interessante investir no Qemu, mesmo que fosse necessário um pouco de tempo para melhorar o processo de desenvolvimento colaborativo.
Glauber concluiu que, mesmo o Qemu tendo um processo de desenvolvimento complicado, ele era sim, um software bem sucedido, pois atendia as expectativas do desenvolvedor.
Ou seja, mesmo tendo processos de desenvolvimento diferentes, tanto o kernel Linux como Qemu, são softwares livres bem sucedidos.
Glauber destacou que, num processo colaborativo como o do kernel, muitas vezes tem-se conflitos, mas isso nem sempre é algo ruim. Normalmente isso ajuda na evolução do software. Alguns desses conflitos podem gerar forks, e esses forks podem acabar ou seguir por muito tempo.
O fato de ter Red Hat e Suse, que são concorrentes, trabalhando no kernel não é ruim para ambas, muito pelo contrário, pois os custos de melhoria do kernel acaba sendo dividido entre várias empresas.
Glauber também enfatizou que a Red Hat figura atualmente como a maior contribuidora, responsável pelo desenvolvimento de aproximadamente 12% do kernel. Ou seja, se ela parar de contribuir, causará algum impacto, mas não impossibilitará a continuidade do projeto.
O palestrante, Glauber Costa, é engenheiro e mestre em computação pela Unicamp. É envolvido com o processo de desenvolvimento do kernel Linux desde 2004. Está envolvido no projeto Qemu a cerca de 3 anos. Já trabalho no Linux Technology center da IBM e atualmente trabalha no grupo de virtualização da Red Hat.
O objetivo da palestra foi mostrar como funciona o processo de desenvolvimento de dois softwares livres.
Segundo Glauber, o processo de desenvolvimento do kernel funciona como uma árvore de confiança. O mantenedor do kernel não revisa todo o código. Ele confia no mantenedor de cada ramo da árvore de desenvolvimento, que por sua vez, confia nos sub-ramos, se eles existirem. Cada mantenedor fica responsável por garantir que todo o código de sua árvore é confiável, seja revisando, seja confiando em outra pessoa que revisaram.
Isso é necessário porque não é possível alguém revisar todas as alterações, pois atualmente o kernel tem mais de 14 milhões de linhas.
O Qemu é utilizado para virtualização, e começou como um projeto individual de Fabrice Bellard.
Por ser um projeto individual, as colaborações muitas vezes demoravam para serem inseridas a ele. Isso tornava a evolução lenta.
Com o advento da virtualização, alguns desenvolvedores viram que era interessante investir no Qemu, mesmo que fosse necessário um pouco de tempo para melhorar o processo de desenvolvimento colaborativo.
Glauber concluiu que, mesmo o Qemu tendo um processo de desenvolvimento complicado, ele era sim, um software bem sucedido, pois atendia as expectativas do desenvolvedor.
Ou seja, mesmo tendo processos de desenvolvimento diferentes, tanto o kernel Linux como Qemu, são softwares livres bem sucedidos.
Glauber destacou que, num processo colaborativo como o do kernel, muitas vezes tem-se conflitos, mas isso nem sempre é algo ruim. Normalmente isso ajuda na evolução do software. Alguns desses conflitos podem gerar forks, e esses forks podem acabar ou seguir por muito tempo.
O fato de ter Red Hat e Suse, que são concorrentes, trabalhando no kernel não é ruim para ambas, muito pelo contrário, pois os custos de melhoria do kernel acaba sendo dividido entre várias empresas.
Glauber também enfatizou que a Red Hat figura atualmente como a maior contribuidora, responsável pelo desenvolvimento de aproximadamente 12% do kernel. Ou seja, se ela parar de contribuir, causará algum impacto, mas não impossibilitará a continuidade do projeto.
Assinar:
Postagens (Atom)