Lançado Resulinux 2.9

O Resulinux, distribuição brasileira baseada no Debian, chegou à sua versão 2.9 final, de apelido "Chesed", lançada ontem. Entre as novidades, está a adição de opções de escolha dentre quatro temas visuais de desktop; KDE 3.5.9 com Compiz; novos painéis de configuração e instalação de pacotes; melhorias na segurança; kernel 2.6.23.13 focado em melhor desempenho; correções de bugs no Kaffeine e scripts de instalação de drivers proprietáriso de vídeo da ATI e Nvidia; novo script para configuração de redes wireless; várias correções e melhorias em desempenho.

Fonte:

http://distrowatch.com/?newsid=04926

Lista de alterações, anúncio oficial e download:

http://partedmagic.com/wiki/PartedMagic.php?n=PartedMagic.ChangeLog

Link direto: http://neacm.fe.up.pt/pub/resulinux/resulinux2.9chesed.iso (696 MB, MD5)

Utilizando o PcManFm

Muito usuários, principalmente de Linux, estão extremamente habituados com ambientes desktop como o KDE ou GNOME, onde tudo é fácil e acessível de se fazer. Contudo, há aqueles usuários que desejam manter em seu computador um gerenciador de janelas mais leve e simples como o Fluxbox, seja por curiosidade, gosto ou necessidade, e com isso normalmente não utilizam um gerenciador de arquivos por não encontrarem uma solução eficiente e adequada ao ambiente.

Tendo este assunto em mente, Phillipe Smith postou no site Viva o Linux um artigo chamado "Utilizando o PcManFm". Leia a descrição:

"Para aqueles que estão acostumados com desktops completos como Gnome e KDE, que fornecem gerenciadores de arquivos amplamente modernos e configuráveis, segue uma alternativa super leve para gerenciadores de arquivos, mas não só para gerenciadores de arquivos, como também para WMs como Fluxbox e Openbox."

E um trecho (introdução):

"O PcManFm de cara é em parecido com o Thunar, mas é claro que ainda não tem muitas funções dele. No entanto, o PcManFm possui alguns recursos bem interessantes.

Por exemplo, muita gente que vai utilizar um desktop ou WM (Gerenciador de Janelas) diferente pela primeira vez, como o FluxBox ou Openbox, dão de cara com um desktop limpo, sem ícones, sem papel de parede, sem barra de tarefas, sem nada, contendo apenas um simples menu ao clicar com o botão direito do mouse, o que faz com que muitos nem queiram saber como se utiliza eles.

Mas a implantação de ícones e papéis de parede podem ser facilmente implantadas com o PcManFm. Isso mesmo, o PcManFM possui um recurso onde você pode colocar ícones e papéis de parede em seu desktop, fazendo com que o mesmo fique muito mais bonito. "

O artigo está dividido entre as seguinte seções:

Veja o artigo completo em:

http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=8284

RoboBraille converte textos para Braille e voz via e-mail

Acesso total de forma fácil e veloz à todo o conteúdo da Web, como notícias, livros, artigos e outro tipos de páginas é um sonho de muitos deficientes visuais e auditivos, que muitas vezes são excluídos do processo de evolução da tecnologia. Tentando contornar essa situação, foi criado um serviço gratuito que traduz um texto em Braille e em gravações de áudio; tudo isso a partir de um e-mail.

Com este assunto, foi publicada a notícia "RoboBraille converte textos para Braille e voz via e-mail", no site "Inovação Tecnológica", prolonga este assunto:

"Desenvolvido por pesquisadores europeus, o RoboBraille oferece uma solução única para o problema da conversão de texto em Braille e áudio, sem a necessidade de que os usuários operem programas complicados.

"Nós começamos a trabalhar nesse campo há 20 anos, desenvolvendo programas para traduzir texto em Braille, mas nós descobrimos que os usuários achavam os programas difíceis de usar. Nós então procuramos uma solução mais simples," explica Lars Ballieu Christensen, coordenador do projeto."

