O Mapa Interativo do Kernel Linux

O kernel do Linux é um dos projetos open source mais complexos. Há muitos livros sobre o kernel, é complicado entendê-lo e "desmontá-lo".

Uma página com um mapa interativo do kernel dá uma visão de como ele se estrutura. Você pode ver as camadas mais importantes, funcionalidades, módulos, funções e chamadas. Cada função no mapa é um link para o código do objeto em questão.

Veja em:

http://www.makelinux.net/kernel_map

O mapa é interativo, você pode aplicar zoom e arrastá-lo pela página para ver melhor a área que lhe interessa.

Via osnews.com

Mais um concorrente para o iPhone: Samsung i900 Omnia

A Samsung lançou um novo rival do iPhone, no mesmo dia em que o iPhone possivelmente ganharia uma nova edição, o iPhone 3G.

O i900 Omnia da Samsung é um telefone touchscreen com sistema Windows Mobile 6.1. Usa o Opera como navegador, no lugar do IE, assim como o HTC Touch Pro e Touch Diamond.

A tela de 3,2 polegadas (240x400 pixels) ocupa quase todo o aparelho. Ele vem com um trackpad pequenininho, que ajuda quando os botões na tela forem muito pequenos para clicar com o dedo, além de um accelerometer (ainda raro em dispositivos com Windows Mobile), que gira automaticamente a tela quando o aparelho é deitado. O aparelho é quad-band (850/900/1800/1900 MHz), suportanto tanto WCDMA quanto GSM, além de acessar redes HSDPA e EDGE.

Há uma versão com 8 GB e outra com 16 GB de memória flash para armazenamento interno, além de um slot microSD, permitindo usar mais 8 GB de espaço extra. Traz uma câmera de 5 megapixel com software de detecção de face e sorriso, além de auto-foco. O acesso a Internet pode se dar em até 7.2 Mbps HSDPA em redes 3G suportadas, e via Wi-Fi para outras áreas. Traz ainda um sintonizador FM, Bluetooth e GPS.

A Samsung planejava disponibilizá-lo já em junho, coincidindo com uma nova versão do iPhone. Na Europa, deverá chegar comercialmente entre julho e agosto. Não há previsão de data para lançamento em outras regiões ainda.

O aparelho será apresentado formalmente na feira Communicasia, em Cingapura, na próxima semana.

Referências:

http://www.electronista.com/articles/08/06/09/samsung.i900.omnia/

http://idgnow.uol.com.br/[...]samsung-anuncia-omnia-novo-rival-para-iphone/

Microsoft lança Silverlight 2 beta 2

A Microsoft publicou o beta 2 do Silverlight 2, seu concorrente do Flash. O instalador da versão cliente para Windows tem 4,66 MB, e para Mac (com processador Intel), 6,65 MB.

O Silverlight 2 beta 2 está disponível para os seguintes navegadores:

• IE7 no Windows Vista ou XP SP2
• IE6 no Windows XP SP2 ou 2000
• Firefox 2 e 1.5, no Vista ou XP SP2
• Safari no Mac OS 10.4.8+ (com processador Intel)

Há várias mudanças nessa nova versão. Algumas delas são:

• Foi adicionado o controle TabControl ao SDK. Também há quebra de linha automática e barras de rolagem para TextBox (campos de texto), e Autosize, Reorder e Sort foram adicionados no DataGrid.
• Vários controles foram movidos do SDK (a aplicação) para o ambiente de runtime, e outros ficaram compatíveis com os correspondentes no Windows Presentation Foundation (WPF). Desenvolvedores que visam tanto o Silverlight como o WPF terão vantagens, podendo aproveitar mais o código das aplicações.
• A modelagem de controles foi simplificada com a introdução do Visual State Manager.
• O WebClient permite uploads, e comunicações duplex ('push' do servidor para o Silverlight).
• O Deep Zoom recebeu uma grande atualização: agora o formato é baseado em XML, em vez de um formato binário. Isso facilita a manipulação e geração das imagens e coleções do lado do servidor.

A versão final do SilverLight 2 é esperada para depois do verão norte-americano, ou seja, daqui alguns meses.

Para muitos, o Silverlight é um projeto desnecessário, visto que o Flash reina em conteúdo interativo e multimídia online há muito tempo. A tentativa da MS de combater a aplicação da Adobe pode dar certo ou não. Certamente um longo tempo se passará até que várias aplicações web usem seu formato de conteúdo para web, o que justificaria a instalação do Silverlight nos inúmeros computadores dos usuários. Além do que Linux é algo que a MS ainda foge um pouco, evitando falar. Naturalmente o Silverlight deverá ter edições para diversos sistemas, se quiser ser algo realmente competitivo.