Veja a notícia original em:

http://www.inovacaotecnologica.com.br

Asus Eee PC de 10 polegadas é oficialmente anunciado

No mês passado haviam muitos rumores sobre o lançamento de uma versão de 10 polegadas do Asus Eee PC, e finalmente o "não tão ultra-portátil" laptop foi anunciado oficialmente na Computex, semana passada. A versão maior do Eee PC terá como processador o Intel Atom, e é também esperado que a versão de 8.9 polegadas, o Eee PC 901, chegue finalmente aos consumidores semana que vem (no exterior, é claro).

Possivelmente tendo como modelo "1000" ou "1001", a versão de 10 polegadas terá o lançamento final similar ou à frente de seu concorrente direto, o MSI Wind, que usará também chip Atom, com sistema operacional Linux e custo estimado de 400 dólares. O novo Eee PC chegará ao Reino Unido em novembro, sendo provável que as vendas nos EUA se iniciem também neste período. Preços não foram revelados, mas espera-se que seja mais caro que o 901, que custará em torno de 550 dólares.

Fonte:

http://www.electronista.com/articles/08/05/30/new.eee.pc.debut.official/

Rastreamento distribuído de bugs

Distributed bug tracking

Autor original: Jonathan Corbet

Publicado originalmente no: http://lwn.net/

Tradução: Roberto Bechtlufft

Não é exagero dizer que os sistemas de gerenciamento distribuído de código fonte estão dominando o mundo. Ainda há muitos sistemas centralizados em uso, mas hoje são raros os projetos que preferem adotar um sistema de gerenciamento de código (ou SCM) centralizado. Os desenvolvedores já se acostumaram à idéia de carregar todo o histórico do projeto em seus laptops, fazer alterações e executar o merge quando tiverem tempo.

Porém, ainda que qualquer desenvolvedor possa consolidar alterações em um projeto mesmo preso com um cinto de segurança a uma lata voadora atravessando o Pacífico, geralmente esse desenvolvedor não pode trabalhar simultaneamente com o banco de dados de bugs do projeto. Consolidar alterações e atualizar as informações de bugs são atividades que costumam andar de mãos dadas, mas os sistemas de rastreamento de bugs ainda estão fortemente fincados no modelo centralizado. Nosso desenvolvedor que vive cruzando os oceanos pode consolidar dezenas de alterações, mas só vai poder atualizar as informações de bug quando o avião pousar e ele conseguir uma conexão com a internet.

Há vários projetos por aí tentando mudar essa situação, trabalhando na criação de sistemas de rastreamento distribuído de bugs. O desenvolvimento desses programas ainda está engatinhando, mas o potencial deles - e suas limitações - é evidente.

Um dos projetos mais adiantados é o Bugs Everywhere, que mudou de casa há pouco tempo, e agora tem Chris Ball como mantenedor. O Bugs Everywhere, como os outros sistemas que investiguei, tenta trabalhar com um sistema de gerenciamento distribuído de código fonte embutido para gerenciar a criação e o rastreamento de entradas de bugs. O Bugs Everywhere em particular cria um novo diretório (chamado de .be) no topo da estrutura de diretórios do projeto. Os bugs são armazenados como diretórios cheios de arquivos de textos, e esses bugs são gerenciados pelo SCM embutido.

As vantagens dessa abordagem são óbvias. O banco de dados de bugs agora pode ser baixado junto com o código do projeto. Ele pode ser ramificado com o código; se uma ramificação em particular contém uma correção de um bug, pode conter também a entrada atualizada sobre o bug. Isso, por sua vez, garante que a informação atualizada sobre o bug chegará ao upstream ao mesmo tempo que a correção em si. Hoje em dia os projetos costumam ter muitos repositórios e ramificações, cada um contendo um conjunto diferente de bugs e correções; distribuir o banco de dados de bugs nesses repositórios só pode ajudar a manter o código e as informações de bugs consistentes em todo lugar.

Mas também há algumas desvantagens nesse esquema, pelo menos em sua forma atual. As mudanças nas informações de bugs não se tornam reais até serem consolidadas no SCM. Quando um bug é corrigido, consolidar a correção e a informação de bug atualizada faz sentido, mas quando só se quer acrescentar alguns comentários sobre um bug, a necessidade de fazer a consolidação acaba sendo trabalhosa. O fato de que, ao menos no git, é preciso adicionar explicitamente quaisquer arquivos novos criados pelo rastreador de bugs (e eles têm nomes como 12968ab9-5344-4f08-9985-ef31153e504f/comments/97f56c43-4cf2-4569-9ef4-3e8f2d9eb1fe/body) não ajuda muito.

Além disso, rastrear bugs dessa forma cria dois grupos independentes de metadados - a informação de bug em si e o que quer que o desenvolvedor tenha acrescentado ao consolidar as alterações. Ainda não existe uma maneira de unir esses dois cursos de metadados. E ainda há a questão do merge. O Bugs Everywhere parece ter pensado nesse problema; a maioria das alterações envolve a criação de arquivos novos e de nomes (aparentemente) aleatórios para que não haja conflitos ao realizar o merge. Mesmo assim, não demorou para que eu provasse que alterar a gravidade de um bug em duas ramificações diferentes e realizar um merge criava um conflito que só podia ser resolvido pela edição manual dos arquivos de rastreamento de bugs. Esses arquivos são de texto puro, mas são bem menos confortáveis de se trabalhar do que você pensa.

Tudo isso pode fazer parecer que o rastreamento distribuído de bugs dá mais trabalho aos desenvolvedores, o que certamente não o levará à dominação mundial. Parece que o que precisamos é de uma combinação de ferramentas mais avançadas e de uma maior integração com o SCM embutido. O Bugs Everywhere, ao tentar trabalhar com qualquer SCM, corre o risco de não ser fácil de usar com nenhum deles.

Um projeto que busca maior integração é o ticgit que, como você já deve ter imaginado, é baseado no git. O ticgit tem uma abordagem diferente: nenhum arquivo é adicionado à árvore de fontes do projeto, pelo menos não diretamente. Ao invés disso, o ticgit adiciona uma nova ramificação ao SCM e armazena lá a informação sobre os bugs. Isso permite que o banco de dados de bugs viaje com os fontes (desde que se tenha o cuidado de dar push e pull na ramificação do ticgit!) ao mesmo tempo em que mantém os arquivos associados fora do caminho. As operações do ticgit trabalham no diretório de banco de dados de objetos do git, por isso não é necessária uma operação separada de consolidação. Por outro lado, essa abordagem abre mão de oferecer uma visualização separada do banco de dados de bugs de cada ramificação; a conexão entre as correções de bug e as mudanças no bug acabou enfraquecida. Isso é algo que pode ser consertado, e parece (pelos comentários nos fontes) que lidar com ramificações está nos planos do autor.

O ticgit tem um claro potencial, mas uma integração ainda maior pode valer à pena. Não seria ótimo se um único comando git commit também associasse por tabela a entrada de bug associada no banco de dados? Desenvolvedores interessados poderiam visualizar uma consolidação que supostamente corrige um bug sem que ninguém precise copiar IDs de consolidação para lá e para cá. Reverter uma consolidação de correção de bug poderia automaticamente reabri-lo. E por aí vai. A longo prazo, é difícil imaginar como uma rastreamento distribuído de bugs verdadeiramente integrado pode ser implementado de forma independente do sistema de gerenciamento de código fonte.

Há outros projetos em desenvolvimento nessa área:

• O scmbug é um projeto relativamente avançado que pretende "resolver os problemas de integração de uma vez por todas." Mas ele não é um autêntico sistema distribuído de rastreamento de bugs; ele depende de hooks no SCM que conversa com um servidor central. Apesar disso, o projeto pensou bastante em como os rastreadores de bugs e os sistemas de gerenciamento de código devem trabalhar juntos.
• O disTract é um rastreador distribuído de bugs que trabalha com uma interface web. Para isso, ele usa um monte de código JavaScript específico do Firefox para executar programas locais, escritos em Haskell, que manipulam entradas de bugs em um repositório Monotone. Confesso que não juntei todas as peças para que esta ferramenta funcionasse.
• O DITrack é um conjunto de scripts em Python que manipula informações de bugs em um repositório Subversion. Seu objetivo é implementar o modelo distribuído, e um dia trabalhar com qualquer backend, mas o uso que faz do Subversion limita o quão distribuído ele pode ser por enquanto.
• O ditz é um conjunto de scripts em Ruby que manipula informações de bugs em um sistema de gerenciamento de código fonte; ele não faz distinção entre SCMs.

Como se pode ver, não é pouco o trabalho nesta área, embora poucos destes projetos tenham alcançado um alto nível de usabilidade. Só o scmbug tem sido usado em grande escala até agora. Alguns desses projetos tem o potencial de mudar a forma como se desenvolve software, mas antes é preciso que vários problemas de integração e interface do usuário sejam resolvidos.

E ainda há um problema que não foi abordado por ninguém. Um rastreador de bugs funciona como uma espécie de lista de tarefas para os desenvolvedores, mas ele é mais do que isso. Ele é também um ponto focal de discussão entre desenvolvedores e usuários. A maioria dos usuários não ficará muito impressionada com uma mensagem do tipo "configure um repositório git e execute estes comandos para postar ou comentar um bug." Em outras palavras, há valor em um sistema centralizado com uma interface web que torna o sistema de rastreamento de problemas acessível a uma ampla comunidade. Qualquer sistema distribuído de rastreamento que não facilite essa discussão vai acabar fracassando. Criar um rastreamento distribuído que também seja bom para os usuários pode ser o maior dos desafios.

Créditos a Jonathan Corbet - http://lwn.net/

Tradução por Roberto Bechtlufft <robertobech at gmail.com>

Republicação do livro Hardware, Manual Completo

Entre 1998 e 2002 publiquei uma série de livros dentro da área de hardware, que acabaram sendo agrupados em um e-book que passei a disponibilizar gratuitamente através do Guia do Hardware, como uma forma de propagar o conhecimento e dar minha parcela de contribuição nos estudos de quem precisava se especializar na área. Na época, livros técnicos em Português ainda eram raros, de forma que o Hardware Manual Completo atingiu um volume muito grande de leitores e acabou se tornando uma obra de referência.

Como a última atualização do livro ocorreu em 2002, ele está brutalmente desatualizado, mas ainda pode ser útil se você tem curiosidade em conhecer melhor os componentes de hardware usados em micros antigos, ou se quer melhorar seus conhecimentos gerais. Se você está procurando um livro de hardware atualizado, veja o livro Hardware, o Guia Definitivo.

O livro está sendo republicado aos poucos, conforme o tempo disponível, por isso nem todos os capítulos estão disponíveis. Ele estará completo em breve. Se você começar a ler o livro seqüencialmente a partir do início, provavelmente os capítulos serão publicados mais rápido do que você conseguirá ler :)

Clique para ler: Hardware Manual Completo

ABNT protesta contra adoção do OOXML

O Brasil entrou com um apelo formal contra o formato Office Open XML (OOXML) na ISO, como padrão internacional para documentos digitais. O pedido foi enviado pela ABNT (Associação Brasileira de Normas Técnicas), representante do país nessa questão.

O OOXML passou por várias modificações e recebeu diversas críticas durante o processo de aprovação, mas mesmo assim acabou sendo aceito como padrão pela ISO. O Brasil votou "não" ao formato.

A insatisfação da ABNT e de outros grupos visa beneficiar o ODF (OpenDocument Format), formato adotado por comunidades de software livre, e já dado como um padrão anterior pela ISO. Países como Índia e África do Sul também enviaram mensagens de contestação à adoção do OOXML.