Página do projeto:

http://silverlight.net/GetStarted/

Documentação SDK, para desenvolvedores:

http://www.microsoft.com/downloads/details.aspx?FamilyID=bce7684a-507b-4fc6-bc99-6933cd690cab

Log de alterações completo:

http://blogs.msdn.com/silverlight_sdk/archive/2008/06/04/what-s-new-in-silverlight-2-beta-2.aspx

Fonte:

http://arstechnica.com/journals/microsoft.ars/2008/06/06/silverlight-2-beta-2-arrives-on-time-available-now

Debian repensando o gerenciamento de patches

Debian contemplates patch management

Autor original: Jonathan Corbet

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

Tradução: Roberto Bechtlufft

Os desenvolvedores do projeto Debian tiveram uma semana de muito trabalho limpando a casa depois que a vulnerabilidade do openssl foi anunciada. Depois que o problema foi resolvido, o Debian parou para repensar seus procedimentos. Obviamente, alguns furos na maneira como o Debian lida com os patches de seus programas vieram à tona, e agora o projeto gostaria de encarar o problema e melhorar as coisas no futuro. A discussão que se originou daí mostra um Debian mais introspectivo, e pode surtir efeitos aos quais as outras distribuições devem ficar atentas. Como disse um desenvolvedor do Fedora: "esse bug poderia ter nos atingido facilmente." Todos os distribuidores fazem alterações em seus pacotes, e todos estão potencialmente expostos a esse tipo de falha.

A política de empacotamento do Debian lembra a de muitas outras distribuições. Um pacote fonte do Debian supostamente inclui um tarball (um arquivo .tar compactado) contendo o código fonte original, sem alterações, do upstream (que é a entidade de origem do programa, como o projeto openssl, por exemplo). Quaisquer patches específicos da distribuição são incluídos separadamente e aplicados quando o pacote fonte é preparado para a compilação. Mas há algumas questões específicas do Debian a serem resolvidas:

• Pelo que se tem ouvido da discussão, parece que a regra do "tarball cristalino do upstream" volta e meia é quebrada pelos desenvolvedores. Às vezes não há opção: algumas distribuições de código do upstream contêm material que, devido a questões de licença, não pode ser empacotado pelo Debian. A justificativa para os outros casos já não é tão clara.

• Os patches do Debian são todos postos juntos em um único arquivo diff. Por isso, não há metadados descrevendo os patches, e é difícil separá-los uns dos outros. Nesse sentido, o Debian difere de outras distribuições baseadas no RPM, que costumam manter os patches separados.

O resultado é que é complicado para os outros revisar os patches do Debian, é complicado para o projeto upstream avaliar as mudanças e é mais complicado ainda para os desenvolvedores do Debian lidar com tudo isso.

Raphaël Hertzog deu início a um debate sobre como melhorar essa situação. Uma parte importante da abordagem dele (uma idéia que também é apoiada por outros) é fazer alterações ao formato de pacotes do Debian para tornar mais explícita a natureza de cada patch. Os empacotadores deveriam, no mínimo, incluir um diretório debian/patches junto com os fontes, e esse diretório conteria cada patch, em arquivos separados. Alguns pacotes do Debian já são montados assim, mas a prática está longe de ser universal.

Além disso, seria ótimo se o pacote fonte "entendesse" o patch e seus metadados. Já há propostas para que isso se realize: Raphaël apóia o formato "3.0 (quilt)," que mantém os patches (em um tarball separado) como uma série do quilt. O formato parece ter bastante apoio; dentre outras coisas, sua simplicidade facilitaria a criação de pacotes nesse formato pelos desenvolvedores do Debian, sem que eles precisassem aprender a usar novas ferramentas. O arquivo de série do quilt - como o arquivo spec usado em pacotes RPM - deixa claro quais patches devem ser aplicados, e em qual ordem.

Mas há outras variantes do formato de pacotes fontes 3.0. O formato "3.0 (git)" contém um repositório git com o código fonte do upstream e uma série de patches. Essa abordagem tem a vantagem de incluir um histórico de patches com os metadados. Ela também poderia, quem sabe, fazer com que outros distribuidores (incluindo o upstream) selecionassem com mais facilidade os patches interessantes. Por outro lado, um formato de pacotes baseado no git exige a disponibilidade do git e tem grandes chances de aumentar o tamanho dos pacotes. O FAQ do GitSrc tem mais informações sobre o formato; também há outra variante do formato, o "3.0 (bzr)".