A ABNT questiona o curto intervalo de tempo em que o OOXML foi aprovado, apontando possíveis falhas técnicas no processo. Uma votação às pressas não permitiria que todos os países analisassem com calma o formato de arquivos proposto.

Mesmo assim, pelo menos de imediato o peso do OOXML como padrão deve ser reduzido agora. A Microsoft anunciou há alguns dias que não pretende tornar o Office 2007 ainda totalmente compatível com o OOXML, seu próprio formato. Pelo contrário, ela disponibilizará no SP2 do Office 2007 uma integração nativa ao formato ODF, que é adotado por aplicações abertas como o OpenOffice (veja esta notícia aqui). O suporte ao OOXML no Office 2007, se vier, deverá chegar mais tarde somente.

Referência:

http://www.bbc.co.uk/portuguese/reporterbbc/story/2008/05/080530_microsoftbrasil_mp.shtml

Gosta do Firefox? Colabore com o Firefox Download Day!

A Mozilla costuma usar alternativas sociais para divulgação, diferentemente de anúncios ou eventos tradicionais. O tema da vez vem com o objetivo de bater o record de downloads num único dia, e entrar para o Guinness Book - o livro dos recordes.

Para isso lançaram o Firefox Download Day 2008, que será no dia do lançamento oficial do Firefox 3.0 (ainda não divulgado). Os interessados em "colaborar" devem se inscrever em:

http://www.spreadfirefox.com/en-US/worldrecord/

E receberão por e-mail uma mensagem com o dia do download, assim que estiver chegando. O que fazer? Nada mais nada menos do que simplesmente baixar o Firefox 3 no dia do seu lançamento. Estão disponíveis também banners e botões para entusiastas que têm sites ou blogs ajudarem na divulgação.

Segundo mapa publicado na página do "evento", muitos países já têm vários membros inscritos: aproximadamente 92 mil nos EUA, 16 mil na Rússia e também no Canadá, e 42 mil no Brasil - sem contar os outros países, claro. O total de inscritos até hoje de manhã está na faixa dos 580 mil.

Talvez pareça bobeira, mas a Mozilla gosta de contar com a força da comunidade fã dos seus produtos. Com doações, ela já conseguiu um anúncio de duas páginas cheias no jornal norte-americano New York Times, durante o lançamento do Firefox 1.0 (em 2004), e também conquistou um molde do logotipo do Firefox numa plantação nos EUA. Se você perdeu na época, veja:

O anúncio no New York Times:

http://www.mozilla.org/press/mozilla-2004-12-15.html

O logo numa plantação, nos Estados Unidos:

http://maps.google.com/?[...]spn=0.012112,0.024097&t=h

Verificador de regras de codificação para GCC

Guillem Marpons anunciou uma ferramenta de verificação de código para o GCC, que visa validar a estrutura do código dos programas baseando-se em algumas regras.

Seguindo o contexto do projeto GlobalGCC, a ferramenta visa tornar os códigos mais legíveis e de fácil manutenção, em linguagens como C e C++. Isso é importante especialmente em projetos com muitos desenvolvedores (como software livre), onde várias pessoas mexem no código. Uma organização deve se manter, seguindo as normas da linguagem em uso - o que nem sempre acontece quando o código é visto e compilado por um único programador.

Há mais informações sobre essas regras nesta página:

http://www.ggcc.info/?q=codingrules

A ferramenta será apresentada em algumas semanas no GCC Developers Summit 2008, e pode ser baixada e testada seguindo as instruções disponíveis em:

http://www.ggcc.info/files/README-codingrules.txt

No momento, somente informações estruturais são checadas (classes, herança, métodos, variáveis, etc). No decorrer do desenvolvimento, o projeto visa obter informações também dos front-ends, como templates, recursos estáticos, etc.

Leia o anúncio oficial em:

http://lwn.net/Articles/284112/