Qualquer dos novos formatos, se adotado em larga escala, traria um novo nível de transparência às atividades com patches do Debian. Isso permitiria a criação de um site "patches.debian.org" (claramente inspirado no patches.ubuntu.com), onde qualquer um poderia dar uma rápida olhada nas alterações realizadas em um pacote específico. Alguns desenvolvedores acham que não há muita utilidade nisso. Eles temem que os desenvolvedores do upstream não se interessem em usar um site para verificar as alterações feitas ao código. No entanto, ao menos um desenvolvedor (o hacker do GNOME, Vincent Untz) acredita que o site patches.debian.org seria um passo na direção certa.

Também há gente dizendo que o Debian não precisa de uma nova infra-estrutura de gerenciamento de patches. Alguns dizem que o local adequado para se acompanhar patches é no projeto upstream. Ninguém parece duvidar que mais patches devem voltar ao upstream, mas é preciso considerar que muitos patches jamais voltarão para lá. Os desenvolvedores upstream de vários projetos têm objetivos diferentes e são vistos pelos mantenedores das distribuições como avessos à cooperação. E alguns patches - como os que removem material não livre - podem não ser desejados nem pelos mantenedores cooperativos. Por isso sempre haverá a necessidade de patches específicos para cada distribuição. A abordagem "acompanhe pelo upstream" não vai resolver o problema.

Enquanto isso, Joey Hess trouxe uma idéia completamente diferente à mesa: tratar qualquer divergência do upstream como um bug. Cada patch teria uma entrada correspondente no BTS (sistema de rastreamento de bugs) do Debian, com uma tag especial. Qualquer um poderia listar esses bugs, exibir os patches e participar na discussão associada a eles. O uso do BTS oferece algumas vantagens técnicas reais, uma vez que o sistema já existe. Mas, como disse Joel, o maior benefício é outro.

A maior razão para se usar o BTS não é técnica. É que, se decidirmos que o projeto deve tratar divergências do upstream como bugs, é porque decidimos efetivamente que os mantenedores são responsáveis por minimizar divergências desnecessárias, comunicá-las ao upstream e acompanhar as divergências existentes. Afinal, os desenvolvedores são responsáveis por seus bugs.

Um mecanismo de rastreamento de patches, pelo contrário, seria em grande parte um subsistema automático em um lado que não exerceria o mesmo tipo de pressão sobre os desenvolvedores.

Mas a abordagem do BTS também não é uma unanimidade. Alguns desenvolvedores afirmam que a maioria dos patches específicos do Debian não são bugs do Debian, mas sim bugs do upstream. Quer isso seja verdade ou não, rastreadores de bugs de distribuições geralmente trazem várias entradas que, no fim das contas, descrevem bugs nos pacotes upstream. Outra reclamação é que a criação e a manutenção de entradas no BTS seria mais um trabalho burocrático imposto aos desenvolvedores do Debian. Sem dúvida, alguns desenvolvedores vão encarar desta forma.

Mas pode ser que nesse ponto mais burocracia faça sentido. Os distribuidores de Linux de todo o mundo (e não apenas os do Debian) aplicam milhares de patches nos programas livres que distribuem. Tornar mais explícita a natureza e o impacto desses patches só pode favorecer a usuários, revisores, distribuidores e mantenedores do upstream. Uma clara conclusão à qual se chega com os eventos recentes é a de que todos os distribuidores podem se esforçar mais para informar à comunidade sobre as alterações que promovem.

A habilidade de um programador de aplicar patches a um programa é parte crucial do ecossistema - é a maneira do distribuidor balancear as necessidades dos usuários com as políticas dos mantenedores do upstream. Mas os distribuidores precisam ser mais claros quanto às mudanças que estão fazendo, estar dispostos a devolver essas mudanças ao upstream sempre que possível, e cobrar o feedback do upstream sobre os patches. Qualquer "burocracia" que ajude a realizar isso vai ajudar à comunidade de um modo geral, de maneiras que extrapolam a simples prevenção de outro desastre com o do openssl.

Uma última observação: a existência de formatos de pacotes fontes que incorporam repositórios de sistemas de controle de versão distribuído mostram que os desenvolvedores já pensam no problema há algum tempo. Isso não é meramente uma resposta aos eventos recentes. Há um projeto discutindo os reais benefícios que a interseção entre um controle de versão e o empacotamento pode trazer aos distribuidores. O projeto pode ser encontrado em vcs-pkg.org. Eles estão trabalhando na organização de um evento em setembro em Extremadura. Vale à pena acompanhar o vcs-pkg. Ele tem potencial para melhorar as coisas para usuários e desenvolvedores de todas as distribuições.

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

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

Lançado DamnSmall Linux 4.4

Foi anunciada uma nova versão final, a 4.4, de uma das menores e mais leves distribuições Linux baseadas em Debian do mundo, o Damn Small Linux. Entre as novidades, estão: novo Lua/Fltk refeito para melhor desempenho; nova biblioteca Fltj, agora disponível para programas C/C++; novo fldiff, uma interface gráfica para o diff; atualização do rsync para versão 3.0.2; navegador mydslBrowser atualizado, agora com o recurso "Somente baixar"; aplicativo 'X Window Snapshot' modificado para salvar a imagem com a data; adicionada associação dfm para os arquivos do 'X Window Snapshot'; motores de busca do Firefox restaurados ao padrão; novo tema e papel de parede para baixos recursos; nova fonte adicionada, a smoothansi, usada no menu do JWM; novo .luafltkrc para o tema Lua/Fltk; dmix atualizado; nfs-commom atualizado para também inicializar o Portmap quando necessário; kbdconfig corrigido para exibir mapas de caracteres corretos; .bash_profile modificado para eliminar o login extra no shell; dentre outras inúmeras novidades.

Fonte:

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

Lista completa de alterações:

http://www.damnsmalllinux.org/notes.html

Download:

http://www.damnsmalllinux.org/download.html

Link direto: ftp://ftp.belnet.be/packages/damnsmalllinux/current/dsl-4.4.iso (49.7 MB, MD5)

Asus exibe o Eee Box, uma versão desktop do Eee PC

Pegando embalo na onda de notebooks ultraportáteis dos últimos tempos, a Asus não fica só no Eee PC. Na feira Computex, que ocorre em Taipei durante essa semana, ela apresentou seu Eee Box - uma "versão desktop" do Eee PC.

O Eee Box B202 tem apenas 25 mm de espessura (medindo 216 x 178 mm em largura/altura). Usa o processador Atom 280 da Intel, a versão desktop do N270, que é usado nos laptops Eee.

A maquininha vem com 1 GB de memória RAM DDR2 e HD de 80 GB; usa o chipset 945GSE da Intel. Vem também com interface de rede Gigabit Ethernet e Wi-Fi 802.11n - há uma antena externa que pode ser plugada numa porta atrás do "gabinete".

Diferentemente do Eee PC, o Eee Box tem uma porta DVI em vez de VGA, além de duas portas USB. Alguns modelos terão Bluetooth onboard também, segundo a Asus. Possivelmente terão versões em algumas cores diferentes.

Aparentemente ele será comercializado no começo de julho, pelo menos na Ásia - por NT$9888 (cerca de $326 dólares).

Outro PC compacto recente da Asus é o Mini PC Nova Lite PX24, com suporte total a vídeos HD, como você pode ver nesta notícia aqui no GdH.

Fonte:

http://www.reghardware.co.uk/2008/06/06/asus_shows_eee_box_b202/

Fonte das imagens:

http://www.hkepc.com/?id=1263&fs=c3nh

Artigo: O que fazer com o BasicLinux

A evolução gráfica e prática do Linux se iniciou de forma mais rápida há relativamente pouco tempo, já que antes, era um sistema operacional voltado mais para a parte técnica. Não obstante, muitos hoje preferem o Linux "da forma que veio ao mundo" para cumprir apenas funções básicas e rodar em micros antigos, que não necessitem de utilitários e interfaces gráficas com design avançado, e sim da boa e velha linha de comando aliada a interfaces simples e funcionais que gastem o mínimo de memória RAM; tudo unido a um pacote que contém o essencial dos aplicativos. Aprofundando mais sobre este tema, Sergio Teixeira postou um artigo chamado "O que fazer com o BASIC LINUX" no site Viva o Linux. Leia a descrição:

"Desta vez vamos tratar daquilo que podemos e/ou não podemos fazer com esse "sabor" da GNU/Linux. Ele vem em diversas versões, sendo que de forma estranha, uma não é necessariamente "atualização" da outra como poderíamos imaginar, mas cada uma cumpre com uma finalidade diferente."

E um trecho (conclusão): "O Basic Linux trabalha em rede, o que é evidente, por tratar-se de um Linux. Dizer isso é até mesmo uma redundância. (...) Basic Linux foi desenvolvido para ser leve, prático e extremamente rápido, não para ser necessariamente bonito ou completo. Por consumir muito pouca memória, dificilmente precisaremos de uma 'swap', mas nada nos impede de implementá-la; seu tamanho segue a 'regra geral' para PCs de RAM reduzida. Então ideal será o dobro da memória já instalada.

Tenha-se em mente que o BASIC LINUX também não foi feito para ser parecido com o Windows. Atende porém às necessidades normais de computação de um usuário mediano, mas não dos "top users". Sendo uma distribuição minimalista, as coisas não vêm prontas, mastigadas; temos de personalizar nossa instalação. E se por um lado isso pode ser um tremendo incômodo, por outro lado nos dá a chance de entender melhor o seu funcionamento, suas particularidades, e as pequenas diferenças com relação a outras distros.(...)"

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

1. Em que máquinas posso instalar o BASIC LINUX?
2. O que podemos fazer em um 486 DX com 16mb ram?
3. O que podemos fazer com um Pentium I ou II com 32mb ram
4. O que não posso fazer com o BASIC LINUX?
5. Observações finais

Veja o artigo completo em:

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

Novo algoritmo reconhece imagens diminuindo sua resolução

Um novo algoritmo desenvolvido por pesquisadores do MIT promete revolucionar áreas como de visão artificial e identificação de imagens online por conteúdo, além de também servir para que robôs tenham um sistema de visão mais parecido com o humano. Ao contrário do que mundos pensavam, os cientistas provaram que é necessária uma pequena quantidade de pixels para a identificação de um objeto ou imagem.

Pensando neste assunto, foi publicada a notícia "Novo algoritmo reconhece imagens diminuindo sua resolução", no site "Inovação Tecnológica":

"Observe, por exemplo, a imagem [abaixo]. Dentro dos círculos vermelhos, você consegue ver uma garrafa, um telefone celular, uma pessoa e um sapato?

Na verdade, em todas elas, o que está dentro do círculo vermelho é o mesmo sapato. Os pesquisadores utilizaram esta imagem para demonstrar como o contexto afeta nossa percepção dos objetos. Algo com que o novo algoritmo consegue lidar."

Veja a notícia original em:

http://www.inovacaotecnologica.com.br

Comente em: http://www.hardware.com.br/comunidade/algoritmo-imagens/873900/

Via lança Mini-ITX 2.0

A Via lançou a nova plataforma Mini-ITX 2.0, a mais recente voltada para mini-PCs. Estas placas-mãe são projetadas para permitir pequenos e "quietos" sistemas usando processadores como o Via Nano, com direito até a slot PCI Express 2.0; isso permite a instalação de uma placa de vídeo rápida, praticamente garantindo suporte para jogos e outros aplicativos que necessitem do DirectX 10 ou OpenGL 2, além do fato da placa já possuir um chipset onboard compatível com DirectX 9.

A atualização da série Mini-ITX permite certa customização por parte dos fabricantes de PC para a produção de diferentes dispositivos, além de oferecer um determinado padrão para os que não possuem essa preocupação. A placa terá suporte para pelo menos 2 GB de RAM, saída VGA e HDMI, áudio 5.1 canais e Gigabit Ethernet; na parte de expansões, temos pelo menos dois conectores Serial ATA II, um Pararell ATA, e no mínimo quatro portas USB. A novidade também será capaz de rodar Windows Vista e XP, bem como várias distribuições Linux. A Mini-ITX 2.0 estará disponível, bem como os produtos que a usam, ainda este ano.

Fonte:

http://www.electronista.com/articles/08/06/05/via.mini.itx.20/

Gadgets do Google Desktop são open source para Linux

O Google disponibilizou o código fonte dos gadgets do Google Desktop para Linux. A idéia é permitir que a comunidade os termine e faça ajustes, colaborando com o projeto.

Depois de lançar o Google Desktop para Linux e adicionar recursos pedidos, como suporte a 64-bit e pesquisa nos arquivos (assim cono na versão para Windows), faltava o suporte aos gadgets.

Os gadgets são como "mini programas" que rodam na barra lateral adicionando funcionalidades, quase sempre baseados em atividades online.

O site ArsTechnica testou a compilação dos gadgets. Ainda não estão prontos para os usuários finais, mas para desenvolvedores Linux pode ser interessante.

Um dos destaques é o suporte tanto à GTK+ como Qt, permitindo estabilidade e otimização para os dois ambientes mais usados no Linux (respectivamente Gnome e KDE). O Google não está fornecendo os binários, apenas o código fonte e algumas instruções para a compilação. As dependências necessárias normalmente podem ser instaladas sem problemas, usando o gerenciador de pacotes da sua distro. Estão liberados sob a licença do Apache.

Leia mais em:

http://arstechnica.com/news.ars/post/20080605-google-gadgets-open-sourced-for-linux.html

Divulgação oficial:

http://google-opensource.blogspot.com/2008/06/google-gadgets-for-linux.html